摘要：消息與邏輯請求或響應消息對應的完整的一系列幀。聲明數據流依賴關系指出，應盡可能先向父數據流分配資源，然后再向其依賴項分配資源。數據流應先于和獲得完整資源分配和應先于和獲得相同的資源分配和應基于其權重獲得比例分配。

轉載自 | 小米運維（公眾號 ID：MI-SRE）

HTTP/2 是現行 HTTP 協議（HTTP/1.x）的替代，但它不是重寫，HTTP 方法 / 狀態碼 / 語義都與 HTTP/1.x 一樣。不過，HTTP/2 修改了數據格式化（分幀）以及在客戶端與服務器間傳輸的方式。HTTP/2 基于 SPDY3，專注于性能，最大的一個目標是在用戶和網站間只用一個連接。

HTTP/2 通過支持完整的請求與響應復用來減少延遲，通過有效壓縮 HTTP 報頭字段將協議開銷降至最低，同時增加對請求優先級和服務器推送的支持。

HTTP/2 協議由以下兩個 RFC 組成：

RFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)； RFC 7541 -

HPACK: Header Compression for HTTP/2；

影響一個 HTTP 網絡請求的因素主要有兩個：帶寬和延遲。在當今的網絡情況下，帶寬一般不再是瓶頸，所以我們主要討論下延遲。延遲一般由下面幾個因素所造成：

瀏覽器線頭阻塞（Head-Of-Line Blocking）：瀏覽器會因為一些原因阻塞請求。

DNS 查詢。

建立連接（Initial connection）：HTTP 基于 TCP 協議，TCP 的 3 次握手和慢啟動極大增加延遲。

連接無法復用：
連接無法復用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大。

HTTP/1.0 傳輸數據時，每次都需要重新建立連接，增加延遲。

HTTP/1.1 雖然加入 keep-alive，可以復用一部分連接，但域名分片等情況下仍然需要建立多個 connection，耗費資源，給服務器帶來性能壓力。

線頭阻塞（Head-Of-Line Blocking）：
導致帶寬無法被充分利用，以及后續健康請求被阻塞。HOLB 是指在 HTTP/1.x 中，由于服務器必須按接受請求的順序發送響應的規則限制，那么假設瀏覽器在一個（tcp）連接上發送了兩個請求，那么服務器必須等第一個請求響應完畢才能發送第二個響應——HOLB。雖然現在瀏覽器允許每個 origin 建立 6 個 connection，但大量網頁動輒幾十個或上百個資源，HOLB 依然是主要問題。
協議開銷大：
HTTP/1.x 中 header 內容過大（每次請求 header 基本不怎么變化），增加了傳輸的成本。
安全因素：
在 HTTP 中傳輸的內容都是明文，客戶端和服務端雙方無法驗證身份。

連接復用：
在用戶和網站之間只用一個連接，避免后續建立連接過程中的幾個往返和慢啟動，同時減少了服務器的資源消耗。

沒有線頭阻塞：
采用新的二進制分幀層的機制，組成消息的幀可以亂序發送，幀到達對端重新組裝，不需要等待前面的幀到達后再發送。

報頭壓縮：
HTTP/2 協議中采用 HPACK 來壓縮請求頭和響應頭，降低協議開銷。

更加安全：
當前主流瀏覽器，都只支持基于 HTTPS 部署的 HTTP/2。

HTTP 2.0 性能增強的核心，全在于新增的二進制分幀層，它定義了如何封裝 HTTP 消息并在客戶端和服務器之間傳輸，和 HTTP/1.x 對比如下圖：

這里所謂的 “層”，指的是位于套接字接口與應用可見的高級 HTTP API 之間一個經過優化的新編碼機制：HTTP 的語義（包括各種動詞、方法、標頭）都不受影響，不同的是傳輸期間對它們的編碼方式變了。HTTP/1.x 協議以換行符作為純文本的分隔符，而 HTTP/2 將所有傳輸的信息分割為更小的消息和幀，并采用二進制格式對它們編碼。
這樣一來，客戶端和服務器為了相互理解，都必須使用新的二進制編碼機制：HTTP/1.x 客戶端無法理解只支持 HTTP/2 的服務器，反之亦然。不過不要緊，現有的應用不必擔心這些變化，因為客戶端和服務器會替我們完成必要的分幀工作。

新的二進制分幀機制改變了客戶端與服務器之間交換數據的方式。 為了說明這個過程，我們需要了解 HTTP/2 的三個概念：

