面向5G的阿裡自研标準化協定庫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 降到 4packet 改為降到 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

[3]

TLS/1.3

[4] GQUIC - 指Google QUIC版本，與IETF QUIC草案版本有一定差異

[5]

IETF QUIC - 指IETF QUIC工作組正在推進的QUIC系列草案：

包括QUIC-Transport、QUIC-TLS、QUIC-recovery、HTTP/3.0、QPACK等一系列草案内容

[6]

MPTCP

[7]

3GPP向IETF提出的需求說明

[8]

MPQUIC - 我們正在嘗試推進的草案

淘系架構與基礎服務團隊

緻力于為淘系和阿裡提供基礎核心能力、産品與解決方案：

• 下一代網絡協定QUIC的實作與落地 - XQUIC

• 自适應高可用解決方案與核心能力 - Noah

• 新一代業務研發模式平台 - Gaia

• 支撐整個阿裡的移動中間件體系（千萬級QPS接入網關、API網關、推送/消息、移動配置中心等）

團隊大牛雲集~~ 想要加入我們，請郵件履歷至：[email protected]

關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~