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

隨著互聯(lián)網(wǎng)的快速發(fā)展，基礎(chǔ)網(wǎng)絡環(huán)境也在發(fā)生變化，WEB網(wǎng)絡協(xié)議也經(jīng)歷了HTTP1.0、HTTP1.1、HTTP2.0以及即將迎來HTTP3.0; HTTP3.0將以QUIC協(xié)議替代TCP作為傳輸層，具備stream多路復用、握手0RTT、連接遷移以及用戶態(tài)擁塞算法諸多優(yōu)勢。CDN產(chǎn)品關(guān)注QUIC協(xié)議演進并實踐落地，從gQUIC協(xié)議到標準IETF QUIC協(xié)議已經(jīng)部署在CDN邊緣節(jié)點，并在短視頻和圖片業(yè)務場景實踐有不錯的收益。

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

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

QUIC協(xié)議介紹

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

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

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

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

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

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

1. 低連接延時

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

2. 無隊頭阻塞

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

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

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

4. 連接遷移

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

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

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

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

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

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

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

TCPRTT測量使用發(fā)送包和確認包時間戳計算，未考慮主機延遲問題，QUIC使用ACKDelay機制，使得路徑RTT測量更加準確。

QUIC使用PTO探測超時機制，代替TCP的RTO&TLP。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• SSL加密算法的開銷：

對稱加解密也10%左右的開銷；優(yōu)化措施，不同場景選擇不同加密算法，實驗環(huán)境下對各加密算法進行性能測試，AES在cpu 指令優(yōu)化下，性能提升20%，chacha20針對移動端有優(yōu)化

• UDP 收發(fā)包的開銷：

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

• QUIC協(xié)議棧開銷：

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

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

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

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

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

從不同業(yè)務實踐中，CDN QUIC服務針對業(yè)務場景進行了全面優(yōu)化，包括4個方面：

• 連接優(yōu)化0-RTT連接復用率，降低連接的延遲。
• 加解密優(yōu)化明文傳輸，可以減少加解密造成的一些影響。
• 傳輸優(yōu)化亂序報文緩存，針對特殊數(shù)據(jù)優(yōu)先級需求進行調(diào)整。
• 針對線上的不同業(yè)務場景調(diào)整參數(shù)，利用擁塞算法，提升在不同業(yè)務場景下的效果。

原文鏈接

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

總結(jié)

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

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