HTTP/3 為什么這么快？

HTTP/3 已經(jīng)來(lái)臨，這對(duì) Web 性能是件大事。讓我們看看它能讓網(wǎng)站速度提升多少吧！

等等，HTTP/2 難道不好么？它在這幾年不是挺火的嗎？確實(shí)是，但它仍有一些問(wèn)題。為了解決這些問(wèn)題，新版本的協(xié)議正朝向“標(biāo)準(zhǔn)跟蹤（standards track，RFC 的類別之一）”做出努力。

嗯，但 HTTP/3 真能讓網(wǎng)絡(luò)變得更快？它肯定能，我們將用基準(zhǔn)測(cè)試來(lái)證明這一點(diǎn)。

預(yù)覽

在我們深入細(xì)節(jié)之前，讓我們快速預(yù)覽一下基準(zhǔn)測(cè)試的結(jié)果。在下方的圖表中，我們?cè)谙嗤木W(wǎng)絡(luò)中使用相同的瀏覽器請(qǐng)求相同的站點(diǎn)，唯一不同的只是 HTTP 協(xié)議的版本。每個(gè)站點(diǎn)都被重復(fù)請(qǐng)求 20 次，響應(yīng)時(shí)間通過(guò)瀏覽器的 Performance API 測(cè)量。（更多關(guān)于基準(zhǔn)測(cè)試的細(xì)節(jié)在下方。）

你可以清楚地看到使用每個(gè)新版本的 HTTP 協(xié)議（相較于 HTTP/1.1）帶來(lái)的性能提升：

當(dāng)?shù)乩砭嚯x更遠(yuǎn)或網(wǎng)絡(luò)不太可靠時(shí)，這些差別將變得更加明顯。

在了解 HTTP/3 基準(zhǔn)測(cè)試的細(xì)節(jié)之前，我們需要知道一些背景知識(shí)。

HTTP 簡(jiǎn)史

HTTP（超文本傳輸協(xié)議 1.0）的第一個(gè)正式版本在 1996 年完成。然而，該版本存在一些實(shí)踐問(wèn)題且部分標(biāo)準(zhǔn)需要更新，所以 HTTP/1.1 在一年后（也就是 1997 年）發(fā)布了。正如作者所說(shuō)：

然而，HTTP/1.0 沒(méi)有充分考慮分層代理、緩存、持久連接的需求和虛擬主機(jī)的影響。此外，將自身標(biāo)榜為 "HTTP/1.0" 但又沒(méi)完全實(shí)踐 HTTP/1.0 的應(yīng)用數(shù)量急劇增加；因此，我們需要一個(gè)新版的協(xié)議以便兩個(gè)相互通信應(yīng)用能確認(rèn)對(duì)方真實(shí)的通信能力。

18 年后，新版本的 HTTP 發(fā)布了。在 2015 年，RFC 7540 大張旗鼓地宣布，會(huì)將 HTTP/2 標(biāo)準(zhǔn)化為協(xié)議的下一個(gè)主要版本。

一個(gè)連接，一個(gè)文件

如果一個(gè)網(wǎng)頁(yè)需要 10 個(gè) JavaScript 文件，那么瀏覽器就需要檢索所有的 10 個(gè)文件才能完成加載。在 HTTP/1.1 那個(gè)時(shí)代，一次與服務(wù)器的 TCP 連接只能下載一個(gè)文件。這意味著文件是依次下載的，只要有一個(gè)文件出現(xiàn)延遲，后面的所有下載都會(huì)被阻塞。這個(gè)現(xiàn)象被稱為隊(duì)頭阻塞；這對(duì)頁(yè)面性能是不利的。

為了解決這個(gè)問(wèn)題，瀏覽器可以打開(kāi)多個(gè) TCP 連接來(lái)并行地檢索資源。然而，這是種資源密集型的方法。每個(gè)新的 TCP 連接都會(huì)消耗客戶端和服務(wù)端的資源；并且當(dāng)你再引入 TLS 后，整個(gè)通信過(guò)程將會(huì)發(fā)生大量的 SSL 協(xié)商。因此，我們需要一種更好的解決方案。

