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

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

HTTP協(xié)議的演變

早期的HTTP/1

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

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

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

| TCP 隊頭阻塞

HTTP/2 解決問題

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

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

| 服務器推送

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

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

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

QUIC選擇 UDP 作為其傳輸協(xié)議，可以避免復雜的部署。大多數(shù)防火墻、NAT、路由器以及用戶和服務器之間的其他中間設備僅支持 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)絡中間件。QUIC 包含基于 TLS 1.3 的內置加密協(xié)議，可在端點之間提供安全通信，并使第三方更難攔截和操縱互聯(lián)網(wǎng)流量。QUIC結合了 UDP 的速度和效率、TLS 的安全性，以及TCP 的流完整性和流量控制功能，增加了更靈活的多流處理版本，還增加了對地址敏捷性的更好支持，以支持各種NAT地址轉換行為。

QUIC的主要改進

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

快速握手和連接建立

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

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

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

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

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

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

| 0-RTT連接建立

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

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

如下圖，紫色部分為Stream Frame包的認證頭，黃色部分為加密后的內容：

| QUIC協(xié)議的加密

改進多路復用以避免 HoL 阻塞

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

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

| QUIC 的多路復用

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

可插拔擁塞控制

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

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

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

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

連接遷移

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

| QUIC 連接

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

前向糾錯

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

HTTP/3和QUIC的更多應用

實時應用

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

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

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

電子商務與金融支付

在電子商務中，QUIC 提供的可靠性和速度有助于確?？蛻艏词乖诹髁扛叻迤谝材塬@得無縫順暢的購物體驗。此外，QUIC 還提供必要的性能和安全功能來支持電子商務應用程序，例如快速頁面加載時間和安全支付交易。

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

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

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






審核編輯：劉清