关于quic:阿里自研标准化协议库-XQUIC-正式开源

开源地址 ：https://github.com/alibaba/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 在 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 是 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 传输层通用事件进行开发。

QUIC Transport 层，对 TLS 模块有如下依赖：加密握手协商、数据加解密、密钥更新、session resumption、0-RTT、传输参数、ALPN 协商。TLS 层，则须要依赖底层 SSL 库，来撑持上述性能。因而，TLS 模块存在数据的多样性，以及依赖的多样性，数据流程和代码构造会比较复杂。TLS 层须要对这些数据流进行归类整顿，从而来简化上下游的依赖关系，升高代码的复杂度。

XQUIC 适配了 babassl、boringssl 两种底层的 ssl 库，向上提供对立的接口，从而打消了它们之间接口、流程的差别，并形象为对立的外部数据流程，仅针对不同 ssl 库提供轻薄的适配层，缩小反复适配的代码逻辑，达到升高代码复杂度、晋升可维护性的成果。同时 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 曾经在手淘 Android/iOS 双端正式版本、以及团体对立接入网关大规模利用，比方咱们关上手机淘宝的首页，或是搜寻咱们感兴趣的商品，或是关上逛逛浏览达人的视频，XQUIC 都为这些场景提供更快的网络数据传输，每天稳固为超过百亿量级的网络申请提供端到端减速能力。在 2021 年的双十一购物节中，XQUIC 在外围导购链路、短视频场景下也通过了大规模验证。

咱们打算每 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 篇挪动技术实际 & 干货给你思考！

关于quic:阿里自研标准化协议库-XQUIC-正式开源

XQUIC 是什么？

XQUIC 的劣势

XQUIC 外围介绍

模块设计

拥塞控制算法框架

传输层能力和利用协定协商

TLS 层设计

XQUIC 开源历史

为什么要做 XQUIC

咱们为什么要开源 XQUIC

利用场景和成果

后续 Roadmap

团队介绍