深刻淺出：HTTP/2

概述

HTTP/2 的目的就是經過支持請求與響應的多路複用來減小延遲，經過壓縮HTTP首部字段將協議開銷降至最低，同時增長對請求優先級和服務器端推送的支持。爲達成這些目標，HTTP/2 還會給咱們帶來大量其餘協議層面的輔助實現，好比新的流量控制、錯誤處理和更新機制。上述幾種機制雖然不是所有，但倒是最重要的，全部Web開發者都應該理解並在本身的應用中利用它們。

HTTP/2 不會改動HTTP的語義。HTTP方法、狀態碼、URI及首部字段，等等這些核心概念一如往常。可是，HTTP/2 修改了格式化數據（分幀）的方式，以及客戶端與服務器間傳輸這些數據的方式。這兩點統帥全局，經過新的組幀機制向咱們的應用隱藏了全部複雜性。換句話說，全部原來的應用均可以沒必要修改而在新協議運行。這固然是好事。

下面咱們就來詳細介紹一下這些新的機制。

歷史及其與SPDY的淵源

SPDY是谷歌開發的一個實驗性協議，於2009年年中發佈，其主要目標是經過解決HTTP 1.1中廣爲人知的一些性能限制，來減小網頁的加載延遲。大體上，這個項目設定的目標以下：

• 頁面加載時間（PLT，Page Load Time）下降50%；

• 無需網站做者修改任何內容；

• 把部署複雜性降至最低，無需變動網絡基礎設施；

• 與開源社區合做開發這個新協議；

• 收集真實性能數據，驗證這個實驗性協議是否有效。

2012年，這個新的實驗性協議獲得了Chrome、Firefox和Opera的支持，不少大型網站（如谷歌、Twitter、Facebook）都對兼容客戶端提供SPDY會話。換句話說，SPDY在被行業採用並證實可以大幅提高性能以後，已經具有了成爲一個標準的條件。最終，HTTP-WG（HTTP Working Group）在2012年初把HTTP/2 提到了議事日程，吸收SPDY的經驗教訓，並在此基礎上制定官方標準。

走向HTTP/2

從那時起，SPDY 已經通過了不少變化和改進，並且在 HTTP/2 官方標準公佈以前，還將有不少變化和改進。在此，有必要回顧一下HTTP/2 宣言草稿，由於這份宣言明確了該協議的範圍和關鍵設計要求：

HTTP/2 應該知足以下條件：

• 相對於使用TCP的HTTP 1.1，用戶在大多數狀況下的感知延遲要有實質上、可度量的改進；

• 解決HTTP中的「隊首阻塞」問題；

• 並行操做無需與服務器創建多個鏈接，從而改進TCP的利用率，特別是擁塞控制方面；

• 保持HTTP 1.1的語義，利用現有文檔，包括（但不限於）HTTP方法、狀態碼、URI，以及首部字段；

• 明確規定HTTP/2 如何與HTTP 1.x互操做，特別是在中間介質上；

• 明確指出全部新的可擴展機制以及適當的擴展策略；

HTTP/2 特徵

二進制分幀層

HTTP/2 性能加強的核心，全在於新增的二進制分幀層（以下圖所示），它定義瞭如何封裝HTTP消息並在客戶端與服務器之間傳輸。

這裏所謂的「層」，指的是位於套接字接口與應用可見的高層HTTP API之間的一個新機制：HTTP的語義，包括各類動詞、方法、首部，都不受影響，不一樣的是傳輸期間對它們的編碼方式變了。HTTP 1.x以換行符做爲純文本的分隔符，而HTTP/2 將全部傳輸的信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼。

這樣一來，客戶端和服務器爲了相互理解，必須都使用新的二進制編碼機制：HTTP 1.x客戶端沒法理解只支持HTTP/2 的服務器，反之亦然。不過沒關係，現有的應用沒必要擔憂這些變化，由於客戶端和服務器會替它們完成必要的分幀工做。

首部壓縮

HTTP的每一次通訊都會攜帶一組首部，用於描述傳輸的資源及其屬性。在HTTP 1.x中，這些元數據都是以純文本形式發送的，一般會給每一個請求增長500～800字節的負荷。若是算上HTTP cookie，增長的負荷一般會達到上千字節。爲減小這些開銷並提高性能，HTTP/2會用 「HPACK」 算法來壓縮頭部數據。

