HTTP2.0簡明筆記

版權聲明：本文由史燕飛原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/82

來源：騰雲閣 https://www.qcloud.com/community

 

RFC2616發佈以來，一直是互聯網發展的基石。HTTP協議也成爲了能夠在任何領域使用的核心協議，基於這個協議人們設計和部署了愈來愈多的應用。HTTP的簡單本質是其快速發展的關鍵，但隨着愈來愈多的應用被部署到WEB上，HTTP的問題慢慢凸顯出來。今天，用戶和開發者都迫切須要經過THHP1.1達到一種幾近實時的響應速度和協議性能，而要知足這個需求，只在原有協議上進行修補是不夠的。爲了應對這些挑戰，HTTP必須繼續發展。HTTP工做組已經在2012年宣佈要設計和開發HTTP2.0。HTTP2.0的主要目標是改進傳輸性能，實現低延遲和高吞吐量。

在HTTP2.0真正誕生以前，谷歌開發了一個實驗性質的協議-SPDY，它定位於解決HTTP1.1中的一些性能限制，來減小網頁的延時。自從2009年SPDY發佈以後，這個協議獲得了衆多瀏覽器廠商和大型網站的支持，實踐證實它確實能夠很大幅度的提高性能，已經具有成爲一個標準的條件。因而，HTTP-WG於2012年初提出要重在SPDY的一些實踐基礎上新設計和開發HTTP2.0，以期使數據傳輸具備更好的性能和更少的延時。SPDY是HTTP2.0的先驅，但兩者並不能初略的劃爲等號，SPDY V2草案是HTTP2.0標準制定的起點，今後以後SPDY標準並無停滯，而是在不斷進化，它成爲了HTTP2.0新功能及新建議的實驗場，爲HTTP2.0標準收納的每一項建議，提供事前的測試和評估手段，整體來講SPDY比HTTP2.0更爲激進。HTTP2.0協議版本發佈歷程以下：

• 2012年3月，HTTP2.0徵集建議；
• 2012年11月，HTTP2.0第一稿；
• 2014年8月，HTTP2.0 draft-17和HPACK draft-12發佈；
• 2014年8月，工做組最後徵集HTTP2.0建議；
• 2015年2月，IESG批准HTTP2.0和HPACK草稿；
• 2015年5月，RFC 7540 (HTTP2.0) 和 RFC 7541 (HPACK) 發佈；

在新的協議中，將會從根本上解決以往HTTP1.1版本中所作的「特殊優化」，將在這些解決方案內置在傳輸層中，使數據傳輸更加便捷和高效，如HTTP1.1及之前的版本中影響性能的很大一個問題，就是隊首阻塞問題，在HTTP2.0中會將會經過新的組幀機制來解決這個問題，使鏈接能夠多路複用，再經過壓縮HTTP首部字段將協議開銷降到最低。HTTP2.0不會改動HTTP語義，很好的繼承以往版本的HTTP方法、狀態碼、URI及首部字段等核心概念，下面將對這些內容進行細緻的描述。

1.二進制分幀

HTTP2.0的根本改進仍是新增的二進制分幀層，不一樣於HTTP1.X使用換行符分割純文本，二進制分幀層更加簡潔，處理起來也更加高效。這裏所謂的層，指的是位於套接字接口與應用可見的高層HTTP API間的一個新機制：HTTP語義，包括各類動詞、方法、首部，都不受影響，不一樣的是傳輸它們的編碼方式變了。HTTP 1.X以換行符做爲純文本的分隔符，而HTTP 2.0將全部傳輸的信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼。示例以下：

由上圖可知，在HTTP1.1傳輸數據時，首部和數據是一塊發送的，每次傳輸都是須要帶有首部信息；在HTTP2.0中，首部信息被分爲一個獨立的幀進行發送，數據幀在在首部幀發送後，再進行發送，並且採用首部壓縮後，每次傳輸只須要發送改動的部分便可，極大提升了數據發送的效率。

1.1.分幀首部

在創建HTTP2.0鏈接以後，客戶端與服務器會經過交換幀進行通訊，幀是HTTP2.0協議的最小單位。全部的幀都擁有一個8字節的首部，具體格式以下：

