阿里自研標準化協議庫 XQUIC 正式開源！

阿里巴巴移動技術發表於2022-01-08
阿里協議UI

開源地址：https://github.com/alibaba/xquic

XQUIC 是什麼？

XQUIC[1]是阿里自研的IETF QUIC標準化傳輸協議庫。XQUIC是基於IETF QUIC協議實現的UDP傳輸框架，包含加密可靠傳輸、HTTP/3兩大塊主要內容，為應用提供可靠、安全、高效的資料傳輸功能，可以極大改善弱網和行動網路下產品的使用者網路體驗。這項技術研發由大淘寶平臺技術團隊發起和主導，當前有達摩院XG實驗室、阿里雲CDN等多個團隊參與其中。

現今QUIC有多家開源實現，為什麼選擇標準協議 + 自研實現的道路？我們從14年開始關注Google在QUIC上的實踐（手機淘寶在16年全面應用HTTP/2），從17年底開始跟進並嘗試在電商場景落地GQUIC[2]，在18年底在手淘圖片、短視訊等場景落地GQUIC並拿到了一定的網路體驗收益。然而在使用開源方案的過程中，或多或少碰到了一些問題，例如包大小過大、依賴複雜等等。最終促使我們走上自研實現的道路。

為什麼要選擇IETF QUIC[3]標準化草案的協議版本？過去我們也嘗試過自研私有協議，在端到端都由內部控制的場景下，私有協議的確是很方便的，並且能夠跟隨業務場景的需求快速迭代演進；但私有協議方案很難走出去建立一個生態圈 / 或者與其他的應用生態圈結合（遵循相同的標準化協議實現互聯互通）；另一方面從雲廠商的角度，私有協議也很難與外部客戶打通；同時由於IETF開放討論的工作模式，協議在安全性、擴充套件性上會有更全面充分的考量。因此我們選擇IETF QUIC標準化草案版本來落地。截止目前，IETF工作組已經發布QUIC v1版本[4]RFC，XQUIC已經支援該版本，並能夠與其他開源實現基於QUIC v1互通。

XQUIC 的優勢

XQUIC是一個輕量、高效能、標準化的跨平臺協議庫：

輕量性：

  • XQUIC在Android/iOS雙端的編譯產物均小於400KB
  • 除TLS/1.3能力依賴SSL庫之外，無其他外部依賴，可以方便地部署到移動裝置和各種嵌入式裝置中
  • 適用於需要高效能但同時又對包大小敏感的移動端APP場景（為了減少新使用者的安裝成本，移動端APP希望能儘量減少APP包大小）

高效能傳輸：

  • XQUIC已經在手機淘寶實現核心導購、短視訊鏈路大規模使用，並相對於核心態TCP+HTTP/2優化20%的網路請求耗時
  • 支援0-RTT功能
  • 支援多通道傳輸加速能力[5]

標準化：

  • XQUIC實現了整套IETF QUIC標準協議，包含傳輸層、加密層、應用層協議棧
  • 協議版本支援QUIC version 1，以及draft-29
  • SSL庫相容適配BoringSSL或BabaSSL（可任意選擇其中之一）

易用性：

  • 跨平臺：支援Linux/Android/iOS/Mac等平臺，後續也會支援Windows平臺適配，客戶端可以通過SDK方式很方便地接入並使用。
  • 支援Wireshark解析、qlog事件日誌標準，方便問題排查
  • 完善的文件（中文/英文對照）、demo示例和單測

XQUIC核心介紹

模組設計

XQUIC是IETF QUIC草案版本的一個C協議庫實現，端到端的整體鏈路架構設計如下圖所示。XQUIC內部包含了QUIC-Transport（傳輸層）、QUIC-TLS（加密層、與TLS/1.3對接）和HTTP/3.0（應用層）的實現。除了每層的協議棧功能模組之外，在公共模組部分，XQUIC也支援了qlog[5]日誌標準。

擁塞控制演算法框架

擁塞控制演算法模組，在傳輸協議棧中承擔了發動機的職能。為了能夠方便地實現多套擁塞控制演算法、並方便針對各類典型場景進行優化，我們將擁塞控制演算法流程抽象成7個回撥介面，其中最核心的兩個介面onAck和onLost用於讓演算法實現收到報文ack和檢測到丟包時的處理邏輯。XQUIC內部實現了多套擁塞控制演算法，包括最常見的Cubic、New Reno，以及時下比較流行的BBR v1和v2，每種演算法都只需要實現這7個回撥介面即可實現完整演算法邏輯。

為了方便用資料驅動網路體驗優化，我們將連線的丟包率、RTT、頻寬等資訊通過取樣和分析的方式，結合每個版本的演算法調整進行效果分析。同時在實驗環境下模擬真實使用者的網路環境分佈，更好地預先評估演算法調整對於網路體驗的改進效果。

傳輸層能力和應用協議協商

XQUIC提供兩套介面，分別是使用標準HTTP3的7層介面和直接使用傳輸層能力的4層介面，同時XQUIC支援ALPN[6]協商機制，可以通過向ALPN介面註冊新的應用層協議回撥，並通過握手期間的協商實現多套應用層協議的相容。

7層協議的擴充套件能力和易用性： XQUIC的介面中，將QUIC Transport事件歸類為通用傳輸層事件和麵嚮應用層協議的事件。連線會話、Stream事件面向Application-Layer-Protocol定義；而剩餘的通用傳輸層事件，因為在不同的應用層協議之間，具備高度共性，可以複用。這種設計保證了在擴充套件多種7層協議的時候，開發者只需要關注7層協議對於連線會話、Stream資料的處理，而不需要重複對QUIC傳輸層通用事件進行開發。