「HPACK」算法是專門爲壓縮 HTTP 頭部定製的算法，與 gzip、zlib 等壓縮算法不一樣，它是一個「有狀態」的算法，須要客戶端和服務器各自維護一份「索引表」，也能夠說是「字典」（這有點相似 brotli），壓縮和解壓縮就是查表和更新表的操做。

• HTTP/2 在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵－值對，對於相同的數據，再也不經過每次請求和響應發送；

• 首部表在HTTP/2 的鏈接存續期內始終存在，由客戶端和服務器共同漸進地更新;

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

因而，HTTP/2 鏈接的兩端都知道已經發送了哪些首部，這些首部的值是什麼，從而能夠針對以前的數據只編碼發送差別數據，具體以下圖所示。

請求與響應首部的定義在HTTP/2 中基本沒有改變，只是全部首部鍵必須所有小寫，並且請求行要獨立爲:method 、:scheme 、:host 和:path 這些鍵－值對。

在前面的例子中，第二個請求只須要發送變化了的路徑首部（:path ），其餘首部沒有變化，不用再發送了。這樣就能夠避免傳輸冗餘的首部，從而顯著減小每一個請求的開銷。

通訊期間幾乎不會改變的通用鍵－值對（用戶代理、可接受的媒體類型，等等）只需發送一次。事實上，若是請求中不包含首部（例如對同一資源的輪詢請求），那麼首部開銷就是零字節。此時全部首部都自動使用以前請求發送的首部！

二進制幀

頭部數據壓縮以後，HTTP/2 就要把報文拆成二進制的幀準備發送。

HTTP/2 的幀結構有點相似 TCP 的段或者 TLS 裏的記錄，但報頭很小，只有 9 字節，很是地節省（能夠對比一下 TCP 頭，它最少是 20 個字節）。

二進制的格式也保證了不會有歧義，並且使用位運算可以很是簡單高效地解析。

幀開頭是 3 個字節的長度（但不包括頭的 9 個字節），默認上限是 2^14，最大是 2^24，也就是說 HTTP/2 的幀一般不超過 16K，最大是 16M。

長度後面的一個字節是幀類型，大體能夠分紅數據幀和控制幀兩類，HEADERS 幀和 DATA 幀屬於數據幀，存放的是 HTTP 報文，而 SETTINGS、PING、PRIORITY 等則是用來管理流的控制幀。

HTTP/2 總共定義了 10 種類型的幀，但一個字節能夠表示最多 256 種，因此也容許在標準以外定義其餘類型實現功能擴展。這就有點像 TLS 裏擴展協議的意思了，好比 Google 的 gRPC 就利用了這個特色，定義了幾種自用的新幀類型。

第 5 個字節是很是重要的幀標誌信息，能夠保存 8 個標誌位，攜帶簡單的控制信息。經常使用的標誌位有END_HEADERS表示頭數據結束，至關於 HTTP/1 裏頭後的空行（「\r\n」），END_STREAM表示單方向數據發送結束（即 EOS，End of Stream），至關於 HTTP/1 裏 Chunked 分塊結束標誌（「0\r\n\r\n」）。

報文頭裏最後 4 個字節是流標識符，也就是幀所屬的「流」，接收方使用它就能夠從亂序的幀裏識別出具備相同流 ID 的幀序列，按順序組裝起來就實現了虛擬的「流」。

流標識符雖然有 4 個字節，但最高位被保留不用，因此只有 31 位可使用，也就是說，流標識符的上限是 2^31，大約是 21 億。

流、消息和幀

新的二進制分幀機制改變了客戶端與服務器之間交互數據的方式（以下圖所示）。爲了說明這個過程，咱們須要瞭解HTTP/2 的兩個新概念。

• 流：已創建的鏈接上的雙向字節流。

• 消息：與邏輯消息對應的完整的一系列數據幀。

• 幀：HTTP/2 通訊的最小單位，每一個幀包含幀首部，至少也會標識出當前幀所屬的流。

全部HTTP/2 通訊都在一個鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。相應地，每一個數據流以消息的形式發送，而消息由一或多個幀組成，這些幀能夠亂序發送，而後再根據每一個幀首部的流標識符從新組裝。」

