[[355676]]

 雖然 HTTP/3 規(guī)范仍處于起草階段，但最新版本的 Chrome 瀏覽器已經(jīng)默認支持它了。Chrome 擁有約 70％的瀏覽器市場份額，所以，可以說 HTTP/3 已經(jīng)進入主流世界。

這一基礎協(xié)議的最新修訂版旨在讓 Web 更加高效、安全并縮短內(nèi)容交付延遲。從某些角度來說，它是 HTTP2 的完善：通過使用新的專用協(xié)議 QUIC 替換基礎 TCP 協(xié)議來解決和之前類似的目標。

想要弄明白 QUIC 的優(yōu)點，最好的辦法是講清楚 TCP 作為 HTTP 請求的傳輸方式有哪些不足之處。

為此，我們將從頭開始細細道來。

1. HTTP：起源

1991 年，當?shù)倌?middot;伯納斯·李爵士設計出一個簡單的單行超文本交換協(xié)議時，TCP 已經(jīng)是一個古老而可靠的協(xié)議了。前者的原始定義文檔（也就是后人熟知的 HTTP 0.9）特別提到 TCP 是首選的（盡管并非唯一的）傳輸協(xié)議：

注意：HTTP 當前運行在 TCP 上，但也可以運行在任何面向連接的服務上。

當然，HTTP 的這個概念驗證版本與我們現(xiàn)在所知道和喜歡的 HTTP 幾乎沒有相似之處。沒有標頭，也沒有狀態(tài)碼。典型的請求只有GET/path而已。響應僅包含 HTML，且 TCP 連接關閉就會結束。

由于瀏覽器尚未流行，因此用戶需要直接閱讀 HTML。可以用它鏈接到其他資源，但是在這個 HTML 早期版本中存在的所有標簽都不會異步請求其他資源。一個 HTTP 請求就傳遞了一個完整的、自給自足的頁面。

2. HTTP/1.0 出現(xiàn)

在隨后幾年中，互聯(lián)網(wǎng)迎來爆炸式的發(fā)展，盡管傳輸 HTML 仍然是 HTTP 的主要特色，但它逐漸發(fā)展成一種可擴展且靈活的通用協(xié)議。HTTP 的三大重要更新奠定了這一演變的基礎：

•  方法的引入使客戶能確定其想要執(zhí)行操作的類型。例如，引入 POST 是為了允許客戶端將數(shù)據(jù)發(fā)送到服務器以處理和存儲；
•  狀態(tài)碼為客戶端提供了一種確認服務器已成功處理請求的方法——如果處理失敗，則可以用它了解發(fā)生了哪種錯誤；
•  標頭增加了將結構化文本元數(shù)據(jù)附加到可以修改客戶端或服務器行為的請求和響應上的功能。例如，編碼和內(nèi)容類型頭使 HTTP 不僅可以傳輸 HTML，還可以傳輸任何類型的負載。“壓縮”標頭允許客戶端和服務器協(xié)商支持的壓縮格式，從而減少了通過連接傳輸?shù)臄?shù)據(jù)量。

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

現(xiàn)在，瀏覽器需要執(zhí)行多個請求來顯示一個網(wǎng)頁，而原始的“按請求連接”架構是做不到的。建立和終止 TCP 連接涉及大量的數(shù)據(jù)包來回交換，因此在延遲開銷方面相對昂貴。網(wǎng)頁不見得一定由單個文本文件組成，但是隨著每頁請求數(shù)量的增加，延遲也隨之增加。

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

TCP 連接需要三個請求才能建立連接，四個請求可以完全關閉。

人們創(chuàng)建了一個“連接”標頭來解決這個問題。客戶端發(fā)送帶有“connection:keep-alive”標頭的請求，以表明意圖為后續(xù)請求保持 TCP 連接的打開狀態(tài)。如果服務器理解此標頭并同意遵守該標頭，則其響應還將包含“connection:keep-alive”標頭。

這樣，雙方都保持 TCP 通道打開并使用它進行后續(xù)通信，直到任何一方?jīng)Q定關閉它為止。隨著 SSL/TLS 加密技術的發(fā)展，這一點變得更加重要，因為協(xié)商加密算法和交換加密密鑰需要在每個連接上增加一個請求 / 響應周期。

單個 TCP 連接可以通過“connection:keep-alive”標頭。

