XQUIC团队隶属于大淘宝平台技术-移动技术中台团队，希望能通过网络技术演进给用户带来更丝滑的体验。如果对XQUIC、网络技术、高性能网络传输等领域比较感兴趣，欢迎点击“阅读原文”关注我们的 GitHub 仓库：
https://github.com/alibaba/xquic
如果在使用XQUIC相关产品中遇到问题，欢迎加入XQUIC社区钉钉群反馈&交流：
Back to basic，自主创新标准实践，开放共创卓越工程！（by 大淘宝技术研究员长恭）
开源地址：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传输层通用事件进行开发。
▐ TLS层设计
QUIC Transport层，对TLS模块有如下依赖：加密握手协商、数据加解密、密钥更新、session resumption、0-RTT、传输参数、ALPN协商。TLS层，则需要依赖底层SSL库，来支撑上述功能。因此，TLS模块存在数据的多样性，以及依赖的多样性，数据流程和代码结构会比较复杂。TLS层需要对这些数据流进行归类整理，从而来简化上下游的依赖关系，降低代码的复杂度。
XQUIC适配了babassl、boringssl两种底层的ssl库，向上提供统一的接口，从而消除了它们之间接口、流程的差异，并抽象为统一的内部数据流程，仅针对不同ssl库提供轻薄的适配层，减少重复适配的代码逻辑，达到降低代码复杂度、提升可维护性的效果。同时XQUIC也提供了编译选项，方便开发者根据自身应用的情况，选择适合自己的依赖库。
▐ 为什么要做XQUIC
▐ 我们为什么要开源XQUIC
目前，XQUIC已经在手淘Android/iOS双端正式版本、以及集团统一接入网关大规模应用，比如我们打开手机淘宝的首页，或是搜索我们感兴趣的商品，或是打开逛逛浏览达人的视频，XQUIC都为这些场景提供更快的网络数据传输，每天稳定为超过百亿量级的网络请求提供端到端加速能力。在2021年的双十一购物节中，XQUIC在核心导购链路、短视频场景下也经过了大规模验证。
我们计划每1~2个月发布一个稳定版本，当前计划如下：
互通性功能补充，包括Key update、Retry以及ECN WG draft版本的多路径功能支持
适配开源Tengine的module支持 非可靠传输datagram支持
Masque特性支持
UDP性能优化feature XUDP适配支持
windows平台支持
网络性能测量工具
开源仓库已经提供了基于draft-34校订的草案中文翻译，后续会陆续更新RFC8999-9002的中文译版