這簡簡單單的幾句話裏濃縮了大量的信息，咱們再重申一次。要理解HTTP/2 ，就必須理解流、消息和幀這幾個基本概念。

• 全部通訊都在一個TCP鏈接上完成。

• 流是鏈接中的一個虛擬信道，能夠承載雙向的消息；每一個流都有一個惟一的整數標識符（一、2...N）。

• 消息是指邏輯上的HTTP消息，好比請求、響應等，由一或多個幀組成。

• 幀是最小的通訊單位，承載着特定類型的數據，如HTTP首部、負荷，等等。

簡言之，HTTP/2 把HTTP協議通訊的基本單位縮小爲一個一個的幀，這些幀對應着邏輯流中的消息。相應地，不少流能夠並行地在同一個TCP鏈接上交換消息。

多向請求與響應

在HTTP 1.x中，若是客戶端想發送多個並行的請求以及改進性能，那麼必須使用多個TCP鏈接。這是HTTP 1.x交付模型的直接結果，該模型會保證每一個鏈接每次只交付一個響應（多個響應必須排隊）。更糟糕的是，這種模型也會致使隊首阻塞，從而形成底層TCP鏈接的效率低下。

HTTP/2 中新的二進制分幀層突破了這些限制，實現了多向請求和響應：客戶端和服務器能夠把HTTP消息分解爲互不依賴的幀（以下圖所示），而後亂序發送，最後再在另外一端把它們從新組合起來。

 

上包含了同一個鏈接上多個傳輸中的數據流：客戶端正在向服務器傳輸一個DATA幀（stream 5），與此同時，服務器正向客戶端亂序發送stream 1和stream 3的一系列幀。此時，一個鏈接上有3個請求/響應並行交換！

把HTTP消息分解爲獨立的幀，交錯發送，而後在另外一端從新組裝是HTTP/2 最重要的一項加強。事實上，這個機制會在整個Web技術棧中引起一系列連鎖反應，從而帶來巨大的性能提高，由於：

• 能夠並行交錯地發送請求，請求之間互不影響；

• 能夠並行交錯地發送響應，響應之間互不干擾；

• 只使用一個鏈接便可並行發送多個請求和響應；

• 消除沒必要要的延遲，從而減小頁面加載的時間；

• 沒必要再爲繞過HTTP 1.x限制而多作不少工做。

• ……

總之，HTTP/2 的二進制分幀機制解決了HTTP 1.x中存在的隊首阻塞問題，也消除了並行處理和發送請求及響應時對多個鏈接的依賴。結果，就是應用速度更快、開發更簡單、部署成本更低。

支持多向請求與響應，能夠省掉針對HTTP 1.x限制所費的那些腦筋和工做，好比拼接文件、圖片精靈、域名分區。相似地，經過減小TCP鏈接的數量，HTTP/2 也會減小客戶端和服務器的CPU及內存佔用。

請求優先級

把HTTP消息分解爲不少獨立的幀以後，就能夠經過優化這些幀的交錯和傳輸順序，進一步提高性能。爲了作到這一點，每一個流均可以帶有一個31比特的優先值：

• 0 表示最高優先級。
• 2³¹ -1表示最低優先級。

有了這個優先值，客戶端和服務器就能夠在處理不一樣的流時採起不一樣的策略，以最優的方式發送流、消息和幀。具體來說，服務器能夠根據流的優先級，控制資源分配（CPU、內存、帶寬），而在響應數據準備好以後，優先將最高優先級的幀發送給客戶端。

瀏覽器在渲染頁面時，並不是全部資源都具備相同的優先級：HTML文檔自己對構建DOM不可或缺，CSS對構建CSSOM不可或缺，而DOM和CSSOM的構建均可能受到JavaScript資源的阻塞（參見10.1節的附註欄「DOM、CSSOM和JavaScript」），其餘資源（如圖片）的優先級均可以下降。

爲加快頁面加載速度，全部現代瀏覽器都會基於資源的類型以及它在頁面中的位置排定請求的優先次序，甚至經過以前的訪問來學習優先級模式——好比，以前的渲染若是被某些資源阻塞了，那麼一樣的資源在下一次訪問時可能就會被賦予更高的優先級。