數據流：已建立的連接內的雙向字節流，可以承載一條或多條消息。

消息：與邏輯請求或響應消息對應的完整的一系列幀。

幀：HTTP/2 通信的最小單位，每個幀都包含幀頭，至少也會標識出當前幀所屬的數據流。

這些概念的關系總結如下：

所有通信都在一個 TCP 連接上完成，此連接可以承載任意數量的雙向數據流。

每個數據流都有一個唯一的標識符和可選的優先級信息，用于承載雙向消息。

每條消息都是一條邏輯 HTTP 消息（例如請求或響應），包含一個或多個幀。

幀是最小的通信單位，承載著特定類型的數據，例如 HTTP 標頭、消息負載等等。 來自不同 數據流的幀可以交錯發送，然后再根據每個幀頭的數據流標識符重新組裝，如下圖：

簡言之，HTTP/2 將 HTTP 協議通信分解為二進制編碼幀的交換，這些幀對應著特定數據流中的消息。所有這些都在一個 TCP 連接內復用。這是 HTTP/2 協議所有其他功能和性能優化的基礎。

在 HTTP/1.x 中，如果客戶端要想發起多個并行請求以提升性能，則必須使用多個 TCP 連接。這是 HTTP/1.x 交付模型的直接結果，該模型可以保證每個連接每次只交付一個響應（響應排隊）。更糟糕的是，這種模型也會導致隊首阻塞，從而造成底層 TCP 連接的效率低下。
HTTP/2 中新的二進制分幀層突破了這些限制，實現了完整的請求和響應復用：客戶端和服務器可以將 HTTP 消息分解為互不依賴的幀，然后交錯發送，最后再在另一端把它們重新組裝起來。

上圖捕捉了同一個連接內并行的多個數據流。客戶端正在向服務器傳輸一個 DATA 幀（數據流 5），與此同時，服務器正向客戶端交錯發送數據流 1 和數據流 3 的一系列幀。因此，一個連接上同時有三個并行數據流。
將 HTTP 消息分解為獨立的幀，交錯發送，然后在另一端重新組裝是 HTTP 2 最重要的一項增強。事實上，這個機制會在整個網絡技術棧中引發一系列連鎖反應，從而帶來巨大的性能提升，讓我們可以：

并行交錯地發送多個請求，請求之間互不影響。

并行交錯地發送多個響應，響應之間互不干擾。

使用一個連接并行發送多個請求和響應。

不必再為繞過 HTTP/1.x 限制而做很多工作（對 HTTP/1.x 進行優化，例如級聯文件、image sprites 和域名分片。

消除不必要的延遲和提高現有網絡容量的利用率，從而減少頁面加載時間。

等等…

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

HTTP 1.1 的有一個缺點是：當一個含有確切值的 Content-Length 的 HTTP 消息被送出之后，你就很難中斷它了。當然，通常你可以斷開整個 TCP 連接（但也不總是可以這樣），但這樣導致的代價就是需要通過三次握手來重新建立一個新的 TCP 連接。
一個更好的方案是只終止當前傳輸的消息并重新發送一個新的。在 HTTP/2 里面，我們可以通過發送 RST_STREAM 幀來實現這種需求，從而避免浪費帶寬和中斷已有的連接。

將 HTTP 消息分解為很多獨立的幀之后，我們就可以復用多個數據流中的幀，客戶端和服務器交錯發送和傳輸這些幀的順序就成為關鍵的性能決定因素。為了做到這一點，HTTP/2 標準允許每個數據流都有一個關聯的權重和依賴關系：

可以向每個數據流分配一個介于 1 至 256 之間的整數。

每個數據流與其他數據流之間可以存在顯式依賴關系。

數據流依賴關系和權重的組合讓客戶端可以構建和傳遞 “優先級樹”，表明它傾向于如何接收響應。反過來，服務器可以使用此信息通過控制 CPU、內存和其他資源的分配設定數據流處理的優先級，在資源數據可用之后，帶寬分配可以確保將高優先級響應以最優方式傳輸至客戶端。

如上圖，HTTP/2 內的數據流依賴關系通過將另一個數據流的唯一標識符作為父項引用進行聲明；如果忽略標識符，相應數據流將依賴于 “根數據流”。聲明數據流依賴關系指出，應盡可能先向父數據流分配資源，然后再向其依賴項分配資源。換句話說，“請先處理和傳輸響應 D，然后再處理和傳輸響應 C”。

