譯者 | 陳峻

審校 | 重樓

如果你關(guān)注數(shù)據(jù)傳輸?shù)男阅?、可靠性、以及在為移動?yīng)用布局的話，是時候測試和啟用HTTP/3了。

由互聯(lián)網(wǎng)工程任務(wù)組（IETF）于2015年正式發(fā)布下一代HTTP協(xié)議--HTTP/2，旨在解決當(dāng)時HTTP/1.1協(xié)議存在的性能瓶頸問題，提升網(wǎng)絡(luò)傳輸效率。不過，盡管HTTP/2有著諸多承諾，但網(wǎng)絡(luò)延遲與抖動仍存在于現(xiàn)實的網(wǎng)絡(luò)世界中。目前，HTTP/3已面市，它并非單純的升級，而是對用戶數(shù)據(jù)報協(xié)議（UDP）的重新設(shè)計。下面，讓我們來詳細(xì)了解真實用戶的使用感受，以及廣泛的互聯(lián)網(wǎng)性能監(jiān)控。

HTTP/2的核心限制

當(dāng)HTTP/2推出時，它通過引入多路復(fù)用、二進制幀和標(biāo)頭壓縮，來解決HTTP/1.1的局限性。然而，其最大的缺陷在于它仍然與TCP綁定。而TCP是一種并不適合現(xiàn)代多路網(wǎng)絡(luò)工作負(fù)載的協(xié)議。其具體表現(xiàn)在：

• TCP行頭（head-of-line，HOL）的阻塞：盡管HTTP/2允許在單個連接中跑多個傳輸流，但由于TCP的有序交付要求，一旦丟失的TCP數(shù)據(jù)包則會阻斷掉所有傳輸流。
• 連接設(shè)置的開銷：建立HTTP/2連接往往需要經(jīng)歷：DNS解析→TCP握手→TLS握手（通常使用應(yīng)用層協(xié)議進行協(xié)商）的過程。
• 恢復(fù)處罰：數(shù)據(jù)包丟失會觸發(fā)TCP級別的重新傳輸。由于增加了首字節(jié)（TTFB）和交互時間（TTI），因此這往往會影響到整個連接。而用戶在真實使用中確實能感受到由HTTP/2代理引發(fā)的抖動、丟包、延遲、以及可靠性降低。

HTTP/3如何解決TCP的核心瓶頸

其實，HTTP/3并非簡單地將HTTP/2應(yīng)用到UDP上，而是為當(dāng)前互聯(lián)網(wǎng)重新構(gòu)建了HTTP/2，并運行在QUIC（快速UDP互聯(lián)網(wǎng)連接）上。此處的QUIC是由谷歌設(shè)計的傳輸協(xié)議。雖然用到了UDP，但它是一套針對可靠性、加密和性能而自行構(gòu)建的技術(shù)棧?？偟膩碚f，HTTP/3的主要優(yōu)勢在于：

• 無行頭阻塞：QUIC支持完全獨立的傳輸流。即使某個傳輸流中出現(xiàn)了丟失包，也不會阻止其他數(shù)據(jù)包的傳輸。
• 更快的握手：QUIC結(jié)合了加密和傳輸設(shè)置。TLS 1.3直接被集成到了QUIC中，以允許1-RTT（往返時間）甚至0-RTT的恢復(fù)。
• 恢復(fù)的改進：QUIC使用了數(shù)據(jù)包編號和ACK（確認(rèn)）范圍，而非序號，因此具有更智能的擁塞控制和恢復(fù)機制。
• 連接的遷移：QUIC連接可以在IP變更中留存下來。這對于在Wi-Fi和LTE之間切換的移動網(wǎng)絡(luò)來說非常實用。此外，在高丟包率的條件下，HTTP/3仍能縮短現(xiàn)實傳輸?shù)牡却图虞d時間。

HTTP/3工作原理

為了充分讀懂HTTP/3的工作原理，我們需要了解瀏覽器、DNS和緩存層，并獲悉它們是如何相互協(xié)同的。

1.初始DNS查詢

該過程始于客戶端對A/AAAA記錄執(zhí)行DNS查詢時。該查詢會將IPV6映射到相應(yīng)的域名上。為了讓HTTP/3使用UDP之上的QUIC，服務(wù)端必須向客戶端發(fā)出支持QUIC的信號。此類信號主要有兩種方式：

• DNS級別：服務(wù)端可以使用HTTPS記錄（特別是各種服務(wù)綁定的參數(shù)或SvcParams）直接在DNS響應(yīng)中包含對QUIC的支持，以告知客戶端支持QUIC（以及HTTP/3）。示例：_443._tcp.example.com. IN HTTPS 1 . alpn="h3, h2"
• 瀏覽器級別：如果不通過DNS提供QUIC信息，服務(wù)端在初始化HTTP/2連接期間，仍可能在響應(yīng)標(biāo)頭中發(fā)出支持HTTP/3的信號。此處的Alt-Svc標(biāo)頭（例如，alt-svc: h3=":443"; ma=2592000）被包含在服務(wù)端的HTTP/2響應(yīng)中，以通知瀏覽器HTTP/3可用，客戶端需將其用于后續(xù)的連接。

