HTTP/3 + QUIC：性能有余 安全不足

HTTP 概述

超文本傳輸協(xié)議（HTTP）全稱Hyper Text Transfer Protocol，用于使用超文本鏈接加載網(wǎng)頁。HTTP 是一種應用層協(xié)議，主要涉及客戶端向服務器發(fā)出請求，然后服務器發(fā)送響應消息。

HTTP 是一種無狀態(tài)協(xié)議，目前主要與 TLS（傳輸層安全）協(xié)議一起使用，TLS為 HTTP 提供機密性、完整性和身份驗證機制——通常稱為 HTTPS。 HTTP 由各種不同的組件組成，用于交換實際數(shù)據(jù)和元數(shù)據(jù)：

HTTP 請求方法（即 GET、POST、PUT、PATCH、DELETE）

HTTP 標頭（即 Cookie、XFF、主機、內(nèi)容類型、連接）

HTTP 響應碼- 表示請求狀態(tài)的數(shù)值（例如：404 Not Found，表示在服務器上找不到請求的資源）

HTTP的歷史

歷史上最早的HTTP協(xié)議是1989年CERN（譯注：即“歐洲核子研究組織”的原稱 - Conseil Européen pour la Recherche Nucléaire）的 Tim Berners-Lee 發(fā)明的，目前命名為HTTP/0.9。然而，由于缺乏現(xiàn)代的傳輸機制、頭文件、方法等，它從未獲得官方的RFC，實際上也不再被使用。下面列出了官方 HTTP 初始規(guī)范 RFC，重點介紹了它們引入時最重要的新功能： HTTP/1.0 - 1996 年 5 月 - RFC 1945

支持 HTTP 報頭

支持 HTTP 狀態(tài)碼

支持 Content-Type 報頭

增加了新的POST 和 HEAD 方法

HTTP/1.1 - 1997 年 1 月 - RFC 2068

引入持久連接- 可以通過單個連接發(fā)送多個請求

強制主機頭 - 對web代理路由很重要

新的 HTTP 狀態(tài)碼 100

新的 HTTP 方法 - PUT、PATCH、DELETE、CONNECT、TRACE 和 OPTIONS

支持各種壓縮和解壓縮方法- Gzip 最常用

HTTP/2.0 - 2015 年 5 月 - RFC 7540

支持請求多路復用，引入 HTTP 流，現(xiàn)在請求/響應可以多路復用并且不是連續(xù)的

支持請求優(yōu)先級，例如，CSS 文件應該在 JS 文件之前發(fā)送

自動 Gzip 壓縮

HTTP 連接重置支持，如果在 HTTP 級別發(fā)生錯誤，可以立即重置連接

支持服務器推送，服務器可以在沒有明確請求的情況下主動將內(nèi)容推送回客戶端。

支持報頭壓縮 (HPAK)

HTTP/3.0 - 2022 年 6 月 - RFC 9114

使用 QUIC 協(xié)議代替TCP/TLS 棧 - RFC 9000

2022 年 6 月，IETF（互聯(lián)網(wǎng)工程任務組）HTTP 組不僅發(fā)布了 HTTP/3 RFC 9114，還決定對 HTTP RFC 結構進行細化、清理和重建。此外，有些東西已經(jīng)從 HTTP 標準中分離出來，并移至它們自己的 RFC 中。

HTTP 語義- RFC 9110：HTTP 的總體架構、常用術語和共享協(xié)議方面，例如請求和響應消息/doc/rfc9111s、方法、狀態(tài)碼、頭和尾字段、消息內(nèi)容、表示數(shù)據(jù)、內(nèi)容編碼等等。

HTTP 緩存- RFC 9111：HTTP 緩存和相關的報頭字段來控制響應緩存的行為。

HTTP/1.1 - RFC 9112

HTTP/2.0 - RFC 9113

QPAC - RFC 9204

| 圖 1 HTTP 相關 RFC

在最初的HTTP/1.0發(fā)布之后，用戶很快發(fā)現(xiàn)它缺少很多潛在的特性，需要進行一些優(yōu)化。僅半年之后就發(fā)布了HTTP/1.1來解決這些問題。而新的官方HTTP/2標準花了整整18年的時間來開發(fā)，主要是為了解決性能方面的問題。7年后的2022年6月，HTTP/3協(xié)議被引入。

