能加速互聯(lián)網(wǎng)的QUIC協(xié)議有哪些

能加速互聯(lián)網(wǎng)的QUIC協(xié)議有哪些，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

眾所周知，QUIC（Quick UDP Internet Connection）是谷歌制定的一種互聯(lián)網(wǎng)傳輸層協(xié)議，它基于UDP傳輸層協(xié)議，同時(shí)兼具TCP、TLS、HTTP/2等協(xié)議的可靠性與安全性，可以有效減少連接與傳輸延遲，更好地應(yīng)對(duì)當(dāng)前傳輸層與應(yīng)用層的挑戰(zhàn)。下面將由低向上分層討論QUIC協(xié)議的特點(diǎn)。

QUIC協(xié)議是一系列協(xié)議的集合，主要包括：

• 傳輸協(xié)議（Transport）

• 丟包檢測與擁塞控制（Recovery)

• 安全傳輸協(xié)議（TLS)

• HTTP3協(xié)議

• HTTP頭部壓縮協(xié)議（QPACK)

• 負(fù)載均衡協(xié)議（Load Balance)

基于quic的討論均基于quic-34系列版本。

QUIC協(xié)議類似快遞公司，在收到用戶數(shù)據(jù)后，將數(shù)據(jù)打包，傳輸?shù)綄?duì)端，再進(jìn)行拆包，將用戶數(shù)據(jù)交給了最終目標(biāo)用戶。QUIC是基于UDP協(xié)議，實(shí)現(xiàn)了類似TCP的可靠傳輸，并在此基礎(chǔ)上，結(jié)合HTTP3/QPACK，更好地服務(wù)互聯(lián)網(wǎng)上海量的HTTP Request/Response需求。如其名發(fā)音，QUIC(quick)，其目標(biāo)就是希望比基于TCP的HTTP交互有更好的體驗(yàn)。

QUIC/HTTP3的特點(diǎn)：

• 有序傳輸：用stream的概念，確保數(shù)據(jù)有序。不同的stream或者packet，不保證有序到達(dá)。

• 報(bào)文壓縮，提高荷載比率：比如QUIC引入了variable-length integer encoding。又比如引入QPACK進(jìn)行頭部壓縮

• 可靠傳輸：支持丟包檢測和重傳

• 安全傳輸：TLS 1.3安全協(xié)議

分層的協(xié)議

QUIC是在UDP的基礎(chǔ)上，構(gòu)建類似TCP的可靠傳輸協(xié)議。HTTP3則在QUIC基礎(chǔ)上完成HTTP事務(wù)。
網(wǎng)絡(luò)總是分層討論的，在此我們由低向上分層討論quic協(xié)議

• UDP層: 在UDP層傳輸?shù)氖荱DP報(bào)文，此處關(guān)注的是UDP報(bào)文荷載內(nèi)容是什么，以及如何高效發(fā)送UDP報(bào)文

• Connection層: Connection通過CID來確認(rèn)唯一連接，connection對(duì)packet進(jìn)行可靠傳輸和安全傳輸

• Stream層: Stream在相應(yīng)的Connection中，通過StreamID進(jìn)行唯一流確認(rèn)，stream對(duì)stream frame進(jìn)行傳輸管理

• HTTP3層：HTTP3建立在QUIC Stream的基礎(chǔ)上，相對(duì)于HTTP1.1和HTTP2.0，HTTP3提供更有效率的HTTP事務(wù)傳輸。HTTP3中通過QPACK協(xié)議進(jìn)行頭部壓縮

UDP層

本章節(jié)討論QUIC發(fā)包的UDP部分的相關(guān)問題。

UDP荷載大小

荷載大小受限于3個(gè)對(duì)象：QUIC協(xié)議規(guī)定；路徑MTU；終端接受能力
1、QUIC不能運(yùn)行在不支持1200字節(jié)的單個(gè)UDP傳輸網(wǎng)絡(luò)路徑上 QUIC有規(guī)定initial包大小不得小于1200，如果數(shù)據(jù)本身不足1200（比如initial ack)，那么需要用padding方式至少填充到1200字節(jié)

