互聯網的未來：為什么我們需要HTTP/3？

自1997年HTTP/1.1標準化以來，一直是首選的應用層協議。多年來，為了跟上互聯網的發展和網絡上交換內容的多樣性，HTTP 不得不進行升級。本文展示了 HTTP 協議的演變，深入探討了 HTTP/3，重點介紹了 HTTP/3 的特性，最后展望了HTTP/3 驅動下互聯網的未來。

HTTP/3 的出現

HTTP 催生互聯網

當 Tim Berners-Lee 構想互聯網時，HTTP(超文本傳輸協議) 是一個“單行協議”。HTTP/0.9 由 ASCII 文本字符串請求組成：GET method，后跟文檔地址、可選的端口地址，以回車符 (CR) 和換行符 (LF) 結尾。請求由一串 ASCII 字符組成，只能傳輸 HTML 文件，沒有 HTTP 報頭，也沒有狀態或錯誤代碼。?

多年來，HTTP 從 HTTP/1.0 發展到 HTTP/1.1，再到 HTTP/2。在每次迭代中，都會向協議中添加新特性，以滿足當時的需求，例如應用層要求、安全考慮、會話處理和媒體類型。

?

HTTP/2 面臨壓力

在 Internet 和 HTTP 的發展過程中，HTTP 的底層傳輸機制基本沒有變化。然而，隨著移動設備技術的大規模普及，實時應用需求的增加，互聯網流量不斷增長，HTTP/2 的缺點也越來越明顯。

其一，HTTP/2 的最終版本并沒有在 HTTP/1.1 基礎上改進很多。為了保持與 HTTP/1.1 的向后兼容，該協議必須保留相同的 POST 請求、GET請求 、狀態代碼（200、301、404 和 500）等。?

其二，一些已實現的功能帶來了安全問題。除了遺留的強制加密缺失之外，還包括容易受到攻擊的壓縮頁面報頭和 cookie。

HTTP/3 的目標是解決 HTTP/2 的傳輸相關問題，可以在各種設備上提供快速、可靠和安全的 Web 連接。為此，它使用了一種名為 QUIC 的協議，該協議運行在UDP互聯網協議之上，而不是TCP。?

與 TCP 的有序消息交換方案不同，UDP 允許消息的多向廣播，這一特性有助于解決數據包級別的隊頭阻塞 (HoL) 問題。

TCP 和 UDP 中消息排序的區別（SYN=同步；ACK=確認）

此外，QUIC 重新設計了客戶端和服務器之間握手的方式，減少了與建立重復連接相關的延遲。

TCP、TCP+TLS 和 QUIC 中重復連接數據第一個字節的消息數

HTTP/3 的出現

在IETF正式標準化 HTTP/2 的同時，谷歌正在獨立構建新的傳輸協議 gQUIC，可以在網絡狀況不佳的情況下改善瀏覽體驗。?

采用 gQUIC 的呼聲越來越高，它被重新命名為 QUIC。大多數 IETF 成員投票決定為 HTTP 建立一個新的規范以在 QUIC 上運行（HTTP over QUIC），也就是 HTTP/3。

HTTP/3 在語法和語義上與 HTTP/2 相似，遵循著相同的請求和響應消息交換順序，其數據格式包含方法、報頭、狀態碼和正文。HTTP/3 的顯著差異在于 UDP 之上協議層的堆疊順序，如下圖所示。?

HTTP/3 中的堆疊順序顯示 QUIC 與安全層和部分傳輸層重疊

HTTP/3 和 QUIC 如何解決 TCP 的局限性

HTTP/3 功能的優勢來自于底層的 QUIC 協議。在我們討論 QUIC 和 UDP 之前，先了解一下TCP 發展的局限性。

QUIC 中使用UDP 不會在出錯時請求數據重發

TCP的局限性

TCP 會間歇性掛起數據傳輸

如果序列號較低的數據段尚未到達/接收，即使序列號較高的段已經到達/接收，TCP 的接收器滑動窗口也不會前進。這會導致 TCP 流暫時掛起甚至關閉，這個問題稱為 TCP 流的隊頭阻塞 (HoL) 。

