HTTP/3展望、我應該遷移到HTTP/2嗎

1. HTTP/3展望

HTTP/3 基于 QUIC 協議，完全解決了“隊頭阻塞”問題，弱網環境下的表現會優于 HTTP/2；
QUIC 是一個新的傳輸層協議，建立在 UDP 之上，實現了可靠傳輸；
QUIC 內含了 TLS1.3，只能加密通信，支持 0-RTT 快速建連；
QUIC 的連接使用“不透明”的連接 ID，不綁定在“IP 地址 + 端口”上，支持“連接遷移”；
QUIC 的流與 HTTP/2 的流很相似，但分為雙向流和單向流；
HTTP/3 沒有指定默認端口號，需要用 HTTP/2 的擴展幀“Alt-Svc”來發現。

1.1. HTTP/2 的“隊頭阻塞”

HTTP/2 雖然使用“幀”“流”“多路復用”，沒有了“隊頭阻塞”，但這些手段都是在應用層里，而在下層，也就是 TCP 協議里，還是會發生“隊頭阻塞”。

在 HTTP/2 把多個“請求 - 響應”分解成流，交給 TCP 后，TCP 會再拆成更小的包依次發送（其實在 TCP 里應該叫 segment，也就是“段”）。

在網絡良好的情況下，包可以很快送達目的地。但如果網絡質量比較差，像手機上網的時候，就有可能會丟包。而 TCP 為了保證可靠傳輸，有個特別的“丟包重傳”機制，丟失的包必須要等待重新傳輸確認，其他的包即使已經收到了，也只能放在緩沖區里，上層的應用拿不出來，只能“干著急”。

舉例：

客戶端用 TCP 發送了三個包，但服務器所在的操作系統只收到了后兩個包，第一個包丟了。那么內核里的 TCP 協議棧就只能把已經收到的包暫存起來，“停下”等著客戶端重傳那個丟失的包，這樣就又出現了“隊頭阻塞”。

“HTTP over QUIC”就是 HTTP 協議的下一個大版本，HTTP/3。它在 HTTP/2 的基礎上又實現了質的飛躍，真正“完美”地解決了“隊頭阻塞”問題。

1.2. QUIC 協議

QUIC 最早是由 Google 發明的，被稱為 gQUIC。而當前正在由 IETF 標準化的 QUIC 被稱為 iQUIC。兩者的差異非常大。

gQUIC 混合了 UDP、TLS、HTTP，是一個應用層的協議。而 IETF 則對 gQUIC 做了“清理”，把應用部分分離出來，形成了 HTTP/3，原來的 UDP 部分“下放”到了傳輸層，所以 iQUIC 有時候也叫“QUIC-transport”。

以下說的 QUIC 都是指 iQUIC，它與早期的 gQUIC 不同，是一個傳輸層的協議，和 TCP 是平級的。

QUIC 的特點

1. 基于UDP的高效傳輸

QUIC使用UDP作為底層協議，避免了TCP協議因中間設備（如防火墻、路由器）的僵化導致的部署難題，同時繞開了TCP的隊頭阻塞問題

2. 多路復用與消除隊頭阻塞（HOL Blocking）

獨立邏輯流：QUIC支持在單個連接上并行傳輸多個獨立的邏輯數據流（Stream），每個流的數據包可亂序傳輸且互不影響。即使某個流的數據包丟失，其他流仍可正常處理，徹底解決了TCP層和應用層的隊頭阻塞問題。

與HTTP/2的對比：HTTP/2雖支持多路復用，但仍依賴TCP，一旦發生丟包，所有流需等待重傳；而QUIC通過UDP和流隔離機制，僅影響丟失的流。

3. 快速握手與低延遲

4. 內置安全性與加密

5. 連接遷移與網絡適應性

QUIC連接通過64位Connection ID標識，而非TCP的四元組（源IP、端口等）。即使設備切換網絡（如WiFi轉4G），連接仍可保持不斷，適合移動場景。

6. 可靠性與流控機制

QUIC 內部細節

QUIC 的基本數據傳輸單位是包（packet）和幀（frame），一個包由多個幀組成，包面向的是“連接”，幀面向的是“流”。

QUIC 使用不透明的“連接 ID”來標記通信的兩個端點，客戶端和服務器可以自行選擇一組 ID 來標記自己，這樣就解除了 TCP 里連接對“IP 地址 + 端口”（即常說的四元組）的強綁定，支持“連接遷移”（Connection Migration）。

QUIC 的幀里有多種類型，PING、ACK 等幀用于管理連接，而 STREAM 幀專門用來實現流。

QUIC 里的流與 HTTP/2 的流非常相似，也是幀的序列，你可以對比著來理解。但 HTTP/2 里的流都是雙向的，而 QUIC 則分為雙向流和單向流。

流 ID 還保留了最低兩位用作標志，第 1 位標記流的發起者，0 表示客戶端，1 表示服務器；第 2 位標記流的方向，0 表示雙向流，1 表示單向流。

所以 QUIC 流 ID 的奇偶性質和 HTTP/2 剛好相反，客戶端的 ID 是偶數，從 0 開始計數。

1.3. HTTP/3 協議

HTTP/3 把流控制都交給 QUIC 去做。調用的不再是 TLS 的安全接口，也不是 Socket API，而是專門的 QUIC 函數。

HTTP/3 里仍然使用流來發送“請求 - 響應”，但它自身不需要像 HTTP/2 那樣再去定義流，而是直接使用 QUIC 的流，相當于做了一個“概念映射”。