HTTP/2 中的多路復(fù)用

HTTP/2 的最大亮點(diǎn)就是它的多路復(fù)用（multiplexing）機(jī)制。HTTP/2 解決了應(yīng)用層的隊(duì)頭阻塞的問(wèn)題，通過(guò)將為數(shù)據(jù)轉(zhuǎn)化為二進(jìn)制（譯者注：并且在傳輸前將數(shù)據(jù)進(jìn)行分幀，以幀為單位進(jìn)行傳輸），使得在多文件下載時(shí)能夠多路復(fù)用。即，客戶端可以同時(shí)請(qǐng)求所有的 10 個(gè)文件，并通過(guò)一個(gè) TCP 連接并行地下載這 10 個(gè)文件。

不幸的是，HTTP/2 的通信過(guò)程中仍存在隊(duì)頭阻塞的問(wèn)題，而源頭就出現(xiàn)在它的下一層 —— TCP 變成了傳輸鏈上最脆弱的一環(huán)。任何出現(xiàn)了丟包的數(shù)據(jù)流都需要等待該包重新傳輸后才能繼續(xù)。

然而，由于 HTTP/2 多路復(fù)用的并行特性對(duì)于 TCP 的丟包恢復(fù)機(jī)制是不可見(jiàn)的，一個(gè)丟失或順序不對(duì)的數(shù)據(jù)包會(huì)導(dǎo)致所有活動(dòng)的事務(wù)停頓，無(wú)論其是否受到丟包的直接影響。

事實(shí)上，在高丟包的環(huán)境下，HTTP/1.1 反而表現(xiàn)得更好，正是因?yàn)?HTTP/2 開(kāi)了太多并行的 TCP 連接！

QUIC 和 HTTP/3 中真正的多路復(fù)用

現(xiàn)在說(shuō)到 HTTP/3。HTTP/2 和 HTTP/3 的主要區(qū)別在于所使用的傳輸協(xié)議。與之前的 TCP 協(xié)議不同，HTTP/3 使用了一個(gè)全新的協(xié)議 —— QUIC。QUIC 是一個(gè)通用的傳輸協(xié)議，解決了 HTTP/2 因?yàn)?TCP 而產(chǎn)生的隊(duì)頭阻塞問(wèn)題。這個(gè)協(xié)議能讓你通過(guò) UDP 創(chuàng)建一系列帶狀態(tài)的流（這與 TCP 很相似）。

QUIC 傳輸協(xié)議包含流的復(fù)用和對(duì)每個(gè)流的流量控制，這兩者與 HTTP/2 中實(shí)現(xiàn)的類似。通過(guò)在整個(gè)連接中提供流級(jí)別的可靠性和擁塞控制，比起 TCP 映射，QUIC 更能提高 HTTP 的性能。

如果你不關(guān)心測(cè)試是怎么進(jìn)行的，那就跳到下方的結(jié)果吧！

HTTP/3 的基準(zhǔn)測(cè)試

要想了解 HTTP/3 在性能方面帶來(lái)了什么改變，我們需要先搭建一個(gè)基準(zhǔn)測(cè)試環(huán)境。

HTML

