HTTP 協議入門

早上看了阮一峰老師寫的 " http 協議入門 "，總結一下。

一、http

http 協議（無狀態協議）是基於 tcp/ip 協議的應用層協議，規定了客戶端與服務端的通訊格式，一般用 80 埠。

無狀態：減少伺服器的 cpu 及記憶體資源的消耗。但是不對之前發生過的請求和響應的狀態進行管理。

解決方法：引入 cookie。客戶端首次傳送請求，收到響應報文內的叫做 set-cookie 的首部字段資訊，儲存 cookie，下次請求時，自動在請求報文中加入 cookie 值後傳送出去。伺服器端收到 cookie，檢查是從哪個客戶端發來的請求，對比記錄，得到之前的狀態資訊。

http 的缺點

為什麼不一直使用 https

因為與純文字通訊對比，加密通訊會消耗更多的 cpu 及記憶體資源。所以，非敏感資訊使用 http 通訊。

三、http/1.0

請求格式

回應格式

http/1.0 200 ok 　　//協議版本 + 狀態碼（status code） + 狀態描述

content-type: text/plain　　//回應的資料的格式，可以自定義型別
content-length: 137582
expires: thu, 05 dec 1997 16:00:00 gmt
last-modified: wed, 5 august 1996 15:55:28 gmt server: apache 0.84 hello world

缺點

每個 tcp 連線只能傳送乙個請求，傳送資料完成之後連線就關閉，如果還想請求其他的資源，必須重新建立新的 tcp 連線。

有的瀏覽器在請求的時候，使用 connection 字段，要求伺服器不關閉 tcp 連線，以便其他請求復用，伺服器同樣回應同樣的字段：

connection: keep-alive 

缺點

雖然可以同時傳送請求，但是伺服器的回應依然是按照次序進行的，所以可能造成 「 隊頭堵塞 」。

1、減少請求數

2、同時多開持久連線，每個請求分開在不同的 tcp 連線裡

小車廠 說：

引用王軍的發言：

阮老師，

您在管道機制中，提到http1.1已經支援管道機制；在同乙個tcp中，可以同時傳送多個請求；為什麼3.6缺點中卻又說，在同乙個tcp連線中，必須按照次序傳送請求，無法同時傳送？這不是自相矛盾嗎？

3.2 管道機制

1.1 版還引入了管道機制（pipelining），即在同乙個tcp連線裡面，客戶端可以同時傳送多個請求。這樣就進一步改進了http協議的效率。

舉例來說，客戶端需要請求兩個資源。以前的做法是，在同乙個tcp連線裡面，先傳送a請求，然後等待伺服器做出回應，收到後再發出b請求。管道機制則是允許瀏覽器同時發出a請求和b請求，但是伺服器還是按照順序，先回應a請求，完成後再回應b請求。

3.6 缺點

雖然1.1版允許復用tcp連線，但是同乙個tcp連線裡面，所有的資料通訊是按次序進行的。伺服器只有處理完乙個回應，才會進行下乙個回應。要是前面的回應特別慢，後面就會有許多請求排隊等著。這稱為"隊頭堵塞"（head-of-line blocking）。

在您說的裡面，應該是按照次序回應請求，而不是傳送請求。

個人理解。

http協議入門

1 http協議是什麼？有什麼作用？http協議 超文字傳輸協議 http，hypertext transfer protocol 是網際網路上應用最為廣泛的一種網路協議以www開頭的，必定遵守http協議 有以下三種特性 超文字 超文字效果，超文字內容 傳輸 雙向的傳輸 請求 響應 一問一答機制 ...

HTTP協議入門

http協議是hypertext transfer protocol超文字傳輸協議的縮寫。http協議屬於應用層協議，它構建在tcp和ip協議之上，處於tcp ip體系架構中的頂端，使用tcp ip協議來傳輸資料。這樣一來它就不必處理下層協議間諸如丟包補發 握手及資料的分段和重新組裝等。靈活 htt...

HTTP協議入門

rtt 往返時間，指乙個分組從客戶端傳送到伺服器，然後再返回到客戶端所需的時間，包括分組傳播時延 分組在中間路由器和交換機上的排隊時延以及分組處理時延。connection closeconnection close get 最為常用，用於請求伺服器的乙個物件 post 提交表單時使用，右圖請求資料...