簡(jiǎn)介：在1月12日的「阿里云CDN產(chǎn)品發(fā)布會(huì)-新一代傳輸協(xié)議QUIC讓CDN更快一步」之上，阿里云技術(shù)專(zhuān)家淮葉分享了QUIC技術(shù)及其應(yīng)用落地實(shí)踐，內(nèi)容包含：QUIC協(xié)議介紹、相比TCP有哪些優(yōu)勢(shì)、應(yīng)用場(chǎng)景以及技術(shù)落地實(shí)踐中的協(xié)議庫(kù)選擇，QUIC協(xié)議軟件實(shí)現(xiàn)、落地技術(shù)架構(gòu)和性能優(yōu)化。

隨著互聯(lián)網(wǎng)的快速發(fā)展，基礎(chǔ)網(wǎng)絡(luò)環(huán)境也在發(fā)生變化，WEB網(wǎng)絡(luò)協(xié)議也經(jīng)歷了HTTP1.0、HTTP1.1、HTTP2.0以及即將迎來(lái)HTTP3.0; HTTP3.0將以QUIC協(xié)議替代TCP作為傳輸層，具備stream多路復(fù)用、握手0RTT、連接遷移以及用戶(hù)態(tài)擁塞算法諸多優(yōu)勢(shì)。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ò)的收益。

在1月12日的「阿里云CDN產(chǎn)品發(fā)布會(huì)-新一代傳輸協(xié)議QUIC讓CDN更快一步」之上，阿里云技術(shù)專(zhuān)家淮葉分享了QUIC技術(shù)及其應(yīng)用落地實(shí)踐。本文根據(jù)分享內(nèi)容梳理，包括以下三個(gè)部分：

• QUIC協(xié)議介紹，包括協(xié)議誕生歷史、基礎(chǔ)特性、相比TCP有哪些優(yōu)勢(shì)，以及QUIC協(xié)議可以應(yīng)用在哪些業(yè)務(wù)場(chǎng)景
• CDN QUIC技術(shù)落地實(shí)踐，包括協(xié)議庫(kù)選擇，QUIC協(xié)議軟件實(shí)現(xiàn)以及QUIC落地技術(shù)架構(gòu)，以及QUIC性能優(yōu)化，QUIC產(chǎn)品如何接入使用
• CDN QUIC技術(shù)落地場(chǎng)景，主要介紹阿里巴巴集團(tuán)業(yè)務(wù)使用QUIC加速后的收益，以及背后的一些優(yōu)化措施

QUIC協(xié)議介紹

當(dāng)我們?cè)L問(wèn)視頻網(wǎng)站和APP應(yīng)用時(shí)，經(jīng)常會(huì)遇到各種各樣的性能問(wèn)題，網(wǎng)頁(yè)加載慢、視頻卡頓、網(wǎng)絡(luò)出錯(cuò)，其中關(guān)鍵影響因素就是網(wǎng)絡(luò)協(xié)議。

HTTP 協(xié)議作為互聯(lián)網(wǎng)web協(xié)議，經(jīng)歷了幾次重要的升級(jí)：

HTTP1.0 -> HTTP1.1：支持長(zhǎng)連接，請(qǐng)求pipeline特性，通過(guò)減少了TCP三次握手，降低連接建立的開(kāi)銷(xiāo)
HTTP -> HTTPS：增加TLS層握手，傳輸內(nèi)容加解密，因增加安全特性，故增加建連延遲
HTTP1.1 -> HTTP2：H2特性是請(qǐng)求數(shù)據(jù)流的多路復(fù)用與頭部壓縮，提高了單連接的并發(fā)能力

從HTTP1.0升級(jí)到HTTP2，其中傳輸層協(xié)議沒(méi)有變化都是基于TCP協(xié)議。TCP協(xié)議是可靠傳輸協(xié)議，需要三次握手狀態(tài)，還有隊(duì)頭阻塞問(wèn)題，為了解決這些問(wèn)題，基于UDP設(shè)計(jì)實(shí)現(xiàn)的一種可靠傳輸協(xié)議——QUIC協(xié)議應(yīng)運(yùn)而生。因此，HTTP協(xié)議再次升級(jí)。

HTTP2->HTTP3：HTTP3基于QUIC協(xié)議，因此具備QUIC協(xié)議的傳輸特性，解決TCP隊(duì)頭阻塞問(wèn)題，具備TLS1.30-RTT、H2多路復(fù)用能力，還具備連接遷移能力。QUIC協(xié)議已于2021年5月正式標(biāo)準(zhǔn)化，編號(hào)為RFC9000。

