阿里正式开源自研 XQUIC：已服务手淘上亿用户，网络耗时降低超 20%

2022 年 1 月 7 日 InfoQ

作者 | 褚杏娟

采访嘉宾 | 喵吉

1 月 7 日，阿里巴巴大淘宝技术团队主导自研的 IETF QUIC 标准化协议库 XQUIC 正式开源，其中多路径传输能力与达摩院 XG 实验室联合研发。XQUIC 采用了目前应用较为广泛的 Apache License 2.0 许可证，并将代码托管在 GitHub 上。

XQUIC 项目链接：https://github.com/alibaba/xquic

据 XQUIC 项目负责人、阿里巴巴架构师喵吉介绍，XQUIC 协议的整体架构遵循 IETF QUIC 协议分层的设计理念，阿里团队针对传输层和应用层做了解耦实现。当前的 XQUIC 开源版本与之前发布的版本相比，新增了对 IETF RFC 版本的 QUIC v1 支持，对 QPACK 等部分功能模块进行了重构，增加了多路径支持等功能。到目前为止，XQUIC 已经在手淘正式版本为上亿用户提供了网络请求加速的体验优化。

XQUIC 特点

阿里巴巴大淘宝技术团队在 2018 年底开始研发 XQUIC 实现，去年 8 月正式对外发布。如今，XQUIC 针对 IETF QUIC 协议的实现已相对成熟，并且在手淘体系里也做了大规模应用来验证其稳定性。

据悉，目前手淘里面的导购场景 RPC 请求、短视频下载与文件上传等核心场景中应用了 XQUIC 实现网络加速。团队也在应用实践中，不断做新功能迭代 / AB 实验和 Congestion Control 算法调优等工作。

此外，阿里内部其他 APP，如闲鱼、AliExpress 等，也开始尝试使用 XQUIC 进行网络体验优化。

喵吉表示，XQUIC 本身服务手淘场景，目前更多地聚焦在短视频传输、视频 / 图片上传等典型的可靠传输场景，但 XQUIC 也将非可靠传输 / 半可靠传输场景纳入研发计划，未来也将结合社区开发者诉求，逐步纳入更多传输需求场景。

据喵吉介绍，目前开源版本的 XQUIC 主要具备以下两个优势：

协议设计方面，XQUIC 是按照 IETF QUIC 标准 [1] 进行的协议栈能力实现，在互通性方面，XQUIC 也在 IETF 开发者社区进行了比较充分的互通性验证 [2]。在 QUIC V1 标准的基础之上，XQUIC 添加了对多路径传输的能力支持。
协议实现方面，XQUIC 是跨平台的 C 库实现，当前提供对 Android/iOS/Linux 平台的支持。在移动端 APP 场景，XQUIC 在 Android / iOS 双端的包大小在 300～400KB 之间，相对轻量化。同时，XQUIC 也具备高性能传输能力，针对移动性场景优化也会持续进行。

关于 multipath 技术演进，具体可以查看大淘宝技术团队与达摩院 XG 实验室联合发表的论文链接：https://dl.acm.org/doi/pdf/10.1145/3452296.3472893

据喵吉透露，XQUIC 将手淘导购 RPC 的网络耗时缩减了 17.52%~20.26%，短视频 / 图片的上传速度提升了 22.61%，并减少了短视频下载场景下 7~16% 的视频分片下载耗时。

研发一年半，终于发布

XQUIC 的研发从一定程度上来说是一件不得不做的事。

如今的电商早已是移动端的天下。2020 年，亚洲移动端电商已经占到了整个电商行业的 78%。在这一趋势下，网络传输协议可以有一个端到端的良好实现，能在安卓和 IOS 系统上有良好的适配、在服务端有高性能协议栈的实现，成了电商业务场景提升网络体验的核心需要。

面对该业务需求，有两种可以选择的方案：一是基于其他的开源实现做轻微改进并直接使用，但开源实现是否能够满足各方面需求是个疑问；二是基于某个开源方案做大量的优化和改进，但这样又会导致修改后的版本难以回归到主干，以致出现版本分裂的问题。

2018 年底的时候，除了国外的一些大厂，相对成熟且开源的 IETF QUIC 协议实现并不多。而时至今日，虽然很多国外厂家的 QUIC 协议实现已经开源，但仍存在一些问题：有的实现相对较重，有的对移动端跨平台的适配不在高优先级支持，有的则与自己生态结合比较紧密，对所在企业的实现库依赖性很大。此外，国内的大厂一直都没有太多的 QUIC 开源实现。这种情况下，阿里大淘宝技术团队开始自研 QUIC 协议。