TLS層設計

QUIC Transport層，對TLS模組有如下依賴：加密握手協商、資料加解密、金鑰更新、session resumption、0-RTT、傳輸引數、ALPN協商。TLS層，則需要依賴底層SSL庫，來支撐上述功能。因此，TLS模組存在資料的多樣性，以及依賴的多樣性，資料流程和程式碼結構會比較複雜。TLS層需要對這些資料流進行歸類整理，從而來簡化上下游的依賴關係，降低程式碼的複雜度。

XQUIC適配了babassl、boringssl兩種底層的ssl庫，向上提供統一的介面，從而消除了它們之間介面、流程的差異，並抽象為統一的內部資料流程，僅針對不同ssl庫提供輕薄的適配層，減少重複適配的程式碼邏輯，達到降低程式碼複雜度、提升可維護性的效果。同時XQUIC也提供了編譯選項，方便開發者根據自身應用的情況，選擇適合自己的依賴庫。

XQUIC開源歷史

為什麼要做XQUIC

我們從18年左右，開始探索從TCP轉向UDP方向，最早是基於GQUIC，主要應用在手淘的圖片和短視訊等內容分發的場景。在18年底19年初，當時大家有一個共同的判斷是要走標準化道路，一方面整個標準化協議的設計和安全性都有更完備的考量，另一方面是因為從網路加速產品角度，私有協議解決方案更難被使用者認可。在決定選擇標準化道路之後，當時市面上也沒有特別成熟並適用於移動端的IETF QUIC協議棧實現，所以手淘就啟動了自研XQUIC專案。

經過1年半的研發和打磨，於20年的6月份開始全面上線，並在20年8月在手淘核心導購RPC請求場景進行規模化驗證。在21年初與CDN IETF QUIC產品實現對接，並在短視訊場景上開始逐步應用IETF QUIC技術。在去年的9月份我們實現了IETF QUIC整套協議棧在短視訊場景下的規模化應用。之後，我們經歷了2021年雙十一的考驗，XQUIC的效能和穩定性都有了很好的驗證，因此在今年的1月7號，我們完成XQUIC的對外開源，後續也將持續更新迭代開源版本。

我們為什麼要開源XQUIC

通過開源可以幫助整個社群更好地瞭解這項技術，可以幫助我們改進，同時可以通過社群的影響力對這項技術加以推廣。社群的反饋也能夠幫助我們吸收更多的需求場景輸入，幫助我們更好地迭代這項技術。我們期望XQUIC在服務於淘寶技術的同時積極回饋社會，也歡迎網路技術研發的愛好者加入開源社群與我們交流。

應用場景和效果

目前，XQUIC已經在手淘Android/iOS雙端正式版本、以及集團統一接入閘道器大規模應用，比如我們開啟手機淘寶的首頁，或是搜尋我們感興趣的商品，或是開啟逛逛瀏覽達人的視訊，XQUIC都為這些場景提供更快的網路資料傳輸，每天穩定為超過百億量級的網路請求提供端到端加速能力。在2021年的雙十一購物節中，XQUIC在核心導購鏈路、短視訊場景下也經過了大規模驗證。

後續Roadmap

我們計劃每1~2個月釋出一個穩定版本，當前計劃如下：

新功能特性方面：

  • 互通性功能補充，包括Key update、Retry以及ECN
  • WG draft版本的多路徑功能支援
  • 適配開源Tengine的module支援
  • 非可靠傳輸datagram支援
  • Masque特性支援

由於當前Multi-path QUIC[5]草案正處於即將被IETF QUIC Working Group接收的流程中，並且WG draft版本與XQUIC前期支援的多路徑版本有部分差異，因此我們暫時在開源版本去掉了這部分功能。後續我們將在2月份基於Working Group草案版本更新多路徑功能。

效能優化方面：

  • UDP效能優化feature
  • XUDP適配支援

跨平臺支撐方面：

  • windows平臺支援

配套工具方面：

  • 網路效能測量工具

文件及中文資料：

  • 開源倉庫已經提供了基於draft-34校訂的草案中文翻譯，後續會陸續更新RFC8999-9002的中文譯版

附錄：

[1] XQUIC: https://github.com/alibaba/xquic

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

[3] IETF QUIC: 指IETF工作組推進的QUIC標準 https://datatracker.ietf.org/...，包括RFC8999~9002，以及還在推進中的HTTP/3.0、QPACK等一系列內容

[4] QUIC v1: RFC8999~9002所描述的QUIC協議版本

[5] MPQUIC: 即將被IETF QUIC WG工作組接收的草案 https://datatracker.ietf.org/...

[6] ALPN協商: https://datatracker.ietf.org/...

團隊介紹

XQUIC團隊隸屬於大淘寶平臺技術-移動技術中臺團隊，希望能通過網路技術演進給使用者帶來更絲滑的體驗。如果對XQUIC、網路技術、高效能網路傳輸等領域比較感興趣，歡迎點選“閱讀原文”關注我們的 GitHub 倉庫：

https://github.com/alibaba/xquic

如果在使用XQUIC相關產品中遇到問題，歡迎加入XQUIC社群釘釘群反饋&交流：

圖片

如果你想加入我們，歡迎投遞簡歷至miaoji.lym#alibaba-inc.com（投遞簡歷時請把#換成@）

關注【阿里巴巴移動技術】微信公眾號，每週 3 篇移動技術實踐&乾貨給你思考！

相關文章