重用于多個請求當時，許多 HTTP 改進都是自發(fā)出現(xiàn)的。當流行的瀏覽器或服務器應用程序需要新的 HTTP 功能時，它們會自己實現(xiàn)該功能，并希望其他各方也能效仿。具有諷刺意味的是，去中心化的 Web 需要一個中心化的管理機構來避免碎片化造成的不兼容問題。

該協(xié)議的最初創(chuàng)建者蒂姆·伯納斯·李（TimBerners-Lee）意識到了這種危險，并于 1994 年成立了萬維網(wǎng)聯(lián)盟（W3C），該聯(lián)盟與互聯(lián)網(wǎng)工程任務組（IETF）一起致力于規(guī)范互聯(lián)網(wǎng)的技術棧。作為為已有環(huán)境帶來更多規(guī)范的第一步，他們記錄了當時 HTTP 中最常用的一些功能，并將其命名為 HTTP/1.0 協(xié)議。

但是，由于這種“規(guī)范”描述的是多種多樣的，通常在“實踐”中用法不一致的技術，因此它從未獲得過標準地位。相比之下，關于 HTTP 協(xié)議新版本的工作已經(jīng)開始了。

3. HTTP/1.1 的標準化

HTTP/1.1 修復了 HTTP/1.0 的不一致之處，并調(diào)整了協(xié)議，使其在新的 Web 生態(tài)系統(tǒng)中具備更好的性能表現(xiàn)。新版引入的兩個最關鍵的更改是默認使用持久 TCP 連接（保持活動狀態(tài)）和 HTTP 管線化。

HTTP 管線化的意思就是客戶端無需在發(fā)送后續(xù) HTTP 請求之前等待服務器響應請求。此功能可以更有效地利用帶寬并減少延遲，但它的改進空間甚至更大。HTTP 管線化仍要求服務器按照接收到的請求順序進行響應，因此，如果管線化中的單個請求執(zhí)行得很慢，則對客戶端的所有后續(xù)響應都將相應地延遲下去。這個問題被稱為線頭阻塞。

由于首先請求了 large-picture.jpg，因此阻止了 style.css 的發(fā)布

在這個時候，Web 正在獲得越來越多的交互功能。Web 2.0 指日可待，一些網(wǎng)頁包含數(shù)十個甚至數(shù)百個外部資源。為解決線頭阻塞，并降低頁面加載速度，客戶端會在每個主機上建立多個 TCP 連接。當然，連接開銷并沒有消失不見。實際上情況變得更糟了，因為越來越多的應用程序開始使用 SSL/TLS 加密 HTTP 通信。因此，大多數(shù)瀏覽器都設置了最大可能同時連接數(shù)的限制，以尋求微妙的平衡。

許多較大的 Web 服務已經(jīng)意識到，現(xiàn)有的限制對于其交互極為繁重的 Web 應用程序來說太過嚴格，因此它們會通過多個域名分發(fā)其應用程序來“玩弄系統(tǒng)”。這種辦法好歹起效了，但是解決方案根本談不上優(yōu)雅。

盡管存在一些缺點，但是 HTTP/1.0 和 HTTP/1.1 的簡單性使它們獲得了廣泛的成功，并且十多年來，沒有人認真地嘗試過改變它們。

4. SPDY 和 HTTP/2

谷歌在 2008 年發(fā)布了 Chrome 瀏覽器，這種瀏覽器因其快速和創(chuàng)新而迅速流行。它使谷歌在互聯(lián)網(wǎng)技術問題上獲得了強大的話語權。在 2010 年代初期，谷歌在 Chrome 中增加了對其 Web 協(xié)議 SPDY 的支持。

HTTP/2 標準基于 SPDY，并進行了一些改進。HTTP/2 通過在單個打開的 TCP 連接上多路復用 HTTP 請求，解決了線頭阻塞問題。這允許服務器以任何順序響應請求，然后客戶端可以在接收到響應時重新組合響應，從而在單個連接中加快整個交換的速度。

由于 HTTP/2 可以多路傳輸，因此在 large-picture.jpg 之前返回了 style.css

實際上，使用 HTTP/2 服務器甚至可以在請求之前就將資源提供給客戶端！舉個例子，如果服務器知道客戶端很可能需要樣式表來顯示 HTML 頁面，它可以將 CSS“推”到客戶端，而無需等待相應的請求。雖然這從理論上講是有益的，但此功能在實踐中很少見，因為它需要服務器了解其服務的 HTML 結構，但這種情況很少發(fā)生。

除了請求正文以外，HTTP/2 還允許壓縮請求標頭，這進一步減少了通過網(wǎng)絡傳輸?shù)臄?shù)據(jù)量。

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

