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

去年，負責(zé)定義互聯(lián)網(wǎng)技術(shù)的互聯(lián)網(wǎng)工程任務(wù)組（IETF）對該協(xié)議的新版本 HTTP/3 進行了標準化。此后，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ò)上兩個實體（通常是用戶設(shè)備和網(wǎng)絡(luò)服務(wù)器）之間的數(shù)據(jù)通信方式。由于有許多不同的公司都在為網(wǎng)絡(luò)開發(fā)軟件，因此需要將協(xié)議標準化，以便所有這些軟件都能 "互操作"，也就是說，它們都能相互理解，因為它們遵循相同的規(guī)則。

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

互聯(lián)網(wǎng)的許多原始協(xié)議都是在上世紀 80 和 90 年代標準化的，這意味著它們是根據(jù)當(dāng)時的目標和限制而構(gòu)建的。其中一些協(xié)議經(jīng)受住了時間的考驗，而另一些協(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 請求/響應(yīng)之前，它們必須建立 TCP 連接。

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

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

QUIC 解決方案

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

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

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

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

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

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

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

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