從HTTP到HTTP/3的發展簡史

雖然 HTTP/3 規範仍處於起草階段，但最新版本的 Chrome 瀏覽器已經默認支持它了。Chrome 擁有約 70％的瀏覽器市場份額，因此，能夠說 HTTP/3 已經進入主流世界。

這一基礎協議的最新修訂版旨在讓 Web 更加高效、安全並縮短內容交付延遲。從某些角度來講，它是 HTTP2 的完善：經過使用新的專用協議 QUIC 替換基礎 TCP 協議來解決和以前相似的目標。

想要弄明白 QUIC 的優勢，最好的辦法是講清楚 TCP 做爲 HTTP 請求的傳輸方式有哪些不足之處。

爲此，咱們將從頭開始細細道來。

1. HTTP：起源

1991 年，當蒂姆·伯納斯·李爵士設計出一個簡單的單行超文本交換協議時，TCP 已是一個古老而可靠的協議了。前者的原始定義文檔（也就是後人熟知的 HTTP 0.9）特別提到 TCP 是首選的（儘管並不是惟一的）傳輸協議：

注意：HTTP 當前運行在 TCP 上，但也能夠運行在任何面向鏈接的服務上。

固然，HTTP 的這個概念驗證版本與咱們如今所知道和喜歡的 HTTP 幾乎沒有類似之處。沒有標頭，也沒有狀態碼。典型的請求只有GET/path而已。響應僅包含 HTML，且 TCP 鏈接關閉就會結束。

因爲瀏覽器還沒有流行，所以用戶須要直接閱讀 HTML。能夠用它連接到其餘資源，可是在這個 HTML 早期版本中存在的全部標籤都不會異步請求其餘資源。一個 HTTP 請求就傳遞了一個完整的、自給自足的頁面。

2. HTTP/1.0 出現

在隨後幾年中，互聯網迎來爆炸式的發展，儘管傳輸 HTML 仍然是 HTTP 的主要特點，但它逐漸發展成一種可擴展且靈活的通用協議。HTTP 的三大重要更新奠基了這一演變的基礎：

• 方法的引入使客戶能肯定其想要執行操做的類型。例如，引入 POST 是爲了容許客戶端將數據發送到服務器以處理和存儲；

• 狀態碼爲客戶端提供了一種確認服務器已成功處理請求的方法——若是處理失敗，則能夠用它瞭解發生了哪一種錯誤；

• 標頭增長了將結構化文本元數據附加到能夠修改客戶端或服務器行爲的請求和響應上的功能。例如，編碼和內容類型頭使 HTTP 不只能夠傳輸 HTML，還能夠傳輸任何類型的負載。「壓縮」標頭容許客戶端和服務器協商支持的壓縮格式，從而減小了經過鏈接傳輸的數據量。

同時，HTML 也不斷進化，支持了圖像、樣式和其餘連接資源。

如今，瀏覽器須要執行多個請求來顯示一個網頁，而原始的「按請求鏈接」架構是作不到的。創建和終止 TCP 鏈接涉及大量的數據包來回交換，所以在延遲開銷方面相對昂貴。網頁不見得必定由單個文本文件組成，可是隨着每頁請求數量的增長，延遲也隨之增長。

下圖說明了每創建一個新的 TCP 鏈接涉及多少請求開銷。

TCP 鏈接須要三個請求才能創建鏈接，四個請求能夠徹底關閉。

人們建立了一個「鏈接」標頭來解決這個問題。客戶端發送帶有「connection:keep-alive」標頭的請求，以代表意圖爲後續請求保持 TCP 鏈接的打開狀態。若是服務器理解此標頭並贊成遵照該標頭，則其響應還將包含「connection:keep-alive」標頭。

這樣，雙方都保持 TCP 通道打開並使用它進行後續通訊，直到任何一方決定關閉它爲止。隨着 SSL/TLS 加密技術的發展，這一點變得更加劇要，由於協商加密算法和交換加密密鑰須要在每一個鏈接上增長一個請求 / 響應週期。

單個 TCP 鏈接能夠經過「connection:keep-alive」標頭。

重用於多個請求當時，許多 HTTP 改進都是自發出現的。當流行的瀏覽器或服務器應用程序須要新的 HTTP 功能時，它們會本身實現該功能，並但願其餘各方也能效仿。具備諷刺意味的是，去中心化的 Web 須要一箇中心化的管理機構來避免碎片化形成的不兼容問題。

