QUIC協(xié)議詳解

介紹

QUIC，發(fā)音同quick，是"Quick UDP Internet Connections"的簡稱，是一種通用的傳輸層網(wǎng)絡(luò)協(xié)議。QUIC與TCP相同，是一種有連接的傳輸協(xié)議。但是與TCP不同的是QUIC是建立在UDP傳輸層協(xié)議之上的，實現(xiàn)了在兩個端點之間的多路復用。QUIC的是在用戶空間實現(xiàn)的，TCP/UDP則是在內(nèi)核空間實現(xiàn)的。[2]

QUIC所處的網(wǎng)絡(luò)層次如下圖所示。圖源文獻[1:1]。

優(yōu)勢

Quic 相比現(xiàn)在廣泛應(yīng)用的 http2+tcp+tls 協(xié)議有如下優(yōu)勢：

1. 減少了 TCP 三次握手及 TLS 握手時間。

2. 改進的擁塞控制。

3. 避免隊頭阻塞的多路復用。

4. 連接遷移。

5. 前向安全。

建立連接（握手）

QUIC實現(xiàn)了快速握手，并把握手過程分為兩種情況，分別是1-RTT和0-RTT。在介紹這兩種握手過程之前，讀者需自行熟悉Diffie-Hellman算法的基本原理[3]。

在上圖(文獻[1:2])中顯示了三種不同情況的連接過程。其中最左邊的圖表示的是第一次連接時的情況，中間的圖表示重復連接的情況（在一定條件下，客戶端可以重新連接服務(wù)器而不需要從初始化情況連接），最右邊的圖則是重連失敗之后從初始話連接的情況。最后一種情況是第一種情況的組會，0-RTT也是1-RTT的一部分，后文中將重點介紹1-RTT的連接過程。

1-RTT

第一次握手：

• 客戶端主動向服務(wù)器發(fā)送Inchoate CHLO報文

• 服務(wù)器會向客戶端發(fā)送REJ報文。REJ報文包含了服務(wù)器的配置信息，如長期的Diffie-Hellman值，服務(wù)器配置的簽名，source-address-token(stk, 用于驗證的加密塊，包含有服務(wù)器看到的客戶端的IP地址和服務(wù)器當前的時間戳，之后客戶端會將該stk發(fā)回)等，為了進行身份證明還會使用私鑰進行簽名，同時也可以防篡改；

• 在收到服務(wù)器的配置信息后，客戶端會通過證書鏈機制驗簽，并實現(xiàn)對服務(wù)器的身份認證。

第二次握手：

• 客戶端在通過對服務(wù)器的驗證之后，客戶端會生成一個Diffie-Hellman值。此時客戶端有了自身和對方的Diffie-Hellman值，就可以計算出初始密鑰（initial key, ik）；

• 客戶端將包含有DH公開之的明文Complete CHLO發(fā)送至服務(wù)器；

• 客戶端使用ik對請求數(shù)據(jù)加密，發(fā)送至服務(wù)器；

• 服務(wù)器收到Complete CHLO之后就可以獲得客戶端的Diffie-Hellman的值，就可以計算出初始密鑰。

• 服務(wù)器立即向客戶端發(fā)送SHLO報文（ik加密的）。SHLO報文含有一個服務(wù)器臨時Diffie-Hellman值，可以用于計算前向安全的密鑰（會話密鑰）；

• 服務(wù)器收到加密的請求數(shù)據(jù)，使用初始密鑰進行解密；

• 服務(wù)器使用會話密鑰對響應(yīng)數(shù)據(jù)進行加密，發(fā)回給客戶端。

• 客戶端在收到SHLO之后使用初始密鑰解密得到服務(wù)器的臨時DH公開值，根據(jù)該臨時值計算出會話密鑰；

• 客戶端收到加密的響應(yīng)數(shù)據(jù)后，使用會話密鑰進行解密。

