[[355676]]

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

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

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

為此，我們將從頭開始細(xì)細(xì)道來。

1. HTTP：起源

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

注意：HTTP 當(dāng)前運(yùn)行在 TCP 上，但也可以運(yùn)行在任何面向連接的服務(wù)上。

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

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

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

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

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

同時(shí)，HTML 也不斷進(jìn)化，支持了圖像、樣式和其他鏈接資源。

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

下圖說明了每建立一個(gè)新的 TCP 連接涉及多少請(qǐng)求開銷。

TCP 連接需要三個(gè)請(qǐng)求才能建立連接，四個(gè)請(qǐng)求可以完全關(guān)閉。

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

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

單個(gè) TCP 連接可以通過“connection:keep-alive”標(biāo)頭。

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

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

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

3. HTTP/1.1 的標(biāo)準(zhǔn)化

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

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

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

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

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

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

4. SPDY 和 HTTP/2

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

HTTP/2 標(biāo)準(zhǔn)基于 SPDY，并進(jìn)行了一些改進(jìn)。HTTP/2 通過在單個(gè)打開的 TCP 連接上多路復(fù)用 HTTP 請(qǐng)求，解決了線頭阻塞問題。這允許服務(wù)器以任何順序響應(yīng)請(qǐng)求，然后客戶端可以在接收到響應(yīng)時(shí)重新組合響應(yīng)，從而在單個(gè)連接中加快整個(gè)交換的速度。

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

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

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

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

5. HTTP/3 革命

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

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

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

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

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

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

6. HTTP/3 存在的問題

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

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

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

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