HTTP 2.0 協議詳解

一、HTTP 2.0：改進傳輸效能

HTTP 2.0 的主要目標是改進傳輸效能，實現低延遲和高輸送量。從另一方面看，HTTP 的高層協議語義並不會因為這次版本升級而受影響。所有HTTP 首部、值，以及它們的使用情境都不會變。 現有的任何網站和應用，無需做任何修改都可以在HTTP 2.0 上跑起來。不用為了利用HTTP 2.0 的好處而修改標記。HTTP 伺服器必須運行HTTP 2.0 協議，但大部分使用者都不會因此而受到影響。 二、HTTP2.0曆史及其與SPDY的淵源

SPDY 是Google開發的一個實驗性協議，於2009 年年中發布，主要目標是通過解決HTTP 1.1 中廣為人知的一些效能限制，來減少網頁的載入延遲 SPDY協議設定的目標 頁面載入時間（PLT，Page • Load Time）降低 50%； 無需網站作者修改任何內容； 把部署複雜性降至最低，無需變更網路基礎設施； 與開源社區合作開發這個新協議；

收集真實效能資料，驗證這個實驗性協議是否有效。

註：為了達到降低50% 頁面載入時間的目標，SPDY 引入了一個新的二進位分幀資料層，以實現多向請求和響應、優先次序、最小化及消除不必要的網路延遲，目的是更有效地利用底層TCP 串連； HTTP-WG（HTTP Working Group）在2012 年初把HTTP 2.0提到了議事議程，吸取SPDY 的經驗教訓，並在此基礎上制定官方標準 三、HTTP2.0深入探究

HTTP/2.0 應該滿足如下條件： 相對於使用TCP 的HTTP 1.1，• 使用者在大多數情況下的感知延遲要有實質上、可度量的改進； 解決 HTTP 中的“隊首阻塞”問題； 並行操作無需與伺服器建立多個串連，從而改進 TCP 的利用率，特別是擁塞控制方面； 保持 HTTP 1.1 的語義，利用現有文檔，包括（但不限於）HTTP 方法、狀態代碼、URI，以及首部欄位； 明確規定 HTTP 2.0 如何與 HTTP 1.x 互操作，特別是在中間介質上； 明確指出所有新的可擴充機制以及適當的擴充策略。 HTTP 2.0 致力於突破上一代標準眾所周知的效能限制，但它也是對之前1.x 標準的擴充，而非替代。之所以要遞增一個大版本到2.0，主要是因為它改變了用戶端與伺服器之間交換資料的方式，HTTP 2.0 增加了新的二進位分幀資料層 四、HTTP2.0設計和技術目標

HTTP/2.0 通過支援首部欄位壓縮和在同一串連上發送多個並發訊息，讓應用更有效地利用網路資源，減少感知的延遲時間。而且，它還支援伺服器到用戶端的主動推送機制。

二進位分幀層 HTTP 2.0 二進位分幀層，封裝HTTP 訊息並在用戶端與伺服器之間傳輸

HTTP2.0 將所有傳輸的資訊分割為更小的訊息和幀，並對它們採用二進位格式的編碼。

註：HTTPS 是二進位分幀的另一個典型樣本：所有HTTP 訊息都以透明的方式為我們編碼和解碼，不必對應用進行任何修改。HTTP2.0工作原理有點類似

流、訊息和幀 流：流是串連中的一個虛擬通道，可以承載雙向的訊息；每個流都有一個唯一的整數標識符（1、2…N）； 訊息：是指邏輯上的 HTTP 訊息，比如請求、響應等，由一或多個幀組成。 幀：HTTP 2.0 通訊的最小單位，每個幀包含幀首部，至少也會標識出當前幀所屬的流，承載著特定類型的資料，如 HTTP 首部、負荷，等等

HTTP 2.0 的所有幀都採用二進位編碼，所有首部資料都會被壓縮。 所有通訊都在一個 TCP 串連上完成。 HTTP 2.0 把HTTP協議通訊的基本單位縮小為一個一個的幀，這些幀對應著邏輯流中的訊息。相應地，很多流可以並行地在同一個TCP 串連上交換訊息

多向請求與響應

HTTP 2.0 中新的二進位分幀層突破了這些限制，實現了多向請求和響應：用戶端和伺服器可以把HTTP 訊息分解為互不依賴的幀，然後亂序發送，最後再在另一端把它們重新組合起來

圖中包含了同一個串連上多個傳輸中的資料流：用戶端正在向伺服器傳輸一個DATA 幀（stream 5），與此同時，伺服器正向用戶端亂序發送stream 1 和stream 3的一系列幀。此時，一個串連上有3 個請求/ 響應並行交換。

