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