5. HTTP/3 革命

由于 HTTP/2 的問題不能僅靠應用程序?qū)觼斫鉀Q，因此協(xié)議的新迭代必須更新傳輸層。但是，創(chuàng)建新的傳輸層協(xié)議并非易事。傳輸協(xié)議需要硬件供應商的支持，并且需要大多數(shù)網(wǎng)絡運營商的部署才能普及。由于此事涉及的成本和工作量，運營商們不愿進行更新。以 IPv6 為例：它是 24 年前推出的，但如今距離獲得普遍支持還有很遠的距離。

幸運的是還有另一種選擇。UDP 協(xié)議與 TCP 一樣得到廣泛支持，但前者足夠簡單，可以作為在其之上運行的自定義協(xié)議的基礎。UDP 數(shù)據(jù)包是一勞永逸的：沒有握手、持久連接或錯誤校正。HTTP3 背后的主要思想是放棄 TCP，轉而使用基于 UDP 的 QUIC 協(xié)議。QUIC 以對 Web 環(huán)境有意義的方式添加了許多必要的功能（包括以前由 TCP 提供的功能，以及更多功能）。

與 HTTP2 在技術上允許未加密的通信不同，QUIC 嚴格要求加密后才能建立連接。此外，加密不僅適用于 HTTP 負載，還適用于流經(jīng)連接的所有數(shù)據(jù)，從而避免了一大堆安全問題。建立持久連接、協(xié)商加密協(xié)議，甚至發(fā)送第一批數(shù)據(jù)都被合并到 QUIC 中的單個請求 / 響應周期中，從而大大減少了連接等待時間。如果客戶端具有本地緩存的密碼參數(shù)，則可以通過簡化的握手（0-RTT）重新建立與已知主機的連接。

為了解決傳輸級別的線頭阻塞問題，通過 QUIC 連接傳輸?shù)臄?shù)據(jù)被分為一些流。流是持久性 QUIC 連接中短暫、獨立的“子連接”。每個流都處理自己的錯誤糾正和傳遞保證，但使用連接全局壓縮和加密屬性。每個客戶端發(fā)起的 HTTP 請求都在單獨的流上運行，因此丟失數(shù)據(jù)包不會影響其他流/請求的數(shù)據(jù)傳輸。

HTTP/3 將連接分為單獨的流UDP 是一種無狀態(tài)協(xié)議（持久連接只是其之上的抽象），使 QUIC 能夠支持一些很大程度上忽略了數(shù)據(jù)包傳遞復雜性的功能。例如，從理論上講，客戶端更改其 IP 地址中間連接（例如智能手機從移動網(wǎng)絡跳轉到家庭 wifi）時不應中斷連接，因為該協(xié)議允許在不同 IP 地址之間遷移而無需重新連接。

QUIC 協(xié)議的所有現(xiàn)有實現(xiàn)當前都在用戶空間，而不是 OS 內(nèi)核中運行。由于客戶端（例如瀏覽器）和服務器的更新通常比操作系統(tǒng)內(nèi)核更新的頻率更高，因此人們希望可以藉此更快地采用新功能。

6. HTTP/3 存在的問題

我認為 HTTP/3 標準雖然是向更快、更安全的互聯(lián)網(wǎng)邁出的一大步，但它并不完美。它的某些問題是由其新穎性引起的，而其他一些問題似乎是該協(xié)議固有的。

TCP 協(xié)議已經(jīng)存在了很長時間，對于路由器來說很容易理解。它具有清晰的未加密標記（用于建立和關閉連接），可用于跟蹤和控制現(xiàn)有會話。在網(wǎng)絡硬件學會了解新協(xié)議之前，它將把 QUIC 流量簡單地看作獨立的 UDP 數(shù)據(jù)包流，這將使網(wǎng)絡配置更加棘手。

從客戶端緩存“恢復”連接的能力使該協(xié)議很容易遭受重播攻擊：在某些情況下，惡意攻擊者可以重新發(fā)送以前捕獲的數(shù)據(jù)包，這些數(shù)據(jù)包將被服務器解釋為有效的，來自受害者的。像那些提供靜態(tài)內(nèi)容的 Web 服務器一樣，許多 Web 服務器不會受到此類攻擊的傷害。對于身處易受攻擊環(huán)境的應用程序來說，必須要記住禁用 0-RTT 功能。

這就是 HTTP 到今天為止的故事。我認為 HTTP/3 是向前邁出的一大步，并且當然希望 HTTP/3 在不久的將來會被廣泛采用。