HTTP 概述

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

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

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

HTTP 標頭（即 Cookie、XFF、主機、內容類型、連接）

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

HTTP的歷史

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

支持 HTTP 報頭

支持 HTTP 狀態碼

支持 Content-Type 報頭

增加了新的POST 和 HEAD 方法

HTTP/1.1 - 1997 年 1 月 - RFC 2068

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

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

新的 HTTP 狀態碼 100

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

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

HTTP/2.0 - 2015 年 5 月 - RFC 7540

支持請求多路復用，引入 HTTP 流，現在請求/響應可以多路復用并且不是連續的

支持請求優先級，例如，CSS 文件應該在 JS 文件之前發送

自動 Gzip 壓縮

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

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

支持報頭壓縮 (HPAK)

HTTP/3.0 - 2022 年 6 月 - RFC 9114

使用 QUIC 協議代替TCP/TLS 棧 - RFC 9000

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

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

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

HTTP/1.1 - RFC 9112

HTTP/2.0 - RFC 9113

QPAC - RFC 9204

| 圖 1 HTTP 相關 RFC

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

HTTP/3協議最大的變化是放棄了對 TCP/TLS 堆棧的支持，并用新的互聯網協議——QUIC傳輸協議取而代之。

讓我們比較一下 HTTP/2 和 HTTP/3 協議。

HTTP/2 與 HTTP/3



| 圖2HTTP/2 vs. HTTP/3

我們逐層進行分析：

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

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

UDP（用戶數據報協議）取代了TCP 協議進行包轉發

QUIC：

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

集成TLS1.3協議，負責流量加解密

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

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

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

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

減少線頭阻塞

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

0-RTT 會話設置

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



| 圖 3 不同實現之間的 RTT 比較

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

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



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

雖然這看起來只是節省一個 RTT，但是在衛星和長距離連接方面可能是一個巨大優勢。

連接遷移

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

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

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

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

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

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

最終用戶角度

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

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

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

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



| 圖 5 防火墻傳統

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

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

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

HTTP/2 與 HTTP/3 使用統計

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



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



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

總 結

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

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

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

審核編輯：劉清