HTTP/3協(xié)議最大的變化是放棄了對 TCP/TLS 堆棧的支持，并用新的互聯(lián)網(wǎng)協(xié)議——QUIC傳輸協(xié)議取而代之。

讓我們比較一下 HTTP/2 和 HTTP/3 協(xié)議。

HTTP/2 與 HTTP/3



| 圖2HTTP/2 vs. HTTP/3

我們逐層進行分析：

1）第 3 層沒有變化——IP 堆棧保持不變；支持 IPv4 和 IPv6

2）在第 4-6 層，我們看到了主要差異：

UDP（用戶數(shù)據(jù)報協(xié)議）取代了TCP 協(xié)議進行包轉(zhuǎn)發(fā)

QUIC：

取代了所有 TCP 協(xié)議功能，如面向連接、提供擁塞控制和避免、流量控制機制等

集成TLS1.3協(xié)議，負責流量加解密

TLS 層正在與 QUIC 集成，并提供密鑰協(xié)商、身份驗證和會話恢復功能

流復用機制也從HTTP層搬到了QUIC層

3）在 HTTP 層使用更高效的 QPACK 頭壓縮算法，可以利用 QUIC 協(xié)議功能 HTTP/2 和 HTTP/3 之間最大的區(qū)別是使用 QUIC over UDP 而不是 TCP 作為傳輸機制，其中 QUIC 協(xié)議不僅集成了 TCP 典型功能，還集成了 TLS 來提供安全性和流復用。值得一提的是，在 QUIC 實現(xiàn)中，TLS 的使用是強制性的——因此 HTTP/3 不再有純文本 HTTP。

HTTP/2與 HTTP/3- 性能考慮

減少線頭阻塞

通過將流多路復用從HTTP層移到QUIC傳輸層，HOL阻塞的情況可能會減少，不過它在很大程度上取決于 Web 瀏覽器上的特定多路復用實現(xiàn)。

0-RTT 會話設置

下圖通過客戶端和服務器之間示例流的往返時間來比較 HTTP/2 和 HTTP/3：



| 圖 3 不同實現(xiàn)之間的 RTT 比較

TLS1.3 的特性是0-RTT 會話恢復，假設我們最近與特定的 Web 服務器進行過通信，我們可以自動重用密鑰，并在初始會話設置時開始傳輸實際數(shù)據(jù)。對于 TCP，它會將 RTT 減少到 2，而QUIC 可以減少到 1。

下圖顯示了 TCP 和 QUIC 在最佳情況下的差異：



| 圖 4 TLS1.3 0-RTT TCP與QUIC對比

雖然這看起來只是節(jié)省一個 RTT，但是在衛(wèi)星和長距離連接方面可能是一個巨大優(yōu)勢。

連接遷移

由于 QUIC 協(xié)議使用了叫做源和目標Circuit ID (CID) 的新字段，現(xiàn)在在不丟失文件傳輸?shù)那闆r下從一個連接遷移到另一個連接要容易得多。例如，連接可以輕松地從 Wi-Fi 遷移到 5G，并且仍然可以重用現(xiàn)有的 QUIC 會話。

總結性能考慮因素——通常在現(xiàn)代城市地區(qū)——從 TCP+HTTP/2 遷移到 QUIC+HTTP/3 的好處可能不會那么大。然而，不太理想的連接條件將變成 QUIC+HTTP/3 應該表現(xiàn)得更好并提供更好的性能和可靠性。

在性能方面，如果是在現(xiàn)代城市地區(qū)，從TCP+HTTP/2遷移到QUIC+ HTTP/3的優(yōu)勢可能不是那么大。然而，在連接條件不太理想的情況下，QUIC+HTTP/3的表現(xiàn)會更好，并能夠提供更好的性能和可靠性。

此外，TCP 實現(xiàn)通常是在操作系統(tǒng)內(nèi)核上，這大大減慢了新 TCP 擴展和機制的開發(fā)和采用，而QUIC是用戶空間實現(xiàn)。隨著時間的推移，越來越多的 QUIC 功能將被轉(zhuǎn)移到操作系統(tǒng)級別，以提高性能，此外還將引入 SmartNIC，將部分或全部 QUIC 功能卸載到硬件級別。

HTTP/2 與 HTTP/3 - 安全考慮

