爲何愈來愈多的團隊投入QUIC協議自研實現？來自阿里巴巴淘系技術的劉彥梅的投稿很好的解釋了背後的緣由——提供更好的靈活性。同時，遵照標準的IETF QUIC也讓研發投入能產生長期回報。劉彥梅介紹了XQUIC的前生今世，以及將來的開源計劃。
XQUIC是阿里巴巴淘系架構團隊自研的IETF QUIC標準化協議庫實現，在手機淘寶上進行了普遍的應用，並在多個不一樣類型的業務場景下取得明顯的效果提高，爲手機淘寶APP的用戶帶來絲般順滑的網絡體驗：
html
在RPC請求場景，網絡耗時下降15%web
在直播高峯期場景，卡頓率下降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個巨大的優點：app
(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 北京站咱們也將邀請講師討論網絡端的優化問題，點擊【閱讀原文】可瞭解更多講師及話題信息。
點擊【閱讀原文】瞭解更多講師及話題信息
本文分享自微信公衆號 - LiveVideoStack（livevideostack）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。