簡介：在1月12日的「阿里雲CDN產品發佈會-新一代傳輸協議QUIC讓CDN更快一步」之上，阿里雲技術專家淮葉分享了QUIC技術及其應用落地實踐，內容包含：QUIC協議介紹、相比TCP有哪些優勢、應用場景以及技術落地實踐中的協議庫選擇，QUIC協議軟件實現、落地技術架構和性能優化。
隨着互聯網的快速發展，基礎網絡環境也在發生變化，WEB網絡協議也經歷了HTTP1.0、HTTP1.1、HTTP2.0以及即將迎來HTTP3.0; HTTP3.0將以QUIC協議替代TCP作爲傳輸層，具備stream多路複用、握手0RTT、連接遷移以及用戶態擁塞算法諸多優勢。CDN產品關注QUIC協議演進並實踐落地，從gQUIC協議到標準IETF QUIC協議已經部署在CDN邊緣節點，並在短視頻和圖片業務場景實踐有不錯的收益。
在1月12日的「阿里雲CDN產品發佈會-新一代傳輸協議QUIC讓CDN更快一步」之上，阿里雲技術專家淮葉分享了QUIC技術及其應用落地實踐。本文根據分享內容梳理，包括以下三個部分：
- QUIC協議介紹，包括協議誕生歷史、基礎特性、相比TCP有哪些優勢，以及QUIC協議可以應用在哪些業務場景
- CDN QUIC技術落地實踐，包括協議庫選擇，QUIC協議軟件實現以及QUIC落地技術架構，以及QUIC性能優化，QUIC產品如何接入使用
- CDN QUIC技術落地場景，主要介紹阿里巴巴集團業務使用QUIC加速後的收益，以及背後的一些優化措施
QUIC協議介紹
當我們訪問視頻網站和APP應用時，經常會遇到各種各樣的性能問題，網頁加載慢、視頻卡頓、網絡出錯，其中關鍵影響因素就是網絡協議。
HTTP 協議作爲互聯網web協議，經歷了幾次重要的升級：
HTTP1.0 -> HTTP1.1：支持長連接，請求pipeline特性，通過減少了TCP三次握手，降低連接建立的開銷
HTTP -> HTTPS：增加TLS層握手，傳輸內容加解密，因增加安全特性，故增加建連延遲
HTTP1.1 -> HTTP2：H2特性是請求數據流的多路複用與頭部壓縮，提高了單連接的併發能力
從HTTP1.0升級到HTTP2，其中傳輸層協議沒有變化都是基於TCP協議。TCP協議是可靠傳輸協議，需要三次握手狀態，還有隊頭阻塞問題，爲了解決這些問題，基於UDP設計實現的一種可靠傳輸協議——QUIC協議應運而生。因此，HTTP協議再次升級。
HTTP2->HTTP3：HTTP3基於QUIC協議，因此具備QUIC協議的傳輸特性，解決TCP隊頭阻塞問題，具備TLS1.30-RTT、H2多路複用能力，還具備連接遷移能力。QUIC協議已於2021年5月正式標準化，編號爲RFC9000。
QUIC 協議解決了哪些問題
1. 低連接延時
QUIC 基於 UDP，無需 TCP 連接，最好情況下，QUIC 可以做到 0RTT 開啓數據傳輸。而基於 TCP 的 HTTPS，即使在TLS1.3的early data下仍然需要 1RTT 開啓數據傳輸。然而對於常見的 TLS1.2 完全握手的情況，則需要 3RTT 開啓數據傳輸。
2. 無隊頭阻塞
雖然 HTTP2 實現了多路複用，但是傳輸層依然使用的是TCP，一旦出現某個報文丟包，將會影響多路複用下的所有請求流。然而QUIC 基於 UDP，在設計上就解決了隊頭阻塞問題。同時HTTP3使用 QPACK 編碼替換 HPACK 編碼，在一定程度上也減輕了 HTTP 請求頭的隊頭阻塞問題。
3. 用戶態擁塞控制
QUIC 的傳輸控制不再依賴內核的擁塞控制算法，而是實現在應用層上。這意味着可以根據不同的業務場景，實現配置不同的擁塞控制算法以及參數，甚至同一個業務的不同QUIC連接也可以使用不同的擁塞控制算法。
4. 連接遷移
當實際用戶的網絡發生變化時，從 WIFI 網絡切換到 4G 網絡時，用戶地址發生變化，基於 TCP 的 HTTP 協議無法保持連接的存活；而QUIC 基於連接 CID 作爲連接標識, 仍然可以保證連接存活和數據正常收發。
既然QUIC協議設計初衷是解決傳輸層協議問題，與其競對的就是TCP協議，那麼從傳輸協議特性分析兩種協議設計差異，可得出以下對比：
- QUIC爲每個加密級別使用單獨的包號空間，除了0-RTT和1-RTT密鑰使用相同的包號空間，隔離的包號空間可以確保使用一種加密級別發送包的ACK, 不會引起使用其他加密級別發送的包的虛假重傳問題。
- QUIC的包號嚴格按照包號空間遞增，直接編碼傳輸順序。報文號越高表示報文發送時間越晚，報文號越低表示報文發送時間越早。當一個包含應答幀的包被檢測到丟失時，QUIC會在一個新的包中包含必要的幀，並添加一個新的包號，從而消除了當收到應答時確認哪個包的不確定性。因此，可以進行更精確的進行RTT測量，可以輕鬆地檢測到虛假重傳。
- Quicack幀包含類似於TCP選擇性應答(sack)的信息。然而QUIC不允許數據包的確認被違背，這大大簡化了雙方的實現，並降低了發送方的內存壓力。
- 與TCP的三個SACK範圍相反，QUIC支持許多ACK範圍。在高丟包環境中，這種方法可以加快恢復速度，減少虛假重傳。
- TCPRTT測量使用發送包和確認包時間戳計算，未考慮主機延遲問題，QUIC使用ACKDelay機制，使得路徑RTT測量更加準確。
- QUIC使用PTO探測超時機制，代替TCP的RTO&TLP。
- TCP使用一個包的最小擁塞窗口。如果丟失單個數據包意味着發送方需要等待PTO來恢復，當接收方延遲確認時，發送一個單一的ack-eliciting包也增加了引起額外延遲。因此，QUIC建議最小擁塞窗口爲兩個包。雖然這增加了網絡負載，但它被認爲是安全的，因爲在持續擁塞的情況下，發送方仍然會以指數方式降低發送速率。
- 動態請求(API和信令傳輸場景)：降低動態交互耗時
- 短視頻：提升首屏秒開率，降低卡頓率
- 圖片文件下載：降低文件下載總耗時
- 直播：降低播放卡頓率，提升推流穩定性
CDN QUIC技術落地實踐
關於協議庫如何選擇？
QUIC 協議棧的實現版本庫很多，但協議功能實現的全面性各有不同，通過QUIC協議互通性測試報告，可以瞭解各協議庫的QUIC特性支持程度。
CDN在QUIC協議上的實踐路線，是從gQUIC版本開始調研實現，然後跟進QUIC標準化進度，然後支持 IETFQUIC標準，並實現HTTP3接入服務。選擇gQUIC的原因是GOOGLE是QUIC協議的開創者，基於chromium實現的QUIC協議棧最早，功能最齊，實現上也最爲標準，因此選擇了它。
關於IETFQUIC協議版本，NGINX官方已實現了一個基礎版本，生產環境使用仍然存在很多問題沒解決，擁塞控制算法沒有實現；但從QUIC協議互通測試報告看，QUIC協議實現比較全面，並且性能也不錯，相信NGINX官方很快就會把QUIC分支合入主幹。同時，補全了其缺失功能，比如擁塞算法。
gQUIC&IETFQUIC兼容架構
我們選擇了兩套不同的QUIC協議棧實現版本，來分別支持gQUIC和IETFQUIC，其中gQUIC版本支持Q039,Q043,Q046，IETFQUIC支持h3-29quicv1。
gQUIC協議庫，自從2018年調研嵌入到CDN服務，我們從chromium裁剪出net網絡庫部分，開發QUIC模塊，以及自研擁塞算法。隨着IETFQUIC協議草案逐漸成熟，2020年RFC草案基本定稿，CDN也開始IETFQUIC實現調研，我們基於NGINX官方QUIC版本進行深度開發，解決QUIC加密庫、擁塞算法、資源運維等問題，達到CDN上線標準。現在CDN QUIC同時支持gQUIC和IETFQUIC兩種版本，客戶接入無需更換域名，更換調度域。（CDN實現已經做了協議分流）
技術架構實現分爲兩個組件：QUIC-LB 和 QUIC-Server
QUIC-LB: 主要實現根據QUIC連接CID選擇後端QUIC-Server邏輯
QUIC-Server：實現QUIC協議棧特性，並且根據連接CID選擇已建立會話的worker進行服務
在 CDN QUIC 技術落地實踐中，我們面臨一個難題是QUIC傳輸帶來的CPU資源損耗高於TCP協議棧的CPU消耗，QUIC 協議將 TCP協議棧 的特性從內核移到了應用層，從目前開源 QUIC 實現版本來看，性能相比 TCP 還有差距。因爲TCP長期使用以來，從協議棧到網卡經過了非常多的優化，相比之下，UDP的優化很少。除了內核和硬件外，QUIC 協議的性能也與其實現有關，不同的實現版本可能也會有很大的差距。
- SSL加密算法的開銷：
對稱加解密也10%左右的開銷；優化措施，不同場景選擇不同加密算法，實驗環境下對各加密算法進行性能測試，AES在cpu 指令優化下，性能提升20%，chacha20針對移動端有優化
- UDP 收發包的開銷：
針對大文件下載的情況，sendmsg佔比很高，可以達到 30%以上；優化措施，開啓GSO模式，相比單包發送，性能提升2-3倍
- QUIC協議棧開銷：
受協議棧自身實現的影響，如 ACK 的處理，MTU 探測和發包大小，內存拷貝等；優化措施，ACK 合併、調整udp payload size
CDN QUIC協議如何接入使用
1.CDN控制檯，先申請開通，用戶即可自助開啓、關閉QUIC
2.測試工具，瀏覽器或者一些QUIC開源庫工具，curl已經支持HTTP3
3.QUIC監控，可以從CDN內部監控系統查看QUIC連接異常問題
4.QUIC分析工具，wireshark最新版本已經支持QUIC協議分析
CDN QUIC產品的應用效果
CDN QUIC在阿里巴巴集團的一些業務上已經實踐落地並取得了一些效果。例如：淘寶短視頻業務在開啓HTTP3後，客戶端分片下載耗時下降 20%，播放器卡頓率下降 10%；支付寶圖片下載業務在開啓gQUIC後，小程序包下載耗時下降 25%，整體業務下載耗時下降 40%。
從不同業務實踐中，CDN QUIC服務針對業務場景進行了全面優化，包括4個方面：
- 連接優化0-RTT連接複用率，降低連接的延遲。
- 加解密優化明文傳輸，可以減少加解密造成的一些影響。
- 傳輸優化亂序報文緩存，針對特殊數據優先級需求進行調整。
- 針對線上的不同業務場景調整參數，利用擁塞算法，提升在不同業務場景下的效果。
本文爲阿里雲原創內容，未經允許不得轉載。