譯者 | 陳峻
審校 | 重樓
如果你關注數據傳輸的性能、可靠性、以及在為移動應用布局的話，是時候測試和啟用HTTP/3了。
由互聯網工程任務組（IETF）于2015年正式發布下一代HTTP協議--HTTP/2，旨在解決當時HTTP/1.1協議存在的性能瓶頸問題，提升網絡傳輸效率。不過，盡管HTTP/2有著諸多承諾，但網絡延遲與抖動仍存在于現實的網絡世界中。目前，HTTP/3已面市，它并非單純的升級，而是對用戶數據報協議（UDP）的重新設計。下面，讓我們來詳細了解真實用戶的使用感受，以及廣泛的互聯網性能監控。
HTTP/2的核心限制
當HTTP/2推出時，它通過引入多路復用、二進制幀和標頭壓縮，來解決HTTP/1.1的局限性。然而，其最大的缺陷在于它仍然與TCP綁定。而TCP是一種并不適合現代多路網絡工作負載的協議。其具體表現在：
- TCP行頭（head-of-line，HOL）的阻塞：盡管HTTP/2允許在單個連接中跑多個傳輸流，但由于TCP的有序交付要求，一旦丟失的TCP數據包則會阻斷掉所有傳輸流。
- 連接設置的開銷：建立HTTP/2連接往往需要經歷：DNS解析→TCP握手→TLS握手（通常使用應用層協議進行協商）的過程。
- 恢復處罰：數據包丟失會觸發TCP級別的重新傳輸。由于增加了首字節（TTFB）和交互時間（TTI），因此這往往會影響到整個連接。而用戶在真實使用中確實能感受到由HTTP/2代理引發的抖動、丟包、延遲、以及可靠性降低。
HTTP/3如何解決TCP的核心瓶頸
其實，HTTP/3并非簡單地將HTTP/2應用到UDP上，而是為當前互聯網重新構建了HTTP/2，并運行在QUIC（快速UDP互聯網連接）上。此處的QUIC是由谷歌設計的傳輸協議。雖然用到了UDP，但它是一套針對可靠性、加密和性能而自行構建的技術棧。總的來說，HTTP/3的主要優勢在于：
- 無行頭阻塞：QUIC支持完全獨立的傳輸流。即使某個傳輸流中出現了丟失包，也不會阻止其他數據包的傳輸。
- 更快的握手：QUIC結合了加密和傳輸設置。TLS 1.3直接被集成到了QUIC中，以允許1-RTT（往返時間）甚至0-RTT的恢復。
- 恢復的改進：QUIC使用了數據包編號和ACK（確認）范圍，而非序號，因此具有更智能的擁塞控制和恢復機制。
- 連接的遷移：QUIC連接可以在IP變更中留存下來。這對于在Wi-Fi和LTE之間切換的移動網絡來說非常實用。此外，在高丟包率的條件下，HTTP/3仍能縮短現實傳輸的等待和加載時間。
HTTP/3工作原理
為了充分讀懂HTTP/3的工作原理，我們需要了解瀏覽器、DNS和緩存層，并獲悉它們是如何相互協同的。
1.初始DNS查詢
該過程始于客戶端對A/AAAA記錄執行DNS查詢時。該查詢會將IPV6映射到相應的域名上。為了讓HTTP/3使用UDP之上的QUIC，服務端必須向客戶端發出支持QUIC的信號。此類信號主要有兩種方式：
- DNS級別：服務端可以使用HTTPS記錄（特別是各種服務綁定的參數或SvcParams）直接在DNS響應中包含對QUIC的支持，以告知客戶端支持QUIC（以及HTTP/3）。示例：_443._tcp.example.com. IN HTTPS 1 . alpn="h3, h2"
- 瀏覽器級別：如果不通過DNS提供QUIC信息，服務端在初始化HTTP/2連接期間，仍可能在響應標頭中發出支持HTTP/3的信號。此處的Alt-Svc標頭（例如，alt-svc: h3=":443"; ma=2592000）被包含在服務端的HTTP/2響應中，以通知瀏覽器HTTP/3可用，客戶端需將其用于后續的連接。
2.Alt-Svc廣告
如果存在Alt-Svc標頭，則：
- 瀏覽器在ma（max-age）參數所定義的持續時間內對其緩存。
- 在后續訪問時，瀏覽器直接嘗試HTTP/3，而無需先通過HTTP/2進行協商。
3.瀏覽器的緩存行為
一旦Alt-Svc被緩存：
- 瀏覽器將對于后續同一來源的連接，優先考慮HTTP/3。
- 如果QUIC連接失敗（例如出現被阻止的UDP或NAT問題），瀏覽器會通過TCP靜默地返回HTTP/2，而不會中斷用戶的瀏覽體驗。
4.TLS握手中的ALPN
應用層協議協商（ALPN）會在TLS握手期間被用于協商HTTP的版本：
- 如果服務端支持HTTP/3，它便會發布h3 ALPN字符串。
- QUIC握手則會啟用a1-RTT連接（如果使用的是會話恢復的話，則啟用0-RTT）。
- 如果服務不支持h3，客戶端將會自動降回到HTTP/2。
5.回退流（可通過Wireshark觀察到）
以下是HTTP/3在實踐中能夠發揮的作用：
- 瀏覽器根據A/AAAA記錄（可能還有HTTPS/SVCB或服務綁定記錄）發送DNS查詢。
- 它嘗試向目標IP和端口進行QUIC握手。
- 如果在較短的超時窗口（通常為300-500毫秒）內沒有收到QUIC響應，瀏覽器將并行啟動TCP握手。
可見，瀏覽器上發生的實際上是QUIC和TCP的連接“比拼”，即：在完成握手后，判斷：
- 如果QUIC成功，則使用HTTP/3。
- 如果QUIC被阻止或超時，基于TCP的HTTP/2將接管。
這種雙握手模式確保了HTTP/3為首選，如果需要，則可以優雅地回退到HTTP/2，且不會影響用戶的體驗。就兼容性而言：
- Chrome和Firefox都能夠支持這種回退機制。
- 而Microsoft Edge相對保守，可能需要手動啟用HTTP/3或實驗性設置，才能進行一致性的測試。
讓我們再從性能方面進行考慮：
- 雖然回退較快，但并非瞬時，因此盡管QUIC與TCP的競賽最大限度地減少了中斷，但是在回退到TCP時可能會帶來較小的延遲，特別是在高損耗或高延遲環境中。
- 而在網絡狀況的影響方面：在出現Aggressive NAT、以及網絡抖動或數據包丟失率過高等情況時，QUIC的連接也可能會中斷或失敗。此類情況在亞太地區和非洲尤為明顯。
總的說來，HTTP/3的雙回退策略（無論是通過DNS的HTTPS記錄，還是Alt-Svc標頭發起）都能夠提供強大、用戶透明的協議協商功能。即使在次優的網絡條件下，瀏覽器也可以通過回退到HTTP/2來保持連接，以確保可靠性。
部署注意事項
盡管具有架構優勢，但是HTTP/3并非隨處可用。在現實世界的網絡中，仍然會有如下障礙，可能會影響到它的可靠性，甚至完全阻止其被使用。
關鍵的環境依賴性：
- 中間層和防火墻：A.許多企業防火墻和一些傳統路由器會阻止或降低UDP流量的優先級。
B.QUIC（以及h3擴展）使用UDP端口443，但并非所有網絡都配置為允許使用該端口。 - 運營商級NAT（CGNAT）：A.在移動和共享IP環境中，QUIC的連接ID是一個很大的優勢，但如果NAT映射過期設置太短或被快速重新分配，則會導致QUIC的中斷。
- 舊路由器和網絡設備：A.一些較舊的路由器可能無法很好地處理高速UDP，導致在高吞吐量QUIC會話期間出現數據包的抖動或丟失。
- TLS卸載和代理：
A.在卸載了TLS的邊緣架構處（如一些反向代理或負載平衡器），可能無法原生地支持QUIC，或需要架構的調整。
回退是一項特征，而并非失敗
當QUIC因上述任何原因被阻止或失敗時，現代化的瀏覽器和CDN會優雅地回退到HTTP/2，這也是h3的精妙之處。下表是兩代技術的比較：
特點 | HTTP/1.1 | HTTP/2 | HTTP/3 |
傳輸協議 | TCP | TCP | UDP + QUIC |
多路復用級別 | 無（每個連接1個請求） | 應用層（多個流） | 傳輸層（QUIC原生流） |
并發請求/域 | 約6個（瀏覽器限制） | 通過流媒體且無限制 | 通過流媒體且無限制 |
行頭阻塞 | 在應用程序/瀏覽器級別 | 是的（TCP級HoL會影響所有流） | 否（QUIC避免了傳輸級的HoL） |
性能（多資產） | 排隊并被封鎖 | 并行加載 | 并行、更適合在較差的網絡中 |
TLS支持 | 可選/通過TCP | 強制性（TLS 1.2/1.3） | 內置（僅限TLS 1.3） |
握手RTT | 2–3個RTT（TCP + TLS） | 2–3個RTT | 1個RTT（0-RTT恢復后） |
0-RTT支持 | 不 | 不 | 是（在恢復連接時） |
IP移動性/NAT重新綁定 | 不 | 不 | 是（通過QUIC連接ID） |
連接恢復 | TLS會話ID/單 | TLS會話恢復 | QUIC-原生連接ID |
連接重用 | 有限的 | 是 | 是 |
傳輸流優先級 | 不 | 是 | 是 |
需要加密 | 不 | 通常強制執行 | 始終（QUIC通過設計加密） |
瀏覽器/CDN支持 | 通用 | 完全支持 | 快速增加（Chrome、Safari等） |
丟包狀況 | 影響整個連接 | 影響所有多路流 | 隔離到單個傳輸流 |
最佳用例 | 傳統系統，向后兼容 | 帶有常規網絡流量的穩定網絡 | 現代應用程序、移動、有損或高延遲網絡 |
現實世界正在加速采用HTTP/3
讓我們來查看一些基于年份的數據：
年份 | HTTP/2的采用 | HTTP/3的采用 |
2022 | ~63% | ~22%（參考QUIC） |
2023 | ~64% | ~28% |
2024 | ~50% | ~34% |
2025（預計） | ~62.5% | ~41.5% |
2026年（預計） | ~52.5% | ~57.5% |
其中：
- Cloudflare、Fastly和Akamai等CDN現在已默認啟用HTTP/3。
- Chrome、Firefox、Safari和Edge都支持HTTP/3。
- 支持HTTP/3的網站呈增長趨勢，特別是在那些注重性能的地區。
HTTP/3的重要特性
根據我們的經驗和現實世界的測試，HTTP/3在以下領域意義重大：
- 高延遲和損包地區：非洲、東南亞偏遠的拉丁美洲城市。
- 移動網絡：在LTE和Wi-Fi之間頻繁切換。
- 密集API的應用：通過非阻塞多路復用受益于多并發調用。
- 性能第一團隊：愿意投資于毫秒級改進的團隊（如Core Web Vitals）。
真實測試洞見
我們使用跨多個國家的分布式主干節點，采用強制協議模式在HTTP/2和HTTP/3之間進行并行比較。測量了以下方面：
- DNS、連接、SSL、等待、加載時間
- 跨區域的h2和h3之間的性能
- 數據包丟失/抖動與協議回退的相關性
在幾乎每個涉及非理想條件的情況下，HTTP/3在等待和加載時間上都優于HTTP/2。
性能分析
通過對在六個國家運行的性能比較與分析，基于數千次運行結果，我們測量了首字節時間（TTFB）、最大內容顯示（Largest Contentful Paint，LCP）和視覺完整性（VC）的中位數與第99百分位的數值，結果表明HTTP/3在關鍵網絡性能指標上始終優于HTTP/2。
HTTP/3的主要改進
測量指標 | 改進（%） |
首字節到達時間的中位數（毫秒） | 41.80% |
首字節第99百分位到達時間的中位數（毫秒） | 7.30% |
最大內容顯示中位數（毫秒） | 10.40% |
最大內容顯示第99百分位數（毫秒） | 9.60% |
視覺完成中位數（毫秒） | 10.50% |
視覺完成第99百分位數（毫秒） | 8.60% |
如上表所示，HTTP/3大幅減少了TTFB中位數（平均41.8%）。可見，在所有測試區域中，初始服務端的響應時間與HTTP/2相比要快得多。同時，最大內容顯示（LCP）和視覺完成（VC）的改進也是一致的（平均約10%）。這意味著用戶使用HTTP/3能夠更快地看到最多的內容和完整的頁面。
國家級細分
國家 | TTFB Mdn | TTFB 99th | LCP Mdn | LCP 99th | VC Mdn | VC 99th |
澳大利亞 | 84.10% | 4.10% | 14.90% | 16.40% | 18.70% | 16.30% |
巴西 | 15.80% | -11.60% | 7.60% | 0.80% | 3.20% | -2.30% |
德國 | 78.70% | 13.80% | 19.10% | 8.80% | 21.90% | 12.50% |
日本 | 10.90% | 27.30% | 4.70% | 20.70% | 1.00% | 11.80% |
英國 | 47.10% | 8.80% | 14.40% | 7.90% | 15.70% | 10.10% |
美國 | 13.80% | 1.30% | 1.70% | 3.10% | 2.50% | 3.30% |
如上表所示：
- 澳大利亞和德國通過HTTP/3（超過78%）得到了最大的TTFB改進，同時轉化為LCP和VC的顯著提升。
- 巴西的第99百分位數TTFB和VC顯示了負改善。該異常情況表明，在最慢的請求中，HTTP/3的表現不如HTTP/2。
- 日本、英國和美國在大多數指標上，顯示出了適度且一致的改善，特別是在中位數方面。
其他觀察
- 一致性：中位數的改進通常大于第99百分位數，表明HTTP/3對于那些典型（非極端）用戶的體驗特別奏效。
- 區域差異性：雖然HTTP/3總體向好，但是實際改進程度因地而異，這與各地網絡基礎設施和延遲有關。
實際上，在多個國家的真實骨干測試中，HTTP/3一直優于HTTP/2。這在澳大利亞和德國最為明顯。它在減少初始化響應時間（TTFB）和頁面渲染速度（LCP、VC）上的合理改善已卓見成效。相關案例也表明，HTTP/3可以為那些延遲敏感的應用程序，帶來網絡性能上的提升。而在巴西等一些地區的個案中，瀏覽器連接仍傾向于用HTTP/2來處理最慢的請求。
小結
綜上所述，HTTP/3不僅能提供更快的速度，而且具有一定的魯棒性。如果你關注數據傳輸的性能、可靠性、以及在為移動應用布局的話，是時候測試和啟用HTTP/3了。無論是自運營的基礎設施，還是使用第三方CDN，由HTTP/3帶來的協議上的演變，必將為現實世界中上億規模的用戶帶來更快的互聯網瀏覽體驗。
譯者介紹
陳峻（Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。
原標題：HTTP/3 in the Wild: Why It Beats HTTP/2 Where It Matters Most，作者：Wasil Banday