共享相同父項的數據流（即，同級數據流）應按其權重比例分配資源。 例如，如果數據流 A 的權重為 12，其同級數據流 B 的權重為 4，那么要確定每個數據流應接收的資源比例，請執行以下操作：
將所有權重求和：4 + 12 = 16
將每個數據流權重除以總權重：A = 12/16, B = 4/16 因此，數據流 A 應獲得四分之三的可用資源，數據流 B 應獲得四分之一的可用資源；數據流 B 獲得的資源是數據流 A 所獲資源的三分之一。 我們來看一下上圖中的其他幾個動手示例：順序為從左到右：

   數據流 A 和數據流 B 都沒有指定父依賴項，依賴于顯式 “根數據流”；A 的權重為 12，B 的權重為 4。因此，根據比例權重：數據流 B 獲得的資源是 A 所獲資源的三分之一。
   數據流 D 依賴于根數據流；C 依賴于 D。因此，D 應先于 C 獲得完整資源分配。權重不重要，因為 C 的依賴關系擁有更高的優先級。
   數據流 D 應先于 C 獲得完整資源分配；C 應先于 A 和 B 獲得完整資源分配；數據流 B 獲得的資源是 A 所獲資源的三分之一。
   數據流 D 應先于 E 和 C 獲得完整資源分配；E 和 C 應先于 A 和 B 獲得相同的資源分配；A 和 B 應基于其權重獲得比例分配。

如上面的示例所示，數據流依賴關系和權重的組合明確表達了資源優先級，這是一種用于提升瀏覽性能的關鍵功能，網絡中擁有多種資源類型，它們的依賴關系和權重各不相同。不僅如此，HTTP/2 協議還允許客戶端隨時更新這些優先級，進一步優化了瀏覽器性能。換句話說，我們可以根據用戶互動和其他信號更改依賴關系和重新分配權重。

注：數據流依賴關系和權重表示傳輸優先級，而不是要求，因此不能保證特定的處理或傳輸順序。即，客戶端無法強制服務器通過數據流優先級以特定順序處理數據流。 盡管這看起來違反直覺，但卻是一種必要行為。 我們不希望在優先級較高的資源受到阻止時，還阻止服務器處理優先級較低的資源。

有了新的分幀機制后，HTTP/2 不再依賴多個 TCP 連接去并行復用數據流；每個數據流都拆分成很多幀，而這些幀可以交錯，還可以分別設定優先級。因此，所有 HTTP/2 連接都是永久的，而且僅需要每個來源一個連接，隨之帶來諸多性能優勢。
大多數 HTTP 傳輸都是短暫且急促的，而 TCP 則針對長時間的批量數據傳輸進行了優化。 通過重用相同的連接，HTTP/2 既可以更有效地利用每個 TCP 連接，也可以顯著降低整體協議開銷。不僅如此，使用更少的連接還可以減少占用的內存和處理空間，也可以縮短完整連接路徑（即，客戶端、可信中介和源服務器之間的路徑）這降低了整體運行成本并提高了網絡利用率和容量。 因此，遷移到 HTTP/2 不僅可以減少網絡延遲，還有助于提高通量和降低運行成本。

在 HTTP/2 RFC 文檔中建議實現時客戶端不應該在給定的目的地上打開多個 HTTP/2 連接，目的地是由給定的 URI 確定的 IP 地址及 TCP 端口，或者配置的代理 IP 和端口。當然客戶端可以使用不相同的服務端名稱標識值或者提供不一樣的 ssl 證書對相同的 IP 地址及 TCP 端口打開多個連接，但應該避免對相同的配置上創建多個連接。
注：連接數量減少對提升 HTTPS 部署的性能來說是一項特別重要的功能：可以減少開銷較大的 TLS 連接數、提升會話重用率，以及從整體上減少所需的客戶端和服務器資源。

流量控制是一種阻止發送方向接收方發送大量數據的機制，以免超出后者的需求或處理能力：發送方可能非常繁忙、處于較高的負載之下，也可能僅僅希望為特定數據流分配固定量的資源。例如，客戶端可能請求了一個具有較高優先級的大型視頻流，但是用戶已經暫停視頻，客戶端現在希望暫停或限制從服務器的傳輸，以免提取和緩沖不必要的數據。再比如，一個代理服務器可能具有較快的下游連接和較慢的上游連接，并且也希望調節下游連接傳輸數據的速度以匹配上游連接的速度來控制其資源利用率；等等。