QUIC 協(xié)議解決了哪些問(wèn)題

1. 低連接延時(shí)

QUIC 基于 UDP，無(wú)需 TCP 連接，最好情況下，QUIC 可以做到 0RTT 開(kāi)啟數(shù)據(jù)傳輸。而基于 TCP 的 HTTPS，即使在TLS1.3的early data下仍然需要 1RTT 開(kāi)啟數(shù)據(jù)傳輸。然而對(duì)于常見(jiàn)的 TLS1.2 完全握手的情況，則需要 3RTT 開(kāi)啟數(shù)據(jù)傳輸。

2. 無(wú)隊(duì)頭阻塞

雖然 HTTP2 實(shí)現(xiàn)了多路復(fù)用，但是傳輸層依然使用的是TCP，一旦出現(xiàn)某個(gè)報(bào)文丟包，將會(huì)影響多路復(fù)用下的所有請(qǐng)求流。然而QUIC 基于 UDP，在設(shè)計(jì)上就解決了隊(duì)頭阻塞問(wèn)題。同時(shí)HTTP3使用 QPACK 編碼替換 HPACK 編碼，在一定程度上也減輕了 HTTP 請(qǐng)求頭的隊(duì)頭阻塞問(wèn)題。

3. 用戶(hù)態(tài)擁塞控制

QUIC 的傳輸控制不再依賴(lài)內(nèi)核的擁塞控制算法，而是實(shí)現(xiàn)在應(yīng)用層上。這意味著可以根據(jù)不同的業(yè)務(wù)場(chǎng)景，實(shí)現(xiàn)配置不同的擁塞控制算法以及參數(shù)，甚至同一個(gè)業(yè)務(wù)的不同QUIC連接也可以使用不同的擁塞控制算法。

4. 連接遷移

當(dāng)實(shí)際用戶(hù)的網(wǎng)絡(luò)發(fā)生變化時(shí)，從 WIFI 網(wǎng)絡(luò)切換到 4G 網(wǎng)絡(luò)時(shí)，用戶(hù)地址發(fā)生變化，基于 TCP 的 HTTP 協(xié)議無(wú)法保持連接的存活；而QUIC 基于連接 CID 作為連接標(biāo)識(shí), 仍然可以保證連接存活和數(shù)據(jù)正常收發(fā)。

QUIC協(xié)議與TCP協(xié)議對(duì)比

既然QUIC協(xié)議設(shè)計(jì)初衷是解決傳輸層協(xié)議問(wèn)題，與其競(jìng)對(duì)的就是TCP協(xié)議，那么從傳輸協(xié)議特性分析兩種協(xié)議設(shè)計(jì)差異，可得出以下對(duì)比：

QUIC為每個(gè)加密級(jí)別使用單獨(dú)的包號(hào)空間，除了0-RTT和1-RTT密鑰使用相同的包號(hào)空間，隔離的包號(hào)空間可以確保使用一種加密級(jí)別發(fā)送包的ACK, 不會(huì)引起使用其他加密級(jí)別發(fā)送的包的虛假重傳問(wèn)題。

QUIC的包號(hào)嚴(yán)格按照包號(hào)空間遞增，直接編碼傳輸順序。報(bào)文號(hào)越高表示報(bào)文發(fā)送時(shí)間越晚，報(bào)文號(hào)越低表示報(bào)文發(fā)送時(shí)間越早。當(dāng)一個(gè)包含應(yīng)答幀的包被檢測(cè)到丟失時(shí)，QUIC會(huì)在一個(gè)新的包中包含必要的幀，并添加一個(gè)新的包號(hào)，從而消除了當(dāng)收到應(yīng)答時(shí)確認(rèn)哪個(gè)包的不確定性。因此，可以進(jìn)行更精確的進(jìn)行RTT測(cè)量，可以輕松地檢測(cè)到虛假重傳。

Quicack幀包含類(lèi)似于TCP選擇性應(yīng)答(sack)的信息。然而QUIC不允許數(shù)據(jù)包的確認(rèn)被違背，這大大簡(jiǎn)化了雙方的實(shí)現(xiàn)，并降低了發(fā)送方的內(nèi)存壓力。

