Back to basic, 自主创新标准实践, 开放共创卓越工程!(by 大淘宝技术研究员长恭)
开源地址: https://github.com/alibaba/xquic
XQUIC是什么?
XQUIC 是阿里自研的 IETF QUIC 标准化传输协议库。XQUIC是基于 IETF QUIC 协议实现的 UDP 传输框架, 包含加密可靠传输、 HTTP/3 两大块主要内容, 为应用提供可靠、安全、高效的数据传输功能, 可以极大改善弱网和移动网络下产品的用户网络体验。这项技术研发由大淘宝平台技术团队发起和主导, 当前有达摩院 XG 实验室、 阿里云 CDN 等多个团队参与其中。
现今 QUIC 有多家开源实现, 为什么选择标准协议 + 自研实现的道路? 我们从 14 年开始关注 Google 在 QUIC 上的实践(手机淘宝在 16 年全面应用 HTTP/2), 从 17 年底开始跟进并尝试在电商场景落地 GQUIC, 在 18 年底在手淘图片、 短视频等场景落地 GQUIC 并拿到了一定的网络体验收益。然而在使用开源方案的过程中, 或多或少碰到了一些问题, 例如包大小过大、 依赖复杂等等。最终促使我们走上自研实现的道路。
为什么要选择 IETF QUIC 标准化草案的协议版本? 过去我们也尝试过自研私有协议, 在端到端都由内部控制的场景下, 私有协议的确是很方便的, 并且能够跟随业务场景的需求快速迭代演进;但私有协议方案很难走出去建立一个生态圈 / 或者与其他的应用生态圈结合(遵循相同的标准化协议实现互联互通);另一方面从云厂商的角度, 私有协议也很难与外部客户打通;同时由于 IETF 开放讨论的工作模式, 协议在安全性、 扩展性上会有更全面充分的考量。因此我们选择 IETF QUIC 标准化草案版本来落地。截止目前, IETF 工作组已经发布 QUIC v1 版本 RFC, XQUIC 已经支持该版本, 并能够与其他开源实现基于 QUIC v1 互通。
XQUIC的优势

XQUIC 是一个轻量、高性能、标准化的跨平台协议库:
轻量性:
- XQUIC 在 Android/iOS 双端的编译产物均小于 400KB
- 除 TLS/1.3 能力依赖 SSL 库之外, 无其他外部依赖, 可以方便地部署到移动设备和各种嵌入式设备中
- 适用于需要高性能但同时又对包大小敏感的移动端 APP 场景(为了减少新用户的安装成本, 移动端 APP 希望能尽量减少 APP 包大小)
高性能传输:
- XQUIC 已经在手机淘宝实现核心导购、短视频链路大规模使用, 并相对于内核态 TCP+HTTP/2 优化 20% 的网络请求耗时
- 支持 0-RTT 功能
- 支持多通道传输加速能力
标准化:
- 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 日志标准。

拥塞控制算法框架

拥塞控制算法模块, 在传输协议栈中承担了发动机的职能。为了能够方便地实现多套拥塞控制算法、并方便针对各类典型场景进行优化, 我们将拥塞控制算法流程抽象成 7 个回调接口, 其中最核心的两个接口 onAck 和 onLost 用于让算法实现收到报文 ack 和检测到丢包时的处理逻辑。XQUIC 内部实现了多套拥塞控制算法, 包括最常见的 Cubic、New Reno, 以及时下比较流行的 BBR v1 和 v2, 每种算法都只需要实现这 7 个回调接口即可实现完整算法逻辑。
为了方便用数据驱动网络体验优化, 我们将连接的丢包率、RTT、带宽等信息通过采样和分析的方式, 结合每个版本的算法调整进行效果分析。同时在实验环境下模拟真实用户的网络环境分布, 更好地预先评估算法调整对于网络体验的改进效果。
传输层能力和应用协议协商
XQUIC 提供两套接口, 分别是使用标准 HTTP3 的 7 层接口和直接使用传输层能力的 4 层接口, 同时 XQUIC 支持 ALPN 协商机制, 可以通过向 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 草案正处于即将被 IETF QUIC Working Group 接收的流程中, 并且 WG draft 版本与 XQUIC 前期支持的多路径版本有部分差异, 因此我们暂时在开源版本去掉了这部分功能。后续我们将在 2 月份基于 Working Group 草案版本更新多路径功能。
性能优化方面:
- UDP 性能优化 feature
- XUDP 适配支持
跨平台支撑方面:
配套工具方面:
文档及中文资料:
- 开源仓库已经提供了基于 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/wg/quic/documents/, 包括 RFC8999~9002, 以及还在推进中的 HTTP/3.0、QPACK 等一系列内容
[4] QUIC v1: RFC8999~9002 所描述的 QUIC 协议版本
[5] MPQUIC: 即将被 IETF QUIC WG 工作组接收的草案 https://datatracker.ietf.org/doc/draft-lmbdhk-quic-multipath/
[6] ALPN 协商: https://datatracker.ietf.org/doc/html/rfc7301
XQUIC 团队隶属于大淘宝平台技术-移动技术中台团队, 希望能通过网络技术演进给用户带来更丝滑的体验。如果对 XQUIC、网络技术、高性能网络传输等领域比较感兴趣, 欢迎关注我们的 GitHub 仓库:
https://github.com/alibaba/xquic
了解更多关于网络协议和前沿技术,欢迎访问云栈社区的网络/系统板块,与更多开发者交流学习。