不過，由于 HTTP/2 數據流在一個 TCP 連接內復用，TCP 流控制既不夠精細，也無法提供必要的應用級 API 來調節各個數據流的傳輸。為了解決這一問題，HTTP/2 提供了一組簡單的構建塊，這些構建塊允許客戶端和服務器實現其自己的數據流和連接級流量控制：

流量控制具有方向性，每個接收方都可以根據自身需要選擇為每個數據流和整個連接設置任意的窗口大小。

流量控制基于窗口更新幀進行，即接收方廣播自己準備接收某個數據流的多少字節，以及對整個連接要接收多少字節。

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

流量控制可以由接收方禁用，包括針對個別的流和針對整個連接。

流量控制基于每一跳進行，而非端到端控制。即，可信中介可以使用它來控制資源使用，以及基于自身條件和啟發式算法實現資源分配機制。

HTTP/2 未指定任何特定算法來實現流量控制。不過，它提供了簡單的構建塊并推遲了客戶端和服務器實現，可以實現自定義策略來調節資源使用和分配，以及實現新傳輸能力，同時提升網絡應用的實際性能和感知性能。

例如，應用層流量控制允許瀏覽器僅提取一部分特定資源，通過將數據流流控制窗口減小為零來暫停提取，稍后再行恢復。換句話說，它允許瀏覽器提取圖像預覽或首次掃描結果，進行顯示并允許其他高優先級提取繼續，然后在更關鍵的資源完成加載后恢復提取。

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

注：HTTP/2 打破了嚴格的請求 - 響應語義，支持一對多和服務器發起的推送工作流，在瀏覽器內外開啟了全新的互動可能性。這是一項使能功能，對我們思考協議、協議用途和使用方式具有重要的長期影響。

為什么在瀏覽器中需要一種此類機制呢？一個典型的網絡應用包含多種資源，客戶端需要檢查服務器提供的文檔才能逐個找到它們。那為什么不讓服務器提前推送這些資源，從而減少額外的延遲時間呢？服務器已經知道客戶端下一步要請求什么資源，這時候服務器推送即可派上用場。

事實上，如果在網頁中內聯過 CSS、JavaScript，或者通過數據 URI 內聯過其他資產，那么就已經親身體驗過服務器推送了。對于將資源手動內聯到文檔中的過程，我們實際上是在將資源推送給客戶端，而不是等待客戶端請求。使用 HTTP/2，我們不僅可以實現相同結果，還會獲得其他性能優勢。 推送資源可以進行以下處理：

由客戶端緩存

在不同頁面之間重用

與其他資源一起復用

由服務器設定優先級

被客戶端拒絕

所有服務器推送數據流都由 PUSH_PROMISE 幀發起，表明了服務器向客戶端推送所述資源的意圖，并且需要先于請求推送資源的響應數據傳輸。這種傳輸順序非常重要：客戶端需要了解服務器打算推送哪些資源，以免為這些資源創建重復請求。滿足此要求的最簡單策略是先于父響應（即，DATA 幀）發送所有 PUSH_PROMISE 幀，其中包含所承諾資源的 HTTP 標頭。
在客戶端接收到 PUSH_PROMISE 幀后，它可以根據自身情況選擇拒絕數據流（通過 RST_STREAM 幀）。 （如果資源已經位于緩存中，可能會發生這種情況。） 這是一個相對于 HTTP/1.x 的重要提升。 相比之下，使用資源內聯（一種受歡迎的 HTTP/1.x“優化”）等同于 “強制推送”：客戶端無法選擇拒絕、取消或多帶帶處理內聯的資源。
使用 HTTP/2，客戶端仍然完全掌控服務器推送的使用方式。客戶端可以限制并行推送的數據流數量；調整初始的流控制窗口以控制在數據流首次打開時推送的數據量；或完全停用服務器推送。這些優先級在 HTTP/2 連接開始時通過 SETTINGS 幀傳輸，可能隨時更新。
推送的每個資源都是一個數據流，與內嵌資源不同，客戶端可以對推送的資源逐一復用、設定優先級和處理。 瀏覽器強制執行的唯一安全限制是，推送的資源必須符合原點相同這一政策：服務器對所提供內容必須具有權威性。

每個 HTTP 傳輸都承載一組報頭，這些報頭說明了傳輸的資源及其屬性。 在 HTTP/1.x 中，此元數據始終以純文本形式，通常會給每個傳輸增加 500–800 字節的開銷。如果使用 HTTP Cookie，增加的開銷有時會達到上千字節。為了減少此開銷和提升性能， HTTP/2 使用 HPACK 壓縮格式壓縮請求和響應標頭元數據，這種格式采用兩種簡單但是強大的技術：

