作者：雲飛、喵吉、之有、洪強
阿里巴巴淘系技術部與達摩院XG實驗室共同研發的XLINK多路傳輸技術，相關論文「XLINK: QoE-driven multi-path QUIC transport in large-scale video services」已經被頂級學術會議SIGCOMM 2021正式接收， 這也是SIGCOMM會議歷史上第一篇關於多路徑QUIC的論文。
綜 述
你是否曾經經歷過：
（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.
多路徑技術：學術界、工業界長達十年的探索
使用兩條路徑同時傳輸， 這個想法聽起來很簡單， 可是做起來卻很難。目前業界成功僅有的比較成功部署多路徑傳輸的是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所示， 具有以下幾個特點：
- 使用者態部署： 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網路抖動，產生了明顯示卡頓。
視訊可見：SIGCOMM 首篇 Multi-path QUIC 論文：阿里自研多路徑傳輸技術XLINK
展望未來
達摩院XG實驗室與淘系技術合作研發的多路徑QUIC技術XLINK，該技術不但在手淘短視訊等場景有很好的體驗優化效果——在弱網條件下短視訊下載時間可降低25%以上；今年開始逐步全量手淘短視訊和手淘逛逛——而且多路徑QUIC草案也在IETF QUIC工作組受到廣泛關注。隨著XLINK不斷在國際舞臺被同行認可，可以說XLINK目前在技術領先性、國際標準的制定、內部業務賦能方面，都取得了振奮人心的成績。
我們處在通往5G與邊緣計算的時代的關鍵節點， 隨之而來的網路架構和技術將會產生革命性的變化。5G將進一步加速大資料、人工智慧、海量儲存等多元化、端計算與邊緣計算業務與應用技術的爆發式增長。由此可推斷，無線網路作為這些新型業務的入口，勢必會再次迎來技術變革，邁向高效能、高穩定、高敏捷的新一代網路，以響應這些新型業務。
同時，伴隨著視訊應用的不斷豐富和視訊QoS需求的異構化， 曾經的一套傳輸層適配所有應用的做法難以達到更好的QoE，以QUIC為代表的使用者態協議棧通過與視訊應用聯合優化，可以實現曾經核心協議棧無法達到的極致的效果。XLINK通過將QoE與多路徑結合，證明了這種協同效果的強大威力。後面我們也會進一步推動XLINK相關技術在IETF的標準化，同時也期待XLINK技術可以更好的服務阿里巴巴的使用者。
附錄
[1] Multipath QUIC草案: https://tools.ietf.org/html/d...
[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.
關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！