QUIC協(xié)議詳解

介紹

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

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

優(yōu)勢(shì)

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

1. 減少了 TCP 三次握手及 TLS 握手時(shí)間。

2. 改進(jìn)的擁塞控制。

3. 避免隊(duì)頭阻塞的多路復(fù)用。

4. 連接遷移。

5. 前向安全。

建立連接（握手）

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

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

1-RTT

第一次握手：

• 客戶端主動(dòng)向服務(wù)器發(fā)送Inchoate CHLO報(bào)文

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

• 在收到服務(wù)器的配置信息后，客戶端會(huì)通過(guò)證書(shū)鏈機(jī)制驗(yàn)簽，并實(shí)現(xiàn)對(duì)服務(wù)器的身份認(rèn)證。

第二次握手：

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

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

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

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

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

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

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

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

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

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

0-RTT

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

如果沒(méi)有過(guò)期的話，就可以直接建立連接，省下了重新建立連接的開(kāi)銷(xiāo)。

前向安全性

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

多路復(fù)用機(jī)制

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

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

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

報(bào)文丟失重傳

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

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

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

流量控制(Flow Control)

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

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

擁塞控制（Congestion Control）

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

連接遷移

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

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

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

實(shí)現(xiàn)參考

Google Quic Project[6]

參考文獻(xiàn)

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)用密碼學(xué) | Diffie-Hellman密鑰交換算法

4. 關(guān)于隊(duì)頭阻塞（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.

文章來(lái)源: www.cnblogs.com/harrypotterjackson/p/15977660.html#fn1