0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | R |     Length (14)           |   Type (8)    |   Flags (8)   |
 +-+-+-----------+---------------+-------------------------------+
 |R|                 Stream Identifier (31)                      |
 +=+=============================================================+
 |                   Frame Payload (0...)                      ...
 +---------------------------------------------------------------+

• R : 保留的2位字段。這些字節的語義是未定義的，而且在發送的時候必須保持未設置(0)，接收的時候必須被忽略此字段。
• Length : 14位無符號整數的幀主體長度。8字節長度的幀報頭信息不計算在此內，主體最大可能長度爲2^14-1(16383)字節，整個幀(包括首部)的最大長度是最大的幀長度是16391字節。
• Type ： 幀的8位類型。幀類型定義了剩餘的幀報頭和幀主體將如何被解釋。具體實現必須在收到未知幀類型(任何未在文檔中定義的幀)時做爲鏈接錯誤中的類型協議錯誤(PROTOCOL_ERROR)處理。
• Flags ： 爲幀類型保留的8字節字段有具體的布爾標識。 標識針對肯定的幀類型賦予特定的語義。肯定幀類型定義語義之外的標示必須被忽略，而且必須在發送的時候保留未設置(0)。
• R : 1位的保留字段。這個字段的語義未設置而且必須在發送的時候保持未設置(0)，在接受的時候必須被忽略。
• Stream Identifier : 31字節的流標識符，惟一標識HTTP2.0的流。0是保留的，標明幀是與鏈接相關做爲一個總體而不是一個單獨的流。

經過這個共享的8字節首部，能夠很快肯定幀的類型、標誌和長度，並且每一幀的長度也是事先定義好的，解析器也能夠迅速的找到下一幀的開始，並進行解析，這對於HTTP1.1X來講也是一個很大的提高。

1.2.幀類型

無論是在鏈接管理或單獨的流中，每種幀都爲了特定的目的而服務。在HTTP2.0中，共定義瞭如下10種幀類型：

• DATA：用於傳輸HTTP消息體；
• HEADERS：用於傳輸關於流的額外的首部字段；
• PRIORITY：用於指定或從新指定引用資源的優先級；
• RST_STREAM：用於知道流的非正常終止；
• SETTINGS：用於通知兩端通訊方式的配置數據；
• PSUH_PROMISE：用於發出建立流和服務器引用資源的要約；
• PING：用於計算往返時間，執行活性檢查；
• GOWAY：通知遠端對等端不要在這個鏈接上創建新流；
• WINDOW_UPDATE：用於針對個別流或個別鏈接實現流量控制；
• CONTINUATION：用於繼續一系列首部片斷。

注：服務器能夠利用GOWAY類型的幀告訴客戶端要處理的最後一個流ID，從而消除一些請求競爭，並且瀏覽器也能夠據此智能地重試或取消「懸着的」請求。這也是保證複用鏈接安全的一個重要和必要的功能。

HTTP2.0性能加強的核心，全在於新增的二進制分幀層，它定義瞭如何封裝HTTP消息並在客戶端與服務器之間傳輸。因爲在HTTP2.0中使用了新的組幀方式，這樣一來，客戶端和服務器爲了相互理解，必須都使用新的二進制編碼機制，因此HTTP1.x客戶端沒法理解只支持HTTP2.0的服務器，反之亦然。但這並不影響咱們使用HTTP2.0，現有的應用不用關注這些變化，由於客戶端和服務器會替它們完成必要的分幀工做。

1.3.流、消息和幀

新的二進制分幀機制改變了客戶端與服務器之間交互數據的方式，爲了更好的理解HTTP2.0中這一核心變化，下面介紹流、消息、幀這三個概念及區別：

• 流（stream）：已創建的鏈接上的雙向字節流，HTTP/2鏈接中的虛擬通道。
• 消息（message）：與邏輯消息對應的完整的一系列數據幀。
• 幀（frame）：HTTP2.0通訊的最小單位，包括根據幀類型結構的字節的報頭和可變長度的序列，每一個幀包含首部。

