使用頭部壓縮（字典）
二進制成幀層解決了隊列頭阻塞，因為Http1.0發送的數據是有序的，客戶端可以處理交錯的返回數據順序。
多路復用允許單個HTTP/2連接同時發起多個請求-響應消息。看壹個例子:
整個訪問過程首先請求index.html頁面，然後瀏覽器會請求style.css和scripts.js文件。左圖是順序加載兩個文件，右圖是並行加載兩個文件。
我們知道HTTP的底層實際上依賴於TCP協議，那麽問題是，兩個請求如何在同壹連接中同時響應？
首先，您應該知道TCP連接相當於兩條管道（壹條用於服務器到客戶端，另壹條用於客戶端到服務器）。管道中的數據傳輸是通過字節碼傳輸的（TCP是面向字節的），傳輸是有序的，每個字節都是逐個傳輸的。
比如客戶端要向服務端發送Hello和World，只能先發送Hello再發送World，不可能同時發送這兩個字。否則，服務器可能會收到HWeolrllod（請註意，它是交替發送的，但順序不會打亂）。這將使服務器變得愚蠢。
按照上面的問題，妳能同時發送Hello和World這兩個字嗎？當然也有可能。妳可以把數據分成包並給每個包貼上標簽。發的時候是這樣的:1 H2 w1e 2 o 1 l 2r 2 l 02d。所以當我們到達服務器時，服務器會根據標簽區分這兩個單詞。實際發送效果如下:
為了達到上述效果，我們引入了壹個新概念:二進制框架。
二進制成幀層位於應用層（HTTP/2）和傳輸層（TCP或UDP）之間。HTTP/2不修改TCP協議，而是盡可能利用TCP的特性。
在二進制成幀層中，HTTP/2將所有傳輸的信息分成幀並以二進制格式進行編碼，其中報頭信息將封裝在報頭幀中，相應的請求體將封裝在數據幀中。
HTTP性能優化的關鍵不是高帶寬，而是低延遲。TCP連接會隨著時間的推移進行自我“調整”，最初會限制連接的最大速度，如果數據成功傳輸，它會隨著時間的推移提高傳輸速度。這種調整被稱為TCP慢啟動。由於這個原因，突然而短暫的HTTP連接變得非常低效。
通過對所有數據流使用相同的連接，HTTP/2可以更有效地使用TCP連接，從而高帶寬可以真正服務於HTTP的性能改進。
通過下面兩張圖片，我們可以對復用有更深入的了解:
HTTP/1
HTTP/2
綜上所述:復用技術:單連接多資源的方式，減輕服務器的鏈路壓力，占用內存少，增加連接吞吐量；由於TCP的慢啟動時間減少，傳輸速度提高。
為什麽要壓縮？在HTTP/1中，HTTP請求和響應由三部分組成:狀態行、請求/響應頭和消息體。壹般來說，消息正文由gzip壓縮，或者壓縮後的二進制文件（如圖片和音頻）自行傳輸，但狀態行和標頭直接作為純文本傳輸，不進行任何壓縮。
隨著Web功能的日益復雜，每個頁面產生的請求數量也在增加，這導致頭部消耗的流量越來越多，尤其是不會頻繁更改的內容，例如UserAgent和Cookie，這完全是壹種浪費。
讓我們用通俗的語言解釋壓縮的原理。報頭壓縮需要在支持HTTP/2的瀏覽器和服務器之間進行。
維護相同的靜態表，包括常見的標題名稱以及特別常見的標題名稱和值的組合；
維護同壹個動態表，可以動態添加內容；
支持霍夫曼編碼）；基於靜態霍夫曼碼表；
靜態字典有兩個功能:
1）對於完全匹配的頭鍵值對，如“:method :GET”，可以直接用壹個字符表示；
2）對於標題名稱可以匹配的鍵值對，如“cookie :xxxxxxx”，名稱可以用壹個字符表示。
HTTP/2中的靜態字典如下（下面只截取了壹部分，完整表格在此）:
同時，瀏覽器和服務器都可以向動態字典添加壹個鍵值對，然後該鍵值對可以用壹個字符表示。應該註意的是，動態字典是上下文相關的，並且需要為每個HTTP/2連接維護不同的字典。在傳輸過程中，使用字符而不是鍵值對大大減少了傳輸的數據量。
服務器端推送是壹種在客戶端請求數據之前發送數據的機制。當代網頁使用許多資源:HTML、樣式表、腳本、圖片等等。這些資源中的每壹個都必須在http/1.x中明確請求。這可能是壹個非常緩慢的過程。瀏覽器從獲取HTML開始，然後在解析和評估頁面時逐步獲取更多資源。因為服務器必須等待瀏覽器發出每壹個請求，所以網絡經常處於閑置狀態且未得到充分利用。
為了改善延遲，HTTP/2引入了服務器推送，它允許服務器在瀏覽器顯式請求資源之前將資源推送到瀏覽器。服務器通常知道壹個頁面需要大量的額外資源，當它響應瀏覽器的第壹個請求時，它可以開始推送這些資源。這使得服務器可以充分利用潛在的空閑網絡並縮短頁面加載時間。