與TCP的三個(gè)SACK范圍相反，QUIC支持許多ACK范圍。在高丟包環(huán)境中，這種方法可以加快恢復(fù)速度，減少虛假重傳。

TCPRTT測(cè)量使用發(fā)送包和確認(rèn)包時(shí)間戳計(jì)算，未考慮主機(jī)延遲問(wèn)題，QUIC使用ACKDelay機(jī)制，使得路徑RTT測(cè)量更加準(zhǔn)確。

QUIC使用PTO探測(cè)超時(shí)機(jī)制，代替TCP的RTO&TLP。

TCP使用一個(gè)包的最小擁塞窗口。如果丟失單個(gè)數(shù)據(jù)包意味著發(fā)送方需要等待PTO來(lái)恢復(fù)，當(dāng)接收方延遲確認(rèn)時(shí)，發(fā)送一個(gè)單一的ack-eliciting包也增加了引起額外延遲。因此，QUIC建議最小擁塞窗口為兩個(gè)包。雖然這增加了網(wǎng)絡(luò)負(fù)載，但它被認(rèn)為是安全的，因?yàn)樵诔掷m(xù)擁塞的情況下，發(fā)送方仍然會(huì)以指數(shù)方式降低發(fā)送速率。

QUIC協(xié)議可以加速哪些場(chǎng)景

• 動(dòng)態(tài)請(qǐng)求(API和信令傳輸場(chǎng)景)：降低動(dòng)態(tài)交互耗時(shí)
• 短視頻：提升首屏秒開(kāi)率，降低卡頓率
• 圖片文件下載：降低文件下載總耗時(shí)
• 直播：降低播放卡頓率，提升推流穩(wěn)定性

CDN QUIC技術(shù)落地實(shí)踐

關(guān)于協(xié)議庫(kù)如何選擇？

QUIC 協(xié)議棧的實(shí)現(xiàn)版本庫(kù)很多，但協(xié)議功能實(shí)現(xiàn)的全面性各有不同，通過(guò)QUIC協(xié)議互通性測(cè)試報(bào)告，可以了解各協(xié)議庫(kù)的QUIC特性支持程度。

CDN在QUIC協(xié)議上的實(shí)踐路線，是從gQUIC版本開(kāi)始調(diào)研實(shí)現(xiàn)，然后跟進(jìn)QUIC標(biāo)準(zhǔn)化進(jìn)度，然后支持 IETFQUIC標(biāo)準(zhǔn)，并實(shí)現(xiàn)HTTP3接入服務(wù)。選擇gQUIC的原因是GOOGLE是QUIC協(xié)議的開(kāi)創(chuàng)者，基于chromium實(shí)現(xiàn)的QUIC協(xié)議棧最早，功能最齊，實(shí)現(xiàn)上也最為標(biāo)準(zhǔn)，因此選擇了它。

關(guān)于IETFQUIC協(xié)議版本，NGINX官方已實(shí)現(xiàn)了一個(gè)基礎(chǔ)版本，生產(chǎn)環(huán)境使用仍然存在很多問(wèn)題沒(méi)解決，擁塞控制算法沒(méi)有實(shí)現(xiàn)；但從QUIC協(xié)議互通測(cè)試報(bào)告看，QUIC協(xié)議實(shí)現(xiàn)比較全面，并且性能也不錯(cuò)，相信NGINX官方很快就會(huì)把QUIC分支合入主干。同時(shí)，補(bǔ)全了其缺失功能，比如擁塞算法。

gQUIC&IETFQUIC兼容架構(gòu)

我們選擇了兩套不同的QUIC協(xié)議棧實(shí)現(xiàn)版本，來(lái)分別支持gQUIC和IETFQUIC，其中g(shù)QUIC版本支持Q039,Q043,Q046，IETFQUIC支持h3-29quicv1。

gQUIC協(xié)議庫(kù)，自從2018年調(diào)研嵌入到CDN服務(wù)，我們從chromium裁剪出net網(wǎng)絡(luò)庫(kù)部分，開(kāi)發(fā)QUIC模塊，以及自研擁塞算法。隨著IETFQUIC協(xié)議草案逐漸成熟，2020年RFC草案基本定稿，CDN也開(kāi)始IETFQUIC實(shí)現(xiàn)調(diào)研，我們基于NGINX官方QUIC版本進(jìn)行深度開(kāi)發(fā)，解決QUIC加密庫(kù)、擁塞算法、資源運(yùn)維等問(wèn)題，達(dá)到CDN上線標(biāo)準(zhǔn)。現(xiàn)在CDN QUIC同時(shí)支持gQUIC和IETFQUIC兩種版本，客戶(hù)接入無(wú)需更換域名，更換調(diào)度域。（CDN實(shí)現(xiàn)已經(jīng)做了協(xié)議分流）

