互聯網傳輸協議這幾年變化很大。HTTP/2 剛普及沒多久，HTTP/3 就來了。這次升級不像以前修修補補，而是直接把底層的 TCP 協議換成了基於 UDP 的 QUIC。這麼大的動靜，主要是為了解決 HTTP/2 在弱網環境下表現不佳的問題。
一、HTTP/2 有什麼問題？
HTTP/2 雖然有多路複用（一個連接傳多個文件），看似解決了併發問題，但底層的 TCP 協議沒變。TCP 是按順序傳輸的，只要有一個數據包丟了，操作系統就會暫停後續所有數據的交付，等待這個包重傳回來。這就是所謂的“隊頭阻塞”（Head-of-Line Blocking）。
在網絡狀況好的時候（比如辦公室 WiFi），HTTP/2 很快；但一旦到了信號不好的地方（比如地鐵、電梯裏），丟包率一上來，HTTP/2 甚至還不如 HTTP/1.1 穩定。HTTP/3 就是為了解決這個問題來的，它即使在丟包嚴重的網絡下，也能保持流暢。
二、QUIC 協議強在哪？
1. 0-RTT 建連（握手非常快）
以前用 TCP+TLS，建立連接得一來一回好幾次（2-3 個 RTT）。QUIC 也就是 HTTP/3 的底層協議，如果是第二次連接，直接 0-RTT，也就是發出的第一個包裏就帶着加密數據，沒有握手等待時間。
2. 沒有隊頭阻塞
QUIC 也是多路複用，但它基於 UDP，每個流（Stream）之間是真正獨立的。A 文件丟包了，隻影響 A，B/C/D 照樣傳輸，互不干擾。
3. 切換網絡不斷線
用 TCP 的時候，你從 WiFi 切到 4G，IP 變了，連接就斷了，必須重新建立。QUIC 用一個叫 Connection ID 的東西標識連接，不管你 IP 怎麼變，只要 ID 還是那個，連接就一直保持。打遊戲、看直播的時候切換網絡，幾乎感覺不到卡頓。
4. 擁塞控制更靈活
TCP 的擁塞控制寫在系統內核裏，想升級很難。QUIC 是在應用層實現的，升級算法（比如 BBR）就像升級 APP 一樣簡單，可以針對即時通訊、視頻點播等不同場景用不同的策略。
三、HTTP/2 vs HTTP/3 實測對比
| 場景 | HTTP/2 (TCP) | HTTP/3 (QUIC) |
|---|---|---|
| 弱網環境（高丟包） | 卡頓明顯，速度慢 | 依然流暢，提升 20% - 50% |
| 握手延遲 | 200-300ms | 0-100ms |
| 網絡切換 | 連接中斷，需重連 | 連接平滑遷移，無感知 |
四、怎麼部署 HTTP/3？
1. 服務器端
- Nginx：1.25+ 版本已經正式支持了，但配置起來稍顯複雜，需要配合 OpenSSL QUIC 分支。
- Caddy：默認就開啓了 HTTP/3，比較省心。
- CDN：由於配置複雜，最簡單的辦法是直接用支持 HTTP/3 的 CDN（比如飛盾雲），源站不用動，邊緣節點幫你搞定協議轉換。
2. 瀏覽器兼容性
現在的 Chrome、Firefox、Edge、Safari 都默認支持了。瀏覽器會通過響應頭裏的 `Alt-Svc` 字段發現服務器支持 HTTP/3，下次請求就會自動切過去。
3. 怎麼看生效沒？
打開 Chrome 開發者工具 -> Network，右鍵表頭勾選 Protocol，如果看到 `h3`，那就是成功了。
飛盾雲 HTTP/3 加速方案
飛盾雲 CDN 已經全線支持 HTTP/3：
- 無感接入：源站哪怕只支持 HTTP/1.1 也沒關係，我們在邊緣節點處理 HTTP/3 連接。
- 智能回退：如果用户網絡環境（比如某些公司內網）封了 UDP，會自動退回到 HTTP/2，保證能訪問。
- 針對性優化：針對視頻和動態 API 場景做了專門的擁塞控制調優。
總結
HTTP/3 對移動端用户多的應用提升尤其明顯。如果你的用户經常在弱網環境（比如移動數據網絡）下使用，或者對延遲很敏感，值得儘早接入。