這種格式支持通過靜態 Huffman 編碼對傳輸的標頭字段進行編碼，從而減小了各個傳輸的大小。

這種格式要求客戶端和服務器同時維護和更新一個包含之前見過的標頭字段的索引列表（換句話說，它可以建立一個共享的壓縮上下文），此列表隨后會用作參考，對之前傳輸的值進行有效編碼。

利用 Huffman 編碼，可以在傳輸時對各個值進行壓縮，而利用之前傳輸值的索引列表，我們可以通過傳輸索引值的方式對重復值進行編碼，索引值可用于有效查詢和重構完整的標頭鍵值對。

作為一種進一步優化方式，HPACK 壓縮上下文包含一個靜態表和一個動態表：靜態表在規范中定義，并提供了一個包含所有連接都可能使用的常用 HTTP 標頭字段（例如，有效標頭名稱）的列表；動態表最初為空，將根據在特定連接內交換的值進行更新。因此，為之前未見過的值采用靜態 Huffman 編碼，并替換每一側靜態表或動態表中已存在值的索引，可以減小每個請求的大小。
注：在 HTTP/2 中，請求和響應標頭字段的定義保持不變，僅有一些微小的差異：所有標頭字段名稱均為小寫，請求行現在拆分成各個 :method、:scheme、:authority 和 :path 偽標頭字段。

至于 HPACK 壓縮的詳細介紹，請點擊這里：HTTP/2 頭部壓縮技術介紹或者官方 RFC。

為了測試 HTTP/2 對 web 訪問的性能提升，本人借助 bbs 產品線的 miui 官方網站，開啟了 tengine 的 HTTP/2 的支持，取一周的訪問數據與 HTTPS、HTTP 訪問數據進行對比分析，詳細結果如下：

響應類型分布

2xx 請求各個響應時間段占比（基于 nginx log 的 request_time 數據）