2、QUIC不希望出現(xiàn)IP層分片現(xiàn)象本要求意味著udp交給ip層的數(shù)據(jù)不會(huì)大于1個(gè)MTU，假設(shè)mtu為1500，ipv4場景下，udp的荷載上限為1472字節(jié)（1500-20-8），ipv6下，udp荷載上限為1452（1500-40-8)。QUIC建議使用PMTUD以及DPLPMTUD進(jìn)行mtu探測。在實(shí)戰(zhàn)中，我們建議設(shè)置IPv6的MTU為1280，大于這個(gè)值，某些網(wǎng)絡(luò)會(huì)存在丟包現(xiàn)象。

3、終端能接受 transport paraments的max_udp_payload_size(0x03)的是終端接受單個(gè)udp包大小的能力，發(fā)送端應(yīng)當(dāng)遵從這一約定。

UDP荷載內(nèi)容

UDP荷載內(nèi)容即為quic協(xié)議中的packet。協(xié)議規(guī)定，如果不超過荷載大小的限制，那么多個(gè)packet可以組成一個(gè)udp報(bào)文發(fā)出去。在quic實(shí)現(xiàn)中，如果每個(gè)udp報(bào)文只包含一個(gè)quic packet，會(huì)更容易出現(xiàn)亂序問題。

高效發(fā)UDP包

和tcp不同，quic需要在應(yīng)用層就完成udp數(shù)據(jù)組裝，且每個(gè)udp報(bào)文不大于1個(gè)mtu，如果不加以優(yōu)化，比如每個(gè)包直接用sendto/sendmsg發(fā)送，勢必會(huì)造成大量的系統(tǒng)調(diào)用，影響吞吐

1、通過sendmmsg接口進(jìn)行優(yōu)化，sendmmsg可以將用戶態(tài)的多個(gè)udp quic包通過一次系統(tǒng)調(diào)用發(fā)到內(nèi)核態(tài)。內(nèi)核態(tài)對(duì)于每個(gè)udp quic包獨(dú)立作為udp包發(fā)出去

2、在1.）解決了系統(tǒng)調(diào)用次數(shù)問題，開啟GSO可以進(jìn)步一分包延遲到發(fā)給網(wǎng)卡驅(qū)動(dòng)前一刻，可以進(jìn)一步提高吞吐，降低CPU消耗

3、在2.）的基礎(chǔ)上，現(xiàn)在主流網(wǎng)卡已經(jīng)支持硬件GSO offload方案，可以進(jìn)一步提高吞吐，降低cpu消耗

上面介紹的發(fā)送方式，事實(shí)上可以理解為udp burst發(fā)送方式，這帶來了一個(gè)問題，擁塞控制需要pacing能力！

Connection層

在我們討論時(shí)，可知1個(gè)udp報(bào)文里傳輸?shù)钠鋵?shí)是一個(gè)或多個(gè)quic協(xié)議定義的packet。那么在Connection這一層面，其實(shí)是以packet為單位進(jìn)行管理的。一個(gè)packet到來，終端需要解析出目標(biāo)ConnectionID(DCID)字段，并將該packet交給找到對(duì)應(yīng)的quic connection。一個(gè)packet是由header加payload兩部分組成。

connection id

不同于tcp的4元組唯一確認(rèn)一條連接的方式，QUIC定義了一個(gè)和網(wǎng)絡(luò)路由無關(guān)的ConnectionID來確認(rèn)唯一連接的。這帶來一個(gè)好處，可以在四元組發(fā)生變化時(shí)（比如nat rebinding或者終端網(wǎng)絡(luò)切換wifi->4G)，依然保持連接。當(dāng)然，雖然連接狀態(tài)依然保持，但由于路徑發(fā)生變化，擁塞控制也需要能夠及時(shí)調(diào)整。

