網絡協定系列十六 - HTTP2/HTTP3

HTTP2、HTTP3各個版本之間的關聯。

一、HTTP協定的不足（HTTP/1.1）

1. 同一時間，一個連接配接隻能對應一個請求（注意：不是建立多個連接配接，是多個請求隻能在一個連接配接内隊列等待）。針對同一個域名，大多數浏覽器允許同時最多6個并發連接配接。
2. 隻允許用戶端主動發起請求（請求應答模式，即一個請求隻能對應一個響應）。
3. 同一個會話的多次請求中，頭資訊會被重複傳輸。通常會給每個傳輸增加500~800位元組的開銷。如果使用Cookie，增加的開銷有時會達到上千位元組。

1.1. SPDY

SPDY（speedy的縮寫），是基于TCP的應用層協定，它強制要求使用SSL/TLS。2009年11月，Google宣布将SPDY作為提高網絡速度的内部項目。

1.2. SPDY與HTTP的關系

• SPDY并不用于取代HTTP，它隻是修改了HTTP請求與響應的傳輸方式
• 隻需增加一個SPDY層，現有的所有服務端應用均不用做任何修改
• SPDY是HTTP/2的前身

2015年9月，Google宣布移除對SPDY的支援，擁抱HTTP/2。

二、HTTP/2

HTTP/2，于2015年5月以RFC_7540正式發表。根據W3Techs的資料，截止2019年6月，全球有36.5%的網站支援了HTTP/2。

HTTP/1.1和HTTP/2速度對比：http://www.http2demo.io、https://http2.akamai.com/demo

HTTP/2在底層傳輸做了很多的改進和優化，但在語意上完全與HTTP/1.1相容。比如請求方法（如GET、POST）、Status Code，各種Headers等都沒有改變，是以要想更新到HTTP/2，開發者不需要修改任何代碼，隻需要更新伺服器配置，更新浏覽器。

注意：SPDY強制使用TLS，但是HTTP/2文檔并沒有說明強制使用TLS，但在開發中還是建議使用TLS。

2.1. 基本概念

資料流： 已建立的連接配接内的雙向位元組流，可以承載一條或多條消息。所有通信都在一個TCP連接配接上完成，同一時間内此連接配接可以承載任意數量的雙向資料流。

消息： 與邏輯HTTP請求或響應消息對應，由一系列幀組成。

幀： HTTP/2通信的最小機關，每個幀都包含幀頭（會辨別出目前幀所屬的資料流），來自不同資料流的幀可以交錯發送，然後再根據每個幀頭的資料流辨別符重新組裝。

2.2. HTTP/2的特性

2.2.1. 二進制格式

HTTP/2采用二進制格式傳輸資料，而非HTTP/1.1的文本格式。

二進制格式在協定的解析和優化擴充上帶來更多的優勢和可能。

2.2.2. 多路複用（Multiplexing）

• 用戶端和伺服器可以将HTTP消息分解為互不依賴的幀，然後交錯發送，最後再在另一端把它們重新組裝起來。
• 并行交錯地發送多個請求，請求之間互不影響。
• 并行交錯地發送多個響應，響應之間互不幹擾。
• 使用一個連接配接并行發送多個請求和響應。
• 不必再為繞過HTTP/1.1限制而做很多工作，比如image sprites（精靈圖）、合并CSS/JS（一起放入一個檔案中）、内嵌CSS/JS/Base64圖檔、域名分片（n個域名就能有6n個連接配接）等。

精靈圖是前端開發中的概念，image sprites（也叫作CSS Sprites），将多張小圖合并成一張大圖，最後通過CSS（屬性

background:

）結合小圖的位置，尺寸進行精準定位。

2.2.3. 優先級

• HTTP/2标準允許每個資料流都有一個關聯的權重和依賴關系
  • 可以向每個資料流配置設定一個介于1至256之間的整數
  • 每個資料流與其他資料流之間可以存在顯式依賴關系
• 用戶端可以建構和傳遞“優先級樹”，表明它傾向于如何接收響應
• 伺服器可以使用此資訊通過控制CPU、記憶體和其他資源的配置設定設定資料流處理的優先級
  • 在資源資料可用之後，確定将高優先級響應以最優方式傳輸至用戶端

應盡可能先給父資料流配置設定資源。同級資料流（共享相同父項）應按其權重比例配置設定資源。

1. A、B依賴于隐式“根資料流”，A獲得的資源比例是12/16，B獲得的資源比例是4/16。
2. D依賴于根資料流，C依賴于D，D應先于C獲得完整資源配置設定。
3. D應先于C獲得完整資源配置設定，C應先于A和B獲得完整資源配置設定，B獲得的資源是A所獲資源的1/3。
4. D應先于E和C獲得完整資源配置設定，E和C應先于A和B獲得相同的資源配置設定，B獲得的資源是A所獲資源的1/3。

