超文本傳輸協(xié)議（HTTP）是互聯(lián)網(wǎng)的基石，有助于加載網(wǎng)頁、流式傳輸視頻以及為我們喜愛的應(yīng)用程序獲取數(shù)據(jù)。

去年，負(fù)責(zé)定義互聯(lián)網(wǎng)技術(shù)的互聯(lián)網(wǎng)工程任務(wù)組（IETF）對(duì)該協(xié)議的新版本 HTTP/3 進(jìn)行了標(biāo)準(zhǔn)化。此后，HTTP/3 和相關(guān)的 QUIC 協(xié)議在公共網(wǎng)絡(luò)上迅速普及。具體數(shù)字取決于資料來源和測量方法，全球支持 HTTP/3 的網(wǎng)絡(luò)服務(wù)器和網(wǎng)絡(luò)的比例從 19% 到 50% 以上不等。

由于谷歌和 Meta 等大公司都在大量使用這些新協(xié)議，我們可以有把握地說，目前大部分互聯(lián)網(wǎng)流量都已使用 HTTP/3

在本文中將介紹 HTTP/3 解決了哪些問題、它的性能如何、為何能如此迅速地被采用，以及它仍在努力克服哪些限制。

為什么需要 HTTP/3？

網(wǎng)絡(luò)協(xié)議描述了網(wǎng)絡(luò)上兩個(gè)實(shí)體（通常是用戶設(shè)備和網(wǎng)絡(luò)服務(wù)器）之間的數(shù)據(jù)通信方式。由于有許多不同的公司都在為網(wǎng)絡(luò)開發(fā)軟件，因此需要將協(xié)議標(biāo)準(zhǔn)化，以便所有這些軟件都能 "互操作"，也就是說，它們都能相互理解，因?yàn)樗鼈冏裱嗤囊?guī)則。

實(shí)際上，我們并不使用單一協(xié)議，而是同時(shí)使用多個(gè)協(xié)議的組合，每個(gè)協(xié)議都有自己的職責(zé)和規(guī)則（圖 1）。這樣做的目的是讓事情變得靈活和可重復(fù)使用--無論你使用的是 Wi-Fi、有線電視還是 4G/5G，你都可以使用完全相同的 HTTP 邏輯。

互聯(lián)網(wǎng)的許多原始協(xié)議都是在上世紀(jì) 80 和 90 年代標(biāo)準(zhǔn)化的，這意味著它們是根據(jù)當(dāng)時(shí)的目標(biāo)和限制而構(gòu)建的。其中一些協(xié)議經(jīng)受住了時(shí)間的考驗(yàn)，而另一些協(xié)議則開始顯出老態(tài)。大多數(shù)問題都通過變通方法和巧妙技巧得到了解決。不過，很明顯，有些東西必須改變。傳輸控制協(xié)議（TCP）尤其如此，它可以確保您的數(shù)據(jù)在互聯(lián)網(wǎng)上可靠傳輸。

為什么 TCP 協(xié)議不是當(dāng)今網(wǎng)絡(luò)的最佳選擇

HTTP/1.1 和 HTTP/2 依靠 TCP 成功完成任務(wù)。在客戶端和服務(wù)器交換 HTTP 請(qǐng)求/響應(yīng)之前，它們必須建立 TCP 連接。

隨著時(shí)間的推移，人們一直在努力更新 TCP 并解決它的一些低效問題--TCP 仍然把網(wǎng)頁當(dāng)作單個(gè)文件加載，而不是成百上千個(gè)單獨(dú)文件的集合。其中一些更新取得了成功，但大多數(shù)影響較大的更新（如 TCP 多路徑和 TCP 快速打開）需要近十年的時(shí)間才能在公共互聯(lián)網(wǎng)上實(shí)際使用。

對(duì) TCP 協(xié)議進(jìn)行修改所面臨的主要挑戰(zhàn)是，互聯(lián)網(wǎng)上成千上萬的設(shè)備都有自己的 TCP 協(xié)議。這些設(shè)備包括手機(jī)、筆記本電腦和服務(wù)器，以及路由器、防火墻、負(fù)載平衡器和其他類型的 "中間件"。因此，如果我們想更新 TCP 協(xié)議，就必須等待所有這些設(shè)備中的很大一部分更新它們的實(shí)現(xiàn)，而這實(shí)際上可能需要數(shù)年時(shí)間。

QUIC 解決方案

這就成了一個(gè)問題，以至于最實(shí)際的辦法就是用一種全新的協(xié)議來取代 TCP。這種替代品就是 QUIC 協(xié)議，盡管許多人仍然（開玩笑地）把它稱為 TCP 2.0。這個(gè)昵稱是恰當(dāng)?shù)?，因?yàn)?QUIC 包含了許多與 TCP 相同的高級(jí)功能，但也有一些關(guān)鍵的變化。

主要變化是 QUIC 與傳輸層安全（TLS）協(xié)議進(jìn)行了大量整合。TLS 負(fù)責(zé)加密網(wǎng)絡(luò)上的敏感數(shù)據(jù)，也就是 HTTPS 中的 S（安全）。使用 TCP 時(shí)，TLS 只對(duì)實(shí)際 HTTP 數(shù)據(jù)進(jìn)行加密（圖 2）。對(duì)于 QUIC，TLS 還對(duì) QUIC 協(xié)議本身的大部分內(nèi)容進(jìn)行加密。這就意味著，在 TCP 中所有中間件都能看到（并且可以更改）的數(shù)據(jù)包編號(hào)和連接關(guān)閉信號(hào)等元數(shù)據(jù)，現(xiàn)在只有 QUIC 中的客戶端和服務(wù)器才能看到。

此外，由于 QUIC 進(jìn)行了更廣泛的加密，因此更改它或添加新功能比 TCP 要容易得多--我們只需更新客戶端和服務(wù)器，因?yàn)橹虚g件無論如何都無法解密元數(shù)據(jù)。這使得 QUIC 成為一個(gè)面向未來的協(xié)議，讓我們能夠更快地解決新的挑戰(zhàn)

QUIC 還具有許多其他與安全相關(guān)的功能，包括防御分布式拒絕服務(wù) (DDoS) 攻擊，如防止放大和 RETRY 數(shù)據(jù)包。

最后，與 TCP 相比，QUIC 還在效率和性能方面做了大量改進(jìn)，包括更快的連接握手（見圖 3）、消除 "線頭阻塞 "問題、更好的丟包檢測/恢復(fù)以及處理用戶切換網(wǎng)絡(luò)的方法（我將在下一篇文章中詳細(xì)介紹）。

我們不需要 HTTP/3，我們需要的是 QUIC

最初，有人試圖保留 HTTP/2，并進(jìn)行最小程度的調(diào)整，以便我們也能在底層使用 QUIC（畢竟，這正是這些不同的合作和可重用協(xié)議的意義所在）。然而，QUIC 與 TCP 的差異顯然足以使其與 HTTP/2 不兼容。因此，人們決定為 QUIC 制作一個(gè)新版本的 HTTP，最終成為 HTTP/3。

HTTP/3 與 HTTP/2 幾乎完全相同。它們的主要區(qū)別在于在 QUIC 或 TCP 基礎(chǔ)上對(duì)功能的技術(shù)實(shí)現(xiàn)。不過，由于 HTTP/3 可以使用 QUIC 的所有新功能，因此在加載網(wǎng)頁和流媒體視頻時(shí)，它的性能會(huì)更高。在實(shí)踐中，正是這一點(diǎn)促使 HTTP/3 迅速得到采用。