該協議的最初建立者蒂姆·伯納斯·李（TimBerners-Lee）意識到了這種危險，並於 1994 年成立了萬維網聯盟（W3C），該聯盟與互聯網工程任務組（IETF）一塊兒致力於規範互聯網的技術棧。做爲爲已有環境帶來更多規範的第一步，他們記錄了當時 HTTP 中最經常使用的一些功能，並將其命名爲 HTTP/1.0 協議。

可是，因爲這種「規範」描述的是多種多樣的，一般在「實踐」中用法不一致的技術，所以它從未得到過標準地位。相比之下，關於 HTTP 協議新版本的工做已經開始了。

3. HTTP/1.1 的標準化

HTTP/1.1 修復了 HTTP/1.0 的不一致之處，並調整了協議，使其在新的 Web 生態系統中具有更好的性能表現。新版引入的兩個最關鍵的更改是默認使用持久 TCP 鏈接（保持活動狀態）和 HTTP 管線化。

HTTP 管線化的意思就是客戶端無需在發送後續 HTTP 請求以前等待服務器響應請求。此功能能夠更有效地利用帶寬並減小延遲，但它的改進空間甚至更大。HTTP 管線化仍要求服務器按照接收到的請求順序進行響應，所以，若是管線化中的單個請求執行得很慢，則對客戶端的全部後續響應都將相應地延遲下去。這個問題被稱爲線頭阻塞。

因爲首先請求了 large-picture.jpg，所以阻止了 style.css 的發佈

在這個時候，Web 正在得到愈來愈多的交互功能。Web 2.0 指日可待，一些網頁包含數十個甚至數百個外部資源。爲解決線頭阻塞，並下降頁面加載速度，客戶端會在每一個主機上創建多個 TCP 鏈接。固然，鏈接開銷並無消失不見。實際上狀況變得更糟了，由於愈來愈多的應用程序開始使用 SSL/TLS 加密 HTTP 通訊。所以，大多數瀏覽器都設置了最大可能同時鏈接數的限制，以尋求微妙的平衡。

許多較大的 Web 服務已經意識到，現有的限制對於其交互極爲繁重的 Web 應用程序來講太過嚴格，所以它們會經過多個域名分發其應用程序來「玩弄系統」。這種辦法好歹起效了，可是解決方案根本談不上優雅。

儘管存在一些缺點，可是 HTTP/1.0 和 HTTP/1.1 的簡單性使它們得到了普遍的成功，而且十多年來，沒有人認真地嘗試過改變它們。

4. SPDY 和 HTTP/2

谷歌在 2008 年發佈了 Chrome 瀏覽器，這種瀏覽器因其快速和創新而迅速流行。它使谷歌在互聯網技術問題上得到了強大的話語權。在 2010 年代初期，谷歌在 Chrome 中增長了對其 Web 協議 SPDY 的支持。

HTTP/2 標準基於 SPDY，並進行了一些改進。HTTP/2 經過在單個打開的 TCP 鏈接上多路複用 HTTP 請求，解決了線頭阻塞問題。這容許服務器以任何順序響應請求，而後客戶端能夠在接收到響應時從新組合響應，從而在單個鏈接中加快整個交換的速度。

因爲 HTTP/2 能夠多路傳輸，所以在 large-picture.jpg 以前返回了 style.css

實際上，使用 HTTP/2 服務器甚至能夠在請求以前就將資源提供給客戶端！舉個例子，若是服務器知道客戶端極可能須要樣式表來顯示 HTML 頁面，它能夠將 CSS「推」到客戶端，而無需等待相應的請求。雖然這從理論上講是有益的，但此功能在實踐中不多見，由於它須要服務器瞭解其服務的 HTML 結構，但這種狀況不多發生。

除了請求正文之外，HTTP/2 還容許壓縮請求標頭，這進一步減小了經過網絡傳輸的數據量。

HTTP/2 解決了 Web 上的許多問題，但不是所有。在 TCP 協議級別上仍然存在相似類型的線頭問題，而 TCP 仍然是 Web 的基礎構建塊。當 TCP 數據包在傳輸過程當中丟失時，在服務器從新發送丟失的數據包以前，接收方沒法確認傳入的數據包。因爲 TCP 在設計上不遵循 HTTP 之類的高級協議，所以單個丟失的數據包將阻塞全部進行中的 HTTP 請求的流，直到從新發送丟失的數據爲止。這個問題在不可靠的鏈接上尤其突出，這在無處不在的移動設備時代並不罕見。

