QUIC是如何工作的？為什么HTTP/3要選擇QUIC協(xié)議？

在 QUIC發(fā)布之前，HTTP 使用 TCP 作為傳輸數(shù)據(jù)的底層協(xié)議。隨著移動互聯(lián)網(wǎng)的不斷發(fā)展，人們對實時交互和多樣化網(wǎng)絡(luò)場景的需求越來越大。然而，已經(jīng)使用了40多年的傳統(tǒng)TCP協(xié)議，在目前大規(guī)模遠(yuǎn)距離、移動網(wǎng)絡(luò)差、網(wǎng)絡(luò)切換頻繁的背景下，存在著先天的性能瓶頸。

其實QUIC并不是一個新的協(xié)議，2012 年，Google 就設(shè)計出了QUIC協(xié)議，在瀏覽器以及服務(wù)器端服務(wù)上部署并實現(xiàn)。2021 年 5 月， IETF在RFC 9000中對 QUIC 進(jìn)行了標(biāo)準(zhǔn)化。2022 年 6 月 7 日，HTTP/3 被標(biāo)準(zhǔn)化為 RFC 9114。

HTTP協(xié)議的演變

早期的HTTP/1

20 世紀(jì) 90 年代初的 HTTP/1.0 是基于 TCP 的嚴(yán)格使用：對于每個 TCP 連接，只有一個 HTTP對話、一個請求和一個響應(yīng)。如果瀏覽器需要來自Web服務(wù)器的圖片，則必須建立TCP連接，并且一旦圖片傳輸完成，就要關(guān)閉TCP連接。

單次發(fā)送一個請求，收到響應(yīng)后再發(fā)送下一次請求的方式是十分低效的，于是HTTP/1.1提出了管線化(pipelining)技術(shù)。把多個HTTP請求放到一個TCP 連接中一一發(fā)送，在發(fā)送過程中不需要等待服務(wù)器對前一個請求的響應(yīng)。只不過，服務(wù)器還是要按照發(fā)送請求的順序來處理請求，客戶端也要按照發(fā)送請求的順序來接收響應(yīng)。與此同時，Netscape 創(chuàng)建了 HTTPS(HTTP Secure)，SSL 逐漸成為瀏覽 Internet 的標(biāo)準(zhǔn)。

服務(wù)器在順序處理請求的過程中，如果前一個請求處理非常耗時，就會阻塞后面請求的處理，這就是隊頭阻塞。

| TCP 隊頭阻塞

HTTP/2 解決問題

2015 年，為了解決隊頭阻塞問題，HTTP/2 誕生了，這是一項由 Google 推動、基于 SPDY 的倡議。HTTP/2 引入了兩個主要功能：多路復(fù)用和服務(wù)器推送。

多路復(fù)用允許通過單個 TCP 上連接同步發(fā)送/接收多個邏輯、優(yōu)先的 HTTP 數(shù)據(jù)流，而不是添加并行的 TCP 連接。服務(wù)器推送(Server Push)使服務(wù)器能夠預(yù)測資源，并在客戶端發(fā)出請求之前“搶先”推送資源，客戶端保留拒絕服務(wù)器推送的權(quán)限。在多數(shù)情況下，這些功能可以大大提高流程的效率。

| 服務(wù)器推送

從 HTTP/2 到基于 QUIC 的 HTTP/3

HTTP/2 被采用后，通過多路復(fù)用在應(yīng)用層面解決了“隊頭阻塞”問題，但在傳輸層面 (TCP) 上還面臨著同樣的難題。

在 TCP 中，如果單個數(shù)據(jù)包被丟棄或丟失，整個 TCP 連接及其上運(yùn)行的所有 HTTP 數(shù)據(jù)流都會停止，直到丟失的數(shù)據(jù)包重新傳輸并到達(dá)目的地。這是深深根植于 TCP 的基本特征，旨在保證無流且可靠的數(shù)據(jù)傳輸：面向連接、丟包恢復(fù)、重傳、窗口縮放、擁塞控制。

QUIC選擇 UDP 作為其傳輸協(xié)議，可以避免復(fù)雜的部署。大多數(shù)防火墻、NAT、路由器以及用戶和服務(wù)器之間的其他中間設(shè)備僅支持 TCP 或 UDP協(xié)議。

QUIC是如何工作的？

