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