產(chǎn)品發(fā)布 | 阿里云CDN全面支持IETF QUIC

隨著互聯(lián)網(wǎng)飛速發(fā)展，用戶通過(guò)手機(jī)看到的內(nèi)容越來(lái)越多，交互形式也愈發(fā)豐富。用戶對(duì)于網(wǎng)絡(luò)的響應(yīng)、網(wǎng)絡(luò)的傳輸效率提出了更高的要求。傳統(tǒng)的TCP傳輸方式存在一些問(wèn)題，比如：依賴于操作系統(tǒng)的實(shí)現(xiàn)，部署和升級(jí)的周期很長(zhǎng)；握手時(shí)延無(wú)法避免；傳輸效率上會(huì)存在對(duì)頭阻塞等等，這些問(wèn)題是無(wú)法解決的。基于此，QUIC應(yīng)運(yùn)而生并且不斷發(fā)展演進(jìn)。

QUIC全稱Quick UDP Internet Connection，一種基于UDP實(shí)現(xiàn)可靠傳輸?shù)牡脱訒r(shí)互聯(lián)網(wǎng)傳輸協(xié)議。那么QUIC如何在CDN中應(yīng)用？其技術(shù)應(yīng)用場(chǎng)景可以為業(yè)務(wù)帶來(lái)什么樣的價(jià)值？1月12日，阿里云產(chǎn)品發(fā)布會(huì)154期，阿里云CDN重磅升級(jí)，為網(wǎng)友揭秘了新一代傳輸協(xié)議QUIC如何讓CDN更快一步。

01

QUIC 發(fā)展史回顧

首先，讓我們一起來(lái)回顧下QUIC的發(fā)展歷史。QUIC是從2013年google開(kāi)始基于UDP協(xié)議的一個(gè)研究，在經(jīng)過(guò)2013年到2015年的一些公開(kāi)的試驗(yàn)之后，2016年提交給IETF，也就是互聯(lián)網(wǎng)標(biāo)準(zhǔn)，進(jìn)行整體協(xié)議的標(biāo)準(zhǔn)化。眾所周知，QUIC具備很多的優(yōu)勢(shì)，比如RTT、0RTT多路復(fù)用等，比較關(guān)鍵是它實(shí)現(xiàn)了從內(nèi)核態(tài)到用戶態(tài)的轉(zhuǎn)變，整個(gè)算法的迭代從可以通過(guò)應(yīng)用層去完成，實(shí)現(xiàn)一客一用，極大提升了更新效率。IETF QUIC最終在2021年7月份完成定稿，命名為RFC9000。QUIC時(shí)代，現(xiàn)在開(kāi)始正式到來(lái)。

02

阿里云CDN QUIC的演進(jìn)

阿里云CDN團(tuán)隊(duì)在2018年開(kāi)始進(jìn)行QUIC相關(guān)調(diào)研和支持，且在2019年已經(jīng)支持了google QUIC的相關(guān)內(nèi)容，包括google的比較廣泛的版本，比如3943和46版本已經(jīng)在支持。在2020年，隨著IETF QUIC整個(gè)標(biāo)準(zhǔn)化進(jìn)展加快，阿里云CDN也開(kāi)始在對(duì)IETF QUIC進(jìn)行兼容和適配。在2021年，阿里云CDN全部物理節(jié)點(diǎn)均支持IETF QUIC。

為什么大家對(duì)QUIC會(huì)得到這么多的關(guān)注呢？通過(guò)互聯(lián)網(wǎng)一些通用的場(chǎng)景，阿里云CDN產(chǎn)品專家容蓓介紹了QUIC的優(yōu)勢(shì)和其與TCP之間的差異化價(jià)值。

03

QUIC 在CDN中的應(yīng)用

?

短視頻是CDN加速的經(jīng)典場(chǎng)景之一。對(duì)于平臺(tái)而言，希望給用戶創(chuàng)造更好的觀看體驗(yàn)，視頻卡頓、延遲都是不利因素，平臺(tái)會(huì)監(jiān)控播放完成率、互動(dòng)率等指標(biāo)，用于評(píng)估短視頻是否具備吸引力。拆分到技術(shù)層面，要看一個(gè)視頻平臺(tái)技術(shù)好不好，指標(biāo)就包括首屏?xí)r間、卡頓率、下載速率等等。

QUIC為什么會(huì)在這些核心指標(biāo)上面比TCP的效果更好？我們逐一來(lái)看。

第一，首屏?xí)r間通常是指用戶觀看到視頻或者是觀看到圖片的第一幀的時(shí)間。這個(gè)時(shí)間越快、延遲越小，用戶的體感就會(huì)越好，就不會(huì)有延遲。