QUIC 協(xié)議位于 UDP 和 HTTP 之間，是一種端到端傳輸協(xié)議的實現(xiàn)。從某方面來說，QUIC = HTTP/2 + TLS + UDP，而UDP + QUIC = 傳輸層。

| OSI 堆棧上的 QUIC

與 TCP 相比，UDP具有更低的延遲和更高的吞吐量，并且它還使 QUIC 能夠繞過可能干擾 TCP 的網(wǎng)絡(luò)中間件。QUIC 包含基于 TLS 1.3 的內(nèi)置加密協(xié)議，可在端點之間提供安全通信，并使第三方更難攔截和操縱互聯(lián)網(wǎng)流量。QUIC結(jié)合了 UDP 的速度和效率、TLS 的安全性，以及TCP 的流完整性和流量控制功能，增加了更靈活的多流處理版本，還增加了對地址敏捷性的更好支持，以支持各種NAT地址轉(zhuǎn)換行為。

QUIC的主要改進(jìn)

QUIC的出現(xiàn)解決了最后一公里的網(wǎng)絡(luò)傳輸問題。以下是 QUIC 的主要改進(jìn)：

快速握手和連接建立

無論是HTTP1.0/1.1還是HTTPS、HTTP2，都是使用TCP協(xié)議進(jìn)行傳輸。HTTPS 和 HTTP2 也需要使用 TLS 協(xié)議進(jìn)行安全傳輸。TCP 三次握手導(dǎo)致了建立 TCP 連接的延遲。

完整的 TLS 握手至少需要 2 個 RTT 才能建立，而簡化的握手需要 1 個 RTT 握手延遲。

對于很多短連接場景，這種握手延遲影響很大，無法消除。

# QUIC協(xié)議在以下兩個方面進(jìn)行了優(yōu)化

1.傳輸層使用UDP，減少了TCP三次握手中一個1-RTT的延遲。

2.采用最新版本的 TLS 協(xié)議——TLS 1.3，允許客戶端在 TLS 握手完成之前發(fā)送應(yīng)用數(shù)據(jù)，同時支持 1-RTT 和 0-RTT。使用 QUIC 協(xié)議，第一次握手協(xié)商需要 1-RTT，但之前連接的客戶端可以使用緩存信息恢復(fù) TLS 連接，只需 0-1 RTT。

| 0-RTT連接建立

經(jīng)過身份驗證和加密的數(shù)據(jù)包

傳統(tǒng)的TCP協(xié)議數(shù)據(jù)包頭沒有加密和認(rèn)證，容易被中間人篡改、注入和竊聽。相比之下，除了 PUBLIC_RESET 和 CHLO 等少數(shù)消息外，QUIC 所有的數(shù)據(jù)包頭都經(jīng)過身份驗證，所有消息體都經(jīng)過加密。這樣數(shù)據(jù)包的任何修改都能被接收端及時發(fā)現(xiàn)，可有效降低安全風(fēng)險。

如下圖，紫色部分為Stream Frame包的認(rèn)證頭，黃色部分為加密后的內(nèi)容：

| QUIC協(xié)議的加密

改進(jìn)多路復(fù)用以避免 HoL 阻塞

QUIC 引入了在連接上復(fù)用多個流的概念，通過為每個流設(shè)計和實現(xiàn)單獨(dú)的流量控制，解決了影響整個連接的隊頭阻塞問題。

QUIC 的多路復(fù)用類似于 HTTP/2，可以在單個 QUIC 連接上同時發(fā)送多個 HTTP 請求（流）。但是，與HTTP/2 多路復(fù)用不同的是，QUIC的流與流之間完全隔離的，互相沒有順序依賴。這意味著如果流 2 丟失了一個 UDP 數(shù)據(jù)包，它只會影響流 2 的處理，不會阻塞流 1 和 3 的數(shù)據(jù)傳輸。因此，該解決方案不會導(dǎo)致隊頭阻塞問題。

| QUIC 的多路復(fù)用

此外，QPACK 作為 QUIC 的一項新功能，旨在減少通過網(wǎng)絡(luò)傳輸?shù)娜哂鄶?shù)據(jù)量，從而有助于緩解隊頭阻塞。這樣QUIC在弱網(wǎng)場景下可以接收到比TCP更多的數(shù)據(jù)。

可插拔擁塞控制

