HTTP2 協議

關於HTTP協議版本的發展可以參閱HTTP 版本發展介紹一章節。

網際網路飛速發展的今天，HTTP1.1版本的不足顯現無疑，參閱HTTP1.1有點與缺點一章節。

一.HTTP2協議的目的：

（1）.支援請求與響應的多路複用來減少延遲。

（2）.壓縮HTTP首部欄位將協議開銷降至最低。

（3）.增加對請求優先順序和伺服器端推送的支援。

同時由於考慮到龐大的HTTP1.1協議使用者，所以HTTP方法、狀態碼、URI及首部欄位，等核心概念保持不變，也就是當前正在執行的網站不用做任何改變即可在HTTP2協議上執行。

二.HTTP2誕生過程：

谷歌公司於2009年釋出名為SPDY的實驗性協議，主要目的是為了解決HTTP1.1所存在的主要問題，由此減少網頁載入的延遲，提升使用者體驗，所要達成的主要目標如下:

（1）.頁面載入時間縮小至原來一半作用，使用者要有明顯的感受。

（2）.當前網站無需修改任何內容即可應用此協議，也就是保持HTTP 1.1的語義。

（3）.測試新協議的有效性，進一步發展推廣詞協議。

由於SPDY協議能夠大幅度提升效能，在隨後的幾年，此協議得到谷歌或者火狐等瀏覽器的支援，於是，它成為一種標準的條件逐步成熟，在2012年，HTTP-WG將HTTP2的開發提上日程，在SPDY的基礎上指定官方標準，最終在2015年釋出了HTTP2。

三.主要技術實現：

雖然HTTP1.1比較簡單，但是以犧牲效能為代價，HTTP2主要目的是為了提升效能，下面就逐一介紹一下HTTP2主要採取哪些技術手段來達成目的。

1.二進位制分幀層：

HTTP2效能之所以得到大幅度提高，主要因為增加了二進位制分幀層，它定義如何封裝HTTP訊息並在客戶端與伺服器之間傳輸。

圖示如下：

二進位制分幀層是位於TCP協議與HTTP應用層協議之間的一個新機制，它不會影響原有的HTTP語義。

不同的是傳輸期間對它們的編碼方式變了。HTTP 1.x以換行符作為純文字的分隔符，而HTTP2將所有傳輸的資訊分割為更小的訊息和幀，並對它們採用二進位制格式的編碼。

2.流、訊息和幀：

二進位制分幀機制改變了客戶端與伺服器之間互動資料的方式，涉及到以下幾個重要的概念:

（1）.流：已建立的TCP連線上的雙向位元組流，邏輯上可看做一個較為完整的互動處理單元，即表達一次完整的資源請求-響應資料交換流程；一個業務處理單元，在一個流內進行處理完畢，這個流生命週期完結。

（2）.訊息：由一個或多個幀組合而成，例如請求和響應。

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

所有HTTP2通訊都在一個連線上完成，此連線理論上可以承載任意數量的雙向資料流。相應地，每個資料流以訊息的形式傳送，而訊息由一或多個幀組成，這些幀可以亂序傳送，然後再根據每個幀首部的流識別符號重新組裝。

圖示如下：

特別說明：HTTP2的所有幀都採用二進位制編碼，所有首部資料都會被壓縮。

上圖只是演示資料流、訊息和幀之間的關係，而非實際傳輸時的編碼結果。

3.多向請求與響應：

在HTTP1.1中，如果想使用多個並行request請求，必須多開TCP連線，但是一個域名對同一個瀏覽器客戶端是有數量限制的（6個左右），同時，每一個連線中的響應是按照順序排隊進行的，容易導致隊頭堵塞。

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

圖示如下：

由上圖可以看出，同一個TCP連線可以傳輸多個資料流，並且伺服器到客戶端方向有多個資料流，流是一個邏輯通道，所以屬於它的幀可以亂序傳送，最後再根據標記組合起來即可。把HTTP訊息分解為獨立的幀，交錯傳送，然後在另一端重新組裝是HTTP2最重要的改進，帶來了巨大的效能提升，主要因為如下幾個原因:

（1）.可以並行交錯地傳送請求，請求之間互不影響。

（2）.可以並行交錯地傳送響應，響應之間互不干擾。

（3）.只使用一個連線即可並行傳送多個請求和響應。

（4）.消除不必要的延遲，從而減少頁面載入的時間。

二進位制分幀機制解決了HTTP1.1對頭阻塞問題，也消除了並行處理和傳送請求及響應時對多個TCP連線的依賴。

4.請求優先順序：

每個流都包含一個優先順序，用來告訴對端哪個流更重要，當資源有限的時候，伺服器會根據優先順序來選擇應該先傳送哪些流。HTTP2中，每個請求都可以帶一個31bit的優先值，0表示最高優先順序。數值越大優先順序越低。有了這個優先值，客戶端和伺服器就可以在處理不同的流時採取不同的策略，以最優的方式傳送流、訊息和幀。

5.伺服器推送:

當前web頁面的功能越來越強大，排版越來越精美，所以需要引用的js檔案、css檔案或者圖片等內容也越來越多，對每一個資源的外部引用，都是一次request請求。在HTTP1.1中，由於不具有多向請求與響應，所以可能需要額外的TCP連線，甚至導致隊頭堵塞，HTTP1.1對此問題的解決方案可以參閱HTTP請求延遲解決方案一章節。

當客戶端獲取伺服器傳送來的文件之後，通過分析獲知需要引入額外的資源，然後再向伺服器傳送請求獲取這些資源，如此大費周章，倒不如伺服器主動推送這些額外資源。

推送資源的特點如下:

（1）.客戶端可以快取推送過來的資源。

（2）.客戶端可以拒絕推送過來的資源。

（3）.推送資源可以由不同的頁面共享。

（4）.伺服器可以按照優先順序推送資源。

6.首部壓縮：

在HTTP1.1中，每次請求或者響應都會傳送一組首部資訊，同時這些資訊都是以文字形式傳送，如果帶有cookie資訊的話，那麼傳送首部資訊就是一份相當大的額外開銷。為減少這些開銷並提升效能，HTTP2會壓縮首部後設資料，HTTP2在客戶端和伺服器端使用“首部表”來跟蹤和儲存之前傳送的鍵/值對，對於相同的資料，不再通過每次請求和響應傳送，首部表在HTTP2的連線存續期內始終存在，由客戶端和伺服器共同漸進地更新。

圖示如下:

四.應用層協商：

客戶端、伺服器都需要升級才能支援HTTP 2.0，升級過程中就存在HTTP1.1、HTTP 2.0並存的情況，然而它們都使用的80埠，那麼如何來選擇使用什麼協議通訊呢，APLN（APLN:Aplication Layer Protocol Negotiation）就是為了解決這個問題的，通過協商來選擇通訊的協議：

（1）.客戶端發起請求，如果支援HTTP/2，則帶upgrade頭部：

[HTML] 純文字檢視 複製程式碼
GET /page HTTP/1.1 
Host: server.example.com 
Connection: Upgrade, HTTP2-Settings 
Upgrade: HTTP/2.0 
HTTP2-Settings: (SETTINGS payload)

（2）.伺服器不支援，則拒絕升級，通過HTTP1.1返回響應 ：

[HTML] 純文字檢視 複製程式碼
HTTP/1.1 200 OK 
Content-length: 243 
Content-type: text/html 
/* HTTP 1.1 response */

（3）.伺服器支援，則接受升級，切換到新分幀，使用HTTP/2通訊：

[HTML] 純文字檢視 複製程式碼
HTTP/1.1 101 Switching Protocols 
Connection: Upgrade 
Upgrade: HTTP/2.0 
/* HTTP 2.0 response */

使用協議協商，無論是哪一種情況，都不需要額外的往返，如果客戶端通過記錄或者其他方式，知道伺服器支援HTTP/2，則直接使用HTTP/2通訊，無需再協議協商。