當通過網絡傳輸數據時，一種新的協議QUIC（Quick UDP Internet Connection，快速UDP互聯網連接）正在成為FAANG的默認選擇。本篇文章描述了QUIC協議是如何克服其他版本HTTP的限制脫穎而出的。

FAANG是美國市場上五大最受歡迎和表現最佳的科技股的首字母縮寫，即Facebook、Apple、Amazon、Netflix和Google。

HTTP的演進

HTTP屬于應用層傳輸協議，運行于TCP/IP之上。現在它已成為萬維網中數據交換的基礎。HTTP包括4個穩定版本：HTTP/0.9、HTTP/1.0、HTTP/1.1 和HTTP/2。HTTP/3于2018年首次提出，目前已獲得全球2/3 web瀏覽器的支持。

HTTP/0.9（1991）

HTTP/0.9是HTTP的第一個版本，用作W3C的底層通信協議。它是一個非常簡單的客戶端-服務器、請求-響應、使用Telnet的協議，只支持GET命令（作為請求方法）和超文本協議（作為響應類型）。該協議不包含HTTP消息頭，且發送響應后，連接會立即斷開。

HTTP/1.0（1996）

HTTP/0.9極其簡單，且使用非常受限。新的HTTP版本HTTP/1.0引入了很多新特性，使它更加通用。這些新的特性包括：

每次HTTP 請求/響應都會重新建立TCP連接

添加了對 POST 和 HEAD 方法的支持

協議頭帶有版本號、協議類型、狀態碼字段

響應類型：超文本、腳本、媒體、樣式表

支持keep-alive連接，但默認情況下它是“關閉”的

HTTP/1.1（1997）

HTTP/1.0的主要缺陷是：它在每次請求響應時都要建立新的TCP連接。這種做法非常耗時，且影響客戶端和服務器的性能。HTTP/1.1的出現解決了這一問題：

單個TCP連接上可以傳送多個HTTP請求和響應

添加了對 PUT、DELETE、TRACE、OPTIONS 方法的支持

默認持久連接

HTTP/2（2015）

隨著流媒體內容的增加，網站也開始變得越來越復雜。為了滿足這種需求，HTTP/1.1的功能不斷擴展：首次支持多個TCP連接，并試驗性地引入了管道機制（pipelining），即在同一個TCP連接里面，客戶端可以同時發送多個請求。但擴展不可能無止境，最終需要采用一個新的協議，于是HTTP/2出現了，該協議包括如下重大改進：

多路復用：這是HTTP/2的一個特性，允許同時通過單個TCP連接發起多重請求-響應消息。每次HTTP請求-響應都被分割成二進制幀，客戶端和服務器都以二進制幀為基本單位發送消息（請求和響應）。通過多路復用，客戶端無需再等待上一個請求完成就可以發送多重請求。這樣，HTTP/2便解決了HTTP隊頭阻塞（HoL）的問題。如圖所示：

頭部壓縮：使用 HPACK 壓縮消息頭

非阻塞下載

支持服務器推送

采用二進制分幀，不再是純文本

解決了隊頭阻塞問題

HTTP/3（2018）

通過多路復用，HTTP/2解決了隊頭阻塞問題。但如果TCP流中出現了丟包，根據TCP的擁塞控制機制，其他數據流就只能等待丟包被重新發送和接收。所以，TCP的隊頭阻塞問題在HTTP/2中依然存在。

HTTP/3通過使用基于UDP的傳輸協議QUIC解決了這一問題。

HTTP/3是自HTTP/2之后最新且最主要的HTTP版本。因為HTTP/3本身就是為QUIC協議設計的，所以也被描述為基于QUIC的HTTP/2。HTTP/3的目標是通過使用谷歌的QUIC協議提供快速、可靠安全的網絡連接。HTTP/3包括以下特性：

使用基于UDP的QUIC作為傳輸協議

解決了TCP隊頭阻塞問題

使用QPACK頭部壓縮機制

提供更快頁面加載時間

HTTP/2 VS HTTP/3

相同點：

HTTP/2 和 HTTP/3 使用相同的語法和語義結構，并且適用于同一請求/響應方法、狀態碼和協議字段。此外，兩者都使用設計相似的頭部壓縮算法（HPACK 和 QPACK）。

不同點：

QUIC是一種新的多路傳輸層網絡協議標準，建立在 UDP 之上。QUIC的主要目標是通過減少頁面加載時間提升用戶體驗，并提高HTTPS的傳輸性能。它在本質上是TCP+TLS+HTTP/2。

設計HTTP/3的目的就是要充分利用 QUIC 的優勢。QUIC 協議本身可以處理數據流，所以排除了 TCP 隊頭阻塞問題。

QUIC 的一些關鍵特性包括：

基于UDP

使用沒有隊頭阻塞的連接復用

重構TCP的關鍵機制（連接復用、連接建立、擁塞控制、可靠性），并成為可靠的傳輸協議

交換數據包

對于典型的QUIC協議，客戶端和服務器之間交換了三種類型的數據包，如下圖所示：

1. 安全的首包

首先，客戶端在一個CRYPTO幀中傳輸包含TLS 1.3 Client Hello的首包。Client Hello包含不同類型的的擴展項，如目標服務器的SNI（Server Name Indication，服務器名稱指示 ）、QUIC 傳輸參數、壓縮證書等，以及客戶端支持的壓縮方法和不同的加密套件。

如果服務器接受QUIC和TLS 1.3參數，它也會在CRYPTO幀中發送包含對客戶端首包確認信息和TLS 1.3 Server Hello的首包信息。Server Hello中包含被服務器接收的加密套件和不同的擴展（如密鑰共享、支持的版本等）。在客戶端接收到 Server Hello后，會向服務器發送一個ACK確認包。

這三個首包都可能包含一個填充幀，以根據需要增加數據包的大小。

2. 握手包

客戶端和服務器之間的首包被交換以后，服務器會發送一個握手數據包，其中包含余下的服務器端消息，如證書、與服務器身份驗證相關的加密擴展。客戶端會驗證這些證書，然后QUIC 握手以客戶端發送的握手消息結束。

3. 安全的凈荷包

一旦安全的QUIC連接建立，客戶端與服務器之間的信息便可以安全傳輸。

QUIC 0-RTT

為了縮短建立新連接的時間，QUIC采用0-RTT。在這里，如果客戶端之前使用1-RTT連接到服務器，則服務器必須存儲與流量控制相關的傳輸參數的副本，如 initial_max_data、initial_max_stream_data_bidi_local 等。

下一次，在QUIC 0-RTT模式中，客戶端立即開始與服務器的數據傳輸，不需要等待握手完成。

然而，0-RTT也有設計上的缺陷：允許重放攻擊。

我們為什么要用QUIC？

傳統的TCP協議是建立在操作系統層和中間路由模塊之上實現的，它的握手階段信息很容易被這些中間模塊篡改而變得不安全。

但QUIC協議是在UDP之上的用戶級（如瀏覽器）中實現的，因此它更加靈活、對用戶更友好，并且能夠在短時間內支持更多設備。

在 QUIC 中，傳輸相關的信息被不同的保護層加密，握手包在傳輸鏈路上不容易被識別和修改。因此它提供了更安全的網絡數據傳輸。

翻譯/ Alex 技術Review / 袁榮喜 原文鏈接： https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2021/07/16/road_to_quic-DGa5.html 特別說明：原作者Anubhab Sahu已授權本文的翻譯與發布，特此感謝。

編輯：jq