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

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

HTTP協議的演變

早期的HTTP/1

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

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

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

| TCP 隊頭阻塞

HTTP/2 解決問題

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

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

| 服務器推送

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

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

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

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

QUIC是如何工作的？

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

| OSI 堆棧上的 QUIC

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

QUIC的主要改進

QUIC的出現解決了最后一公里的網絡傳輸問題。以下是 QUIC 的主要改進：

快速握手和連接建立

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

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

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

# QUIC協議在以下兩個方面進行了優化

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

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

| 0-RTT連接建立

經過身份驗證和加密的數據包

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

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

| QUIC協議的加密

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

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

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

| QUIC 的多路復用

此外，QPACK 作為 QUIC 的一項新功能，旨在減少通過網絡傳輸的冗余數據量，從而有助于緩解隊頭阻塞。這樣QUIC在弱網場景下可以接收到比TCP更多的數據。

可插拔擁塞控制

QUIC支持可插拔的Cubic、BBR、Reno等擁塞控制算法，也可以根據具體場景定制私有算法。“可插拔”意味著它可以靈活地生效、更改和停止，可體現在以下幾個方面：

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

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

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

連接遷移

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

| QUIC 連接

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

前向糾錯

QUIC還支持前向糾錯（FEC），弱網丟包環境下，動態的增加一些FEC數據包，可以減少重傳次數，提升傳輸效率。

HTTP/3和QUIC的更多應用

實時應用

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

物聯網

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

電子商務與金融支付

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

QUIC 協議下一步是什么？

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

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






審核編輯：劉清