爲什麼越來越多的團隊投入QUIC協議自研實現？來自阿里巴巴淘系技術的劉彥梅的投稿很好的解釋了背後的原因——提供更好的靈活性。同時，遵守標準的IETF QUIC也讓研發投入能產生長期回報。劉彥梅介紹了XQUIC的前生今世，以及未來的開源計劃。爲什麼越來越多的團隊投入QUIC協議自研實現？來自阿里巴巴淘系技術的劉彥梅的投稿很好的解釋了背後的原因——提供更好的靈活性。同時，遵守標準的IETF QUIC也讓研發投入能產生長期回報。劉彥梅介紹了XQUIC的前生今世，以及未來的開源計劃。爲什麼越來越多的團隊投入QUIC協議自研實現？來自阿里巴巴淘系技術的劉彥梅的投稿很好的解釋了背後的原因——提供更好的靈活性。同時，遵守標準的IETF QUIC也讓研發投入能產生長期回報。劉彥梅介紹了XQUIC的前生今世，以及未來的開源計劃。
爲什麼越來越多的團隊投入QUIC協議自研實現？來自阿里巴巴淘系技術的劉彥梅的投稿很好的解釋了背後的原因——提供更好的靈活性。同時，遵守標準的IETF QUIC也讓研發投入能產生長期回報。劉彥梅介紹了XQUIC的前生今世，以及未來的開源計劃。
XQUIC是阿里巴巴淘系架構團隊自研的IETF QUIC標準化協議庫實現，在手機淘寶上進行了廣泛的應用，並在多個不同類型的業務場景下取得明顯的效果提升，爲手機淘寶APP的用戶帶來絲般順滑的網絡體驗：
在RPC請求場景，網絡耗時降低15%
在直播高峯期場景，卡頓率降低30%、秒開率提升2%
在短視頻場景，卡頓率降低20%
從以上提升效果可以看出，對QUIC的一個常見認知謬誤：「QUIC只對弱網場景有優化提升」是不準確的。實際上QUIC對於整體網絡體驗有普遍提升，弱網場景由於基線較低、提升空間更顯著。此外，在5G推廣初期，基站部署不夠密集的情況下，如何保證穩定有效帶寬速率，是未來2-3年內手機視頻應用將面臨的重大挑戰，而我們研發的MPQUIC將爲這些挑戰提供有效的解決方案。
本文將會重點介紹XQUIC的設計原理，面向業務場景的網絡傳輸優化，以及面向5G的Multipath QUIC技術（多路徑QUIC）。
QUIC
▐ 網絡分層模型及QUIC進化史
圖1. 網絡七層/四層模型 和 QUIC分層設計
爲了方便說明QUIC在網絡通信協議棧中所處的位置及職能，我們簡單回顧一下網絡OSI模型（七層模型）和TCP/IP模型（四層模型）。從兩套網絡模型中可以看出，網絡傳輸行爲和策略主要由傳輸層來控制，而TCP作爲過去30年最爲流行和廣泛使用的傳輸層協議，是由操作系統控制和實現的。
QUIC是由Google從2013年開始研究的基於UDP的可靠傳輸協議，它最早的原型是SPDY + QUIC-Crypto + Reliable UDP，後來經歷了SPDY[1]轉型爲2015年5月IETF正式發佈的HTTP/2.0[2]，以及2016年TLS/1.3[3]的正式發佈。QUIC在IETF的標準化工作組自2016年成立，考慮到HTTP/2.0和TLS/1.3的發佈，它的核心協議族逐步進化爲現在的HTTP/3.0 + TLS/1.3 + QUIC-Transport的組合。
▐ QUIC帶來的核心收益是什麼
衆所周知，QUIC具備多路複用/0-RTT握手/連接遷移等多種優點，然而在這些優勢中，最關鍵的核心收益，當屬QUIC將四/七層網絡模型中控制傳輸行爲的傳輸層，從內核態實現遷移到了用戶態實現，由應用軟件控制。這將帶來2個巨大的優勢：
(1) 迭代優化效率大大提升。以服務端角度而言，大型在線系統的內核升級成本往往是非常高的，考慮到穩定性等因素，升級週期從月到年爲單位不等。以客戶端角度而言，手機操作系統版本升級同樣由廠商控制，升級週期同樣難以把控。調整爲用戶態實現後，端到端的升級都非常方便，版本迭代週期以周爲計（甚至更快）。
(2) 靈活適應不同業務場景的網絡需求。在過去4G的飛速發展中，短視頻、直播等新的業務場景隨着基建提供的下行帶寬增長開始出現，在流媒體傳輸對於穩定高帶寬和低延遲的訴求下，TCP紛紛被各類標準/私有UDP解決方案逐步替代，難以爭得一席之地。背後的原因是，實現在內核態的TCP，難以用一套擁塞控制算法/參數適應快速發展的各類業務場景。這一缺陷將在5G下變得更加顯著。QUIC則可將擁塞控制算法/參數調控到連接的粒度，針對同一個APP內的不同業務場景（例如RPC/短視頻/直播等）具備靈活適配/升級的能力。
在衆多增強型UDP的選擇中，QUIC相較於其他的方案最爲通用，不僅具備對於HTTP系列的良好兼容性，同時其優秀的的分層設計，也使得它可以將傳輸層單獨剝離作爲TCP的替代方案，爲其他應用層協議提供可靠/非可靠傳輸能力（是的，QUIC也有非可靠傳輸草案設計）。
XQUIC是什麼、爲什麼選擇自研 + 標準
XQUIC是阿里自研的IETF QUIC標準化實現，這個項目由淘系架構網關與基礎網絡團隊發起和主導，當前有阿里雲CDN、達摩院XG實驗室與AIS網絡研究團隊等多個團隊參與其中。
現今QUIC有多家開源實現，爲什麼選擇標準協議 + 自研實現的道路？我們從14年開始關注Google在QUIC上的實踐（手機淘寶在16年全面應用HTTP/2），從17年底開始跟進並嘗試在電商場景落地GQUIC[4]，在18年底在手淘圖片、短視頻等場景落地GQUIC並拿到了一定的網絡體驗收益。然而在使用開源方案的過程中或多或少碰到了一些問題，Google的實現是所有開源實現中最爲成熟優秀的，然而由於Chromium複雜的運行環境和C++實現的緣故，GQUIC包大小在優化後仍然有2.4M左右，這使得我們在集成手淘時面臨困難。在不影響互通性的前提下，我們進行了大量裁剪才勉強能夠達到手淘集成的包大小要求，然而在版本升級的情況下難以持續迭代。其他的開源實現也有類似或其他的問題（例如依賴過多、無服務端實現、無穩定性保障等）。最終促使我們走上自研實現的道路。
爲什麼要選擇IETF QUIC[5]標準化草案的協議版本？過去我們也嘗試過自研私有協議，在端到端都由內部控制的場景下，私有協議的確是很方便的，但私有協議方案很難走出去建立一個生態圈 / 或者與其他的應用生態圈結合（遵循相同的標準化協議實現互聯互通）；從阿里作爲雲廠商的角度，私有協議也很難與外部客戶打通；同時由於IETF開放討論的工作模式，協議在安全性、擴展性上會有更全面充分的考量。
因此我們選擇IETF QUIC標準化草案版本來落地。截止目前，IETF工作組草案已經演化到draft-29版本（2020.6.10發佈），XQUIC已經支持該版本，並能夠與其他開源實現基於draft-29互通。
XQUIC整體架構和傳輸框架設計
XQUIC是IETF QUIC草案版本的一個C協議庫實現，端到端的整體鏈路架構設計如下圖所示。XQUIC內部包含了QUIC-Transport（傳輸層）、QUIC-TLS（加密層、與TLS/1.3對接）和HTTP/3.0（應用層）的實現。在外部依賴方面，TLS/1.3依賴了開源boringssl或openssl實現（兩者XQUIC都做了支持、可用編譯選項控制），除此之外無其他外部依賴。
圖2. XQUIC端到端架構設計 和 內部分層模塊
XQUIC整體包大小在900KB左右（包含boringssl的情況下），對於客戶端集成是較爲輕量的（支持Android/iOS）。服務端方面，由於阿里內部網關體系廣泛使用Tengine（Nginx開源分支），我們開發了一個ngx_xquic_module用於適配Tengine服務端。協議的調度方面，由客戶端網絡庫與調度服務AMDC配合完成，可以根據版本/地域/運營商/設備百分比進行協議調度。
XQUIC傳輸層內部流程設計如下圖，可以看到XQUIC內部的讀寫事件主流程。考慮到跨平臺兼容性，UDP收發接口由外部實現並註冊回調接口。XQUIC內部維護了每條連接的狀態機、Stream狀態機，在Stream級別實現可靠傳輸（這也是根本上解決TCP頭部阻塞的關鍵），並通過讀事件通知的方式將數據投遞給應用層。傳輸層Stream與應用層HTTP/3的Request Stream有一一映射關係，通過這樣的方式解決HTTP/2 over TCP的頭部阻塞問題。
圖3. XQUIC讀寫事件主流程設計
考慮到IETF QUIC傳輸層的設計可以獨立剝離，並作爲TCP的替代方案對接其他應用層協議，XQUIC內部實現同樣基於這樣的分層方式，並對外提供兩套原生接口：HTTP/3請求應答接口 和 傳輸層獨立接口（類似TCP），使得例如RTMP、上傳協議等可以較爲輕鬆地接入。
圖4. XQUIC內部的連接狀態機設計（參考TCP）
XQUIC擁塞控制算法模塊
我們將XQUIC傳輸層的內部設計放大，其中擁塞控制算法模塊，是決定傳輸行爲和效率的核心模塊之一。
圖5. XQUIC擁塞控制算法模塊設計
爲了能夠方便地實現多套擁塞控制算法，我們將擁塞控制算法流程抽象成7個回調接口，其中最核心的兩個接口onAck和onLost用於讓算法實現收到報文ack和檢測到丟包時的處理邏輯。XQUIC內部實現了多套擁塞控制算法，包括最常見的Cubic、New Reno，以及音視頻場景下比較流行的BBR v1和v2，每種算法都只需要實現這7個回調接口即可實現完整算法邏輯。
爲了方便用數據驅動網絡體驗優化，我們將連接的丟包率、RTT、帶寬等信息通過埋點數據採樣和分析的方式，結合每個版本的算法調整進行效果分析。同時在實驗環境下模擬真實用戶的網絡環境分佈，更好地預先評估算法調整對於網絡體驗的改進效果。
面向業務場景的傳輸優化
XQUIC在RPC請求場景降低網絡耗時15%，在短視頻場景下降低20%卡頓率，在直播場景高峯期降低30%卡頓率、提升2%秒開率（相對於TCP）。以下基於當下非常火熱的直播場景，介紹XQUIC如何面向業務場景優化網絡體驗。
▐ 優化背景
部分用戶網絡環境比較差，存在直播拉流打開慢、卡頓問題。
圖6. 某節點丟包率和RTT統計分佈
這是CDN某節點上統計的丟包率和RTT分佈數據，可以看到，有5%的連接丟包率超過20%，0.5%的連接RTT超過500ms，如何優化網絡較差用戶的流媒體觀看體驗成爲關鍵。
▐ 秒開卡頓模型
圖7. 直播拉流模型
直播拉流可以理解爲一個注水模型，上面是CDN服務器，中間是播放器緩衝區，可以理解成一個管道，下面是用戶的體感，用戶點擊播放時，CDN不斷向管道里注水，當水量達到播放器初始buffer時，首幀畫面出現，然後播放器以一定速率排水，當水被排完時，播放器畫面出現停頓，當重新蓄滿支持播放的水後，繼續播放。
我們假設Initial Buffer（首幀）爲100K（實際調整以真實情況爲準），起播時間 T1 < 1s 記爲秒開，停頓時間 T2 > 100ms 記爲卡頓。
優化目標
提升秒開：1s內下載完100K
降低卡頓：保持下載速率穩定，從而保持管道內始終有水
核心思路
提升秒開核心--快
高丟包率用戶：加快重傳
高延遲用戶：減少往返次數
降低卡頓核心--穩
優化擁塞算法機制，穩定高效地利用帶寬
▐ 擁塞算法選型
常見的擁塞算法可分爲三類：
基於路徑時延（如Vegas、Westwood）
將路徑時延上升作爲發生擁塞的信號，在單一的網絡環境下（所有連接都使用基於路徑時延的擁塞算法）是可行的，但是在複雜的網絡環境下，帶寬容易被其他算法搶佔，帶寬利用率最低。
基於丟包（如Cubic、NewReno）
將丟包作爲發生擁塞的信號，其背後的邏輯是路由器、交換機的緩存都是有限的，擁塞會導致緩存用盡，進而隊列中的一些報文會被丟棄。
擁塞會導致丟包，但是丟包卻不一定擁塞導致的。事實上，丟包可以分爲兩類，一類是擁塞丟包，另一類是噪聲丟包，特別是在無線網絡環境中，數據以無線電的方式進行傳遞，無線路由器信號干擾、蜂窩信號不穩定等都會導致信號失真，最終數據鏈路層CRC校驗失敗將報文丟棄。
基於丟包的擁塞算法容易被噪聲丟包乾擾，在高丟包率高延遲的環境中帶寬利用率較低。
基於帶寬時延探測（如BBR）
既然無法區分擁塞丟包和噪聲丟包，那麼就不以丟包作爲擁塞信號，而是通過探測最大帶寬和最小路徑時延來確定路徑的容量。抗丟包能力強，帶寬利用率高。
三種類型的擁塞算法沒有誰好誰壞，都是順應當時的網絡環境的產物，隨着路由器、交換機緩存越來越大，無線網絡的比例越來越高，基於路徑時延和基於丟包的的擁塞算法就顯得不合時宜了。對於流媒體、文件上傳等對帶寬需求比較大的場景，BBR成爲更優的選擇。
▐ 秒開率優化
✎ 加快握手包重傳
圖8. TCP握手階段出現丟包
如圖，TCP在握手時，由於尚未收到對端的ACK，無法計算路徑RTT，因此，RFC定義了初始重傳超時，當超過這個超時時間還未收到對端ACK，就重發sync報文。
TCP秒開率上限：Linux內核中的初始重傳超時爲1s (RFC6298, June 2011)，3%的丟包率意味着TCP秒開率理論上限爲97%，調低初始重傳時間可以有效提升秒開率。
同理，如果你有一個RPC接口超時時間爲1s，那麼在3%丟包率的環境下，接口成功率不會超過97%。
圖9. TCP和QUIC握手階段 - 僞重傳模擬
另一方面，調低初始重傳超時會引發僞重傳，需要根據用戶RTT分佈進行取捨，比如初始重傳超時調低到500ms，那麼RTT大於500ms的用戶在握手期間將會多發一個sync報文。
✎ 減少往返次數
慢啓動階段 N 個 RTT 內的吞吐量（不考慮丟包）:
T = init_cwnd * (2^N-1) * MSS, N = ⌊t / RTT ⌋
Linux內核初始擁塞窗口=10（RFC 6928，April 2013）
首幀100KB，需要4個RTT，如果RTT>250ms，意味着必然無法秒開。在我們舉的這個例子中，如果調整爲32，那麼只需要2個RTT。
圖10. 寬帶速率報告
從2015到2019，固定帶寬翻了4.8倍。從2016到2019，移動寬帶翻了5.3倍。初始擁塞窗口從10調整爲32在合理範圍內。
▐ 卡頓率優化
✎ BBR RTT探測優化
圖11. BBR v1示意圖：ProbeRTT階段
問題
BBR v1的ProbeRTT階段會把inflight降到4*packet並保持至少200ms。會導致傳輸速率斷崖式下跌，引起卡頓
10s進入一次ProbeRTT，無法適應RTT頻繁變化的場景
優化方案
減少帶寬突降：inflight 降到 4*packet 改爲降到 0.75 * Estimated_BDP
加快探測頻率：ProbeRTT進入頻率 10s 改爲 2.5s
推導過程
爲什麼是 0.75x?
Max Estimated_BDP = 1.25*realBDP
0.75 * Estimated_BDP = 0.75 * 1.25 * realBDP = 0.9375* realBDP
保證inflight < realBDP, 確保RTT準確性。
爲什麼是 2.5s?
優化後BBR帶寬利用率：(0.2s * 75% + 2.5s * 100%) / (0.2s+ 2.5s) = 98.1%
原生BBR帶寬利用率：(0.2s * 0% + 10s * 100%) / (0.2s + 10s) = 98.0%
在整體帶寬利用率不降低的情況下，調整到2.5s能達到更快感知網絡變化的效果。
優化效果
保證帶寬利用率不低於原生BBR的前提下，使得發送更平滑，更快探測到RTT的變化。
✎ BBR帶寬探測優化
圖12. BBR v1示意圖：StartUp 和 ProbeBW階段
問題分析
StartUp階段2.89和ProbeBW階段1.25的增益係數導致擁塞丟包，引發卡頓和重傳率升高（Cubic重傳率3%， BBR重傳率4%）重傳導致帶寬成本增加1%。
優化策略
圖13. 帶寬變化示意圖
定義兩個參數：
期望帶寬：滿足業務需要的最小帶寬
最大期望帶寬：能跑到的最大帶寬
未達到期望帶寬時採用較大的增益係數，較激進探測帶寬。
達到期望帶寬後採用較小的增益係數，較保守探測帶寬。
優化效果
成本角度：重傳率由4%降到3%，與Cubic一致，在不增加成本的前提下降低卡頓率。
另外，該策略可以推廣到限速場景，如5G視頻下載限速，避免浪費過多用戶流量。
▐ 卡頓、秒開優化效果
在直播拉流場景下與TCP相比較，高峯期卡頓率降低30%+，秒開率提升2%。
▐ 寫在優化最後的思考
最後，我們看看TCP初始重傳超時和初始擁塞窗口的發展歷程：
初始重傳時間
RFC1122 (October 1989) 爲3s
RFC6298 (June 2011) 改爲1s，理由爲97.5%的連接RTT<1s
初始擁塞窗口
RFC 3390 (October 2002) 爲 min(4 * MSS, max(2 * MSS, 4380 bytes))（MSS=1460時爲3）
RFC 6928 (April 2013) 改爲 min (10 * MSS, max (2 * MSS, 14600))（MSS=1460時爲10）—— 由google提出，理由爲 90% of Google's search responses can fit in 10 segments (15KB).
首先IETF RFC是國際標準，需要考慮各個國家的網絡情況，總會有一些網絡較慢的地區。在TCP的RFC標準中，由於內核態實現不得不面臨一刀切的參數選取方案，需要在考慮大盤分佈的情況下兼顧長尾地區。
對比來看，QUIC作爲用戶態協議棧，其靈活性相比內核態實現的TCP有很大優勢。未來我們甚至有機會爲每個用戶訓練出所在網絡環境最合適的一套最優算法和參數，也許可以稱之爲千人千面的網絡體驗優化：）
Multipath QUIC技術
Multipath QUIC（多路徑QUIC）是當前XQUIC內部正在研究和嘗試落地的一項新技術。
MPQUIC可以同時利用cellular和wifi雙通道進行數據傳輸，不僅提升了數據的下載和上傳速度，同時也加強了應用對抗弱網的能力，從而進一步提高用戶的端到端體驗。此外，由於5G比4G的無線信號頻率更高，5G的信道衰落問題也會更嚴重。所以在5G部署初期，基站不夠密集的情況下如何保證良好信號覆蓋是未來2-3年內手機視頻應用的重大挑戰，而我們研發的MPQUIC將爲這些挑戰提供有效的解決方案。
Multipath QUIC 的前身是MPTCP[6]。MPTCP在IETF有相對成熟的一整套RFC標準，但同樣由於其實現在內核態，導致落地成本高，規模化推廣相對困難。業界也有對MPTCP的應用先例，例如蘋果在iOS內核態實現了MPTCP，並將其應用在Siri、Apple Push Notification Service和Apple Music中，用來保障消息的送達率、降低音樂播放的卡頓次數和卡頓時間。
我們在18年曾與手機廠商合作（MPTCP同樣需要廠商支持），並嘗試搭建demo服務器驗證端到端的優化效果，實驗環境下測試對「收藏夾商品展示耗時」與「直播間首幀播放耗時」降低12-50%不等，然而最終由於落地成本太高並未規模化使用。由於XQUIC的用戶態協議棧能夠大大降低規模化落地的成本，現在我們重新嘗試在QUIC的傳輸層實現多路徑技術。
圖15. Multipath QUIC協議棧模型
Multipath QUIC對於移動端用戶最核心的提升在於，通過在協議棧層面實現多通道技術，能夠在移動端同時複用Wi-Fi和蜂窩移動網絡，來達到突破單條物理鏈路帶寬上限的效果；在單邊網絡信號強度弱的情況下，可以通過另一條通道補償。適用的業務場景包括上傳、短視頻點播和直播，可以提升網絡傳輸速率、降低文件傳輸耗時、提升視頻的秒開和卡頓率。在3GPP Release 17標準中也有可能將MPQUIC引入作爲5G標準的一部分[7]。
技術層面上，和MPTCP不同，我們自研的MPQUIC採取了全新的算法設計，這使得MPQUIC相比於MPTCP性能更加優化，解決了slow path blocking問題。在弱網中的性能比以往提升30%以上。
圖16. 弱網下相對單路徑的文件平均下載時間降低比例（實驗數據）
圖17. 弱網下相對單路徑的視頻播放卡頓率降低比例（實驗數據）
在推進MPQUIC技術落地的過程中，我們將會嘗試在IETF工作組推進我們的方案作爲MPQUIC草案的部分內容[8]。期望能夠爲MPQUIC的RFC標準制定和落地貢獻一份力量。
下一步的未來
我們論證了QUIC的核心優勢在於用戶態的傳輸層實現（面向業務場景具備靈活調優的能力），而非單一針對弱網的優化。在業務場景的擴展方面，除了RPC、短視頻、直播等場景外，XQUIC還會對其他場景例如上傳鏈路等進行優化。
在5G逐步開始普及的時代背景下，IETF QUIC工作組預計也將在2020年底左右將QUIC草案發布爲RFC標準，我們推測在5G大背景下QUIC的重要性將會進一步凸顯。
▐ QUIC/MPQUIC對於5G
對於5G下eMBB（Enhanced Mobile Broadband）和URLLC（Ultra Reliable Low Latency）帶來的不同高帶寬/低延遲業務場景，QUIC將能夠更好地發揮優勢，貼合場景需求調整傳輸策略（擁塞控制算法、ACK/重傳策略）。對於5G運營商提供的切片能力，QUIC同樣可以針對不同的切片適配合適的算法組合，使得基礎設施提供的傳輸能力能夠儘量達到最大化利用的效果。在XQUIC的傳輸層實現設計中，同樣預留了所需的適配能力。
在5G推廣期間，在基站部署不夠密集的情況下，保障穩定的有效帶寬將會是音視頻類的應用場景面臨的巨大挑戰。Multipath QUIC技術能夠在用戶態協議棧提供有效的解決方案，然而這項新技術仍然有很多難點需要攻克，同時3GPP標準化組織也在關注這一技術的發展情況。
▐ XQUIC開源計劃
阿里淘系技術架構團隊計劃在2020年底開源XQUIC，期望能夠幫助加速IETF標準化QUIC的推廣，並期待更多的開源社區開發者參與到這個項目中來。
附錄：參考文獻
[1] SPDY - HTTP/2.0原型，由Google主導的支持雙工通信的應用層協議
[2] HTTP/2.0 - https://tools.ietf.org/html/rfc7540
[3] TLS/1.3 - https://tools.ietf.org/html/rfc8446
[4] GQUIC - 指Google QUIC版本，與IETF QUIC草案版本有一定差異
[5] IETF QUIC - 指IETF QUIC工作組正在推進的QUIC系列草案：https://datatracker.ietf.org/wg/quic/documents/，包括QUIC-Transport、QUIC-TLS、QUIC-recovery、HTTP/3.0、QPACK等一系列草案內容
[6] MPTCP - https://datatracker.ietf.org/wg/mptcp/documents/
[7] 3GPP向IETF提出的需求說明 https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00
[8] MPQUIC - 我們正在嘗試推進的草案 https://datatracker.ietf.org/doc/draft-an-multipath-quic-application-policy/
複雜環境下的網絡優化
用戶最終的極致視頻體驗，其中問題絕不止「複雜網絡」一詞可以概括，基礎設施相對落後、網絡情況複雜、移動端設備性能參差不齊都會直接影響到用戶對於視頻的直觀感受，想要提供良好的視頻服務也絕非易事。本次LiveVideoStackCon 2020 北京站我們也將邀請講師討論網絡端的優化問題，點擊【閱讀原文】可瞭解更多講師及話題信息。
LiveVideoStackCon 2020 北京
2020年10月31日-11月1日
點擊【閱讀原文】瞭解更多講師及話題信息