從下圖中里面來(lái)看到。如果通過(guò)HTTP的協(xié)議去訪問(wèn)視頻，會(huì)有一次建聯(lián)，建聯(lián)之后再進(jìn)行數(shù)據(jù)傳輸。此外，因?yàn)镠TTP是明文傳輸，可能存在如數(shù)據(jù)篡改、劫持的風(fēng)險(xiǎn)，所以在客戶端，大家傾向于選擇使用HTTPS來(lái)傳輸。而HTTPS因?yàn)橛凶C書(shū)存在，它的握手又會(huì)增加，至少要通過(guò)三個(gè)RTT才能獲取到第一幀的內(nèi)容。假設(shè)平均的握手時(shí)間是200毫秒，那這200毫秒首屏延遲是完全無(wú)法避免的。并且，在這一次訪問(wèn)結(jié)束之后，這個(gè)連接會(huì)關(guān)閉。下一次用戶再訪問(wèn)同樣的東西時(shí)，又要再去建聯(lián)，這就意味著200毫秒是持續(xù)存在的，在TCP里面沒(méi)有辦法改善。

而因?yàn)镼UIC用的是這個(gè)UDP的協(xié)議，它的建聯(lián)方式會(huì)更優(yōu)化一些。QUIC中的握手從第一次開(kāi)始就是加密的狀態(tài)，第二次就可以傳輸一個(gè)數(shù)據(jù)，所以在QUIC中，用戶第一次訪問(wèn)一個(gè)資源，那么需要一個(gè)RTT，就可以獲取到數(shù)據(jù)內(nèi)容。而再次訪問(wèn)同樣的內(nèi)容，數(shù)據(jù)如果已經(jīng)存在本地，無(wú)需再建聯(lián)，就能實(shí)現(xiàn)0RTT的邏輯。當(dāng)然，首屏?xí)r間也會(huì)有其他的影響因素，但是這三個(gè)握手時(shí)間的節(jié)省，確實(shí)是QUIC在首屏?xí)r間上能拿到的實(shí)打?qū)嵉男阅芴嵘?/span>

第二，在傳輸層面上，QUIC也比TCP相對(duì)改進(jìn)。從下圖中可以看到，假設(shè)TCP在傳三張圖片，會(huì)把它分成不同的報(bào)文去進(jìn)行傳輸。圖一是TCP的傳輸方式，可以看到1234報(bào)文都被成功傳輸完了，應(yīng)用層也可以讀取到客戶端并進(jìn)行展示了，那么5的報(bào)文丟掉了，實(shí)際上6789在服務(wù)端也已經(jīng)傳成功了，但因?yàn)?丟掉了，所以678應(yīng)用層都是沒(méi)有辦法去接收的，必須要等到5重傳之后，后面的數(shù)據(jù)才能被傳完。

在QUIC里面，通過(guò)多路復(fù)用的方式來(lái)進(jìn)行數(shù)據(jù)傳輸，也就意味著1234傳輸成功之后，5丟掉了，678依舊可以被傳輸過(guò)去。這幾個(gè)報(bào)文數(shù)據(jù)包中只有5需要重傳，其他的都可以被應(yīng)用層讀取。那么在相同的網(wǎng)絡(luò)吞吐量的前提下，在相同時(shí)間內(nèi)會(huì)傳更多的內(nèi)容。所以，QUIC在下載耗時(shí)、卡頓率這個(gè)層面，會(huì)取得比較大的優(yōu)勢(shì)。

第三，擁塞機(jī)制。QUIC基本上繼承了TCP的擁塞算法在里邊。但為什么QUIC會(huì)要比TCP的優(yōu)勢(shì)更明顯呢？那是因?yàn)?/span>QUIC的控制層在應(yīng)用層，應(yīng)用層最大特性就是很靈活，比如說(shuō)我客戶A去配cubic，客戶B去配BBR，這個(gè)都只需要在服務(wù)端去做一個(gè)配置，然后幾個(gè)小時(shí)、幾分鐘快速生效。在TCP里邊，整個(gè)算法的優(yōu)化需要在內(nèi)核層中去做更新，更新是非常緩慢和慎重的，并且內(nèi)核層面部署時(shí)間、發(fā)布時(shí)間都很長(zhǎng)。舉個(gè)栗子，我們要把阿里云CDN 2800個(gè)節(jié)點(diǎn)的內(nèi)核層都更新一次，這個(gè)時(shí)間是非常漫長(zhǎng)的，并且可能會(huì)存在一些不可控的因素在里面。所以QUIC協(xié)議在擁塞控制層面非常靈活，這也是它的核心優(yōu)勢(shì)之一。