QUIC支持可插拔的Cubic、BBR、Reno等擁塞控制算法，也可以根據(jù)具體場景定制私有算法?！翱刹灏巍币馕吨梢造`活地生效、更改和停止，可體現(xiàn)在以下幾個方面：

不同的擁塞控制算法可以在應(yīng)用層實現(xiàn)，不需要操作系統(tǒng)或內(nèi)核的支持，而傳統(tǒng)的TCP擁塞控制需要端到端的網(wǎng)絡(luò)協(xié)議棧才能達(dá)到控制效果。

允許單個應(yīng)用程序的不同連接支持不同的擁塞控制配置。

應(yīng)用程序無需停機(jī)或升級即可更改擁塞控制，唯一要做的就是修改配置并在服務(wù)器端重新加載它。

連接遷移

TCP 連接基于 4 元組：源 IP、源端口、目標(biāo) IP 和目標(biāo)端口。如果其中任何一個發(fā)生變化，則必須重新建立連接。但是QUIC連接是基于一個64位的Connection ID，只要Connection ID不變就可以保持連接，不會斷線重連。

| QUIC 連接

例如，如果客戶端使用IP1發(fā)送數(shù)據(jù)包1和2，然后切換網(wǎng)絡(luò)，更改為IP2并發(fā)送數(shù)據(jù)包3和4，服務(wù)器可以根據(jù)數(shù)據(jù)包中的Connection ID字段識別所有四個數(shù)據(jù)包來自同一個客戶端標(biāo)頭。QUIC能夠?qū)崿F(xiàn)連接遷移的根本原因是底層UDP協(xié)議是無連接的。

前向糾錯

QUIC還支持前向糾錯（FEC），弱網(wǎng)丟包環(huán)境下，動態(tài)的增加一些FEC數(shù)據(jù)包，可以減少重傳次數(shù)，提升傳輸效率。

HTTP/3和QUIC的更多應(yīng)用

實時應(yīng)用

HTTP/3 和 QUIC 非常適合需要低延遲、高吞吐量連接的實時應(yīng)用程序。這包括視頻會議、在線游戲和實時流媒體等應(yīng)用程序?；赒UIC更強(qiáng)的抗不良網(wǎng)絡(luò)能力和連接遷移能力，可以有效改善視頻啟動時間，降低視頻卡頓率和請求失敗率。

物聯(lián)網(wǎng)

物聯(lián)網(wǎng)場景下，終端設(shè)備使用場景復(fù)雜、混亂，如高速移動、海上、山區(qū)等環(huán)境，設(shè)備可用的網(wǎng)絡(luò)資源非常有限?；?TCP 的MQTT物聯(lián)網(wǎng)通信協(xié)議經(jīng)常會在重連過程中出現(xiàn)頻繁的連接中斷和較大的服務(wù)器/客戶端開銷，而QUIC的0RTT重連/1RTT建立能力和復(fù)用特性的優(yōu)勢在惡劣和不穩(wěn)定的網(wǎng)絡(luò)中得到體現(xiàn)，可以提高內(nèi)容傳輸效率，提升用戶體驗。

電子商務(wù)與金融支付

在電子商務(wù)中，QUIC 提供的可靠性和速度有助于確保客戶即使在流量高峰期也能獲得無縫順暢的購物體驗。此外，QUIC 還提供必要的性能和安全功能來支持電子商務(wù)應(yīng)用程序，例如快速頁面加載時間和安全支付交易。

QUIC 協(xié)議下一步是什么？

由于 QUIC 是基于 UDP 而不是 TCP，因此將 HTTP/2 升級到 HTTP/3-QUIC 不像從 HTTP/1.1 升級到 HTTP/2 那樣簡單。HTTP/3 可能會通過外部服務(wù)提供商提供給大多數(shù)用戶，而不是由用戶自己在其服務(wù)器上實現(xiàn)。

目前，QUIC 的部署正在全球范圍內(nèi)加速推進(jìn)。隨著QUIC IETF-v1協(xié)議標(biāo)準(zhǔn)的出現(xiàn)，越來越多的網(wǎng)站開始使用QUIC流量。據(jù)W3Techs統(tǒng)計，目前約有25.5%的網(wǎng)站使用HTTP/3。隨著技術(shù)的不斷發(fā)展和成熟，我們可以期待看到關(guān)于QUIC 更加多樣化和創(chuàng)新的用例出現(xiàn)，從而推動新應(yīng)用程序和服務(wù)的開發(fā)。






審核編輯：劉清