一文了解下一代互聯網核心技術 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 中也得到了加強。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/BW2GsZjXCGeVWd4fVCLhOQ