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

HTTP/3 的出現(xiàn)

HTTP 催生互聯(lián)網(wǎng)

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

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

?

HTTP/2 面臨壓力

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

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

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

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

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

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

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

TCP、TCP+TLS 和 QUIC 中重復連接數(shù)據(jù)第一個字節(jié)的消息數(shù)

HTTP/3 的出現(xiàn)

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

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

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

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

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

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

QUIC 中使用UDP 不會在出錯時請求數(shù)據(jù)重發(fā)

TCP的局限性

TCP 會間歇性掛起數(shù)據(jù)傳輸

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

數(shù)據(jù)包級別的隊頭阻塞會導致 TCP 流關(guān)閉

TCP 不支持流級多路復用

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

TCP 導致冗余通信

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

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

QUIC

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

選擇UDP作為底層傳輸層協(xié)議

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

流復用和流量控制

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

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

靈活的擁塞控制

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

更好的錯誤處理

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

更快地握手

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

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

第一次連接和后續(xù)連接之間不同協(xié)議的 RTT 數(shù)量比較

語法和語義

通過在QUIC之上構(gòu)建基于HTTP/3的應用層，可以獲得增強傳輸機制的所有優(yōu)勢，同時保留與 HTTP/2 相同的語法和語義。但是HTTP/2 不能直接與 QUIC 集成，因為從應用到傳輸?shù)牡讓訋成涫遣患嫒莸?。因此，IETF 的 HTTP 工作組建議將 HTTP/3 作為新的HTTP 版本，并根據(jù) QUIC 協(xié)議的幀格式要求修改其幀映射。

壓縮

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

為什么 HTTP/3 很重要？

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

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

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

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

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

HTTP/3 的最佳用例

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

物聯(lián)網(wǎng) (IoT)

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

微服務

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

網(wǎng)絡虛擬現(xiàn)實 (VR)

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

HTTP/3 的局限性

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

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

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

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

結(jié)論

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

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

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

審核編輯：湯梓紅