在 18 年底到 20 年中的一年半时间里，团队都在做 XQUIC 的研发。据喵吉介绍，整个研发过程可以分为三个阶段：

第一个阶段，团队主要任务是完整地去理解整个协议的设计和很多内部细节。
第二个阶段，团队先针对整体协议设计去做模块的拆解，再针对协议框架和拆解出来的模块去做合理的流程设计。
第三个阶段，团队才开始进行各个功能模块的细节性编码，考量性能、效率等问题。

“整个过程中，相对比较困难的主要有三个地方。一是前期大家对 QUIC 协议认知的对齐，二是在设计阶段对模块功能和报文处理流程的合理抽象，三是后期的传输性能和服务端性能优化。”喵吉说道。

团队要跨过的第一个门槛是要完全理解 QUIC 协议的细节。在研发各个模块之前完全吃透设计原理至关重要。但协议栈本身的设计和各方面机制的建设相对比较复杂，这从 350 多页的协议说明可见一斑。

但在实际中，业界的很多协议介绍资料并不是特别准确，而看原版RFC资料可能存在门槛，不看的话又很难达成统一的认知，甚至会导致传播错误信息的情况。据喵吉透露，他们团队为了完整吃透协议内容，在前期把 IETF QUIC 6 个核心草案内容进行了翻译和学习（沉淀约200 多页的中文资料），并在研发过程中定期组织学习讨论最新草案版本，以此来保证团队内的认知对齐。这些中文资料也已经在开源社区贡献出来，帮助国内开发者更好地理解协议栈原理。

XQUIC 协议本身就是一个技术栈的实现，因此在研发实践中，阿里大淘宝技术团队先从底层开始向上做能力的叠加。早期先在传输层做了实现，并针对传输层做场景优化，之后在此基础上叠加 HTTP3 的实现等，然后再面向各个业务场景做贴合业务场景的 QoS 优化。

填补国内开源空缺

“在我的理解中，现在不是存在很多开源的 QUIC 协议，而是有很多开源的 QUIC 协议的实现，因为 QUIC 协议只有一个版本。”喵吉说道。

QUIC 最早是 Google 提出的一种基于 UDP 的低时延的互联网传输层协议。2016 年 11 月，国际互联网工程任务组 (IETF) 召开了第一次 QUIC 工作组会议，QUIC 开始进行标准化，成为新一代传输层协议。

当前的 QUIC 协议主要有两个流派：一派是 IETF 业务标准化工作组的 QUIC 协议，目前已释放了传输层的四个核心协议，预计今年将释放应用层 HTTP3.0 协议；另一派则是基于 Google 早期开源的 QUIC 版本演进后的各种协议版本。这两个流派的协议演进仍然有不少差异，体现在协议设计和实现两个层面，但是整体的行业大趋势还是往 IETF QUIC 的方向演进。

协议层更多关注协议交互，具体实现上，各家会有比较大的差异。虽然从协议层面上来看，IETF QUIC 传输层的通用性设计，使得它可以适配各类业务场景，但在实践中，每个企业都有自己的侧重点。比如，谷歌会更多从浏览器角度出发，微软则更侧重于 Windows 等的适配，而像阿里手淘这样的 App 厂商则需要更多考虑移动端适配和性能问题。

“XQUIC 是一个适配移动端、轻量且高性能的传输协议库。”喵吉说到，“除了想让 IETF QUIC 在移动端上得到更好的应用外，我们也想弥补当前国内缺少相对成熟的开源实现这一空缺，现在比较成熟的开源实现大部分还是以 Google、Facebook 等国外企业为主。”

此外，喵吉表示，开源可以让更多开发者参与进来，团队也可以得到使用者基于场景的反馈，能更好地对协议做持续迭代。喵吉也呼吁各企业网络研发团队能够一起为协议栈发展贡献力量。

事实上，XQUIC 协议原本计划开源的时间要更早些。喵吉表示，开源的时间节点首先受 IETF QUIC 最终 RFC 的定稿时间影响，其次在这段时间内开发支持的新功能，也希望在内部场景经过充分验证。5 月底，IETF 发布了 QUIC 正式版 RFC 8009 ~ 9002，这一时间已经临近 618，团队决定先将工作重点放在 618 的保障上。之后，我们又针对内部模块做了一些功能重构，并且经历了 21 年电商双十一的大规模考验，稳定性和性能方面都比较成熟，才最终确定在 22 年初的 1 月完成开源。