2.2.4. 頭部壓縮

HTTP/2使用HPACK壓縮請求頭和響應頭，可以極大減少頭部開銷，進而提高性能。

早期版本的HTTP/2和SPDY使用zlib壓縮，可以将所傳輸頭資料的大小減少85%~88%。但在2012年夏天，被攻擊導緻會話劫持，後被更安全的HPACK取代。

用戶端和服務端都會緩存一張請求頭靜态表（Static table），當用戶端發送請求時，會檢測用戶端側的請求頭表中是否有同樣的頭部資料，如果有，隻需要向伺服器發送頭部對應的表中資料索引即可，這樣就能減少頭部的資料，達到頭部壓縮目标。

2.2.5. 伺服器推送（Server Push）

伺服器可以對一個用戶端請求發送多個響應。除了對最初請求的響應外，伺服器還可以向用戶端推送額外資源，而無需用戶端額外明确地請求。

2.3. HTTP/2的問題

2.3.1. 隊頭阻塞（head of line blocking）

TCP在傳輸資料的時候是有順序的，而HTTP/2請求或響應是無序，如果TCP傳輸過程中，隊列頭部請求丢包，後面的請求都将無效，隻能全部重新請求或響應。這是TCP的問題，不是HTTP的問題。

QUIC協定就解決了上面隊頭阻塞問題，如果發現丢包，不影響其他資料的組裝。主要原因是QUIC底層是用UDP實作的。

2.3.2. 握手延遲

RTT（Round Trip Time）：往返時延，可以簡單了解為通信一來一回的時間。

由于TCP本身需要3次握手，使用TLS後會延遲握手時間。QUIC因為使用的是UDP，是以不存在握手環節。

三、HTTP/3

Google覺得HTTP/2仍然不夠快，于是就有了HTTP/3。

HTTP/3由Google開發，棄用TCP協定，改為使用基于UDP協定的QUIC協定實作。

QUIC（Quick UDP Internet Connections），快速UDP網絡連接配接。由Google開發，在2013年實作，于2018年從HTTP-over-QUIC改為HTTP/3。

隊頭阻塞和握手延遲是TCP的缺點，而TCP的優點是可靠傳輸。UDP和TCP進行互補就有了QUIC。

3.1. HTTP/3的特性

3.1.1. 連接配接遷移

TCP基于4要素（源IP、源端口、目标IP、目标端口）。切換網絡時至少會有一個要素發生變化，導緻連接配接發生變化。當連接配接發生變化時，如果還使用原來的TCP連接配接，則會導緻連接配接失敗，就得等原來的連接配接逾時後重建立立連接配接。是以我們有時候發現切換到一個新網絡時，即使新網絡狀況良好，但内容還是需要加載很久。如果實作的好，當檢測到網絡變化時立刻建立新的TCP連接配接，即使這樣，建立新的連接配接還是需要幾百毫秒的時間。

QUIC的連接配接不受4要素的影響，當4要素發生變化時，原連接配接依然維持。QUIC連接配接不以4要素作為辨別，而是使用一組Connection ID（連接配接ID）來辨別一個連接配接。即使IP或者端口發生變化，隻要Connection ID沒有變化，那麼連接配接依然可以維持。比如當裝置連接配接到Wi-Fi時，将進行中的下載下傳從蜂窩網絡連接配接轉移到更快速的Wi-Fi連接配接，當Wi-Fi連接配接不再可用時，将連接配接轉移到蜂窩網絡連接配接。

3.1.2. 作業系統核心、CPU負載

據Google和Facebook稱，與基于TLS的HTTP/2相比，它們大規模部署的QUIC需要近2倍的CPU使用量。因為Linux核心的UDP部分沒有得到像TCP那樣的優化，因為傳統上沒有使用UDP進行如此高速的資訊傳輸。TCP和TLS有硬體加速，而這對于UDP很罕見，對于QUIC則基本不存在。

随着時間的推移，相信這個問題會逐漸得到改善。

3.2. 疑問

• HTTP/3基于UDP，如何保證可靠傳輸？
  • 由QUIC來保證（在QUIC中加入了保證可靠傳輸的算法）
• 為何Google不開發一個新的不同于TCP、UDP的傳輸層協定？
  • 首先Google是絕對有能力開發的，主要是目前世界上的網絡裝置基本隻認TCP、UDP。如果要修改傳輸層，意味着作業系統的核心也要修改。
  • 另外，由IETF标準化的需要TCP新特性都因缺乏廣泛支援而沒有得到廣泛的部署或使用。
  • 是以，要想開發并應用一個新的傳輸層協定，是極其困難的一件事情。

HTTP/3還在優化中（不成熟），是以現在大部分公司還是使用的HTTP/2或者HTTP/1.1。