packet頭部

IETF的quic header分為兩種類型，long header, short header。其中l(wèi)ong header有分為 initial, 0rtt, handshake, retry四種類型。類型的定義可以直接參考rfc文檔，此處不再贅述。

quic規(guī)定packet number始終為自增的，就算某個(gè)packet的內(nèi)容為重傳的frame數(shù)據(jù)，其packet number也必須自增，這相對(duì)于TCP來說，帶來一個(gè)優(yōu)點(diǎn)，能夠更加精確的采集到路徑的RTT屬性。

packet number編解碼: packet number是一個(gè)0~262 -1的取值范圍，quic為了節(jié)約空間，在計(jì)算packet number時(shí)，引入了unacked的概念，通過截?cái)啵ㄖ槐Ａ粲行it位）的方式，只用了1-4個(gè)字節(jié)，即可以encode/decode出正確的packet number。rfc文檔中有附錄詳細(xì)講解了enc/dec的過程。

packet頭在安全傳輸中是被保護(hù)對(duì)象，這也意味著在沒有ssl信息的情況下，無法使用wireshake對(duì)packet進(jìn)行時(shí)序分析。中間網(wǎng)絡(luò)設(shè)備也無法向TCP那樣獲得packet number進(jìn)行亂序重組。

packet荷載

在對(duì)packet進(jìn)行解密，且去除掉packet header后，packet的荷載里就都是frame了（至少包括1個(gè)）。

如果packet的荷載里，不包括ACK, PADDING, and CONNECTION_CLOSE這種三種類型的幀，那么這個(gè)packet則被定義為ack-eliciting，意味著對(duì)端必須對(duì)這種packet生成相應(yīng)的ack通知發(fā)送方，以確保數(shù)據(jù)沒有丟失。

packet的荷載里frames的類型在多達(dá)30種類型，每種類型都有自己的應(yīng)用場景，如ACK Frame用于可靠傳輸（Recovery)，Crypto用于安全傳輸（TLS握手），Stream Frame用于業(yè)務(wù)數(shù)據(jù)傳遞，MAX_DATA/DATA_BLOCKED用于流控，PING Frame可以用于mtu探測，具體描述參考rfc文檔。

安全傳輸

QUIC的安全傳輸依賴TLS1.3，而boringssl是眾多quic實(shí)現(xiàn)的依賴庫。協(xié)議對(duì)Packet的頭部以及荷載均進(jìn)行了保護(hù)（包括packet number）。TLS1.3 0RTT的能力，在提供數(shù)據(jù)保護(hù)的同時(shí)，能在第一時(shí)間（服務(wù)端收到第一個(gè)請(qǐng)求報(bào)文時(shí)）就將Response Header發(fā)給客戶端。大大降低了HTTP業(yè)務(wù)中的首包時(shí)間。為了支持0RTT，客戶端需要保存PSK信息，以及部分transport parament信息。

安全傳輸也經(jīng)常會(huì)涉及到性能問題，在目前主流的服務(wù)端，AESG由于cpu提供了硬件加速，所以性能表現(xiàn)最好。CHACHA20則需要更多的CPU資源。在短視頻業(yè)務(wù)上，出于對(duì)首幀的要求，通常直接使用明文傳輸。

Transport Paramenter（TP)協(xié)商是在安全傳輸?shù)奈帐蛛A段完成，除了協(xié)議規(guī)定的TP外，用戶也可以擴(kuò)展私有TP內(nèi)容，這一特性帶來了很大的便利，比如：客戶端可以利用tp告知服務(wù)端進(jìn)行明文傳輸。

可靠傳輸

QUIC協(xié)議是需要像TCP能夠進(jìn)行可靠傳輸，所以QUIC單獨(dú)有一個(gè)rfc描述了丟包檢測和擁塞控制的話題，

