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

采访嘉宾 | 喵吉

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 实验室联合发表的论文。

据喵吉透露，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