HTTP不同版本主要特性異同分析

HTTP有很多版本，每個版本也有自身的差異性， 本文是對HTTP不同版本主要特性的一個概述和總結，希望能幫助大家。

HTTP1.0

早先1.0的HTTP版本，是一種無狀態、無連線的應用層協定.

HTTP1.0規定瀏覽器和伺服器保持短暫的連接，瀏覽器的每次請求都需要與伺服器建立一個TCP連接，伺服器處理完成後立即斷開TCP連線（無連線），伺服器不追蹤每個用戶端也不記錄過去的請求（無狀態）。

這種無狀態性可以藉助cookie/session機制來做身分認證和狀態記錄。而下面兩個問題就比較麻煩了。

首先，無連接的特性導致最大的效能缺陷就是無法重複使用連接。每次發送請求的時候，都需要進行一次TCP的連接，而TCP的連接釋放過程又是比較費事的。這種無連線的特性會使得網路的使用率非常低。

其次就是隊頭阻塞（head of line blocking）。由於HTTP1.0規定下一個請求必須在前一個請求回應到達之前才能發送。假設前一個請求回應一直不到達，那麼下一個請求就不發送，同樣的後面的請求也給阻塞了。

為了解決這些問題，HTTP1.1出現了。

HTTP1.1

對於HTTP1.1，不僅繼承了HTTP1.0簡單的特點，也克服了許多HTTP1 .0性能上的問題。

首先是長連接，HTTP1.1增加了一個Connection字段，透過設定Keep-Alive可以保持HTTP連接不斷開，避免了每次客戶端與伺服器請求都要重複建立釋放建立TCP連接，提高了網路的使用率。如果用戶端想要關閉HTTP連接，可以在請求頭中攜帶Connection: false來告知伺服器關閉請求。

其次，是HTTP1.1支援請求管道化（pipelining）。基於HTTP1.1的長連接，使得請求管線化成為可能。管線化使得請求能夠並行傳輸。舉個例子來說，假如回應的主體是一個html頁面，頁面中包含了很多img，這個時候keep-alive就起了很大的作用，能夠進行並行發送多個請求。 （客戶端依據網域名稱來向伺服器建立連接，一般PC瀏覽器會針對單一網域的伺服器同時建立6~8個連接，手機端一般控制在4~6個。客戶端能夠區分出每次請求的回應內容。

也就是說，HTTP

管道化可以讓我們把先進先出佇列從客戶端（請求佇列）遷移到服務端（回應佇列）。

如圖所示，客戶端同時發了兩個請求分別來取得html

和

css，假如說伺服器的css資源先準備就緒，伺服器也會先發送html再傳送css。 同時，管道化技術只是讓客戶端能夠往一個伺服器同時發送一組請求，假若客戶端想往這個相同的伺服器發起另一組請求，也必須等待上一組請求全部響應完畢。

可見，HTTP1.1

解決隊頭阻塞（

head of line blocking）還不徹底。同時「管道化」技術有各種各樣的問題，所以很多瀏覽器要么根本不支援它，要么就直接默認關閉，並且開啟的條件很苛刻...此外， HTTP1.1

也加入了

快取處理（強快取和協商快取[傳送門]），支援斷點傳輸，以及增加了Host欄位（使得一個伺服器能夠用來建立多個Web網站）。 HTTP2.0

HTTP2.0

的新功能大致如下：

二進位分幀

HTTP2.0

透過在應用層和傳輸層之間增加一個二進位分幀層，突破了

HTTP1.1的效能限制、改進傳輸效能。

可見，雖然HTTP2.0的協定和HTTP1.x協定之間的規範完全不同了，但實際上HTTP2.0並沒有改變HTTP1.x的語意。
簡單來說，HTTP2.0只是把原來HTTP1.x的header和body部分用frame重新封裝了一層而已。

多路復用（連接共享）

下面是幾個概念：

• 流（stream ）：已建立連線上的雙向位元組流。

• 訊息：與邏輯訊息對應的完整的一系列資料幀。

• 幀（frame）：HTTP2.0通訊的最小單位，每個訊框包含幀首部，至少也會標識出當前幀所屬的流（stream id）。

從圖中可見，所有的HTTP2.0通訊都在一個連線上完成，這個連接可以承載任意數量的雙向資料流。

每個資料流以訊息的形式發送，而訊息由一或多個訊框組成。這些訊框可以亂序發送，然後再根據每個訊框首部的流標識符（stream id）重新組裝。

舉個例子，每個請求是一個資料流，資料流以訊息的方式發送，而訊息又分為多個幀，幀首部記錄stream id用來標識所屬的資料流，不同屬的幀可以在連接中隨機混雜在一起。接收者可以依照stream id將訊框再歸屬到各自不同的請求當中去。

另外，多工（連線共用）可能會導致關鍵請求被阻塞。 HTTP2.0裡每個資料流都可以設定優先權和依賴，優先權高的資料流會被伺服器優先處理和傳回給客戶端，資料流還可以依賴其他的子資料流。

首部壓縮

在HTTP1.x中，首部元資料都是以純文字的形式發送的，通常會給每個請求增加500~800位元組的負載。

比如說cookie，預設情況下，瀏覽器會在每次要求的時候，把##​​#cookie附在header上面寄給伺服器. （由於cookie比較大且每次都重複發送，一般不儲存訊息，只是用來做狀態記錄和身分認證）

HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重複header 的傳輸，又減少了需要傳輸的大小。高效率的壓縮演算法可以很大的壓縮header，減少發送包的數量從而降低延遲。

伺服器推送

伺服器除了對最初請求的回應外，伺服器還可以額外的向客戶端推送資源，而無需客戶端明確的請求。

總結

HTTP1.0

• #無狀態、無連線

##HTTP1.1

#持久連線
請求管道化
增加快取處理
增加
• Host

  欄位、支援斷點傳輸等

HTTP2.0

二進位分幀
#多路復用（或連接共用）
首部壓縮
伺服器推送
相關推薦：

關於HTTP/2伺服器推送

PHP之實作HTTP認證

實例分析PHP實作模擬http請求的方法

以上是HTTP不同版本主要特性異同分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！