?

導(dǎo)讀

QUIC(Quick UDP Internet Connection)是谷歌制定的一種基于UDP的低時(shí)延的互聯(lián)網(wǎng)傳輸層協(xié)議，很好地解決了當(dāng)今傳輸層和應(yīng)用層面臨的各種需求，包括處理更多的連接，低延遲以及安全性保障等，目前QUIC開始了它的標(biāo)準(zhǔn)化過(guò)程，已經(jīng)成為新一代傳輸層協(xié)議。

作者：陸營(yíng)川

單位：中國(guó)移動(dòng)智慧家庭運(yùn)營(yíng)中心

Part 01 ●??什么是QUIC?●?

QUIC(Quick UDP Internet Connection)是Google提出的一個(gè)基于UDP的傳輸協(xié)議，因其高效的傳輸效率和多路并發(fā)的能力，已經(jīng)成為下一代互聯(lián)網(wǎng)協(xié)議HTTP/3的底層傳輸協(xié)議，2021年5月IETF公布RFC9000，QUIC規(guī)范推出了標(biāo)準(zhǔn)化版本。除了應(yīng)用于Web領(lǐng)域，它的優(yōu)勢(shì)同樣適用于一些通用的需要低延遲、高吞吐特性的傳輸場(chǎng)景。

從協(xié)議棧可以看出：QUIC = HTTP/2 + TLS + UDP

Part 02

●??為什么要有QUIC?●?

HTTP從最初的HTTP/0.9，經(jīng)歷了HTTP/1.x，HTTP/2到最新的HTTP/3這幾個(gè)大的迭代。在HTTP/3版本之前，HTTP底層都是用TCP傳輸數(shù)據(jù)，而伴隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡(luò)交互場(chǎng)景越來(lái)越豐富并要求及時(shí)性，傳統(tǒng)TCP固有的性能瓶頸越來(lái)越不能滿足需求，原因有以下幾點(diǎn)：

- 建立連接的握手延遲大

HTTPS包含兩個(gè)握手：1）TCP三次握手，1個(gè)RTT；2）TLS握手，2個(gè)RTT。完整握手總共需要3個(gè)RTT，對(duì)于直播等需要首幀秒開場(chǎng)景，握手延遲太大。

- 多路復(fù)用的隊(duì)首阻塞

以HTTP/2多路復(fù)用為例，多個(gè)數(shù)據(jù)請(qǐng)求作為不同的流，共用一條TCP連接發(fā)送，所有的流應(yīng)用層都必須按序處理。若某個(gè)流的數(shù)據(jù)丟失，后面其他流的數(shù)據(jù)都會(huì)被阻塞，直到丟失的流數(shù)據(jù)重傳完成其他流才能被繼續(xù)傳輸。即使接收端已經(jīng)收到之后流的數(shù)據(jù)包，HTTP協(xié)議也不會(huì)通知應(yīng)用層去處理。

- TCP協(xié)議的更新滯后

TCP協(xié)議實(shí)現(xiàn)在操作系統(tǒng)內(nèi)核內(nèi)，但是用戶端的操作系統(tǒng)版本升級(jí)非常困難，很多老舊的系統(tǒng)還有大量用戶使用，因此TCP協(xié)議的一些更新很難被快速推廣。

正是考慮到以上的這些問(wèn)題，QUIC在應(yīng)用層之上基于UDP實(shí)現(xiàn)丟包恢復(fù)，擁塞控制，加解密，多路復(fù)用等功能，既能優(yōu)化握手延遲，同時(shí)又完全解決內(nèi)核協(xié)議更新滯后問(wèn)題。

Part 03 ●??QUIC建立連接的過(guò)程?●?

QUIC建立連接步驟比較簡(jiǎn)單，流程如下：

1）客戶端發(fā)起Inchoate client hello；

2）服務(wù)器返回Rejection，包括密鑰交換算法的公鑰信息，算法信息，證書信息等被放到server config中傳給客戶端；

3）客戶端發(fā)起client hello，包括客戶端公鑰信息。

此時(shí)，雙方各自計(jì)算出了對(duì)稱密鑰。QUIC的1次RTT建連過(guò)程結(jié)束，平均只耗時(shí)100ms以內(nèi)。后續(xù)發(fā)起連接的過(guò)程中，一旦客戶端緩存或持久化了server config，就可以復(fù)用并結(jié)合本地生成的私鑰進(jìn)行加密數(shù)據(jù)傳輸，不需要再次握手，從而實(shí)現(xiàn)0次RTT建立連接。