第四，弱網(wǎng)優(yōu)化。其實(shí)這也跟QUIC的建聯(lián)方式有關(guān)系。TCP如果要建聯(lián)，會(huì)有四要素，就是客戶端這個(gè)源IP、端口，服務(wù)端的目的IP、目的端口。通常目的IP和目的端口相對(duì)來(lái)講比較穩(wěn)定，不太容易發(fā)生變化。但是源IP這一側(cè)就不一定了。網(wǎng)絡(luò)變了、設(shè)備變了都會(huì)導(dǎo)致IP和端口的變化，在發(fā)生變化之后，哪怕我們看的都是同樣的內(nèi)容，也肯定要重新建聯(lián)。那么剛剛提到的TCP的握手又出來(lái)了，產(chǎn)生了中間的消耗和不確定性。那么，QUIC的建聯(lián)方式是通過(guò)一個(gè)connection ID來(lái)完成的，connection ID是一個(gè)64位的隨機(jī)數(shù)，相對(duì)更靈活。無(wú)論網(wǎng)絡(luò)發(fā)生什么變化，只要connection ID不變，那連接就不會(huì)斷掉，這就保證了用戶在觀看同樣內(nèi)容時(shí)更加順暢，性能體感更好。

阿里巴巴集團(tuán)應(yīng)用在QUIC在CDN的實(shí)踐上已經(jīng)取得了一些效果，比如：手淘今年雙11已經(jīng)將部分流量切到了IETF QUIC之上，短視頻業(yè)務(wù)卡頓率比TCP降低10%，下載分片耗時(shí)降低20%；優(yōu)酷長(zhǎng)視頻業(yè)務(wù)，平均播放卡頓時(shí)長(zhǎng)降低15% - 32.5%（強(qiáng)弱網(wǎng)區(qū)分）；支付寶圖片業(yè)務(wù)使用google QUIC，下載耗時(shí)降低25% - 40%以上。

04

總結(jié)：QUIC的核心優(yōu)勢(shì)

?

第一、快速建聯(lián)

0-RTT的握手，減少TCP握手和TLS的握手時(shí)間，提升首屏效率

第二、多路復(fù)用

相比于HTTP/2，真正的單通道并行傳輸，徹底解決TCP協(xié)議中隊(duì)頭阻塞問(wèn)題

第三、擁塞算法

擁塞算法靈活，不需要基于內(nèi)核或操作系統(tǒng)，可直接在應(yīng)用層改造

第四、持續(xù)在線

頻繁切換網(wǎng)絡(luò)的情況下，不會(huì)斷線，不需要重連，用戶無(wú)任何感知

05

如何開(kāi)通CDN QUIC服務(wù)

通過(guò)阿里云CDN控制臺(tái)，在每個(gè)域名配置下都會(huì)有QUIC選項(xiàng)。如果用戶已經(jīng)申請(qǐng)過(guò)了白名單，即可直接操控開(kāi)關(guān)來(lái)開(kāi)啟或者關(guān)閉QUIC服務(wù)。沒(méi)有申請(qǐng)過(guò)白名單的用戶則需要提交申請(qǐng)，后臺(tái)審核通過(guò)后即可通過(guò)控制臺(tái)來(lái)進(jìn)行操控。

在域名開(kāi)啟之后，用戶可以在資源監(jiān)控中選擇相關(guān)的協(xié)議層，查看QUIC相關(guān)數(shù)據(jù)。同時(shí)，QUIC會(huì)按照每萬(wàn)次五分錢(qián)的一個(gè)計(jì)費(fèi)邏輯按日出賬，用戶可以在用量中查詢QUIC的請(qǐng)求數(shù)的總數(shù)量，來(lái)進(jìn)行賬單的核對(duì)。

06

內(nèi)容預(yù)告

CDN產(chǎn)品關(guān)注QUIC協(xié)議演進(jìn)并實(shí)踐落地，從gQUIC協(xié)議到標(biāo)準(zhǔn)IETF QUIC協(xié)議已經(jīng)部署在CDN邊緣節(jié)點(diǎn)，并在短視頻和圖片業(yè)務(wù)場(chǎng)景實(shí)踐有不錯(cuò)的收益。

下一期，阿里云技術(shù)專家淮葉將帶來(lái)關(guān)于QUIC技術(shù)基礎(chǔ)特性、應(yīng)用場(chǎng)景及其技術(shù)落地實(shí)踐中的協(xié)議庫(kù)選擇、QUIC協(xié)議軟件實(shí)現(xiàn)、性能優(yōu)化的內(nèi)容分享，敬請(qǐng)期待！

往期推薦