丟包檢測：協(xié)議利用兩種方式來判斷丟包是否發(fā)生：一種是基于ack的檢測，通過time threshold和packet threshold根據(jù)已經(jīng)到達(dá)的packet，推斷在此包之前發(fā)出去的包是否丟失。第二種，在失去了參考包的情況下，那么只能通過PTO的方式來推斷包是否丟失。一般來說，大量被觸發(fā)的應(yīng)該是ACK的檢測方式。如果PTO被大量觸發(fā)，會(huì)影響發(fā)包效率。

擁塞控制：QUIC針對(duì)TCP協(xié)議中的一些缺陷，專門做了優(yōu)化。比如始終遞增的packet number，豐富的ack range，host delay計(jì)算等。同時(shí)tcp的擁塞控制需要內(nèi)核態(tài)實(shí)現(xiàn)，而QUIC在用戶態(tài)實(shí)現(xiàn)，這大大降低了研究高效率的可靠傳輸協(xié)議的門檻。Recovery協(xié)議中，描述了newReno的實(shí)現(xiàn)方式。在GOOGLE chrome中，實(shí)現(xiàn)了cubic, bbr, bbrv2，而mvfst項(xiàng)目則更為豐富，包括了ccp, copa協(xié)議。

Stream層

stream是一個(gè)抽象的概念，它表達(dá)了一個(gè)有序傳輸?shù)淖止?jié)流，而這些字節(jié)其實(shí)就是由Stream Frame排在一起構(gòu)成。在一個(gè)quic connection上，可以同時(shí)傳輸多條流。

Stream頭部

在Quic協(xié)議里，stream分為單向流或雙向流，又分為客戶端發(fā)起或服務(wù)端發(fā)起。stream的不同類型定義在HTTP3中得到了充分的利用。

Stream荷載

Stream的荷載即為一系列Stream Frame，通過Stream Frame頭部的Stream ID來確認(rèn)單個(gè)流。
在TCP里，如果一個(gè)segment傳遞丟失，那么后續(xù)segment亂序到達(dá)，也不會(huì)被應(yīng)用層使用，只到丟失的segment重傳成功為止，因此TCP實(shí)現(xiàn)的HTTP2的多路復(fù)用能力受到制約。在QUIC協(xié)議中，有序的概念僅維護(hù)在單個(gè)stream中，stream之間和packet都不要求有序，假設(shè)某個(gè)packet丟失，只會(huì)影響包含在這個(gè)包里的stream，其他stream仍然可以從后續(xù)亂序到達(dá)的packet中提取到自己所需要的數(shù)據(jù)交給應(yīng)用層。

HTTP3層

stream分類

在引入HTTP3后，stream的單向流類型被擴(kuò)展成：控制流，Push流和其他保留類型。其中HTTP3的setting則是在控制流中傳輸，而HTTP數(shù)據(jù)傳輸是在客戶端發(fā)起的雙向流中，所以讀者會(huì)發(fā)現(xiàn)，HTTP數(shù)據(jù)傳輸?shù)膕tream id都是模4等于0的。

在引入QPACK后，單向流被進(jìn)一步擴(kuò)展了兩個(gè)類型，encoder流，decoder流，QPACK中動(dòng)態(tài)表的更新則依賴這兩個(gè)流。

QPACK

QPACK的作用是頭部壓縮。類似HPACK，QPACK定義了靜態(tài)表，動(dòng)態(tài)表用于頭部索引。靜態(tài)表是針對(duì)常見的頭部，協(xié)議預(yù)先定義的。動(dòng)態(tài)表則是在該QUIC Connection服務(wù)HTTP過程中，逐漸建立的。QPACK所建立的Encoder/Decoder流是伴隨用于HTTP事務(wù)的QUIC Connection生命周期。
動(dòng)態(tài)表不是HTTP3能夠運(yùn)行的必須項(xiàng)，所以在某些QUIC開源項(xiàng)目中，并沒有實(shí)現(xiàn)復(fù)雜的動(dòng)態(tài)表功能。

