1 簡介

HTTP是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫。HTTP協議用於從WWW伺服器傳輸超文字到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網路傳輸減少。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示(如文字先於圖形)等。HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端伺服器模型。HTTP是一個無狀態的協議。

1.1 工作流程

一次HTTP操作稱為一個事務，其工作過程可分為四步：

• 首先客戶機與伺服器需要建立連線。只要單擊某個超級連結，HTTP的工作開始。
• 建立連線後，客戶機發送一個請求給伺服器，請求方式的格式為：統一資源識別符號（URL）、協議版本號，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。
• 伺服器接到請求後，給予相應的響應資訊，其格式為一個狀態行，包括資訊的協議版本號、一個成功或錯誤的程式碼，後邊是MIME資訊包括伺服器資訊、實體資訊和可能的內容。
• 客戶端接收伺服器所返回的資訊通過瀏覽器顯示在使用者的顯示屏上，然後客戶機與伺服器斷開連線。 如果在以上過程中的某一步出現錯誤，那麼產生錯誤的資訊將返回到客戶端，有顯示屏輸出。對於使用者來說，這些過程是由HTTP自己完成的，使用者只要用滑鼠點選，等待資訊顯示就可以了。

1.2 HTTP協議特點

• 支援客戶/伺服器模式。支援基本認證和安全認證。
• 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
• 靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。 HTTP 0.9和1.0使用非持續連線：限制每次連線只處理一個請求，伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。HTTP 1.1使用持續連線：不必為每個web物件建立一個新的連線，一個連線可以傳送多個物件。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。

2 HTTP1.1的新機制

HTTP/1.1 版本釋出，只比 1.0 版本晚了半年。它進一步完善了 HTTP 協議，一直用到了20年後的今天，直到現在還是最流行的版本。

2.1 持久連線

1.1 版的最大變化，就是引入了持久連線（persistent connection），即TCP連線預設不關閉，可以被多個請求複用，不用宣告Connection: keep-alive。客戶端和伺服器發現對方一段時間沒有活動，就可以主動關閉連線。不過，規範的做法是，客戶端在最後一個請求時，傳送Connection: close，明確要求伺服器關閉TCP連線。

2.2 管道機制

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

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

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

為了避免這個問題，只有兩種方法：一是減少請求數，二是同時多開持久連線。這導致了很多的網頁優化技巧，比如合併指令碼和樣式表、將圖片嵌入CSS程式碼、域名分片（domain sharding）等等。如果HTTP協議設計得更好一些，這些額外的工作是可以避免的。

2.3 Content-Length欄位

一個TCP連線現在可以傳送多個迴應，勢必就要有一種機制，區分資料包是屬於哪一個迴應的。這就是Content-length欄位的作用，宣告本次迴應的資料長度。

Content-Length: 3295

上面程式碼告訴瀏覽器，本次迴應的長度是3295個位元組，後面的位元組就屬於下一個迴應了。

在1.0版中，Content-Length欄位不是必需的，因為瀏覽器發現伺服器關閉了TCP連線，就表明收到的資料包已經全了。

使用Content-Length欄位的前提條件是，伺服器傳送迴應之前，必須知道迴應的資料長度。對於一些很耗時的動態操作來說，這意味著，伺服器要等到所有操作完成，才能傳送資料，顯然這樣的效率不高。更好的處理方法是，產生一塊資料，就傳送一塊，採用"流模式"（stream）取代"快取模式"（buffer）。

因此，1.1版規定可以不使用Content-Length欄位，而使用"分塊傳輸編碼"（chunked transfer encoding）。只要請求或迴應的頭資訊有Transfer-Encoding欄位，就表明迴應將由數量未定的資料塊組成。

Transfer-Encoding: chunked

每個非空的資料塊之前，會有一個16進位制的數值，表示這個塊的長度。最後是一個大小為0的塊，就表示本次迴應的資料傳送完了。

2.3 其他改進

• 1.1版還新增了許多動詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。
• 另外，客戶端請求的頭資訊新增了Host欄位，用來指定伺服器的域名。有了Host欄位，就可以將請求發往同一臺伺服器上的不同網站，為虛擬主機的興起打下了基礎。

• 有相同愛好的可以進來一起討論哦：企鵝群號：1046795523

  學習視訊資料：http://www.makeru.com.cn/live/1392_1164.html?s=143793