• 整個握手過程會在2個RTT內(nèi)完成。

0-RTT

客戶端在重連同一個服務(wù)器時，會使用已經(jīng)緩存的服務(wù)器相關(guān)配置信息（stk，DH公開值等信息），并直接向服務(wù)器發(fā)送Complete CHLO報文，并使用ik對請求報文進行加密。但是服務(wù)器方面會標識相應(yīng)的stk等信息已經(jīng)過期，這時服務(wù)器會發(fā)送REJ信息，客戶端需要重新與服務(wù)器進行連接。

如果沒有過期的話，就可以直接建立連接，省下了重新建立連接的開銷。

前向安全性

所謂前向安全性就是指，在最后一次握手時，會生成一個會話密鑰sk。這樣即使服務(wù)器的長期DH值被破獲，且生成了初始密鑰ik，也無法對會話中的數(shù)據(jù)進行解密。

多路復用機制

基于TCP的應(yīng)用程序會在TCP單字節(jié)流抽象層中實現(xiàn)多路復用。為了避免由于TCP順序傳遞導致的頭部阻塞（head-of-line blocking）[4]，QUIC支持在單個UDP連接中復用多個流，并保證UDP報文的丟失僅影響相應(yīng)的流，而不會影響其他的流（stream）。

可以在QUIC流上構(gòu)建任意大小的應(yīng)用程序報文，最多支持2^64的字節(jié)。并且stream的實現(xiàn)是輕量級的，即使消息報文很小也可以為它們使用單獨的流。每一個Stream都有stream ID唯一標識。這些流ID由客戶端/服務(wù)器進行靜態(tài)分配。客戶端主動發(fā)起的流的ID永遠是奇數(shù)，服務(wù)器發(fā)起的流的ID是偶數(shù)。這樣可以避免沖突。當在一個未使用過的流上發(fā)送數(shù)據(jù)時，流會自動創(chuàng)建；當需要關(guān)閉時，就會在最后一幀數(shù)據(jù)上設(shè)置一個FIN的標志指示接收方關(guān)閉流。如果發(fā)送方或接收方確定不再需要流上的數(shù)據(jù)，則可以取消流，而無需斷開整個 QUIC 連接。盡管流是可靠的抽象，但 QUIC 不會為已取消的流重新傳輸數(shù)據(jù)。

一個QUIC包是由一個公共的頭后面跟著一個或多個幀組成的，如下圖（圖源[1:3]）所示。QUIC流復用是通過將流數(shù)據(jù)封裝在一個或多個流幀中來實現(xiàn)的，單個QUIC包可以攜帶來自多個流的流幀.

報文丟失重傳

TCP 序列號有助于提高可靠性，并表示在接收方傳送字節(jié)的順序。這種混淆會導致“重傳模糊”（retransmission ambiguity）問題，因為重傳的 TCP 段攜帶與原始數(shù)據(jù)包相同的序列號 。TCP ACK 的接收者無法確定 ACK 是為原始傳輸還是為重傳而發(fā)送，并且通常通過昂貴的超時來檢測重傳段的丟失。每個 QUIC 數(shù)據(jù)包都攜帶一個新的數(shù)據(jù)包編號，包括那些攜帶重傳數(shù)據(jù)的數(shù)據(jù)包。這種設(shè)計不需要單獨的機制來區(qū)分重傳的 ACK 和原始傳輸?shù)?ACK，從而避免了 TCP 的重傳模糊問題。流幀中的流偏移用于傳遞排序，數(shù)據(jù)包編號表示一個明確的時間順序，這使得丟失檢測比 TCP 更簡單、更準確。

QUIC的ACK顯示地記錄了接收的數(shù)據(jù)報文和ACK之間的延遲。單調(diào)增加的報文編號一起，可以精確估算RTT，有助于丟失檢測。QUIC的確認報文支持多達256個ACK，這是使得QUIC比帶有SACK的TCP更能適應(yīng)重新排序或丟失的情況下在線路上保留更多字節(jié)。

