原創 XLINK項目組 淘系技術 5月11日
綜述
你是否曾經經曆過
（1）當你看視訊刷劇刷的正嗨，突然發現視訊變得很卡, 怎麼重連也沒有用？（2）當你打着語音電話從商場走向停車場，電話一下子就斷了，必須要撥号重連？
（3）當你想要争分奪秒地在高速上辦公，但是發現郵件怎麼也發不出去？
上述問題的産生都可以歸結為一個問題，那就是“弱網”。由于無線網絡天生的頻譜限制，無線信号的覆寫不足，多使用者間的互相競争資源，高移動場景下頻繁的基站切換等等， 都可能導緻“弱網”的頻發。克服弱網對于使用者的體驗至關重要。為此， 阿裡巴巴淘系技術部淘系架構團隊與達摩院XG實驗室共同研發了XLINK多路傳輸技術。XLINK使淘寶的使用者可以同時使用多路徑（5G/4G，WiFi）進行傳輸資料， 從根本上解決了由單路徑弱網帶來的使用者體驗問題。XLINK基于阿裡巴巴提出的IETF多路徑Multipath QUIC草案[1]，該草案也是目前唯一一個經過大規模實踐檢驗的Multipath QUIC标準草案。
QUIC技術是由Google提出，谷歌于2017年在SIGCOMM會議上發表了QUIC相關論文并引起了業界的巨大反響今年IETF QUIC 1.0标準工作即将正式完成，下一代HTTP協定HTTP3正是基于QUIC來實作的。可以說，QUIC是目前移動網際網路中最核心和關鍵的傳輸技術，現如今，超過50％的Chrome浏覽器流量和75％的Facebook流量都在使用QUIC進行傳輸。經過過去幾年的不懈努力，阿裡巴巴從QUIC技術的追随者快速成長為QUIC技術的創新者，并在多路徑QUIC技術上取得了突破，XLINK相關論文已經被頂級學術會議SIGCOMM 2021正式接收，這也是SIGCOMM會議曆史上第一篇關于多路徑QUIC的文章。
XLINK 相關文章論文參考：Zhilong Zheng†, Yunfei Ma†, Yanmei Liu†, Furong Yang, Zhenyu Li, Yuanbo Zhang, Jiuhai Zhang, Wei Shi, Wentao Chen, Ding Li, Qing An, Hai Hong, Hongqiang Harry Liu, and Ming Zhang, XLINK: QoE-driven multi-path QUIC transport in large-scale video services, to appear in SIGCOMM 2021. （†表示共同一作）
XLINK基于阿裡巴巴提出的IETF多路徑（Multipath）QUIC草案架構實作，該草案由淘系架構與XG實驗室主導、與集團标準化部、中科院計算所，以及原Internet Architecture Board的主席Christian Huitema進行了深度論證與合作，也是目前唯一一個經過大規模實踐檢驗的Multipath QUIC标準草案。
XLINK基于阿裡巴巴提出的IETF多路徑（Multipath）QUIC草案參考：
Yanmei Liu, Yunfei Ma, Christian Huitema, Qing An, and Zhenyu Li. Multipath Extension for QUIC, Internet Engineering Task Force, December 2020. Work in Progress.
https://tools.ietf.org/html/draft-liu-multipath-quic-03多路徑技術：學術界、工業界長達十年的探索
使用兩條路徑同時傳輸， 這個想法聽起來很簡單， 可是做起來卻很難。目前業界成功僅有的比較成功部署多路徑傳輸的是Apple的Siri、Apple Music等場景（蘋果采用的是MPTCP RFC6824， 該協定于2013年被IETF标準化），這些應用都是音頻(Audio)類，它們主要是利用多路徑增加傳輸的魯棒性。但過去在業界視訊應用(Video)或者實時類的音視訊類(Real-time Video)應用上，對多路傳輸技術的大規模應用是極少見的，因為這類場景對于資料的帶寬速率和時延都有着非常苛刻的要求。而在無線網絡中， 路徑品質的變化是很快的， 過去的多路徑協定和排程算法在高速變化的場景下會發生明顯的失速現象。在XLINK之前，多路徑傳輸在音視訊方面遲遲無法得到施展，學術界也為此奮鬥了很多年，大家提出了很多基于MPTCP的優化方案， 但是目前沒有一個方案可以完全解決存在着如下幾個本質缺陷：
- 核心實作、無法為應用場景提供定制優化：音視訊應用有一個特點， 那就是不同應用間的體驗目标（QoS）差異非常大，需要的傳輸協定和算法也很不一樣。比如短視訊應用（手淘短視訊）注重秒開率，高清長視訊應用（優酷）對于帶寬要求高，視訊會議, 直播（釘釘，手淘直播）更在意延遲和流暢度。這些差異巨大的應用場景需求，需要傳輸算法和協定針對應用自身的QoS需求做特殊優化，可是MPTCP位于作業系統核心的網絡協定棧，所有應用都使用同一套算法，這就導緻衆口難調，同時傳輸協定和排程算法的優化疊代也非常困難。
- 異構網絡：MPTCP的多路聚合效果并不理想，由于在公網上傳輸多路徑是異構的，5G/LTE和Wi-Fi的時延差異較大，此時就會發生多路徑的隊頭阻塞問題（MP-HOL）[2]。MP-HOL阻塞問題是指，當一部分資料包走慢路徑，一部分資料包走快路徑的時候，快路徑的包會先抵達，但是要等待慢路徑包到達以後才能傳給應用，造成延遲增加，部分情況下甚至會比兩條路徑中品質較好的單路更差。更大的挑戰在于無線鍊路的變化很快，是以目前的帶寬預測是很難做到十分準确（在無線場景下我們很難預知下一秒的帶寬情況）。是以基于帶寬預測的排程算法在長尾問題上面頻繁的折戟沉沙。
- 流量成本：為了克服異構網絡問題，有一些多路徑傳輸方案選擇發送備援包（将同樣的資料包在兩條路徑上重複發送）去避免多路隊頭阻塞問題， 但是又引入了兩個新問題：1.重複發送資料包會極大的增加額外的資料流量成本。這個對于視訊應用來說會帶來高額的帶寬成本，這也是為什麼Apple也隻在Siri等對于流量要求不大的音頻場景中使用MPTCP。2.備援資料包也會占用帶寬資源，這又降低了整體的帶寬利用效率。
其它的多路徑方案比如MPUDP和MPRTP目前也有各自的困難與局限。首先UDP不保證資料包傳遞的可靠性， 是以多路的時延不同會給上層應用帶來大量的亂序包， 并且UDP也不對丢包進行恢複， 是以目前幾乎很少被使用。MPRTP自提出以來一直沒有被真正大規模落地[6]，原因是MPRTP在将資料包配置設定到各個路徑時，依賴于各路徑的帶寬和時延精确估計，可是除非擁有大量實體層資訊，LTE信号的預測本身就是一個非常難以解決的問題。
XLINK：使用者體驗驅動的（QoE-driven）的多路徑方案
▐ 為什麼叫XLINK？
XLINK（= X+LINK），本意為通過多條路徑連結（LINK），其中X代表一個未知數，也代表在阿裡巴巴不斷探索未知領域。XLINK技術基于QUIC協定在使用者态實作了WiFi/LTE/5G的多路徑并行傳輸，有效提升傳輸帶寬， 大幅度降低傳輸時延與卡頓率，在高移動性場景展現出優秀的傳輸穩定性。與此同時，XLINK也是全球首個在大規模視訊場景部署與驗證的多路徑QUIC通信協定。XLINK的使用非常友善，XLINK實作在使用者态協定棧XQUIC[3]中，支援Android/iOS/Linux等平台部署，對于移動端app開發者來說隻需要內建XQUIC協定庫便可以使用XLINK技術，對于使用者來說隻需要更新app就可以享受到多路徑傳輸帶來的體驗收益[4]。
為了突破單路徑傳輸的根本限制，并解決MPTCP等多路徑協定在過去實踐中遇到的各種落地問題， 我們開發了XLINK。XLINK與之前所有多路徑技術最大的不同是，它直接利用應用的QoE資訊實作路徑的選擇、切換與排程政策。從技術角度來說， XLINK突破了傳統多路徑協定的設計架構，在QUIC使用者态特性的基礎之上， 提出了Client-Server QoE回報驅動多傳輸排程方案， 克服了過去十多年困擾多路徑協定（比如MPTCP, MPUDP & MPRTP[5]）在實際公網部署的兩大難題：
- 多路隊頭阻塞問題帶來的傳輸失速和聚合效率降低的問題
- 備援資料包發送引入的高昂額外帶寬成本與流量開銷
XLINK的整體架構如圖1所示， 具有以下幾個特點：
Fig.1. XLINK整體方案架構
- 使用者态部署：XLINK工作在使用者态，內建在App當中并在UDP之上實作了資料的可靠傳輸與擁塞控制。它伴随應用快速部署與疊代，即插即用。XLINK的手機端的應用可以做到以周為機關更新，XLINK服務端的應用和算法更新可做到天或小時為粒度。由于XLINK實作在使用者态協定棧中，與app內建在一起，是以XLINK可以直接針對不同的應用做定制化優化。
- 高性能：XLINK利用視訊應用的QoE回報作為排程器的控制信号，QoE信号可以包含多種與使用者體驗相關的參數，通過這個QoE回報控制排程器， XLINK成功克服了MP-HoL所帶來的性能和成本問題， 使多路徑技術在大規模視訊應用中的使用變得可行。XLINK進行多路徑排程時， 并不需要對于路徑的帶寬和時延作精确的估計， 而是采取了資料包重注入(Reinjection)的自适應補償方法， 讓資料包自适應的在多條路徑上實作均衡。此外， XLINK通過對于使用者QoE的了解，可以進一步優化使用者體驗。比如，XLINK可以針對短視訊的首幀進行特殊優化，降低使用者的首幀下載下傳時間，進而提升使用者的秒開率。
- 低成本：XLINK的排程算法不僅可以克服MP-HoL所帶來的性能問題， 而且幾乎不增加額外的資料量，QoE的回報幫助XLINK調節重注入的力度， 達到最優的性能與成本之間的平衡， 是以碼率很高的視訊應用也可以放心的大規模使用多路徑傳輸而不用擔心其流量成本問題。
- 輕量化：XLINK完全基于C語言開發（在XQUIC使用者态協定棧中實作），XQUIC總體的包大小隻有300+KB，非常适合各種移動終端的使用。
手淘落地效果
XLINK已經集在在手淘完成了大規模灰階驗證，測試結果表明，XLINK在弱網下使用可以實作短視訊分片平均下載下傳耗時減少15.03%，視訊分片下載下傳弱網耗時降低25.28%[5]。此外，在旅途中，XLINK的使用者可以同時利用WiFi熱點與手機LTE， 在高移動性場景下仍然保持流暢的視訊觀看體驗。
XLINK手淘Demo展示：
下面的視訊展示了XLINK內建在手淘裡的使用效果，左邊的應用使用打開了WiFi與LTE的XLINK，右邊的應用使用打開了單路徑WiFi的QUIC；可以看出XLINK起播更快，而且全程播放流暢，而單路徑的case在播放過程中由于WiFi網絡抖動，産生了明顯示卡頓。
展望未來
達摩院XG實驗室與淘系技術合作研發的多路徑QUIC技術XLINK，該技術不但在手淘短視訊等場景有很好的體驗優化效果——在弱網條件下短視訊下載下傳時間可降低25%以上；今年開始逐漸全量手淘短視訊和手淘逛逛——而且多路徑QUIC草案也在IETF QUIC工作組受到廣泛關注。随着XLINK不斷在國際舞台被同行認可，可以說XLINK目前在技術領先性、國際标準的制定、内部業務賦能方面，都取得了振奮人心的成績。
我們處在通往5G與邊緣計算的時代的關鍵節點， 随之而來的網絡架構和技術将會産生革命性的變化。5G将進一步加速大資料、人工智能、海量存儲等多元化、端計算與邊緣計算業務與應用技術的爆發式增長。由此可推斷，無線網絡作為這些新型業務的入口，勢必會再次迎來技術變革，邁向高性能、高穩定、高靈活的新一代網絡，以響應這些新型業務。
同時，伴随着視訊應用的不斷豐富和視訊QoS需求的異構化， 曾經的一套傳輸層适配所有應用的做法難以達到更好的QoE，以QUIC為代表的使用者态協定棧通過與視訊應用聯合優化，可以實作曾經核心協定棧無法達到的極緻的效果。XLINK通過将QoE與多路徑結合，證明了這種協同效果的強大威力。後面我們也會進一步推動XLINK相關技術在IETF的标準化，同時也期待XLINK技術可以更好的服務阿裡巴巴的使用者。
附錄
[1] Multipath QUIC草案:
[2] MP-HOL阻塞問題：指Multi-path Head-of-line blocking問題
[3] XQUIC是阿裡自研的IETF QUIC标準化協定庫
[4] 由使用者決定是否開啟和關閉
[5] 這裡弱網統計指視訊分片的p99分位長尾下載下傳耗時
[6] Singh, Varun, Saba Ahsan, and Jörg Ott. "MPRTP: multipath considerations for real-time media."Proceedings of the 4th ACM Multimedia Systems Conference. 2013.