2.Alt-Svc廣告

如果存在Alt-Svc標(biāo)頭，則：

• 瀏覽器在ma（max-age）參數(shù)所定義的持續(xù)時間內(nèi)對其緩存。
• 在后續(xù)訪問時，瀏覽器直接嘗試HTTP/3，而無需先通過HTTP/2進行協(xié)商。

3.瀏覽器的緩存行為

一旦Alt-Svc被緩存：

• 瀏覽器將對于后續(xù)同一來源的連接，優(yōu)先考慮HTTP/3。
• 如果QUIC連接失?。ɡ绯霈F(xiàn)被阻止的UDP或NAT問題），瀏覽器會通過TCP靜默地返回HTTP/2，而不會中斷用戶的瀏覽體驗。

4.TLS握手中的ALPN

應(yīng)用層協(xié)議協(xié)商（ALPN）會在TLS握手期間被用于協(xié)商HTTP的版本：

• 如果服務(wù)端支持HTTP/3，它便會發(fā)布h3 ALPN字符串。
• QUIC握手則會啟用a1-RTT連接（如果使用的是會話恢復(fù)的話，則啟用0-RTT）。
• 如果服務(wù)不支持h3，客戶端將會自動降回到HTTP/2。

5.回退流（可通過Wireshark觀察到）

以下是HTTP/3在實踐中能夠發(fā)揮的作用：

• 瀏覽器根據(jù)A/AAAA記錄（可能還有HTTPS/SVCB或服務(wù)綁定記錄）發(fā)送DNS查詢。
• 它嘗試向目標(biāo)IP和端口進行QUIC握手。
• 如果在較短的超時窗口（通常為300-500毫秒）內(nèi)沒有收到QUIC響應(yīng)，瀏覽器將并行啟動TCP握手。

可見，瀏覽器上發(fā)生的實際上是QUIC和TCP的連接“比拼”，即：在完成握手后，判斷：

• 如果QUIC成功，則使用HTTP/3。
• 如果QUIC被阻止或超時，基于TCP的HTTP/2將接管。

這種雙握手模式確保了HTTP/3為首選，如果需要，則可以優(yōu)雅地回退到HTTP/2，且不會影響用戶的體驗。就兼容性而言：

• Chrome和Firefox都能夠支持這種回退機制。
• 而Microsoft Edge相對保守，可能需要手動啟用HTTP/3或?qū)嶒炐栽O(shè)置，才能進行一致性的測試。

讓我們再從性能方面進行考慮：

• 雖然回退較快，但并非瞬時，因此盡管QUIC與TCP的競賽最大限度地減少了中斷，但是在回退到TCP時可能會帶來較小的延遲，特別是在高損耗或高延遲環(huán)境中。
• 而在網(wǎng)絡(luò)狀況的影響方面：在出現(xiàn)Aggressive NAT、以及網(wǎng)絡(luò)抖動或數(shù)據(jù)包丟失率過高等情況時，QUIC的連接也可能會中斷或失敗。此類情況在亞太地區(qū)和非洲尤為明顯。

總的說來，HTTP/3的雙回退策略（無論是通過DNS的HTTPS記錄，還是Alt-Svc標(biāo)頭發(fā)起）都能夠提供強大、用戶透明的協(xié)議協(xié)商功能。即使在次優(yōu)的網(wǎng)絡(luò)條件下，瀏覽器也可以通過回退到HTTP/2來保持連接，以確保可靠性。

部署注意事項

盡管具有架構(gòu)優(yōu)勢，但是HTTP/3并非隨處可用。在現(xiàn)實世界的網(wǎng)絡(luò)中，仍然會有如下障礙，可能會影響到它的可靠性，甚至完全阻止其被使用。

關(guān)鍵的環(huán)境依賴性：

• 中間層和防火墻：A.許多企業(yè)防火墻和一些傳統(tǒng)路由器會阻止或降低UDP流量的優(yōu)先級。
  B.QUIC（以及h3擴展）使用UDP端口443，但并非所有網(wǎng)絡(luò)都配置為允許使用該端口。
• 運營商級NAT（CGNAT）：A.在移動和共享IP環(huán)境中，QUIC的連接ID是一個很大的優(yōu)勢，但如果NAT映射過期設(shè)置太短或被快速重新分配，則會導(dǎo)致QUIC的中斷。
• 舊路由器和網(wǎng)絡(luò)設(shè)備：A.一些較舊的路由器可能無法很好地處理高速UDP，導(dǎo)致在高吞吐量QUIC會話期間出現(xiàn)數(shù)據(jù)包的抖動或丟失。
• TLS卸載和代理：

A.在卸載了TLS的邊緣架構(gòu)處（如一些反向代理或負(fù)載平衡器），可能無法原生地支持QUIC，或需要架構(gòu)的調(diào)整。

回退是一項特征，而并非失敗