2xx 請求響應時間大于 7 秒的數量 (基于 nginx log 的 request_time 數據）

2xx 請求后端響應時間超過 7 秒的數量（基于 nginx log 的 upstream_response_time）

301 請求響應大小（基于 nginx 的 request_length 和 bytes_sent 數據）

200 請求響應大小（基于 nginx log 的 request_length 和 bytes_sent 數據）

客戶端分析（基于 nginx log 的 user_agent 數據）

平臺分析（基于 nginx log 的 user_agent 數據）

典型網絡 RTT 下（50~200ms），HTTP/2 對網絡延遲性能有一定程度的提升，優于 HTTP/1.x 和 HTTPS。

在 2xx 和 3xx 請求下 HTTP/2 利用 HPACK 機制壓縮響應頭和請求頭，有效降低了請求和響應的大小，節省了流量，降低了協議消耗。

目前 HTTP/2 大部分流量來自于 chrome，其對 HTTP/2 的支持性也是最好的。

實現 HTTP/2 很簡單，不過，HTTP/2 并不是萬能的銀彈，它只對某些 Web 應用有用，對另外一些則沒那么有用。

如果你使用 SSL/TLS（以后簡稱 TLS），那么 HTTP/2 可以提升網站性能。如果你沒有，那在使用 HTTP/2 之前要先支持 TLS。這時候，使用 TLS 的性能損耗大致可以被使用 HTTP/2 的性能提升抵銷。不過還是建議你在實際應用之前先測試一下。
HTTP/2 有五大優勢：

每個服務器只用一個連接。HTTP/2 對每個服務器只使用一個連接，而不是每個文件一個連接。這樣，就省掉了多次建立連接的時間，這個時間對 TLS 尤其明顯，因為 TLS 連接費時間。

加速 TLS 交付。HTTP/2 只需一次耗時的 TLS 握手，并且通過一個連接上的多路利用實現最佳性能。HTTP/2 還會壓縮首部數據，省掉 HTTP/1.x 時代所需的一些優化工作，比如拼接文件，從而提高緩存利用率。

簡化 Web 應用。使用 HTTP/2 可以讓 Web 開發者省很多事，因為不用再做那些針對 HTTP/1.x 的優化工作了。

適合內容混雜的頁面。HTTP/2 特別適合混合了 HTML、CSS、JavaScript、圖片和有限多媒體的傳統頁面。瀏覽器可以優先安排那些重要的文件請求，讓頁面的關鍵部分先出現，快出現。

更安全。通過減少 TLS 的性能損失，可以讓更多應用使用 TLS，從而讓用戶信息更安全。

相應地，HTTP/2 也有五個不足之處。

單連接開銷比較大。HPACK 數據壓縮算法會更新兩端的查找表。這樣可以讓連接有狀態，而破壞狀態就意味著要重建查找表，另外單連接占用內存較多。

你可能不需要 SSL。如果你的數據不需要保護，或者已經使用 DRM 或其他編碼進行保護了，那么 TLS 的安全性對你可能無所謂。

需要拋棄針對 HTTP/1.x 的優化。HTTP/1.x 優化在支持 HTTP/2 的瀏覽器中會影響性能，因此可能需要花時間把它們推倒重來。

對下載大文件不利。如果你的應用主要提供大文件下載或者流媒體播放，那可能不想用 TLS，而且在只有一個流的情況下，多路復用也體現不出什么優勢。

你的客戶也許不在乎。你的客戶很可能不在乎他分享的自家貓咪的視頻是否受到 TLS 和 HTTP/2 的保護。

總之，一切要看性能。這方面，有好消息也有壞消息。
好消息是 nginx 官方團隊在內部對 NGINX 做過測試，結果從理論上能夠得到印證：對于要通過典型網絡延遲請求的混合內容網頁，HTTP/2 的性能好于 HTTP/1.x 和 HTTPS。基于連接的 RTT，結果可以分三種情況。

很低的 RTT（0-20ms）：HTTP/1.x、HTTP/2 和 HTTPS 基本無差別。

典型網絡 RTT（30-250ms）：HTTP/2 比 HTTP/1.x 快，而且它們都比 HTTPS 快。美國兩個相鄰城市間的 RTT 約為 30 ms，而東西海岸間（約 3000 英里）則約為 70 ms。東京到倫敦間最短路徑的 RTT 大約 240 ms。

高 RTT（300ms 及以上）：HTTP/1.x 比 HTTP/2 快，后者又比 HTTPS 快。

這張圖顯示了首次渲染的時間，也就是用戶第一次在自己屏幕上看到網頁內容的時間。這個時間一般認為關系到用戶對網站響應速度的感知。

然而，每個網頁都不相同，實際上每個用戶的會話也不一樣。如果你托管流媒體或提供大文件下載，那你的決定可能不一樣，甚至相反。

終止協議意味著客戶端使用期望的協議連接代理服務器，比如 TLS 或 HTTP/2，然后代理服務器再去連接應用服務器、數據庫服務器等，但不需要使用相同的協議，如下圖所示。

使用獨立的服務器終止協議意味著使用多服務器架構。多服務器可能是多個物理服務器、多個虛擬服務器，或者 AWS 這樣的云環境中的多個虛擬服務器實例。多服務器就比單服務器復雜，或者比應用服務器 / 數據庫服務器的組合復雜。不過，多服務器架構有很多好處，而且很多流量大的網站也必須用這種架構。

配置了服務器或者虛擬服務器之后，很多事情都成為可能。新服務器可以分擔其他服務器的負載，可用于負載平衡、靜態文件緩存和其他用途。另外，也可以讓添加和替換應用服務器或其他服務器更容易。
NGINX 和 NGINX Plus 經常被用來終止 TLS 和 HTTP/2 協議、負載平衡。已有環境不必改動，除非要把 NGINX 服務器挪到前端。

在決定采用 HTTP/2 之前，首先得知道你的代碼有哪些是針對 HTTP/1.x 優化過的。大概有四方面的優化。

分域存儲。為了實現并行請求文件，你可能把文件分散到了不同的域里，CDN 會自動這么做。但分域存儲會影響 HTTP/2 的性能，建議使用 HTTP/2 友好的分域存儲（建議六），只針對 HTTP/1.x 用戶分域。

雪碧圖。雪碧圖把很多圖片拼成一個文件，然后通過代碼按需取得每個圖片。雪碧圖在 HTTP/2 的環境下沒太大用處，但還是有點用的。

拼接的代碼文件。與使用雪碧圖的原因類似，很多獨立的文件也會被弄成一個，然后瀏覽器再從其中找到并運行需要的文件。

插入行內的文件。CSS 代碼、JavaScript 代碼，甚至圖片等被直接插到 HTML 文件中的內容。這樣可以減少文件傳輸，代價是初始 HTML 文件較大。

后面三種優化都涉及把小文件塞進一個較大的文件里，目的是減少新建連接的初始化和握手，這些操作對 TLS 而言非常費時間。

第一種優化即分域存儲恰恰相反，強制打開多個連接，目的是并行地從不同的域獲取文件。這兩種看似矛盾的技術對于 HTTP/1.x 下的站點卻十分有效。然而，要用好這兩種技術，必須投入大量時間、精力和資源，用于實現、管理和運維。

在采用 HTTP/2 之前，需要找出應用了這些優化的代碼，分析一下它們會不會影響你的應用設計和工作流程。這樣在遷移到 HTTP/2 之后，就可以著手改造它們，甚至撤銷某些優化。

事實上，部署 HTTP/2 并不難。如果使用 NGINX，只要在配置文件中啟動相應的協議就可以了。瀏覽器和服務器會協商采用什么協議，如果瀏覽器支持 HTTP/2（而且也在使用 TLS），就會使用 HTTP/2。
配置完服務器后，使用支持 HTTP/2 瀏覽器的用戶就會基于 HTTP/2 運行你的應用，而使用舊版本瀏覽器的用戶則會繼續使用 HTTP/1.x 運行你的應用，如下圖所示。如果你的網站流量非常大，那么應該監測改變前后的性能，對于性能降低的情況，可能就得撤銷更改。

注意：使用 HTTP/2 及其單連接之后，NGINX 某些配置的重要性會很明顯，特別要注意的是 output_buffers、proxy_buffers 和 ssl_buffer_size 等指令，多測試一下。參見 general configuration notes，特定的 SSL 建議，以及 NGINX 關于 SSL 性能的白皮書。
注意：使用 HTTP/2 傳輸密文要格外注意。HTTP/2 的 RFC 中有一個長長的列表，列出了要避免的加密套件。建議你自己也搞一個表格，啟用 ssl_buffer_size，然后在所有常用的瀏覽器版本下測試你想用的加密套件。

你說奇怪不，撤銷和修改針對 HTTP/1.x 優化的代碼居然是實現 HTTP/2 最有創意的部分。這里面有幾個問題要注意，因為很多事怎么做都是可以的。
在開始運作之前，必須考慮舊版本瀏覽器用戶是否好過。之后，可以采取三個策略撤銷和修改 HTTP/1.x 的優化。

什么也不用做。假如你并沒有針對 HTTP/1.x 做過優化，或者只做過少量優化，那么你幾乎什么也不用做，就可以直接遷移到 HTTP/2。

有選擇地去做。第二種情況是減少合并某些文件，而不是完全不合并。比如，牽扯到很多場景的雪碧圖就不用動，而被塞得滿滿的 HTML 可能就要分離出來一些。

完全撤銷 HTTP/1.x 優化。可以不再做以前做過的任何優化。

緩存還是普適的。理論上，緩存操作非常適合小文件特別多的情況。但是，小文件多也意味著文件 I/O 多。因此一些相近文件的合并還是必要的，一方面要考慮工作流程，另一方面要考慮應用性能。建議多關注一下其他人在過渡到 HTTP/2 過程中的一些經驗。

分域存儲可能是最極端但也最成功的 HTTP/1.x 優化策略。它能夠提升 HTTP/1.x 下的應用性能，但在 HTTP/2 之下，其性能提升可以忽略不講（因為只有一個連接。)
對 HTTP/2 友好的分域，要保證以下兩點：