在HTTP 1.x中，瀏覽器極少能利用上述優先級信息，由於協議自己並不支持多路複用，也沒有辦法向服務器通告請求的優先級。此時，瀏覽器只能依賴並行鏈接，且最多隻能同時向一個域名發送6個請求。因而，在等鏈接可用期間，請求只能在客戶端排隊，從而增長了沒必要要的網絡延遲。理論上，HTTP管道能夠解決這個問題，只是因爲缺少支持而沒法付諸實踐。

HTTP/2 一舉解決了全部這些低效的問題：瀏覽器能夠在發現資源時當即分派請求，指定每一個流的優先級，讓服務器決定最優的響應次序。這樣請求就沒必要排隊了，既節省了時間，也最大限度地利用了每一個鏈接。

HTTP/2 沒有規定處理優先級的具體算法，只是提供了一種賦予數據優先級的機制，並且要求客戶端與服務器必須可以交換這些數據。這樣一來，優先值做爲提示信息，對應的次序排定策略可能因客戶端或服務器的實現而不一樣：客戶端應該明確指定優先值，服務器應該根據該值處理和交付數據。

在這個規定之下，儘管你可能沒法控制客戶端發送的優先值，但或許你能夠控制服務器。所以，在選擇HTTP/2 服務器時，能夠多留點心！爲說明這一點，考慮下面幾個問題。

• 若是服務器對全部優先值視而不見怎麼辦？

• 高優先值的流必定優先處理嗎？

• 是否存在不一樣優先級的流應該交錯的狀況？

若是服務器不理睬全部優先值，那麼可能會致使應用響應變慢：瀏覽器明明在等關鍵的CSS和JavaScript，服務器卻在發送圖片，從而形成渲染阻塞。不過，規定嚴格的優先級次序也可能帶來次優的結果，由於這可能又會引入隊首阻塞問題，即某個高優先級的慢請求會沒必要要地阻塞其餘資源的交付。

服務器能夠並且應該交錯發送不一樣優先級別的幀。只要可能，高優先級流都應該優先，包括分配處理資源和客戶端與服務器間的帶寬。不過，爲了最高效地利用底層鏈接，不一樣優先級的混合也是必需的。

有了新的分幀機制後，HTTP/2 再也不依賴多個TCP鏈接去實現多流並行了。如今，每一個數據流都拆分紅不少幀，而這些幀能夠交錯，還能夠分別優先級。因而，全部HTTP/2 鏈接都是持久化的，並且客戶端與服務器之間也只須要一個鏈接便可。

實驗代表，客戶端使用更少的鏈接確定能夠下降延遲時間。HTTP/2 發送的總分組數量比HTTP差很少要少40%。而服務器處理大量併發鏈接的狀況也變成了可伸縮性問題，由於HTTP/2 減輕了這個負擔。——HTTP/2.0 Draft 2」

每一個來源一個鏈接顯著減小了相關的資源佔用：鏈接路徑上的套接字管理工做量少了，內存佔用少了，鏈接吞吐量大了。此外，從上到下全部層面上也都得到了相應的好處：

• 全部數據流的優先次序始終如一；

• 壓縮上下文單一使得壓縮效果更好；

• 因爲TCP鏈接減小而使網絡擁塞情況得以改觀；

• 慢啓動時間減小，擁塞和丟包恢復速度更快。

大多數HTTP鏈接的時間都很短，並且是突發性的，但TCP只在長時間鏈接傳輸大塊數據時效率才最高。HTTP/2 經過讓全部數據流共用同一個鏈接，能夠更有效地使用TCP鏈接。

HTTP/2 不只可以減小網絡延遲，還有助於提升吞吐量和下降運營成本！

等一等，我聽你說了一大堆每一個來源一個TCP鏈接的好處，難道它就一點壞處都沒有嗎？有，固然有。

• 雖然消除了HTTP隊首阻塞現象，但TCP層次上仍然存在隊首阻塞（參見2.4節「隊首阻塞」）；

• 若是TCP窗口縮放被禁用，那帶寬延遲積效應可能會限制鏈接的吞吐量；

• 丟包時，TCP擁塞窗口會縮小。