把HTTP 訊息分解為獨立的幀，交錯發送，然後在另一端重新組裝是HTTP 2.0 最重要的一項增強。這個機制會在整個Web 技術棧中引發一系列連鎖反應，從而帶來巨大的效能提升。

  * 可以並行交錯地發送請求，請求之間互不影響；  * 可以並行交錯地發送響應，響應之間互不干擾；  * 只使用一個串連即可並行發送多個請求和響應；  * 消除不必要的延遲，從而減少頁面載入的時間；  * 不必再為繞過 HTTP 1.x 限制而多做很多工作；

1 2 3 4 5 6 7 HTTP 2.0 的二進位分幀機制解決了HTTP 1.x 中存在的隊首阻塞問題，也消除了平行處理和發送請求及響應時對多個串連的依賴。

請求優先順序 把HTTP 訊息分解為很多獨立的幀之後，就可以通過最佳化這些幀的交錯和傳輸順序，每個流都可以帶有一個31 位元的優先值：0 表示最高優先順序；2的31次方-1 表示最低優先順序。 伺服器可以根據流的優先順序，控制資源分派（CPU、記憶體、頻寬），而在響應資料準備好之後，優先將最高優先順序的幀發送給用戶端。 HTTP 2.0 一舉解決了所有這些低效的問題：瀏覽器可以在發現資源時立即指派請求，指定每個流的優先順序，讓伺服器決定最優的響應次序。這樣請求就不必排隊了，既節省了時間，也最大限度地利用了每個串連。

每個來源一個串連 有了新的分幀機制後，HTTP 2.0 不再依賴多個TCP 串連去實現多流並行了。每個資料流都拆分成很多幀，而這些幀可以交錯，還可以分別優先順序。HTTP 2.0 串連都是持久化的，而且用戶端與伺服器之間也只需要一個串連即可。 
實驗表明，用戶端使用更少的串連肯定可以降低延遲時間。HTTP 2.0 發送的總分組數量比HTTP 差不多要少40%。 大多數HTTP 串連的時間都很短，而且是突發性的，但TCP 只在長時間串連傳輸大塊資料時效率才最高。HTTP 2.0 通過讓所有資料流共用同一個串連，可以更有效地使用TCP 串連。

流量控制 HTTP 2.0 為資料流和串連的流量控制提供了一個簡單的機制： 
流量控制基於每一跳進行，而非端到端的控制； 流量控制基於視窗更新幀進行，即接收方廣播自己準備接收某個資料流的多少位元組，以及對整個串連要接收多少位元組； 流量控制視窗大小通過 WINDOW_UPDATE 幀更新，這個欄位指定了流 ID 和視窗大小遞增值； 流量控制有方向性，即接收方可能根據自己的情況為每個流乃至整個串連設定任意視窗大小； 流量控制可以由接收方禁用，包括針對個別的流和針對整個串連。

伺服器推送

HTTP 2.0 新增的一個強大的新功能，就是伺服器可以對一個用戶端請求發送多個響應。伺服器向用戶端推送資源無需用戶端明確地請求。

HTTP 2.0 串連後，用戶端與伺服器交換SETTINGS 幀，藉此可以限定雙向並發的流的最大數量。因此，用戶端可以限定推送流的數量，或者通過把這個值設定為0 而完全禁用伺服器推送。

所有推送的資源都遵守同源策略。換句話說，伺服器不能隨便將第三方資源推送給用戶端，而必須是經過雙方確認才行。

PUSH_PROMISE：所有伺服器推送流都由PUSH_PROMISE 發端，伺服器向用戶端發出的有意推送所述資源的訊號。用戶端接收到PUSH_PROMISE 幀之後，可以視自身需求選擇拒絕這個流

幾點限制： 伺服器必須遵循請求- 響應的迴圈，只能藉著對請求的響應推送資源 PUSH_PROMISE 幀必須在返迴響應之前發送，以免用戶端出現競態條件。

首部壓縮（HPACK壓縮演算法，一邊用index mapping table壓縮，一邊編碼，這個table由靜態表和動態表組成）

http2.0會壓縮首部中繼資料：在用戶端和伺服器端使用“首部表”來跟蹤和儲存之前發送的索引值對，對於相同的資料，不再通過每次請求和響應發送；“首部表”在http2.0的串連存續期內始終存在，由用戶端和伺服器共同漸進地更新；每個新的首部索引值對要麼追加到當前表的末尾，要麼替換表中之前的值。

http2.0首部差異化傳輸

請求與響應首部的定義在HTTP2.0中基本沒有改變，只是所有首部鍵必須全部小寫，而且請求行要獨立為 :method、:scheme、:host、:path這些索引值對。

有效HTTP2.0升級與發現