5. HTTP/3 革命

因爲 HTTP/2 的問題不能僅靠應用程序層來解決，所以協議的新迭代必須更新傳輸層。可是，建立新的傳輸層協議並不是易事。傳輸協議須要硬件供應商的支持，而且須要大多數網絡運營商的部署才能普及。因爲此事涉及的成本和工做量，運營商們不肯進行更新。以 IPv6 爲例：它是 24 年前推出的，但現在距離得到廣泛支持還有很遠的距離。

幸運的是還有另外一種選擇。UDP 協議與 TCP 同樣獲得普遍支持，但前者足夠簡單，能夠做爲在其之上運行的自定義協議的基礎。UDP 數據包是一勞永逸的：沒有握手、持久鏈接或錯誤校訂。HTTP3 背後的主要思想是放棄 TCP，轉而使用基於 UDP 的 QUIC 協議。QUIC 以對 Web 環境有意義的方式添加了許多必要的功能（包括之前由 TCP 提供的功能，以及更多功能）。

與 HTTP2 在技術上容許未加密的通訊不一樣，QUIC 嚴格要求加密後才能創建鏈接。此外，加密不只適用於 HTTP 負載，還適用於流經鏈接的全部數據，從而避免了一大堆安全問題。創建持久鏈接、協商加密協議，甚至發送第一批數據都被合併到 QUIC 中的單個請求 / 響應週期中，從而大大減小了鏈接等待時間。若是客戶端具備本地緩存的密碼參數，則能夠經過簡化的握手（0-RTT）從新創建與已知主機的鏈接。

爲了解決傳輸級別的線頭阻塞問題，經過 QUIC 鏈接傳輸的數據被分爲一些流。流是持久性 QUIC 鏈接中短暫、獨立的「子鏈接」。每一個流都處理本身的錯誤糾正和傳遞保證，但使用鏈接全局壓縮和加密屬性。每一個客戶端發起的 HTTP 請求都在單獨的流上運行，所以丟失數據包不會影響其餘流/請求的數據傳輸。

HTTP/3 將鏈接分爲單獨的流UDP 是一種無狀態協議（持久鏈接只是其之上的抽象），使 QUIC 可以支持一些很大程度上忽略了數據包傳遞複雜性的功能。例如，從理論上講，客戶端更改其 IP 地址中間鏈接（例如智能手機從移動網絡跳轉到家庭 wifi）時不該中斷鏈接，由於該協議容許在不一樣 IP 地址之間遷移而無需從新鏈接。

QUIC 協議的全部現有實現當前都在用戶空間，而不是 OS 內核中運行。因爲客戶端（例如瀏覽器）和服務器的更新一般比操做系統內核更新的頻率更高，所以人們但願能夠藉此更快地採用新功能。

6. HTTP/3 存在的問題

我認爲 HTTP/3 標準雖然是向更快、更安全的互聯網邁出的一大步，但它並不完美。它的某些問題是由其新穎性引發的，而其餘一些問題彷佛是該協議固有的。

TCP 協議已經存在了很長時間，對於路由器來講很容易理解。它具備清晰的未加密標記（用於創建和關閉鏈接），可用於跟蹤和控制現有會話。在網絡硬件學會了解新協議以前，它將把 QUIC 流量簡單地看做獨立的 UDP 數據包流，這將使網絡配置更加棘手。

從客戶端緩存「恢復」鏈接的能力使該協議很容易遭受重播***：在某些狀況下，惡意***者能夠從新發送之前捕獲的數據包，這些數據包將被服務器解釋爲有效的，來自受害者的。像那些提供靜態內容的 Web 服務器同樣，許多 Web 服務器不會受到此類***的傷害。對於身處易受***環境的應用程序來講，必需要記住禁用 0-RTT 功能。

這就是 HTTP 到今天爲止的故事。我認爲 HTTP/3 是向前邁出的一大步，而且固然但願 HTTP/3 在不久的未來會被普遍採用。

原文連接：https://scorpil.com/post/the-long-road-to-http3/

做者 | Scorpil譯者 | 王強策劃 | 萬佳 | 文章轉自：InfoQ