當(dāng)通過網(wǎng)絡(luò)傳輸數(shù)據(jù)時，一種新的協(xié)議QUIC（Quick UDP Internet Connection，快速UDP互聯(lián)網(wǎng)連接）正在成為FAANG的默認(rèn)選擇。本篇文章描述了QUIC協(xié)議是如何克服其他版本HTTP的限制脫穎而出的。

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

HTTP的演進

HTTP屬于應(yīng)用層傳輸協(xié)議，運行于TCP/IP之上?，F(xiàn)在它已成為萬維網(wǎng)中數(shù)據(jù)交換的基礎(chǔ)。HTTP包括4個穩(wěn)定版本：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的底層通信協(xié)議。它是一個非常簡單的客戶端-服務(wù)器、請求-響應(yīng)、使用Telnet的協(xié)議，只支持GET命令（作為請求方法）和超文本協(xié)議（作為響應(yīng)類型）。該協(xié)議不包含HTTP消息頭，且發(fā)送響應(yīng)后，連接會立即斷開。

HTTP/1.0（1996）

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

每次HTTP 請求/響應(yīng)都會重新建立TCP連接

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

協(xié)議頭帶有版本號、協(xié)議類型、狀態(tài)碼字段

響應(yīng)類型：超文本、腳本、媒體、樣式表

支持keep-alive連接，但默認(rèn)情況下它是“關(guān)閉”的

HTTP/1.1（1997）

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

單個TCP連接上可以傳送多個HTTP請求和響應(yīng)

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

默認(rèn)持久連接

HTTP/2（2015）

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

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

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

非阻塞下載

支持服務(wù)器推送

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

解決了隊頭阻塞問題

HTTP/3（2018）

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

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

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

使用基于UDP的QUIC作為傳輸協(xié)議

解決了TCP隊頭阻塞問題

使用QPACK頭部壓縮機制

提供更快頁面加載時間

HTTP/2 VS HTTP/3

相同點：

HTTP/2 和 HTTP/3 使用相同的語法和語義結(jié)構(gòu)，并且適用于同一請求/響應(yīng)方法、狀態(tài)碼和協(xié)議字段。此外，兩者都使用設(shè)計相似的頭部壓縮算法（HPACK 和 QPACK）。

不同點：

QUIC是一種新的多路傳輸層網(wǎng)絡(luò)協(xié)議標(biāo)準(zhǔn)，建立在 UDP 之上。QUIC的主要目標(biāo)是通過減少頁面加載時間提升用戶體驗，并提高HTTPS的傳輸性能。它在本質(zhì)上是TCP+TLS+HTTP/2。

設(shè)計HTTP/3的目的就是要充分利用 QUIC 的優(yōu)勢。QUIC 協(xié)議本身可以處理數(shù)據(jù)流，所以排除了 TCP 隊頭阻塞問題。

QUIC 的一些關(guān)鍵特性包括：

基于UDP

使用沒有隊頭阻塞的連接復(fù)用

重構(gòu)TCP的關(guān)鍵機制（連接復(fù)用、連接建立、擁塞控制、可靠性），并成為可靠的傳輸協(xié)議

交換數(shù)據(jù)包

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

1. 安全的首包

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

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

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

2. 握手包

客戶端和服務(wù)器之間的首包被交換以后，服務(wù)器會發(fā)送一個握手?jǐn)?shù)據(jù)包，其中包含余下的服務(wù)器端消息，如證書、與服務(wù)器身份驗證相關(guān)的加密擴展?？蛻舳藭炞C這些證書，然后QUIC 握手以客戶端發(fā)送的握手消息結(jié)束。

3. 安全的凈荷包

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

QUIC 0-RTT

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

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

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

我們?yōu)槭裁匆肣UIC？

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

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

在 QUIC 中，傳輸相關(guān)的信息被不同的保護層加密，握手包在傳輸鏈路上不容易被識別和修改。因此它提供了更安全的網(wǎng)絡(luò)數(shù)據(jù)傳輸。

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

編輯：jq