更多內(nèi)容參見[5]。

流量控制(Flow Control)

當應(yīng)用程序從QUIC的接收緩沖區(qū)中讀取數(shù)據(jù)較慢時，留戀控制就會限制接收者必須保持的接收緩沖區(qū)大小。一個緩慢耗盡的stream會逐漸耗盡整個連接connection的緩沖區(qū)，因此必須要限制QUIC連接上的每個流可以消耗的緩沖區(qū)大小，避免消耗其他流的緩沖區(qū)的大小。這樣可以改善流之間潛在的隊頭阻塞（head-of-line blocking）。因此QUIC采用連接級別的流量控制（connection-level flow control），這樣可以限制發(fā)送者在所有流中接收者使用的聚合緩沖區(qū)；采用流級別的流量控制(stream-level flow control)可以限制發(fā)送者在任何給定流上使用的緩沖區(qū)。

與HTTP/2類似，QUIC采用基于信用的流量控制。QUIC接收器在每個流中通告接收器愿意接收數(shù)據(jù)的絕對字節(jié)偏移量。在特定流上發(fā)送、接收和傳遞數(shù)據(jù)時，接收器會定期發(fā)送窗口更新幀，以增加該流的窗口偏移限制，從而允許對等方在該流上發(fā)送更多數(shù)據(jù)。連接級流量控制的工作方式與流級流量控制相同，但傳遞的字節(jié)數(shù)和接收到的最高偏移量是所有流的。

擁塞控制（Congestion Control）

QUIC支持的擁塞控制算法有：
Reno（TCP用的）、基于Pacing的擁塞控制算法（PBCCA）、TCP CUBIC等。

連接遷移

QUIC連接使用隨機生成的64bit的cid唯一確定。cid允許客戶機在網(wǎng)絡(luò)之間漫游，而不受網(wǎng)絡(luò)或傳輸層參數(shù)變化的影響。

cid使得客戶端能夠獨立于網(wǎng)絡(luò)地址轉(zhuǎn)換（network address translation, NAT）之外。cid 在路由中起著重要作用，特別是用于連接標識的目的。此外，使用 cids 可以通過探測連接的新路徑實現(xiàn)多路徑。

在連接遷移期間，端點假設(shè)對等方愿意在其當前地址接受數(shù)據(jù)包。因此，端點可以遷移到新的 IP 地址，而無需首先驗證對等方的 IP 地址。新的路由路徑可能不支持端點的當前發(fā)送速率。在這種情況下，端點需要重新構(gòu)建它的擁塞控制器。另一方面，從一個新的對等地址接收非探測包 ，確認對等地址已遷移到新的 IP 地址。

實現(xiàn)參考

Google Quic Project[6]

參考文獻

1. LANGLEY A, RIDDOCH A, WILK A, 等. The QUIC Transport Protocol: Design and Internet-Scale Deployment[C/OL]//Proceedings of the Conference of the ACM Special Interest Group on Data Communication. Los Angeles CA USA: ACM, 2017: 183-196[2022-03-05]. https://dl.acm.org/doi/10.1145/3098822.3098842. DOI:10.1145/3098822.3098842.

2. QUIC wikipedia

3. 應(yīng)用密碼學 | Diffie-Hellman密鑰交換算法

4. 關(guān)于隊頭阻塞（Head-of-Line blocking），看這一篇就足夠了

5. J. Iyengar and I. Swett. 2016. QUIC Loss Detection and Congestion Control.IETF Internet Draft, draft-ietf-quic-recovery

6. QUIC Crypto

7. KUMAR P, DEZFOULI B. Implementation and analysis of QUIC for MQTT[J/OL]. Computer Networks, 2019, 150: 28-45. DOI:10.1016/j.comnet.2018.12.012.

文章來源: www.cnblogs.com/harrypotterjackson/p/15977660.html#fn1