CDN QUIC技術(shù)架構(gòu)實(shí)現(xiàn)

技術(shù)架構(gòu)實(shí)現(xiàn)分為兩個(gè)組件：QUIC-LB 和 QUIC-Server

QUIC-LB:?主要實(shí)現(xiàn)根據(jù)QUIC連接CID選擇后端QUIC-Server邏輯

QUIC-Server：實(shí)現(xiàn)QUIC協(xié)議棧特性，并且根據(jù)連接CID選擇已建立會(huì)話的worker進(jìn)行服務(wù)

在 CDN QUIC 技術(shù)落地實(shí)踐中，我們面臨一個(gè)難題是QUIC傳輸帶來(lái)的CPU資源損耗高于TCP協(xié)議棧的CPU消耗，QUIC 協(xié)議將 TCP協(xié)議棧 的特性從內(nèi)核移到了應(yīng)用層，從目前開(kāi)源 QUIC 實(shí)現(xiàn)版本來(lái)看，性能相比 TCP 還有差距。因?yàn)門(mén)CP長(zhǎng)期使用以來(lái)，從協(xié)議棧到網(wǎng)卡經(jīng)過(guò)了非常多的優(yōu)化，相比之下，UDP的優(yōu)化很少。除了內(nèi)核和硬件外，QUIC 協(xié)議的性能也與其實(shí)現(xiàn)有關(guān)，不同的實(shí)現(xiàn)版本可能也會(huì)有很大的差距。

所以對(duì) QUIC 的傳輸性能，通過(guò)火焰圖進(jìn)行分析，找出了一些影響 QUIC 性能的關(guān)鍵點(diǎn)：

• SSL加密算法的開(kāi)銷(xiāo)：

對(duì)稱(chēng)加解密也10%左右的開(kāi)銷(xiāo)；優(yōu)化措施，不同場(chǎng)景選擇不同加密算法，實(shí)驗(yàn)環(huán)境下對(duì)各加密算法進(jìn)行性能測(cè)試，AES在cpu 指令優(yōu)化下，性能提升20%，chacha20針對(duì)移動(dòng)端有優(yōu)化

• UDP 收發(fā)包的開(kāi)銷(xiāo)：

針對(duì)大文件下載的情況，sendmsg占比很高，可以達(dá)到 30%以上；優(yōu)化措施，開(kāi)啟GSO模式，相比單包發(fā)送，性能提升2-3倍

• QUIC協(xié)議棧開(kāi)銷(xiāo)：

受協(xié)議棧自身實(shí)現(xiàn)的影響，如 ACK 的處理，MTU 探測(cè)和發(fā)包大小，內(nèi)存拷貝等；優(yōu)化措施，ACK 合并、調(diào)整udp payload size

CDN QUIC協(xié)議如何接入使用

1.CDN控制臺(tái)，先申請(qǐng)開(kāi)通，用戶(hù)即可自助開(kāi)啟、關(guān)閉QUIC
2.測(cè)試工具，瀏覽器或者一些QUIC開(kāi)源庫(kù)工具，curl已經(jīng)支持HTTP3
3.QUIC監(jiān)控，可以從CDN內(nèi)部監(jiān)控系統(tǒng)查看QUIC連接異常問(wèn)題
4.QUIC分析工具，wireshark最新版本已經(jīng)支持QUIC協(xié)議分析

CDN QUIC產(chǎn)品的應(yīng)用效果

CDN QUIC在阿里巴巴集團(tuán)的一些業(yè)務(wù)上已經(jīng)實(shí)踐落地并取得了一些效果。例如：淘寶短視頻業(yè)務(wù)在開(kāi)啟HTTP3后，客戶(hù)端分片下載耗時(shí)下降 20%，播放器卡頓率下降 10%；支付寶圖片下載業(yè)務(wù)在開(kāi)啟gQUIC后，小程序包下載耗時(shí)下降 25%，整體業(yè)務(wù)下載耗時(shí)下降 40%。

從不同業(yè)務(wù)實(shí)踐中，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)景下的效果。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的QUIC技术创新 让视频和图片分发再提速的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。