全部HTTP2.0通訊都在一個TCP鏈接上完成，這個鏈接能夠承載任意數量的雙向數據流。相應的，每一個數據流以消息的形式發送，而消息由一個或多個幀組成，這些幀能夠亂序發送，而後根據每一個幀首部的流標識符從新組裝。幀是HTTP2.0中的最小通訊單位，不一樣類型的幀有特殊的做用。

2.多路複用

2.1.隊列傳輸與多路複用

在HTTP1.x中，若是客戶端想發送多個並行的請求以及改進性能，那麼必須使用多個TCP鏈接，並且存在隊首阻塞問題，嚴重影響數據的傳輸效率。在HTTP2.0中，二進制分幀機制突破了這些限制，實現了多向請求和響應，客戶端和服務器能夠把HTTP消息分解爲互不依賴的幀，而後亂序發送，而後在接收端從新組裝，這樣就完成了消息的傳輸。示例以下：

由上圖可知，在同一個鏈接中，有三個流在同時傳輸，有兩個是從服務端發給客戶端的，也有一個是從客戶端發送到服務端，這就大大的提升了鏈接的利用率。
這個新的機制是革命性的，會在整個WEB技術棧中引起一系列連鎖反應，從而帶來巨大的性能提高，由於：

• 能夠並行交錯地發送請求，請求之間互不影響；
• 能夠並行交錯地發送響應，響應之間互不干擾；
• 只使用一個鏈接便可並行發送多個請求和響應；
• 消除沒必要要的延遲，從而減小頁面加載時間；
• 沒必要再爲繞過HTTP1.X限制而作多餘的工做。

HTTP2.0的二進制分幀機制解決了HTTP1.X中存在的隊首阻塞問題，也消除了並行處理和發送請求及響應時對多個鏈接的依賴。這樣，就會使應用更快、開發更簡單、部署成本更低，也會減小客戶端和服務器的CPU及內存佔用。

2.2.每一個來源一個鏈接

在能夠實現鏈接的多路複用後，HTTP2.0再也不依賴多個TCP鏈接去實現多流並行了。如今，多個數據流都拆分紅不少幀，而這些幀能夠交錯，還能夠分別優先級。因而，全部的 HTTP2.0鏈接都是持久化的，並且客戶端與服務器之間也只須要一個鏈接便可。每一個來源一個鏈接顯著減小了相關的資源佔用：鏈接路徑上的套接字管理工做少了，內存佔用少了，鏈接吞吐量大了。因此，不少層面上都有不小的提升：

• 全部數據流的優先級次序始終如一；
• 壓縮上下文單一使得壓縮效果更好；
• 因爲TCP鏈接減小而使網絡擁塞情況得以改觀；
• 慢啓動時間減小，擁塞和丟包恢復速度更快。

大多數HTTP鏈接的時間都很短，並且是突發性的，但TCP只在長時間鏈接傳輸大塊數據時效率才高。HTTP2.0經過讓全部數據流共用同一個鏈接，能夠更有效地使用TCP鏈接。HTTP2.0不只可以減小網絡延遲，還有助於提升吞吐量和下降運營成本。
注：任何事物都有其兩面性，每一個來源一個鏈接固然也會帶來一些問題:

• 雖然消除了HTTP隊首阻塞現象，但TCP層次上仍然存在隊首阻塞；
• 若是TCP窗口縮放被禁用，那帶寬延遲積效應可能會限制鏈接的吞吐量；
• 丟包時，TCP擁塞窗口會縮小。

雖然有上述問題影響HTTP2.0的性能，但實驗代表一個TCP鏈接仍然是目前最佳的策略：壓縮和優先級排定帶來的性能提高，已經超過了隊首阻塞形成的負面效應。與全部其餘的性能優化同樣，去掉一個性能瓶頸，又會帶來新的瓶頸。對HTTP2.0而言，TCP極可能就是下一個瓶頸。這也是服務器端TCP配置對HTTP2.0相當重要的一個緣由。

3.請求優先級