HTTP/3 與 HTTP/2 有兩個主要的安全考慮因素：

最終用戶角度

從最終用戶的角度來看，默認情況下使用 HTTP/3 應該更加安全。HTTP/3目前僅支持 TLS1.3 安全通信，此外與 HTTP/2 相比，HTTP/3 暴露在網(wǎng)絡報頭中的信息要少得多。

目前谷歌、Facebook等公司已經(jīng)支持 HTTP/3了，甚至在 RFC 最終確定之前，谷歌服務實際上就在 QUIC 上使用 HTTP/2，所以它被稱為 HTTP/2 over QUIC，后來變成了 HTTP/3。

中間人視角（防火墻 TLS 代理）

所有主要的下一代防火墻都使用一種稱為 TLS 代理的技術，以便能夠解密 TLS 流量，基本上，防火墻成為充當代理的中間人設備，下圖說明了這一點。



| 圖 5 防火墻傳統(tǒng)

TLS 代理解決方案，來源PaloAlto Networks 這種方法不再適用于 QUIC 協(xié)議，因為很少有支持解密 QUIC 協(xié)議的供應商，并且存在很多挑戰(zhàn)，所有 NGFW檢測模塊都必須重寫才能支持此類功能，這肯定會花費很多時間.

另一個問題是，目前還沒有真正的方法來有效地跟蹤這樣的連接。理論上，目標Circuit ID聽起來是個不錯的選擇，然而，在活動連接期間，客戶端可以隨意更改其源Circuit ID。另一方面，在第4層，它看起來就像是動態(tài)src-port和dst-port為443的常規(guī)UDP數(shù)據(jù)包，打開此類流量可能會導致通過防火墻發(fā)起UDP打洞攻擊。

幸運的是，如果無法建立快速連接，則會自動回退到 HTTP/2 over TCP，然后防火墻可以對其進行解密和檢查。

HTTP/2 與 HTTP/3 使用統(tǒng)計

根據(jù)Web Technologies Surveys，截至 2022 年 11 月，約 42% 的網(wǎng)絡流量是 HTTP/2。但是，自 2021 年 11 月以來，它的使用率一直在下降。



| 圖 6 HTTP/2的使用情況，2022 年 11 月 另一方面，HTTP/3 協(xié)議的使用自 2021 年以來一直在增加，并在 2022 年 11 月達到 26%。



| 圖 7 HTTP/3的使用情況，2022 年 11 月 HTTP/3的缺點在于前述的與 QUIC 不兼容的中間防火墻內(nèi)容檢查和解密機制。截至撰寫本文時，幾乎沒有支持 HTTP/3 解密和檢查的防火墻供應商。

總 結

HTTP/3 主要是為了引入一個更健壯、靈活和現(xiàn)代的傳輸層協(xié)議——QUIC。QUIC 協(xié)議不必只與 HTTP 一起使用，有一些新的舉措可以將它與其他協(xié)議一起使用，例如 DNS 和 SSH。

其次是性能提升，如果與 HTTP/2+TCP+TLS1.3（0-RTT）的最佳可能實現(xiàn)相比，HTTP/3 仍然有一個往返時間 (RTT) 的優(yōu)勢。在現(xiàn)代、快速、城市化的網(wǎng)絡中，這可能聽起來不多，但絕對是一種改進。在較慢的網(wǎng)絡和流量突發(fā)的情況下，加載頁面/資源可能會節(jié)省幾百毫秒。在連接遷移方面也有好處，特別是允許移動用戶更改連接方法并且仍然能夠繼續(xù)下載文件或維持現(xiàn)有連接。

最后，QUIC 仍處于開發(fā)階段的早期，第 1 版專注于完成基本的傳輸和安全協(xié)議，更多高級功能尚未出現(xiàn)，并且隨著時間的推移它只會變得更好更快。由于現(xiàn)有的實現(xiàn)是在用戶空間而不是操作系統(tǒng)級內(nèi)核空間中開發(fā)的，因此新的高級功能的開發(fā)應該更快更容易采用。目前HTTP/3 已經(jīng)在互聯(lián)網(wǎng)上得到了部署和使用。谷歌、Meta、微軟、Akamai、Cloudflare、Fastly、F5 和愛立信等大型科技公司已經(jīng)在大量使用它。

審核編輯：劉清