大多數現代瀏覽器都內建有高效的後台升級機制，支援HTTP2.0的用戶端在發起新請求之前，必須能探索服務器及所有中間裝置是否支援HTTP2.0協議。有三種可能的情況： 通過TLS和ALPN發起新的HTTPS串連； 根據之前的資訊發起新的HTTP串連； 沒有之前的資訊而發起新的HTTP串連。

HTTPS 協商過程中有一個環節會使用ALPN（應用程式層協議協商）。減少網路延遲是HTTP 2.0 的關鍵條件，因此在建立HTTPS 串連時一定會用到ALPN協商。

通過常規非加密通道建立HTTP2.0串連需要多做一點工作。因為HTTP1.0和HTTP2.0都使用同一個連接埠（80），有沒有伺服器是否支援HTTP2.0的其他任何資訊，此時用戶端只能使用HTTP Upgrade機制通過協調確定適當的協議：

Upgrade: HTTP/2.0 ➊HTTP2-Settings: (SETTINGS payload) ➋HTTP/1.1 200 OK ➌HTTP/1.1 101 Switching Protocols ➍...

1 2 3 4 5

➊ 發起帶有HTTP 2.0 Upgrade 首部的HTTP 1.1 請求➋ HTTP/2.0 SETTINGS 淨荷的Base64 URL 編碼➌ 伺服器拒絕升級，通過HTTP 1.1 返迴響應➍ 伺服器接受HTTP 2.0 升級，切換到新分幀

1 2 3 4 HTTP2.0二進位分幀簡介

建立HTTP2.0串連後，用戶端與伺服器會通過交換幀來通訊，幀是基於這個新協議通訊的最小單位。所有幀都共用一個8位元組的首部，其中包含幀的長度、類型、標誌，還有一個保留位和一個31位的流標識符。

發起新流 在發送應用資料之前，必須建立一個新流並隨之發送相應的中繼資料，比如流優先順序、HTTP 首部等； 用戶端通過發送HEADERS幀來發起新流； 伺服器通過發送 PUSH_PROMISE 幀來發起推送流。

發送應用資料 建立新流並發送HTTP 首部之後，接下來就是利用DATA 幀。應用資料可以分為多個DATA 幀，最後一幀要翻轉幀首部的END_STREAM 欄位

HTTP 2.0 標準要求DATA 幀不能超過2的14次方-1（16383）位元組。長度超過這個閥值的資料，就得分幀發送。

HTTP2.0幀資料流分析 HTTP2.0在共用的串連上同時發送請求和響應

3 個流的 ID 都是奇數，說明都是用戶端發起的 伺服器發送的 stream 1 包含多個 DATA 幀，這是對用戶端之前請求的響應資料 伺服器在交錯發送 stream 1 的 DATA 幀和 stream 3 的 HEADERS 幀，這就是響應的多工。 用戶端正在發送 stream 5 的 DATA 幀，表明 HEADERS 幀之前已經發送過了。 針對HTTP2.0的最佳化建議

去掉對1.x的最佳化 每個來源使用一個串連，HTTP 2.0 通過將一個TCP 串連的輸送量最大化來提升效能。 去掉不必要的檔案合并和圖片拼接：HTTP 2.0，很多小資源都可以並行發送 利用伺服器推送：之前針對HTTP 1.x 而嵌入的大多數資源，都可以而且應該通過伺服器推送來交付。

雙協議應用策略 相同的應用代碼，雙協議部署 分離應用代碼，雙協議部署 動態HTTP 1.x和HTTP 2.0最佳化：某些自動化的Web 最佳化架構在響應請求時動態重寫交付的應用代碼（包括串連、拼合、分區，等等） 單協議部署

1.x與2.0的相互轉換

評估伺服器品質與效能 HTTP 2.0 伺服器必須理解流優先順序； HTTP 2.0 伺服器必鬚根據優先順序處理響應和交付資源； HTTP 2.0 伺服器必須支援伺服器推送； HTTP 2.0 伺服器應該提供不同推送策略的實現。

2.0與TLS

兩種可能出現ALPN 協商和TLS 終止的情況 TLS 串連可能會在 HTTP 2.0 伺服器上終止； TLS 串連可能會在上遊（如負載平衡器）上終止。

第一種情況要求HTTP 2.0 伺服器能夠處理TLS； 第二種情況建立一條加密通道，直接將非加密的HTTP 2.0 流發送到伺服器

負載平衡器、代理及應用伺服器 要在TLS 之上實現HTTP 2.0通訊，終端伺服器必須支援 ALPN； 儘可能在接近使用者的地方終止 TLS； 如果無法支援 ALPN，那麼選擇 TCP 負載平衡模式； 如果無法支援 ALPN 且 TCP 負載平衡也做不到，那麼就退而求其次，在非加密通道上使用HTTP 的Upgrade 流；