當(dāng)QUIC因上述任何原因被阻止或失敗時，現(xiàn)代化的瀏覽器和CDN會優(yōu)雅地回退到HTTP/2，這也是h3的精妙之處。下表是兩代技術(shù)的比較：

現(xiàn)實世界正在加速采用HTTP/3

讓我們來查看一些基于年份的數(shù)據(jù)：

其中：

• Cloudflare、Fastly和Akamai等CDN現(xiàn)在已默認(rèn)啟用HTTP/3。
• Chrome、Firefox、Safari和Edge都支持HTTP/3。
• 支持HTTP/3的網(wǎng)站呈增長趨勢，特別是在那些注重性能的地區(qū)。

HTTP/3的重要特性

根據(jù)我們的經(jīng)驗和現(xiàn)實世界的測試，HTTP/3在以下領(lǐng)域意義重大：

• 高延遲和損包地區(qū)：非洲、東南亞偏遠(yuǎn)的拉丁美洲城市。
• 移動網(wǎng)絡(luò)：在LTE和Wi-Fi之間頻繁切換。
• 密集API的應(yīng)用：通過非阻塞多路復(fù)用受益于多并發(fā)調(diào)用。
• 性能第一團隊：愿意投資于毫秒級改進的團隊（如Core Web Vitals）。

真實測試洞見

我們使用跨多個國家的分布式主干節(jié)點，采用強制協(xié)議模式在HTTP/2和HTTP/3之間進行并行比較。測量了以下方面：

• DNS、連接、SSL、等待、加載時間
• 跨區(qū)域的h2和h3之間的性能
• 數(shù)據(jù)包丟失/抖動與協(xié)議回退的相關(guān)性

在幾乎每個涉及非理想條件的情況下，HTTP/3在等待和加載時間上都優(yōu)于HTTP/2。

性能分析

通過對在六個國家運行的性能比較與分析，基于數(shù)千次運行結(jié)果，我們測量了首字節(jié)時間（TTFB）、最大內(nèi)容顯示（Largest Contentful Paint，LCP）和視覺完整性（VC）的中位數(shù)與第99百分位的數(shù)值，結(jié)果表明HTTP/3在關(guān)鍵網(wǎng)絡(luò)性能指標(biāo)上始終優(yōu)于HTTP/2。

HTTP/3的主要改進

如上表所示，HTTP/3大幅減少了TTFB中位數(shù)（平均41.8%）。可見，在所有測試區(qū)域中，初始服務(wù)端的響應(yīng)時間與HTTP/2相比要快得多。同時，最大內(nèi)容顯示（LCP）和視覺完成（VC）的改進也是一致的（平均約10%）。這意味著用戶使用HTTP/3能夠更快地看到最多的內(nèi)容和完整的頁面。

國家級細(xì)分

如上表所示：

• 澳大利亞和德國通過HTTP/3（超過78%）得到了最大的TTFB改進，同時轉(zhuǎn)化為LCP和VC的顯著提升。
• 巴西的第99百分位數(shù)TTFB和VC顯示了負(fù)改善。該異常情況表明，在最慢的請求中，HTTP/3的表現(xiàn)不如HTTP/2。
• 日本、英國和美國在大多數(shù)指標(biāo)上，顯示出了適度且一致的改善，特別是在中位數(shù)方面。

其他觀察

• 一致性：中位數(shù)的改進通常大于第99百分位數(shù)，表明HTTP/3對于那些典型（非極端）用戶的體驗特別奏效。
• 區(qū)域差異性：雖然HTTP/3總體向好，但是實際改進程度因地而異，這與各地網(wǎng)絡(luò)基礎(chǔ)設(shè)施和延遲有關(guān)。

實際上，在多個國家的真實骨干測試中，HTTP/3一直優(yōu)于HTTP/2。這在澳大利亞和德國最為明顯。它在減少初始化響應(yīng)時間（TTFB）和頁面渲染速度（LCP、VC）上的合理改善已卓見成效。相關(guān)案例也表明，HTTP/3可以為那些延遲敏感的應(yīng)用程序，帶來網(wǎng)絡(luò)性能上的提升。而在巴西等一些地區(qū)的個案中，瀏覽器連接仍傾向于用HTTP/2來處理最慢的請求。

小結(jié)

綜上所述，HTTP/3不僅能提供更快的速度，而且具有一定的魯棒性。如果你關(guān)注數(shù)據(jù)傳輸?shù)男阅?、可靠性、以及在為移動?yīng)用布局的話，是時候測試和啟用HTTP/3了。無論是自運營的基礎(chǔ)設(shè)施，還是使用第三方CDN，由HTTP/3帶來的協(xié)議上的演變，必將為現(xiàn)實世界中上億規(guī)模的用戶帶來更快的互聯(lián)網(wǎng)瀏覽體驗。

譯者介紹

陳峻（Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風(fēng)險實施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗。

原標(biāo)題：HTTP/3 in the Wild: Why It Beats HTTP/2 Where It Matters Most，作者：Wasil Banday