由于流管理被“下放”到了 QUIC，所以 HTTP/3 里幀的結構也變簡單了。幀頭只有兩個字段：類型和長度，而且同樣都采用變長編碼，最小只需要兩個字節。

HTTP/3 里的幀仍然分成數據幀和控制幀兩類，HEADERS 幀和 DATA 幀傳輸數據，但其他一些幀因為在下層的 QUIC 里有了替代，所以在 HTTP/3 里就都消失了，比如 RST_STREAM、WINDOW_UPDATE、PING 等。

頭部壓縮算法在 HTTP/3 里升級成了“QPACK”，使用方式上也做了改變。雖然也分成靜態表和動態表，但在流上發送 HEADERS 幀時不能更新字段，只能引用，索引表的更新需要在專門的單向流上發送指令來管理，解決了 HPACK 的“隊頭阻塞”問題。

HTTP/3的服務發現：

HTTP/3 沒有指定默認的端口號，也就是說不一定非要在 UDP 的 80 或者 443 上提供 HTTP/3 服務。

瀏覽器需要先用 HTTP/2 協議連接服務器，然后服務器可以在啟動 HTTP/2 連接后發送一個“Alt-Svc”幀，包含一個“h3=host:port”的字符串，告訴瀏覽器在另一個端點上提供等價的 HTTP/3 服務。
瀏覽器收到“Alt-Svc”幀，會使用 QUIC 異步連接指定的端口，如果連接成功，就會斷開 HTTP/2 連接，改用新的 HTTP/3 收發數據。

2. 應該遷移到HTTP/2嗎？

HTTP/2 完全兼容 HTTP/1，是“更安全的 HTTP、更快的 HTTPS”，頭部壓縮、多路復用等技術可以充分利用帶寬，降低延遲，從而大幅度提高上網體驗；
TCP 協議存在“隊頭阻塞”，所以 HTTP/2 在弱網或者移動網絡下的性能表現會不如 HTTP/1；
遷移到 HTTP/2 肯定會有性能提升，但高流量網站效果會更顯著；
如果已經升級到了 HTTPS，那么再升級到 HTTP/2 會很簡單；
TLS 協議提供“ALPN”擴展，讓客戶端和服務器協商使用的應用層協議，“發現”HTTP/2 服務。

2.1. HTTP/2的主要優點

1. 多路復用（Multiplexing）

核心改進：在單個TCP連接上并行傳輸多個請求/響應，徹底解決HTTP/1.x的“隊頭阻塞”問題（應用層）。
效果：減少延遲、提升連接利用率，避免瀏覽器為并發請求建立多個TCP連接（如HTTP/1.1的6~8個連接限制）。

2. 頭部壓縮（HPACK）

技術：使用HPACK算法壓縮HTTP頭部，消除冗余字段（如重復的Cookie、User-Agent）。
效果：減少數據傳輸量，提升弱網環境下的性能（尤其對移動端和小型請求顯著）。

3. 服務器推送（Server Push）

功能：服務器可主動向客戶端推送資源（如CSS/JS文件），無需等待客戶端解析HTML后發起請求。
場景：優化首次頁面加載速度，減少往返次數（RTT）。

4. 二進制協議

格式：將HTTP/1.x的文本格式改為二進制分幀（Frame），解析更高效，避免文本歧義（如空格、大小寫）。
效果：降低解析復雜度，提升傳輸可靠性。

5. 流優先級與依賴控制

機制：允許客戶端為請求設置優先級（如優先加載HTML/CSS，延遲加載圖片）。
效果：優化關鍵資源的加載順序，提升用戶體驗。

2.2. HTTP/2的主要缺點

1. TCP層隊頭阻塞未解決

問題：HTTP/2依賴TCP協議，若傳輸層發生丟包，所有流需等待丟失包重傳，導致性能下降。
影響：在高丟包率網絡（如移動網絡）中，HTTP/2可能比HTTP/1.1更慢（后者可多連接規避）。

2. 服務器推送的局限性

實現復雜：需服務器準確預測客戶端所需資源，推送錯誤內容會浪費帶寬。
緩存問題：客戶端可能已緩存推送資源，導致冗余傳輸。
實際采用率低：多數網站未廣泛使用此功能，部分瀏覽器已棄用（如Chrome 106+）。

3. 強制依賴HTTPS

現狀：主流瀏覽器（如Chrome、Firefox）僅支持加密的HTTP/2（基于TLS）。
代價：需維護證書和TLS配置，對簡單內網服務可能增加復雜度。

4. 協議復雜性提升

實現難度：二進制分幀、流控制、優先級等機制增加了協議棧復雜度，可能引入新類型Bug（如流狀態管理錯誤）。
調試困難：二進制協議需要專用工具（如Wireshark）分析流量，調試門檻高于HTTP/1.x的文本協議。

5. 中間設備兼容性問題

代理與防火墻：部分老舊中間設備（如傳統代理服務器）不完全支持HTTP/2，可能導致連接降級或失敗。

2.3. 適用場景與替代方案

場景	推薦協議	原因
高延遲、低丟包網絡	HTTP/2	多路復用顯著減少RTT，頭部壓縮節省帶寬。
高丟包率網絡（如4G/5G）	HTTP/3	QUIC解決TCP隊頭阻塞，適應弱網環境。
簡單低頻請求	HTTP/1.1	協議簡單，兼容性更好，無額外性能負擔。