Part 04 ●??QUIC的優(yōu)缺點(diǎn)?●?

4.1 QUIC的優(yōu)勢(shì)體現(xiàn)在如下方面：

（1）可擴(kuò)展性強(qiáng)。更改TCP并不容易，因?yàn)槠渲械闹虚g件抗拒更新，而且TCP 40字節(jié)的可選位幾乎全部填滿。TCP沒(méi)有任何版本協(xié)商(version negotiation)擴(kuò)展位，相比之下，QUIC有32位，所以它有很多空間部署新版本，廠商也可以利用這些空間定義自己的專屬版本。

（2）用戶空間實(shí)現(xiàn)容易。QUIC能夠在應(yīng)用層實(shí)現(xiàn)，與在操作系統(tǒng)內(nèi)核中實(shí)現(xiàn)的TCP相比，它可以更快地進(jìn)行更新。這進(jìn)一步提高了QUIC的可擴(kuò)展性，使得服務(wù)可以非常快速地演進(jìn)，從而新的特性每天都能得到部署。同時(shí)它還能在上下文切換時(shí)通過(guò)調(diào)用較少的開銷而實(shí)現(xiàn)更高的響應(yīng)能力。

（3）建立連接更加快速。Web瀏覽特別需要快速建立連接，因?yàn)橛脩敉ǔ?huì)開啟多個(gè)、短暫的連接。當(dāng)使用HTTPS時(shí)，TCP在建立連接前，需要“三次握手”以及后續(xù)的TLS協(xié)議設(shè)置。QUIC（基于UDP）不需要三次握手，加上它會(huì)在初次握手時(shí)交換安全密鑰，從而使它在建立加密連接時(shí)速度提升了一倍。

（4）丟包敏感度較低。使用TCP時(shí)，如果丟失一個(gè)數(shù)據(jù)包，接下來(lái)所有的數(shù)據(jù)包都會(huì)停止傳輸，直到丟失的那個(gè)數(shù)據(jù)包被發(fā)送，這種現(xiàn)象被稱為“隊(duì)頭阻塞”，它會(huì)導(dǎo)致延遲明顯增加。相比之下，QUIC使用的是類似HTTP/2的多路復(fù)用模式，可以同時(shí)支持多個(gè)數(shù)據(jù)流。如果一個(gè)數(shù)據(jù)流發(fā)送錯(cuò)誤，導(dǎo)致丟包，那么其他數(shù)據(jù)流會(huì)繼續(xù)發(fā)送數(shù)據(jù)包，而不會(huì)阻塞傳輸。

（5）切換網(wǎng)絡(luò)時(shí)的性能提升較高。切換網(wǎng)絡(luò)時(shí)，QUIC可以實(shí)現(xiàn)平穩(wěn)過(guò)渡。比如，當(dāng)你使用家里的Wi-Fi觀看手機(jī)上的視頻，然后你走出家門，家里的Wi-Fi便切換到LTE；或者當(dāng)你一直忙于觀看視頻，在不同的移動(dòng)基站間移動(dòng)時(shí)；在以上這些場(chǎng)景中，TCP將切斷連接，并通過(guò)新的網(wǎng)絡(luò)創(chuàng)建新的連接，進(jìn)而影響到你的觀看體驗(yàn)，而QUIC則能夠?qū)崿F(xiàn)無(wú)縫連接。

（6）安全性和隱私保護(hù)較高。QUIC在傳輸層中內(nèi)置了加密功能，從而驗(yàn)證整個(gè)負(fù)載（包括header）。TCP在header中不包含加密，使它非常容易受到攻擊。QUIC默認(rèn)支持安全的TLS，意味著端到端完全安全。

4.2 QUIC的劣勢(shì)體現(xiàn)在如下方面：

TCP發(fā)明時(shí)，網(wǎng)絡(luò)都是有線連接，而且相當(dāng)可靠，QUIC對(duì)非可靠、無(wú)法預(yù)測(cè)的無(wú)線連接進(jìn)行了改進(jìn)，但并沒(méi)有改變互聯(lián)網(wǎng)傳輸?shù)谋举|(zhì)，它的局限性導(dǎo)致它只能改變某些特定使用場(chǎng)景。下面列舉了一些額外的QUIC局限性：