在HTTP消息被分解爲不少獨立的幀以後，就能夠經過優化這些幀的交錯和傳輸順序，可讓最緊要的幀優先發送，以確保關鍵任務的快速展開。那麼如何定義這些幀的發送順序就是一個難題，爲方便起見，在HTTP / 2標準容許每一個流具備相關聯的權重和依賴性：

• 每一個流可被分配1~256之間的權重值，具備相同父節點的流應該根據權重比例來分配資源；
• 每一個流可聲明對另外一流的顯式依賴性，包含一個依賴偏好設置表示分配資源給特定的流而不是所依賴的流。

經過流依賴和權重，客戶端能夠構建一個「優先級樹」（以下圖所示），將這個樹發送到服務端，表達客戶端願意以怎樣的方式接收響應；服務端在接收到該「優先級樹」後，能夠根據這個信息，經過協調相關服務器資源返回響應，如CPU、存儲器、網絡等資源，優先處理高優先級的流。而且一旦響應數據是可用的，服務端將分配更多的帶寬以確保高優先級的快速響應。

HTTP 2.0內的一個流只能設置一個惟一的流依賴，被依賴流就是當前流的父節點流，若是省略了流依賴的聲明，則默認依賴於「根流」。聲明一個流的依賴性代表，若是可能的話，父流應先於子流進行資源分配和響應，例如請處理和響應C前交付響應D。
具備相同的父流的同級流應該按照其權重比例分配服務器資源。例如，若是流A具優先級重量爲12，他的同級兄弟流B的權重爲4，那麼肯定兩者應分配的資源比例爲：

• 計算全部流的權重總和：4 + 12 = 16；
• 計算每一個流所佔總和的比例：A = 12 / 16，6B = 4/16。

由上可知，如A流獲得四分之三可用資源分配的話，B流應獲得可利用的資源的四分之一。爲了更好的理解優先級機制，下面從左到右依次介紹上圖的優先級重組狀況：

• 不管是流A或B指定一個相同的父依賴，仍是是依賴於隱式的「根流」：A的優先級權重爲12，B的優先級權重爲4，所以基於比例權重--流B應該獲得分配給流A資源的三分之一；
• D是依賴於根流，C是依賴D。所以，D應提早於C，此時權重對資源分配是可有可無的，由於沒有其餘流與C同級；
• D應在C以前接收到資源的充分分配；C應在A和B以前接收資源的充分分配；B流應該接收分配給A流資源的三分之一；
• 在E和C以前，D應該獲得充分的資源分配；E和C應在A和B以前獲得平等的分配；A和B應根據它們的權重進行比例分配。

從上述示例可知，流依賴和權重的組合提供了一個表達資源優先次序的方式，這能夠爲不一樣的資源定義優先級，能夠更好的提升性能。HTTP／2協議也容許客戶端在任什麼時候間點更新優先級信息，優先級信息能夠像它們被建立同樣使用報頭幀或者使用優先級幀來明確指定或者改變。有了這個優先級標識，客戶端和服務器就能夠在處理不一樣的流時採起不一樣的策略，以最優的方式發送流、消息和幀。優先級的目的是容許終端表達它如何讓對等端管理併發流時分配資源。更重要的是，在發送容量有限時優先級能用來選擇流來傳輸幀。提供優先級信息是可選的，沒有明確指定時使用默認值。
流依賴和權重表達一個傳輸偏好，而不是一個要求，所以不保證一個特定的處理或傳輸順序。也就是說，客戶端不能強制服務器以流優先級的優先級來處理特定順序的流。在選擇HTTP2.0服務器時，須要考慮如下幾個問題：

• 若是服務器對全部優先級視而不見怎麼辦？
• 高優先值流必定優先處理嗎？
• 是否存在不一樣優先級的流應該交錯的狀況？

若是服務器不理睬全部優先值，那麼可能會致使應用響應變慢：瀏覽器明明在等關鍵的CSS和JavaScript，服務器卻在發送圖片，從而形成渲染阻塞。然而，嚴格按照規定的優先級次序也可能帶來次優的結果，由於這或許會再次引入隊首阻塞問題，即某個高優先級的慢請求會沒必要要地阻塞其餘資源的交付。
因此，服務器能夠而且應該交錯發送不一樣優先級別的幀，只要可能，高優先級流都應該優先傳輸，不過爲了更高效地利用底層鏈接，不一樣優先級的混合也是必須的。所以優先級的表達僅僅是一個建議。