為了能更貼合實(shí)際使用情況，這次的測(cè)試考慮了三種場(chǎng)景 —— 一個(gè)小型站點(diǎn)、一個(gè)內(nèi)容站點(diǎn)（大量圖片和些許 JavaScript 資源）和一個(gè)單頁(yè)面應(yīng)用（大量 JavaScript 資源）。我查看了幾個(gè)現(xiàn)實(shí)生活中的站點(diǎn)，并計(jì)算了每個(gè)站點(diǎn)的圖片和 JavaScript 文件的平均數(shù)量，然后編寫了一些與這些資源數(shù)量（和大小）差不多的的演示站點(diǎn)。

  • 小型站點(diǎn)
    • 10 個(gè) 2 kB 到 100 kB 的 JavaScript 文件；
    • 10 張 1kB 到 50 kB 的圖片；
    • 總載荷大小 600 kB，共計(jì) 20 個(gè)阻塞資源。
  • 內(nèi)容站點(diǎn)
    • 50 個(gè) 2 kB 到 1 MB 的 JavaScript 文件；
    • 55 張 1 kB 到 1 MB 的圖片；
    • 總載荷大小 10MB，共計(jì) 105 個(gè)阻塞資源（在開(kāi)發(fā)者工具中看看 cnn.com 你就會(huì)明白這個(gè)量為什么會(huì)這么大了）。
  • 單頁(yè)面應(yīng)用
    • 85 個(gè) 2 kB 到 1 MB 的 JavaScript 文件；
    • 30 張 1 kB 到 50 kB 的圖片；
    • 總載荷大小 15MB，共計(jì) 115 個(gè)阻塞資源（在開(kāi)發(fā)者工具中看看 JIRA （缺陷跟蹤管理系統(tǒng)）吧）。

服務(wù)端

Caddy 作為這次測(cè)試的服務(wù)器，向外提供資源及 HTML。

  • 所有響應(yīng)都使用 Cache-Control: "no-store" 以確保瀏覽器每次都會(huì)重新下載資源；
  • HTTP/1.1 和 HTTP/2 使用 TLS 1.2；
  • HTTP/3 使用 TLS 1.3；
  • 所有的 HTTP/3 連接都開(kāi)啟 0-RTT。

地理位置

測(cè)試是從我在明尼蘇達(dá)州的計(jì)算機(jī)到三個(gè)獨(dú)立數(shù)據(jù)中心（由 Digital Ocean 托管）進(jìn)行的：

  • 美國(guó)紐約
  • 英國(guó)倫敦
  • 印度班加羅爾

客戶端

瀏覽器將連續(xù)請(qǐng)求同一個(gè)頁(yè)面 20 次，每次請(qǐng)求間隔 3 秒，過(guò)程完全自動(dòng)化。網(wǎng)絡(luò)的額定速度為 200 Mbps。數(shù)據(jù)采集時(shí)，計(jì)算機(jī)上沒(méi)有運(yùn)行其他應(yīng)用程序。

HTTP/3 有多快？

美國(guó)紐約

以下是從紐約數(shù)據(jù)中心請(qǐng)求三個(gè)不同站點(diǎn)時(shí) HTTP/2 與 HTTP/3 的響應(yīng)時(shí)間：

HTTP/3 在：

  • 小型站點(diǎn)快了 200 毫秒
  • 內(nèi)容站點(diǎn)快了 325 毫秒
  • 單頁(yè)面應(yīng)用快了 300 毫秒

明尼蘇達(dá)州距離紐約 1000 英里（約等于 160 公里）；這長(zhǎng)度對(duì)于網(wǎng)絡(luò)連接來(lái)說(shuō)不算什么。然而重要的是，即使在相對(duì)較短的距離內(nèi)，HTTP/3 也能夠?qū)⑿阅芴岣哌@么多。

英國(guó)倫敦

在這次的測(cè)試中，我也包含了 HTTP/1.1 的基準(zhǔn)測(cè)試。為了展示 HTTP/2 和 HTTP/3 快了多少，我將下方圖表的軸刻度都保持一致了。你可以看到，對(duì)于內(nèi)容站點(diǎn)，HTTP/1.1 的速度是多么的慢；慢得連圖表都不能完全顯示！

正如你所見(jiàn)，當(dāng)網(wǎng)絡(luò)的距離更遠(yuǎn)時(shí)，速度的提高更明顯了。

  • 小型站點(diǎn)快了 600 毫秒（速度是紐約的 3 倍）
  • 內(nèi)容站點(diǎn)快了 1200 毫秒（速度是紐約的 3.5 倍）
  • 單頁(yè)面應(yīng)用快了 1000 毫秒（速度是紐約的 3 倍）

印度班加羅爾