XQUIC 与其它开源方案的一个最大不同就是增加了 QUIC 对于多路径的支持，该方案由手淘与达摩院 XG 实验室联合研发，相关草案已经更新到 04 版本。基于 XQUIC，阿里巴巴首次实现了基于用户体验驱动的多路径传输 XLINK 并在手淘短视频场景做了规模化灰度验证，是业界第一个完成大规模灰度验证的多路径 QUIC 传输方案，相关成果发表于网络领域的 Top1 会议 SIGCOMM 2021。

开源后，除了内容分享，XQUIC 社区会进行定期的 Review，以把控代码的整体质量。

未来还有很多可能

“QUIC 是一个通用的传输层协议框架，未来的趋势是各个典型场景驱动的 QoS 优化，而面向业务场景的 Congestion Control 优化可能是关键的突破点。”喵吉表示。

QUIC 整体设计具有通用性和完备性。与 TCP 相比，更快、安全性更高，有 0-RTT 的握手能力，还提供了非可靠传输能力。很多基于 TCP 应用层协议的场景，已经开始考虑切换到 QUIC 协议上。根据 Cloudflare 分析，现在互联网上使用 QUIC 的 HTTP/3 流量约有 12%。

但是，不同业务对底层网络传输的诉求有很大的差异。例如，RPC请求、视频点播场景以及实时音视频传输的场景，对底层传输能力的要求就不一样。因此，如何在相同的协议框架基础上针对自己的业务做优化，就成了业内非常关注的话题。

很多企业开始自研 QUIC 协议也与此有关。虽然大家有一个通用的协议设计，但由于各企业关注点不同，研发的重点也各不相同，协议的实现也就不同。“很难有一个可以满足所有业务场景的通用解决方案。”

一方面，企业们都够清晰地看到 QUIC 带来的收益。现在，用户体验越来越受重视，而对整体传输质量非常关键的网络传输层必然是需要重视的。另一方面，过去 TCP 实现在内核态，APP 应用对网络传输层的演进和掌控上相对比较薄弱，很多时候要依赖内核升级，但内核升级并不容易，客户端依赖厂商版本，而服务端的内核版本迭代则有一个很长的升级周期。

“QUIC 把过去依靠内核实现的网络传输能力转移到了用户态，这样我们可以面向业务场景做更多的调优，甚至结合应用层的一些特性做 QoE driven 的优化，这对所有 APP 厂商来说都很关键，实践中大家也确实感受到了传输能力提升带来的体验收益。”喵吉表示。QUIC 诞生 8 年，第一个版本已经相对成熟，传输层能力也有基本保障，但在非可靠传输领域和应用层方向上还有很多新的尝试和机会。

相对 TCP 来说，目前所有的 QUIC 实现在服务端性能上与来源内核态实现的差别不大，在加解密、本身协议处理等方面也还存在性能损耗和额外性开销，因此，服务器性能优化是不少开源实现都在重点研究的方向之一。

“Google 做这件事坚持了 7、8 年，这种对底层技术的长期投入是非常值得敬佩的，并且他们也确实拉动了整个网络技术行业的发展。”喵吉说，“我们希望通过开源等方式，也可以为行业尽一份微薄之力。”

参考文献

[1] IETF QUIC 标准：RFC 8999 - RFC 9002

[2] XLINK: QoE-Driven Multi-Path QUIC Transport in Large-scale Video Services, https://dl.acm.org/doi/pdf/10.1145/3452296.3472893

1 月 10 日晚 19:00-20:00，大淘宝技术视频号将上线 XQUIC 开源产品发布会直播，届时会有更详细的技术介绍，欢迎感兴趣的小伙伴来直播间观看互动。（直播间地址可在大淘宝技术视频号获取）

在云原生等技术的加持下，2022 年的架构领域有哪些值得关注的趋势？1 月 7 日晚 8 点，阿里云 MSE 负责人李艳林（彦林）、阿里云高级技术专家李云（至简）一起做客 InfoQ 视频号，为你带来云原生架构领域最新趋势解读。

今日好文推荐

所谓“现代Web开发”，都是些什么妖魔鬼怪？

解读中间件的2021：被云原生重塑之后，选型更难了

解读操作系统的2021：触到了创新的天花板，却站在巨变的前夜