在QPACK的動(dòng)態(tài)表業(yè)務(wù)中，數(shù)據(jù)流，編碼流，解碼流3種對(duì)象共同參與，編碼流和解碼流負(fù)責(zé)維護(hù)動(dòng)態(tài)表變化，數(shù)據(jù)流則解析出頭部的索引號(hào)，去動(dòng)態(tài)表中查詢，得到最終的頭部定義。

其他

Flow Control 流控

QUIC協(xié)議引入了flow control的概念，用于表達(dá)接收端的接受能力。流控分兩級(jí)，Connection級(jí)別，和Stream級(jí)別。發(fā)送端發(fā)送的數(shù)據(jù)偏移量不能超過流控的限制，如果達(dá)到限制，那么發(fā)送端應(yīng)該通過
DATA_BLOCKED/STREAM_DATA_BLOCKED來通知接收端。如果為了傳輸性能，接收端應(yīng)該盡量保持限制足夠大，比如達(dá)到max_data的一半時(shí)，就及時(shí)更新max_data傳給發(fā)送端。如果接收端不希望太快接受數(shù)據(jù)，也可以利用流控對(duì)發(fā)送端進(jìn)行約束。

QUIC版本

QUIC一開始由google主導(dǎo)設(shè)計(jì)開發(fā)，在chromium項(xiàng)目中，可以看到google quic(GQUIC)版本號(hào)被定義為Q039,Q043,Q046,Q050等。

隨著IETF版本的QUIC推出，ietf quic(IQUIC)也有很多版本，如29,30,34(最新版)等，不同版本可能是無法互通的，比如不同版本安全傳輸?shù)膕alt變量規(guī)定不一樣。所以IQUIC引入了版本協(xié)商的功能，用于不同的客戶端和服務(wù)端協(xié)商出可以互通的版本。

在實(shí)踐中，還會(huì)遇到一個(gè)需求，要求一個(gè)服務(wù)能夠同時(shí)服務(wù)GQUIC的不同版本，又能服務(wù)IQUIC的不同版本。這就要求服務(wù)在收取到packet后，需要對(duì)packet作出判斷，分析出它屬于iquic的，還是gquic的，然后進(jìn)行邏輯分流。

QUIC應(yīng)用及未來展望

目前阿里云CDN線上提供GQUIC版本服務(wù)，適用的產(chǎn)品包含靜態(tài)內(nèi)容分發(fā)（圖片小文件、大文件下載、視音頻點(diǎn)播）和動(dòng)態(tài)內(nèi)容分發(fā)（全站加速）。用戶只需在CDN、全站加速控制臺(tái)對(duì)域名開啟【QUIC協(xié)議開關(guān)】功能，支持QUIC協(xié)議的客戶端即可通過QUIC協(xié)議與阿里云CDN節(jié)點(diǎn)通信。

QUIC應(yīng)用場景

圖片小文件：明顯降低文件下載總耗時(shí)，提升效率
視頻點(diǎn)播：提升首屏秒開率，降低卡頓率，提升用戶觀看體驗(yàn)
動(dòng)態(tài)請(qǐng)求：適用于動(dòng)態(tài)請(qǐng)求，提升訪問速度，如網(wǎng)頁登錄、交易等交互體驗(yàn)提升
弱網(wǎng)環(huán)境：在丟包和網(wǎng)絡(luò)延遲嚴(yán)重的情況下仍可提供可用的服務(wù)，并優(yōu)化卡頓率、請(qǐng)求失敗率、秒開率、提高連接成功率等傳輸指標(biāo)
大并發(fā)連接：連接可靠性強(qiáng)，支持頁面資源數(shù)較多、并發(fā)連接數(shù)較多情況下的訪問速率提升
加密連接：具備安全、可靠的傳輸性能

看完上述內(nèi)容，你們掌握能加速互聯(lián)網(wǎng)的QUIC協(xié)議有哪些的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！