4.流量控制

流量控制的定義是用來保護端點在資源約束條件下的操做。流量控制解決的狀況是接收端在一個流上處理數據的同時一樣想繼續處理同個鏈接上的其餘流。在同一個TCP鏈接上傳輸多個數據流，就意味着要共享帶寬。標定數據流的優先級有助於按序交付，但只有優先級還不足以肯定多個數據流或多個鏈接間的資源分配，爲解決這個問題，HTTP2.0爲數據流和鏈接的流量控制提供了一個簡單的機制：

• 流量控制基於每一跳進行，而非端到端的控制；
• 流量控制基於窗口更新幀進行，即接收方廣播本身準備接收某個數據流的多少字節，以及對整個鏈接要接收多少字節；
• 流量控制窗口大小經過WINDOW_UPDATE幀更新，這個字段指定了流ID和窗口大小遞增機制；
• 每一個新的流及整個鏈接的流量控制窗口初始值是65,535字節；
• 流控制方向性，即接收方可能根據本身的狀況爲每一個流乃至整個鏈接設置任意窗口大小；流量控制能夠由接收方禁用，包括針對個別的流和針對整個鏈接。
• 幀類型決定了是否適用流量控制規則。本文檔定義的幀中，只有DATA幀受流量控制；全部其餘的幀不受廣播的流量控制窗口影響。這保證了重要的控制幀不因流量控制所阻塞。

HTTP/2只標準化WINDOW_UPDATE幀格式。HTTP2.0標準沒有規定任何特定的算法、值，或者何時發送WINDOW_UPDATE幀，所以實現能夠選擇本身的算法以匹配本身的應用場景，從而求得最佳性能。
流量控制方案等確保同一鏈接上的流相互之間不會形成破壞性的干擾。流量控制在單個流及整個鏈接過程當中使用，HTTP/2 經過使用WINDOW_UPDATE幀類型來提供流量控制。上面的機制和TCP流量控制是同樣的思路，然而僅憑TCP流量控制是不能對一條HTTP2.0鏈接內的多個流實行差別化策略，因此專門有了HTTP2.0流量控制機制的出現。

5.服務器推送

5.1.服務器端推送

HTTP2.0新增了一個強大的功能，就是服務器能夠對一個客戶端請求發送多個響應。換句話說，出了最初請求的相應外，服務器還能夠額外向用戶端推送資源，而無需客戶端明確地請求。示例以下：

這樣一個機制須要解決的問題是什麼呢？咱們知道，一般一個web應用每每包含數十個資源，客戶端須要分析服務器提供的文檔才能逐個找到它們。那麼爲何不讓服務器提早就把這些資源推送給客戶端，從而減小額外的延時呢？服務器已經知道客戶端下一步要請求什麼資源了，這時候服務器端推薦就能夠大展拳腳了。事實上，網頁上嵌入的CSS及JS，或經過URI嵌入的其餘資源，也能夠算是服務器端推送。把資源直接插入到文檔中，就是把資源直接推送給客戶端，而無需客戶端主動請求。在HTTP2.0中，惟一的不一樣就是能夠把這個過程從應用中拿出來，放到HTTP協議自己來實現，並且帶來了以下好處：

• 客戶端能夠緩存推送的資源;
• 客戶端能夠拒絕推送的資源;
• 推送資源能夠由不一樣的頁面共享;
• 推送資源能夠與其餘資源一塊兒複用;
• 服務器能夠按照優先級推送資源.

有了服務器推送後，HTTP1.X時代的插入或嵌入資源的作法就能夠退出歷史舞臺了。惟一有必要採用嵌入資源方式的狀況就是該資源只供一個頁面使用，並且編碼代價不大，除此以外，其餘全部的場景都應該使用服務器端推送。