（1）遷移app面臨巨大挑戰(zhàn)。將app從HTTP/2遷移到HTTP/3（或者從TCP遷移到UDP）要費(fèi)很大力氣。整個(gè)過(guò)程需要將應(yīng)用層實(shí)現(xiàn)和傳輸層實(shí)現(xiàn)轉(zhuǎn)移到UDP，并在服務(wù)端和客戶端構(gòu)建全新的解決方案。這對(duì)于流媒體領(lǐng)域中資源相對(duì)有限的小廠商而言無(wú)疑挑戰(zhàn)重重，同時(shí)也解釋了谷歌和微軟這樣的科技巨頭可以率先采用QUIC協(xié)議的原因。

（2）采用受限。QUIC的最大問(wèn)題就是它的采用依然受限。幾乎每個(gè)瀏覽器都接受使用QUIC進(jìn)行簡(jiǎn)單的網(wǎng)頁(yè)瀏覽，但是除了chromium，沒(méi)有瀏覽器將它設(shè)置為默認(rèn)選項(xiàng)。除此之外，在流媒體領(lǐng)域，除了谷歌和Facebook之外，少有公司使用QUIC。只有少數(shù)CDN提供商支持QUIC，而其中的一些也只是驗(yàn)證了QUIC的實(shí)現(xiàn)，并沒(méi)有為大規(guī)模部署準(zhǔn)備好。這就帶來(lái)了問(wèn)題：如果你推出了使用multi-CDN并基于QUIC的新服務(wù)，那么將只有20%的訪問(wèn)使用QUIC，因?yàn)槟銦o(wú)法向用戶證明它對(duì)用戶體驗(yàn)的顯著影響。

（3）QUIC包含TCP回退。QUIC之所以被構(gòu)建在UDP之上，部分原因是極少有中間件和網(wǎng)絡(luò)設(shè)備攔截UDP。但確實(shí)存在被攔截的風(fēng)險(xiǎn)，所以基于QUIC的app必須設(shè)計(jì)成能夠回退到TCP，以防萬(wàn)一。這意味著app（基于QUIC）的開發(fā)者要同時(shí)開發(fā)和維護(hù)兩個(gè)不同的版本（由于TCP回退和受到限制的采用率），導(dǎo)致他們的負(fù)擔(dān)很重。好消息是，隨著最新的DEVOPS結(jié)構(gòu)與HTTP的Alt-Svc標(biāo)簽的使用，支持兩種協(xié)議要比以前簡(jiǎn)單得多。

（4）無(wú)法檢查數(shù)據(jù)包。網(wǎng)絡(luò)防火墻無(wú)法解密QUIC流量來(lái)檢查數(shù)據(jù)包，所以潛在的惡意流量非常有可能沒(méi)有被標(biāo)準(zhǔn)安全功能檢測(cè)出來(lái)而進(jìn)入網(wǎng)絡(luò)。因此，思科和Palo Alto Networks等安全廠商通常會(huì)在端口80（Web服務(wù)器）和443(TSL)攔截QUIC數(shù)據(jù)包（認(rèn)為它們包含惡意軟件），迫使客戶端回退使用HTTP/2和TCP協(xié)議。但上述操作并不會(huì)顯著影響內(nèi)容用戶體驗(yàn)，因?yàn)檎_實(shí)現(xiàn)的流媒體服務(wù)會(huì)默認(rèn)回退到TCP+TLS，但這種操作可能會(huì)阻止率先部署QUIC的想法。只有解決這一挑戰(zhàn)，QUIC才能被各大企業(yè)廣泛接受。

Part 05 ●??QUIC在實(shí)際場(chǎng)景中的使用?●?

5.1?QUIC在MQTT通信場(chǎng)景中的應(yīng)用前景

MQTT是基于TCP的物聯(lián)網(wǎng)通信協(xié)議，緊湊的報(bào)文結(jié)構(gòu)能夠在嚴(yán)重受限的硬件設(shè)備和低帶寬、高延遲的網(wǎng)絡(luò)上實(shí)現(xiàn)穩(wěn)定傳輸；心跳機(jī)制、遺囑消息、QoS質(zhì)量等級(jí)等諸多特性能夠應(yīng)對(duì)各種物聯(lián)網(wǎng)場(chǎng)景。盡管如此，由于底層TCP傳輸協(xié)議限制，某些復(fù)雜網(wǎng)絡(luò)環(huán)境下 MQTT 協(xié)議存在固有的弊端：

網(wǎng)絡(luò)切換導(dǎo)致經(jīng)常性連接中斷；

