一文讀懂 HTTP/2 特性

標籤：整數   blank   表示   spdy   頭資訊   https   分享   資料通訊   block   

HTTP/2 是 HTTP 協議自 1999 年 HTTP 1.1 發布後的首個更新，主要基於 SPDY 協議。由互連網工程工作群組（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小組進行開發。該組織於2014年12月將HTTP/2標準提議遞交至IESG進行討論，於2015年2月17日被批准。HTTP/2標準於2015年5月以RFC 7540正式發表。

那 HTTP/2 到底有哪些具體變化呢？

二進位分幀

先來理解幾個概念：

幀：HTTP/2 資料通訊的最小單位訊息：指 HTTP/2 中邏輯上的 HTTP 訊息。例如請求和響應等，訊息由一個或多個幀組成。

流：存在於串連中的一個虛擬通道。流可以承載雙向訊息，每個流都有一個唯一的整數ID。

HTTP/2 採用二進位格式傳輸資料，而非 HTTP 1.x 的文字格式設定，二進位協議解析起來更高效。 HTTP / 1 的請求和響應報文，都是由起始行，首部和實體本文（可選）組成，各部分之間以文本分行符號分隔。HTTP/2 將請求和響應資料分割為更小的幀，並且它們採用二進位編碼。

HTTP/2 中，同網域名稱下所有通訊都在單個串連上完成，該串連可以承載任意數量的雙向資料流。每個資料流都以訊息的形式發送，而訊息又由一個或多個幀組成。多個幀之間可以亂序發送，根據幀首部的流標識可以重新組裝。

多工

多工，代替原來的序列和阻塞機制。所有就是請求的都是通過一個 TCP串連並發完成。 HTTP 1.x 中，如果想並發多個請求，必須使用多個 TCP 連結，且瀏覽器為了控制資源，還會對單個網域名稱有 6-8個的TCP連結要求節流，如，紅色圈出來的請求就因網域名稱連結數已超過限制，而被掛起等待了一段時間：

在 HTTP/2 中，有了二進位分幀之後，HTTP /2 不再依賴 TCP 連結去實現多流並行了，在 HTTP/2中：

• 同網域名稱下所有通訊都在單個串連上完成。

• 單個串連可以承載任意數量的雙向資料流。

• 資料流以訊息的形式發送，而訊息又由一個或多個幀組成，多個幀之間可以亂序發送，因為根據幀首部的流標識可以重新組裝。

這一特性，使效能有了極大提升：

• 同個網域名稱只需要佔用一個 TCP 串連，消除了因多個 TCP 串連而帶來的延時和記憶體消耗。

• 單個串連上可以並行交錯的請求和響應，之間互不干擾。

• 在HTTP/2中，每個請求都可以帶一個31bit的優先值，0表示最高優先順序， 數值越大優先順序越低。有了這個優先值，用戶端和伺服器就可以在處理不同的流時採取不同的策略，以最優的方式發送流、訊息和幀。

伺服器推送

服務端可以在發送頁面HTML時主動推送其它資源，而不用等到瀏覽器解析到相應位置，發起請求再響應。例如服務端可以主動把JS和CSS檔案推送給用戶端，而不需要用戶端解析HTML時再發送這些請求。

服務端可以主動推送，用戶端也有權利選擇是否接收。如果服務端推送的資源已經被瀏覽器緩衝過，瀏覽器可以通過發送RST_STREAM幀來拒收。主動推送也遵守同源策略，伺服器不會隨便推送第三方資源給用戶端。

頭部壓縮

HTTP 1.1請求的大小變得越來越大，有時甚至會大於TCP視窗的初始大小，因為它們需要等待帶著ACK的響應回來以後才能繼續被發送。HTTP/2對訊息頭採用HPACK（專為http/2頭部設計的壓縮格式）進行壓縮傳輸，能夠節省訊息頭佔用的網路的流量。而HTTP/1.x每次請求，都會攜帶大量冗餘頭資訊，浪費了很多頻寬資源。

HTTP每一次通訊都會攜帶一組頭部，用於描述這次通訊的的資源、瀏覽器屬性、cookie等，例如

為了減少這塊的資源消耗並提升效能， HTTP/2對這些首部採取了壓縮策略：

• HTTP/2在用戶端和伺服器端使用“首部表”來跟蹤和儲存之前發送的鍵－值對，對於相同的資料，不再通過每次請求和響應發送；

• 首部表在HTTP/2的串連存續期內始終存在，由用戶端和伺服器共同漸進地更新;

• 每個新的首部鍵－值對要麼被追加到當前表的末尾，要麼替換表中之前的值。

例如：中的兩個請求， 請求一發送了所有的頭部欄位，第二個請求則只需要發送差異資料，這樣可以減少冗餘資料，降低開銷。

我們來看一個實際的例子，下面是用WireShark抓取的訪問google首頁的包： 

是是訪問 https://www.google.com/ 抓到的第一個請求的頭部，可以看到頭部的內容，總共佔用了437 bytes，我們選中頭部的cookie，可以看到cookie總共佔用了118 bytes。接下來我們看看第二個請求的頭部：

從可以看到，得益於頭部壓縮，第二個請求中cookie只佔用了1個位元組，我們來看看變化了的Accept欄位： 

由於Accept欄位與請求一中的內容不同，需要發送給伺服器，所以佔用了29 bytes。

相關推薦

瀏覽器和網路服務支援情況：http2支援清單

如何快速啟用HTTP2: 又拍雲文檔中心

HTTP/2 和 HTTP/1 速度對比：HTTP/2: the Future of the Internet

結語

HTTP/2的通過支援要求與響應的多工來減少延遲，通過壓縮HTTP首部欄位將協議開銷降至最低，同時增加對請求優先順序和伺服器端推送的支援。

參考資料：

1. Jerry Qu blog 中的HTTP/2專題;
2. 維基百科：HTTP/2
3. RFC 7540 – 超文字傳輸通訊協定 (HTTP)第2版（HTTP / 2）
4. FC 7541 – HPACK：HTTP / 2的頭壓縮
5. http2講解

一文讀懂 HTTP/2 特性