HTTP/3 性能的進(jìn)步在從印度加載頁(yè)面時(shí)最為明顯。我并不打算測(cè)試 HTTP/1.1，因?yàn)樗恕Ｒ韵率?HTTP/2 與 HTTP/3 的結(jié)果對(duì)比：

當(dāng)請(qǐng)求涉及更大的地理區(qū)域和更多的網(wǎng)絡(luò)躍點(diǎn)時(shí)，HTTP/3 仍然繼續(xù)領(lǐng)先。更值得注意的是 HTTP/3 的響應(yīng)時(shí)間數(shù)據(jù)分布是多么的集中（譯者注：這說(shuō)明在保證快的前提下，HTTP/3也很穩(wěn)定）。當(dāng)數(shù)據(jù)包傳輸數(shù)千英里時(shí)，QUIC 將發(fā)揮重要的作用。

在每種情況下 HTTP/3 都比歷代 HTTP 更快！

為什么 HTTP/3 這么快？

真正的多路復(fù)用

HTTP/3 真正的多路復(fù)用特性意味著堆棧上的任何地方都不會(huì)發(fā)生隊(duì)頭阻塞。當(dāng)你從更遠(yuǎn)的地理位置請(qǐng)求資源時(shí)，丟包的可能性會(huì)高出很多，TCP 重新傳輸?shù)男枨笠矔?huì)提高。

顛覆局面的 0-RTT

此外，HTTP/3 也支持 0-RTT QUIC 連接，減少了建立安全 TLS 連接的數(shù)據(jù)往返次數(shù)。

QUIC 中的 0-RTT 功能能讓客戶端在三次握手完成之前發(fā)送應(yīng)用數(shù)據(jù)。這個(gè)功能通過(guò)重用先前連接的參數(shù)實(shí)現(xiàn)。0-RTT 依賴于客戶端記住的重要參數(shù)，并向服務(wù)器提供 TLS 會(huì)話票證（session ticket）以恢復(fù)相同的信息。

然而，你不應(yīng)該盲目地啟用 0-RTT?；谀愕耐{模型，它可能存在一些安全問(wèn)題。

0-RTT 數(shù)據(jù)的安全屬性弱于其他類型的 TLS 數(shù)據(jù)。具體來(lái)說(shuō)：

  1. 數(shù)據(jù)不是前向保密（forward secret）的；數(shù)據(jù)僅僅只被預(yù)共享密鑰（pre-shared key，PSK）衍生的密鑰加密。
  2. 不能保證連接之間不重放（譯者注：詳情見(jiàn)重放攻擊）。

我現(xiàn)在能用 HTTP/3 了嗎？

或許可以喔！雖然協(xié)議現(xiàn)在仍處于互聯(lián)網(wǎng)草案（Internet-Draft）狀態(tài)，但市面上已有許多不同的實(shí)踐方案了。

作為這次的基準(zhǔn)測(cè)試，我特別選擇了 Caddy。我只需要修改 Caddyfile 中的一個(gè)簡(jiǎn)單的配置就能啟用 HTTP/3。

Nginx 對(duì) HTTP/3 也有實(shí)驗(yàn)性的支持，且正在朝向?qū)l(fā)布的 HTTP/3（它就在不久的將來(lái)）邁進(jìn)。

像是谷歌和 Facebook 這些科技巨擘已經(jīng)通過(guò) HTTP/3 提供服務(wù)了。在現(xiàn)代瀏覽器中，Google.com 已完全使用 HTTP/3。

對(duì)于那些“困在”微軟生態(tài)系統(tǒng)中的用戶，據(jù)說(shuō) Windows Server 2022 將會(huì)支持 HTTP/3，但你需要執(zhí)行一些“深?yuàn)W”的步驟來(lái)啟用它。

總結(jié)

HTTP/3 能在用戶體驗(yàn)方面帶來(lái)了很大的改善。在一般情況下，站點(diǎn)需要的資源越多，HTTP/3 和 QUIC 的性能提升就越大。隨著標(biāo)準(zhǔn)離定稿越來(lái)越近，也許你是時(shí)候該考慮為你的網(wǎng)站啟用 HTTP/3 了。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容