上述每一點均可能對HTTP/2 鏈接的吞吐量和延遲性能形成不利影響。然而，除了這些侷限性以外，實驗代表一個TCP鏈接仍然是HTTP/2 基礎上的最佳部署策略：

目前爲止的測試代表，壓縮和優先級排定帶來的性能提高，已經超過了隊首阻塞（特別是丟包狀況下）形成的負面效果。

流量控制

在同一個TCP鏈接上傳輸多個數據流，就意味着要共享帶寬。標定數據流的優先級有助於按序交付，但只有優先級還不足以肯定多個數據流或多個鏈接間的資源分配。爲解決這個問題，HTTP/2 爲數據流和鏈接的流量控制提供了一個簡單的機制：

• 流量控制基於每一跳進行，而非端到端的控制；

• 流量控制基於窗口更新幀進行，即接收方廣播本身準備接收某個數據流的多少字節，以及對整個鏈接要接收多少字節；

• 流量控制窗口大小經過WINDOW_UPDATE 幀更新，這個字段指定了流ID和窗口大小遞增值；

• 流量控制有方向性，即接收方可能根據本身的狀況爲每一個流乃至整個鏈接設置任意窗口大小；

• 流量控制能夠由接收方禁用，包括針對個別的流和針對整個鏈接。

HTTP/2 鏈接創建以後，客戶端與服務器交換SETTINGS 幀，目的是設置雙向的流量控制窗口大小。除此以外，任何一端均可以選擇禁用個別流或整個鏈接的流量控制。

上面這個列表是否是讓你想起了TCP流量控制？應該是，這兩個機制其實是同樣的。然而，因爲TCP流量控制不能對同一條HTTP/2 鏈接內的多個流實施差別化策略，所以光有它本身是不夠的。這正是HTTP/2 流量控制機制出臺的緣由。

HTTP/2 標準沒有規定任何特定的算法、值，或者何時發送WINDOW_UPDATE 幀。所以，實現能夠選擇本身的算法以匹配本身的應用場景，從而求得最佳性能。

優先級能夠決定交付次序，而流量控制則能夠控制HTTP/2 鏈接中每一個流佔用的資源：接收方能夠針對特定的流廣播較低的窗口大小，以限制它的傳輸速度。

服務器推送

HTTP/2 新增的一個強大的新功能，就是服務器能夠對一個客戶端請求發送多個響應。換句話說，除了對最初請求的響應外，服務器還能夠額外向客戶端推送資源（以下圖所示），而無需客戶端明確地請求。

創建HTTP/2 鏈接後，客戶端與服務器交換SETTINGS 幀，藉此能夠限定雙向併發的流的最大數量。所以，客戶端能夠限定推送流的數量，或者經過把這個值設置爲0而徹底禁用服務器推送。

爲何須要這樣一個機制呢？

一般的Web應用都由幾十個資源組成，客戶端須要分析服務器提供的文檔才能逐個找到它們。那爲何不讓服務器提早就把這些資源推送給客戶端，從而減小額外的時間延遲呢？服務器已經知道客戶端下一步要請求什麼資源了，這時候服務器推送便可派上用場。事實上，若是你在網頁裏嵌入過CSS、JavaScript，或者經過數據URI嵌入過其餘資源，那你就已經親身體驗過服務器推送了。

把資源直接插入到文檔中，就是把資源直接推送給客戶端，而無需客戶端請求。在HTTP/2 中，惟一的不一樣就是能夠把這個過程從應用中拿出來，放到HTTP協議自己來實現，並且還帶來了以下好處：

• 客戶端能夠緩存推送過來的資源；

• 客戶端能夠拒絕推送過來的資源；

• 推送資源能夠由不一樣的頁面共享；

• 服務器能夠按照優先級推送資源。

全部推送的資源都遵照同源策略。換句話說，服務器不能隨便將第三方資源推送給客戶端，而必須是通過雙方確認才行。

有了服務器推送後，HTTP 1.x時代的大多數插入或嵌入資源的作法基本上也就過期了。惟一有必要直接在網頁中插入資源的狀況，就是該資源只供那一個網頁使用，並且編碼代價不大；除此以外，全部應用都應該使用HTTP/2 服務器推送。

 

參考文章 

• https://hpbn.co/http2/

• Web性能權威指南