數據包級別的隊頭阻塞會導致 TCP 流關閉

TCP 不支持流級多路復用

雖然 TCP 允許與應用層之間的多個邏輯連接，但它不允許在單個 TCP 流中多路復用數據包。使用 HTTP/2，瀏覽器只能打開一個與服務器的 TCP 連接。它使用同一個連接來請求多個對象，例如 CSS、JavaScript 和其他文件。在接收這些對象時，TCP將同一流中的所有對象序列化。因此，它不知道TCP段的對象級分區。

TCP 導致冗余通信

在進行連接握手時，TCP 交換一系列消息，如果與已知主機建立連接，會有冗余的消息交換序列。

使用 TLS 加密通信會話開始時的TCP+TLS 握手

QUIC

QUIC協議在以下設計的基礎上，通過引入一些底層傳輸機制的改變，解決 TCP 的這些限制。

選擇UDP作為底層傳輸層協議

如果還在TCP 之上的建立新的傳輸機制，將仍繼承前面所說的TCP限制。QUIC 是在用戶級別構建的，它不需要在每次協議升級時更改內核，從而更易采用。

流復用和流量控制

QUIC 引入了在單個連接上多路復用流的概念。QUIC 實現了單獨的、逐流的流量控制，從而解決了整個連接的隊頭阻塞問題。

使用 UDP，沒有包級的隊頭阻塞

靈活的擁塞控制

TCP有嚴格的擁塞控制機制。每次 TCP 協議檢測到擁塞時，它都會將擁塞窗口的大小減半。QUIC 的擁塞控制更加靈活，可以更有效地利用可用網絡帶寬，從而獲得更好的流量吞吐量。

更好的錯誤處理

QUIC 提議使用增強的丟失恢復機制和前向糾錯來處理錯誤的數據包，尤其是對于在傳輸中容易出現高錯誤率的緩慢的無線網絡。

更快地握手

QUIC 使用與 HTTP/2 相同的 TLS 模塊來實現安全連接。然而，與 TCP 不同的是，QUIC 的握手機制經過優化，可以避免在兩個已知對等點相互建立通信時進行冗余協議交換。

使用 TCP 和 TLS 建立安全連接至少需要兩次往返時間 (RTT)，增加了延遲開銷。使用 QUIC，建立第一個加密連接是 1 個RTT，當會話恢復時，有效負載數據與第一個數據包一起發送，RTT 最少為零。

第一次連接和后續連接之間不同協議的 RTT 數量比較

語法和語義

通過在QUIC之上構建基于HTTP/3的應用層，可以獲得增強傳輸機制的所有優勢，同時保留與 HTTP/2 相同的語法和語義。但是HTTP/2 不能直接與 QUIC 集成，因為從應用到傳輸的底層幀映射是不兼容的。因此，IETF 的 HTTP 工作組建議將 HTTP/3 作為新的HTTP 版本，并根據 QUIC 協議的幀格式要求修改其幀映射。

壓縮

HTTP/3 還使用了一種稱為 QPACK 的新報頭壓縮機制，是對 HTTP/2 中使用的 HPACK 的修改。在 QPACK 下，HTTP 報頭可以在不同的 QUIC 流中亂序到達。QPACK 使用了一種查找表機制來對報頭進行編碼和解碼。

為什么 HTTP/3 很重要？

TCP 已經存在了40多年。它最初于 1981 年通過 RFC 793 標準化。多年來，它被證明是一個支持互聯網流量增長的非常強大的傳輸協議。然而，在設計上，TCP 不適合處理有損無線介質上的數據傳輸。

在互聯網的早期，有線連接是唯一的連接方式，所以這在當時來說不是什么大問題。但現在，智能手機和便攜式設備的數量超過臺式機和筆記本電腦，超過 50% 的互聯網流量是通過無線傳輸的。隨著這種增長，整體 Web 瀏覽體驗隨著響應時間的增加而惡化。