斷網(wǎng)后重新建立連接困難：斷網(wǎng)后操作系統(tǒng)釋放資源較慢，且應(yīng)用層無(wú)法及時(shí)感知斷開狀態(tài)，重連時(shí)Server/Client開銷較大；

弱網(wǎng)環(huán)境下數(shù)據(jù)傳輸受限于擁塞、丟包偵測(cè)和重傳機(jī)制。

例如車聯(lián)網(wǎng)用戶通常會(huì)面對(duì)類似的問(wèn)題：車輛可能會(huì)運(yùn)行在山區(qū)、礦場(chǎng)、隧道等地方，當(dāng)進(jìn)入到信號(hào)死角或被動(dòng)切換基站時(shí)會(huì)導(dǎo)致連接中斷，頻繁連接中斷與較慢的連接恢復(fù)速度會(huì)導(dǎo)致用戶體驗(yàn)變差。在一些對(duì)數(shù)據(jù)傳輸實(shí)時(shí)性和穩(wěn)定性要求較高的業(yè)務(wù)，如L4級(jí)別的無(wú)人駕駛中，客戶需要花費(fèi)大量的成本來(lái)緩解這一問(wèn)題。

在上述這類場(chǎng)景中，QUIC低連接開銷和多路徑支持的特性就顯示出了其優(yōu)勢(shì)，基于QUIC 0 RTT/1 RTT重連/新建能力，能夠在弱網(wǎng)與不固定的網(wǎng)絡(luò)通路中有效提升用戶體驗(yàn)。

5.2 QUIC協(xié)議在CDN加速方面的應(yīng)用

傳統(tǒng)CDN會(huì)有多級(jí)結(jié)構(gòu)，每一級(jí)結(jié)構(gòu)會(huì)有不同熱度數(shù)據(jù)。在CDN節(jié)點(diǎn)之間有大量的通訊數(shù)據(jù)，這些數(shù)據(jù)進(jìn)行分布式存儲(chǔ)時(shí)的路徑對(duì)最終CDN服務(wù)質(zhì)量有著非常重要的影響。通常來(lái)說(shuō)影響通訊質(zhì)量的因素通常會(huì)受到緩存業(yè)務(wù)內(nèi)容的性質(zhì)、節(jié)點(diǎn)間的網(wǎng)絡(luò)連接和Client-server側(cè)的傳輸架構(gòu)和機(jī)制的影響。這些層級(jí)間的數(shù)據(jù)拉取性能會(huì)直接影響到整體CDN的下發(fā)響應(yīng)速度。通常可以通過(guò)TCP優(yōu)化手段（數(shù)據(jù)連接池、TCP優(yōu)化）、緩存數(shù)據(jù)分塊、高層級(jí)向低層次的數(shù)據(jù)推送、緩存數(shù)據(jù)預(yù)拉取、數(shù)據(jù)壓縮等手段實(shí)現(xiàn)超遠(yuǎn)節(jié)點(diǎn)之間的進(jìn)一步傳輸。

在這種情況下，QUIC的優(yōu)勢(shì)就展現(xiàn)出來(lái)了。CDN QUIC服務(wù)針對(duì)業(yè)務(wù)場(chǎng)景進(jìn)行了全面優(yōu)化，包括4個(gè)方面：

連接優(yōu)化0-RTT連接復(fù)用率，降低連接的延遲。

加解密優(yōu)化明文傳輸，可以減少加解密造成的一些影響。

傳輸優(yōu)化亂序報(bào)文緩存，針對(duì)特殊數(shù)據(jù)優(yōu)先級(jí)需求進(jìn)行調(diào)整。

針對(duì)線上的不同業(yè)務(wù)場(chǎng)景調(diào)整參數(shù)，利用擁塞算法，提升在不同業(yè)務(wù)場(chǎng)景下的效果。

Part 06 ●??總結(jié)?●?

本文主要對(duì)QUIC協(xié)議概念背景以及該協(xié)議的優(yōu)缺點(diǎn)進(jìn)行了簡(jiǎn)要的概述，同時(shí)舉例了該協(xié)議的應(yīng)用場(chǎng)景，方便大家對(duì)該協(xié)議有一個(gè)初步的了解。目前該協(xié)議大型互聯(lián)網(wǎng)公司都有在不同的業(yè)務(wù)場(chǎng)景中使用，得到了不錯(cuò)的性能提升。中國(guó)移動(dòng)也在積極探索新技術(shù)，用技術(shù)改變生活。

編輯：黃飛

?