讓多個域名解析到同一個 IP。

確保證書包含通配符，以便所有分域名都可以使用，適當的多域證書當然也可以。

有了這些保障，分域還會繼續對 HTTP/1.x 有效，即域名仍然可以觸發瀏覽器創建更多連接，但對 HTTP/2 則無效，因為這些域名會被看成同一個域，一個連接就可以訪問所有域名了。

PC 端

如果業務提供的是 web 形式的內容，通過瀏覽器進行訪問，由于當前大部分的瀏覽器都已經支持 HTTP/2 了，所以基本不需進行任何操作，以下為支持 HTTP/2 的瀏覽器列表：

移動端

安卓 app 基本采用 JAVA 開發，由于各個應用采用的與服務端通信的 http 庫各不相同，有的是采用 jdk 自帶的 httpurlconnection 庫和 httpclient 庫，有的用的是安卓系統自帶的 webview 或者 volley（volley 的 HTTP/2 支持依賴于所使用的 httpstack，默認使用 httpurlconection，但現在也有很多開發者使用第三方的 okhttp 作為 volley 的 httpstack），而有的開發者直接使用的是第三方庫類似于 okhttp，netty 等，這些 http 庫對 http2.0 的支持情況各不相同。

基于 java 開發的 http 庫對 HTTP/2 的支持情況如下:

Jetty 從 9.3 版本開始支持，需要依賴于 JDK 8 及以上版本

Netty 從 4.1 版本開始支持

OkHttp 天然支持

Vert.xh 從 3.3.0 版本開始支持

Firefly 支持

其它

Golang 的 net/http 庫從 Go1.6 版本開始支持 http2，并默認開啟

在 HTTP/2 的 github 中維護了一份 HTTP/2 協議的實現列表，更加詳細，可供參考。

由于現有的 URI 結構正在被 HTTP 1.x 使用而不能被更換，所以 HTTP/2 也必須沿用該結構。因此不得不找到一種方式將使用的協議升級至 HTTP/2，比如可以要求服務器讓它作響應時使用 HTTP/2 來替代舊的協議。

HTTP 1.1 本身就制定過 “升級” 的方案：提供一個首部字段，表示允許服務器在收到舊協議請求的同時，可以向客戶端發送新協議的響應。但這一方案往往需要花費一次額外的往返通信來作為升級的代價。
而這一代價是 SPDY 團隊不想接受的。因為他們只實現了基于 TLS 的 SPDY，所以他們開發了一個 TLS 的擴展去簡化協議的協商。這個擴展被稱作 NPN（Next Protocol Negotiation），借助于此，服務器會通知客戶端所有它支持的協議，讓客戶端從中選擇一個合適的來進行通訊。

IETF 將這個非正式標準 --NPN 進行規范化，從而演變成了 ALPN（Application Layer Protocol Negotiation）。ALPN 會隨著 HTTP/2 的應用被推廣，而 SPDY 的客戶端與服務器則會繼續使用 NPN。
由于 NPN 先于 ALPN 誕生，而 ALPN 又經歷了一些標準化過程，所以許多早期的 HTTP/2 客戶端和服務器在協商 HTTP/2 時會將這兩者同時實現。與此同時，考慮到 SPDY 會使用 NPN，而許多服務器又會同時提供 SPDY 以及 HTTP/2，所以在這些服務器上同時支持 ALPN 以及 NPN 顯然會成為最理所當然的選擇。
ALPN 和 NPN 的主要區別在于：誰來決定通信協議。在 ALPN 的描述中，是讓客戶端先發送一個協議優先級列表給服務器，由服務器最終選擇一個合適的。而 NPN 則正好相反，客戶端有著最終的決定權。

ALPN 擴展的具體資料，可以參考 Jerry Qu 寫的這篇博客：談談 HTTP/2 的協議協商機制

QUIC (Quick UDP Internet Connection，快速 UDP 互聯網連接) 是一個新的基于 UDP 的多路復用且安全的傳輸協議，它從頭開始設計，且為 HTTP/2 語義做了優化。盡管以 HTTP/2 作為主要的應用協議而構建，然而 QUIC 的構建是基于傳輸和安全領域數十年的經驗的，且實現了使它成為有吸引力的現代通用傳輸協議的機制。QUIC 提供了等價于
HTTP/2 的多路復用和流控，等價于 TLS 的安全機制，及等價于 TCP 的連接語義、可靠性和擁塞控制。

QUIC 完全運行于用戶空間，它當前作為 Chromium 瀏覽器的一部分發布給用戶，以便于快速的部署和實驗。作為基于 UDP 的用戶空間傳輸協議，QUIC 可以做一些由于遺留的客戶端和中間設備，或曠日持久的操作系統開發和部署周期的阻礙，而被證明很難在現有的協議中部署的創新。

QUIC 的一個重要目標是通過快速的實驗獲得更好的傳輸設計相關的知識。

基于早期的部署的 QUIC 標準化建議為 [draft-hamilton-quic-transport-protocol]，[draft-shade-quic-http2-mapping]，[draft-iyengar-quic-loss-recovery]，和 [draft-thomson-quic-tls]。

更加詳細的資料請參考這里：中文文檔； Chromium 的 QUIC 主頁。

web 性能權威指南

HTTP/2 RFC 文檔

HTTP/2 explained

Nginx HTTP/2 白皮書

HTTP/2 is here, let"s optimize! - Velocity SC 2015

Jerry Qu 的小站 - HTTP/2 資料匯總