注：全部服務器推送流都由PUSH_PROMISE發端，它除了對原始請求的響應以外，服務器向客戶端發出的有意推送所述資源的信號。PUSH_PROMISE幀中只包含有要約資源的HTTP首部。

客戶端在接收到PUSH_PROMISE幀以後，能夠視自身需求選擇接收或拒絕這個流。服務端推送也有一些限制：

• 首先，服務必須遵循請求-響應的循環，只能藉着請求的響應推送資源，服務器端並不能隨意發起推送；
• 其次，PUSH_PROMISE幀必須在返回響應以前發送，以避免客戶端出現競爭狀態，不然會出現客戶端請求的剛好服務器打算推送的情景。

由於推送的響應是有效地逐跳，中介端接從服務端接收到推送響應的能夠選擇不轉發這些到客戶端。也就是說，如何使用推送響應取決於這些中介端。相等的，中介可能選擇不推送的額外的響應給客戶端，不須要服務端進行任何操做。服務端只能推送能夠被緩存的響應；被承諾的請求必須是安全的，並且絕對不能包含一個請求主體。

5.2.如何實現服務器端推送

服務器推送爲優化應用的資源交付提供了不少可能，然而，服務器到底該如何肯定哪些資源能夠或應該推送呢？HTTP2.0並無給出詳盡的規定，那麼就有可能出現多種策略，每種策略可能會考慮一種應用或服務器使用場景。

• 應用能夠在自身的代碼中明確發起服務器推送；
• 應用能夠經過額外的HTTP首部向服務器發送信號，列出它但願推送的資源；
• 服務器能夠不依賴應用而自動學習相關資源，經過分析來推測出須要推送的資源。

上面只是幾個可能的策略，固然也有不少其餘的實現方式，多是手工調用低級的API，也多是一種全自動的實現。總之，服務器推送領域將會出現不少有意思的創新。推送的資源將直接進入客戶端緩存，就像客戶端請求了同樣，不存在客戶端API或JS回調方法等通知機制，能夠用於肯定資源什麼時候到達，整個過程對運行在瀏覽器中的web應用來講好像根本不存在。

雖然如今還不知道如何肯定哪些資源能夠或應該推送，可是如何發起推送的機制已經創建，由服務端先發起推送請求，客戶端再進行推送響應。具體以下：

Push Requests

服務端推送語義上等同於服務端響應一個請求；然而，這種狀況下請求也是由服務端發送的，做爲一個PUSH_PROMISE幀。PUSH_PROMISE包含了一個報頭區塊，含有完整的服務端屬性請求報頭字段。推送的響應老是與客戶端的一個明確的請求相關。服務端在這個明確的請求流上發送PUSH_PROMISE幀。PUSH_PROMISE幀通常包含被承諾的流標識符，從可用的服務端流標識符中選擇。服務端應當在發送任何被承諾的響應以前發送一個PUSH_PROMISE幀。這避免了客戶端在收到任何PUSH_PROMISE幀前發出請求而出現的競賽。PUSH_PROMISE能夠由服務端在任意由客戶端打開的流上發送。

Push Responses

發送PUSH_PROMISE幀後，服務端能夠開始接收被推送進來的響應做爲一個由服務端發起的使用被承諾流標識的流的響應。一旦客戶端接收到PUSH_PROMISE幀而且選擇接受推送的響應，客戶端不該該對被承諾的響應發起請求，直到被承諾的流被關閉爲止。若是客戶端以任何理由決定不但願接受服務端推送的響應，或者服務端花費太長時間纔開始發送承諾的響應，客戶端能夠發送一個RST_STREAM幀，使用CANCEL或者REFUSED_STREAM碼來關聯被推送的流標識符。

6.首部壓縮

HTTP的每一次通訊都會攜帶一組首部，用於描述傳輸的資源及其屬性。在HTTP1.X中，這些元數據是以純文本形式發送的，一般會給每一個請求增長500-800字節的負荷。若是算上COOKIE，增長的負荷會達到上千字節，爲了減小這些開銷並提高性能，HTTP2.0會壓縮首部元數據：