谷歌首次旨在解決 HoL 的測試證明，將 QUIC 作為谷歌服務的底層傳輸協議大大提高了響應速度和用戶體驗。將 QUIC 部署為 YouTube 視頻的底層傳輸協議，谷歌報告稱重新緩沖率下降了 30%，這對視頻觀看體驗有直接影響。

在網絡條件較差的情況下提升非常明顯，這促使谷歌更加積極地改進協議，最終將其提交給 IETF 進行標準化。

憑借這些早期試驗帶來的改進，QUIC 已成為將網絡帶入未來的重要組成部分。

HTTP/3 的最佳用例

HTTP/3 的目的是改善整體網絡體驗，尤其是在高速無線互聯網訪問仍然不可用的地區。盡管 HTTP/2 非常適合其中的一些應用程序，但 HTTP/3 在以下場景中更有價值：

物聯網 (IoT)

由于其局限性， HTTP 可能不是 IoT 的首選協議，但有些應用程序非常適合基于 HTTP 的通信。例如，HTTP/3 可以解決從附加傳感器收集數據的移動設備的無線連接有損問題。這也適用于安裝在車輛或移動資產上的獨立物聯網設備。

微服務

在微服務網格中，為了獲取數據，遍歷所有微服務會浪費大量時間。QUIC 的優勢在于握手次數較少，因此可以在幾毫秒內傳遞這些請求。HTTP/3 在這里的好處不在于大數據的吞吐量，而在于加速每個微交互。

網絡虛擬現實 (VR)

隨著瀏覽器功能的不斷改進，內容格局也會相應發生變化。其中一個變化領域是基于網絡的 VR。盡管仍處于起步階段，但在許多情況下，VR 在增強協作方面發揮著關鍵作用。VR 應用程序需要更多帶寬來呈現虛擬場景的復雜細節，因此遷移到HTTP/3會大有收獲。

HTTP/3 的局限性

過渡到 HTTP/3 不僅涉及應用層的變化，還涉及底層傳輸層的變化。因此，與其前身 HTTP/2 相比，采用 HTTP/3 更具挑戰性，后者只需要在應用層進行更改。?

傳輸層要經過網絡中間層的嚴格審查，如防火墻、代理、NAT 設備等，為了滿足其功能需求，需要進行大量的深層包檢測。因此，新傳輸機制的引入會對 IT 基礎架構和運營團隊產生了一些影響。

安全服務通常建立在應用程序流量（大部分為 HTTP）將通過 TCP 傳輸的前提下，TCP是以可靠性為中心、面向連接的協議。對 UDP 的更改可能會對安全基礎設施解析和分析應用程序流量的能力產生重大影響，因為 UDP 是一種基于數據包的協議，而且可能不可靠。

另一個問題是，TCP目前是大多數web通信的首選協議，防火墻的默認數據包過濾策略可能能不支持長時間運行HTTP/3的UDP會話。

結論

HTTP/3 可以被認為是通過 QUIC 傳輸的 HTTP 語義，QUIC 是默認的加密傳輸協議，使用 UDP 進行擁塞控制。并不是 HTTP/2 的所有特性都可以映射到 QUIC 之上。一些 HTTP/2 功能需要順序保證，雖然 QUIC 可以在單個流中提供這種保證，但它不能跨流提供相同的保證。因此，需要對 HTTP 進行新的修訂。

QUIC 的兩個主要目標是解決數據包級別的隊頭阻塞并減少 HTTP 連接和流量中的延遲。使用 UDP 允許多路復用和輕量級連接建立，改善了最終用戶在低質量網絡上的體驗。

通過一些更改，IETF 驗證了 HTTP-over-QUIC 的概念，并將其重命名為 HTTP/3。2022年6月6日，IETF QUIC 和 HTTP 工作組成員 Robin Marx 宣布，經過 5 年的努力，HTTP/3 正式被標準化為 RFC 9114，同時，HTTP/2 也更新為 RFC 9113標準，HTTP/1.1 和通用 HTTP 語義和緩存概念在 RFC 9110-9112 中也得到了加強。

審核編輯：湯梓紅