• HTTP2.0在客戶端和服務器端使用「首部表」來跟蹤和存儲以前發送的鍵-值對，對於相同的數據，再也不經過每次請求和響應發送；
• 首部表在HTTP2.0的鏈接存續期內始終存在，由客戶端和服務器共同漸進的更新；
• 每一個新的首部鍵-值對要麼被追加到當前表的末尾，要麼替換表中以前的值。

因而，HTTP2.0鏈接的兩端都知道已經發送了哪些首部，這些首部的值是什麼，從而能夠針對以前的數據只編碼發送這些差別數據。在通訊期間幾乎不會改變的鍵值對只需發送一次便可，這樣就大大提升了數據的載荷。示例以下：

HTTP/1 的狀態行信息（Method、Path、Status 等），在 HTTP/2 中被拆成鍵值對放入頭部（冒號開頭的那些），一樣能夠享受到字典和哈夫曼壓縮。另外，HTTP/2 中全部頭部名稱必須小寫。
頭部壓縮須要客戶端和服務器端作好如下工做：

• 維護一份相同的靜態字典（Static Table），包含常見的頭部名稱，以及特別常見的頭部名稱與值的組合；
• 維護一份相同的動態字典（Dynamic Table），能夠動態地添加內容；
• 支持基於靜態哈夫曼碼錶的哈夫曼編碼（Huffman Coding）。

靜態字典的做用有兩個：

• 1）對於徹底匹配的頭部鍵值對，例如 :method: GET，能夠直接使用一個字符表示；
• 2）對於頭部名稱能夠匹配的鍵值對，例如 cookie: xxxxxxx，能夠將名稱使用一個字符表示。

同時，瀏覽器能夠告知服務端，將 cookie: xxxxxxx 添加到動態字典中，這樣後續整個鍵值對就可使用一個字符表示了。相似的，服務端也能夠更新對方的動態字典。須要注意的是，動態字典跟具體鏈接上下文有關，須要爲每一個 HTTP2.0 鏈接維護不一樣的字典。使用字典能夠極大地提高壓縮效果，其中靜態字典在首次請求中就可使用。對於靜態、動態字典中不存在的內容，還可使用哈夫曼編碼來減少體積。HTTP2.0 使用了一份靜態哈夫曼碼錶，也須要內置在客戶端和服務端之中。哈夫曼編碼的核心理念就是使用最少的位數表示最多的信息，HTTP2.0中這份哈夫曼編碼表是根據一個大樣本的HTTP報頭的統計數據生成，常常出現的字符會用較短的二進制數標識，出現頻率較低的字符用較長的二進制數標識，這樣就保證了綜合來看報頭信息佔用了較少的空間，進一步壓縮了報頭信息。

在服務端接收到壓縮過的報頭信息後，會先進行哈夫曼編碼解碼，獲得報首信息後，再結合維護的靜態字典和動態字典信息得出完整的報首信息，隨後進行請求的處理和響應。在須要更新動態字典信息時，對字典進行更新。

HTTP2.0壓縮算法：SPDY早期版本使用zlib和自定義的字典壓縮全部的HTTP首部，能夠減小85%-88%的首部開銷，從而顯著減小加載頁面的時間。然而，在2012年夏天，出現了針對TLS和SPDY壓縮算法的CRIME安全攻擊，因而，zlib算法被撤銷，取而代之的是前面介紹的新索引表算法。該算法沒有相似的安全問題，但能夠實現相差無幾的性能提高。

7.HTTP2.0升級與發現

向HTTP2.0的遷移不可能瞬間完成，不管服務器端仍是客戶端都須要進行必要的更新升級才能使用。好消息是，大多數現代瀏覽器都內置有高效的後臺升級機制，對大多數既有用戶來講，這些瀏覽器能夠很快的支持HTTP2.0，不會帶來很大困擾。然而，服務器端和中間設備的升級、更新就不是那麼容易，是一個長期的過程，並且很費力、費錢。

HTTP1.X至少還會存續十年以上，大多數服務器和客戶端在此期間必須同時支持1.x和2.0標準。因而，支持HTTP2.0的客戶端在發起新請求以前，必須能發現服務器及中間設備是否支持HTTP2.0協議。有如下三種狀況：

• 經過TLS和ALPN發起的新的HTTPS鏈接；
• 根據以前的信息發起的新的HTTP鏈接；
• 沒有以前的信息而發起新的HTTP鏈接；

HTTPS協商過程當中有一個環節會使用ALPN發現和協商HTTP2.0支持狀況。有 ALPN 的狀況下 TLS 握手信息中包含了客戶端支持的協議列表，服務端直接選擇 HTTP2，全部協商在握手階段一次完成，無需額外的報文。
注：應用層協議談判（ALPN）是一個TLS擴展，支持在TLS握手過程當中進行協議協商，從而省去經過HTTP的Upgrade機制所需的額外往返延遲。過程以下：

• 客戶在ClientHello消息添加新的ProtocolNameList字段，包含支持的應用程序協議列表。
• 該服務器檢查ProtocolNameList字段，並在ServerHello消息中返回一個ProtocolName字段，用來指示服務器端選擇的協議。
• 服務器可能只響應其中一個協議，若是它不支持任何客戶端要求的協議，那麼它可能選擇停止鏈接。其結果是，TLS握手完成後，安全隧道創建好了，客戶端和服務端也協商好了所使用的應用協議 - 它們能夠當即開始通訊。

經過非加密信道創建HTTP2.0鏈接須要多作一些工做，由於HTTP1.0和HTTP2.0都使用80端口，又沒有服務器是否支持HTTP2.0的其餘任何信息，此時客戶端只能使用HTTP upgrade 機制經過協商肯定適當的協議：

GET /default.htm HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

不支持HTTP/2的服務端對請求返回一個不包含升級的報頭字段的響應：

HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
...

支持HTTP/2的服務端能夠返回一個101(轉換協議)響應來接受升級請求：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
...

在101空內容響應終止後，服務端能夠開始發送HTTP/2幀。這些幀必須包含一個發起升級的請求的響應。第一個被服務端發送的HTTP/2幀是一個設置(SETTINGS)幀。在收到101響應後，客戶端發送一個包含設置(SETTINGS)幀的鏈接序言。

使用這種Upgrade流，若是服務器不支持HTTP2.0，就當即返回HTTP1.1響應。不然，服務器就會以HTTP1.1格式返回101 switching protocols響應，而後當即切換到HTTP2.0並使用新的二進制分幀協議返回響應。不管哪一種狀況，都不須要額外往返。

最後，若是客戶端由於本身保存有或經過其餘手段（如dns記錄，手工配置）得到了HTTP2.0的支持信息，也能夠直接發送HTTP2.0分幀，而沒必要依賴Upgrade機制。

8.HTTP2.0數據傳輸示例

發起新流

在發送應用數據以前，必須建立一個新流並隨之發送相應的元數據，好比優先級、HTTP首部等。HTTP2.0協議規定客戶端和服務器均可以發起流，所以有兩種可能：

• 客戶端經過發送HEADERS幀來發起流，這個幀裏包含帶有新流ID的公用首部，能夠選的31位優先值，以及一組HTTP鍵值對首部；
• 服務器端經過發送PSUH_PROMISE幀來發起推送流，這個幀與HEADERS等效，但它包含要約流ID，沒有優先值。
  HEADERS幀示例以下：
  
  這兩種幀的類型字段都只用於溝通新流的元數據，淨荷會在DATA幀中單獨發送。

  發送應用數據

  建立新流併發送HTTP首部以後，接下來就是利用DATA幀發送應用數據。應用數據能夠分爲多個DATA幀，最後一幀要翻轉幀首部的END_STREAM字段。數據淨荷不會被另行編碼或壓縮。編碼方式取決於應用或服務器，純文本，gzip壓縮、圖片或適配壓縮格式均可以。DATA幀示例以下：
  

參考資料：

• 《WEB性能權威指南》
• HPACK: Header Compression for HTTP/2
• HTTP/2 頭部壓縮技術介紹
• High Performance Browser Networking
• RFC7540(HTTP2.0)
• HTTP1.1學習筆記