6月7日早晨(UTC时间Mon, 06 June 2022 20:09)，HTTP/3 标准RFC9114 由IETF标准化工作组正式发布，由此QUIC第一代协议族6大基础标准（不变量/传输框架/拥塞控制和恢复/TLS/HTTP3/QPACK压缩）全部完成RFC化，开启一段新的网络时代。在淘宝，我们从18年开始尝试QUIC，到21~~22年实现IETF QUIC及HTTP3标准的规模化应用，针对导购和交易核心链路场景拿到15~~20%的网络耗时优化收益，同时沉淀自研的标准协议库实现XQUIC，并于年初开源。笔者想借由本文谈一谈对于网络7层模型中传输层的发展方向看法，以及对于底层技术发展过程中可能碰到的困难及问题提出一点可行的建议。

开源仓库：github.com/alibaba/xqu…

什么场景下适合选择QUIC作为TCP的替代品

今年我们听到大量的国内外声音，支持QUIC作为TCP的全面替代品，同时也针对QUIC成为网络传输技术新一代的颠覆者，提出支持性的观点。笔者作为XQUIC(一个包含QUIC和HTTP/3标准实现的协议库)项目的发起人和持续建设者，虽然立场相关，但是仍然从客观角度做一下分析。

最近一到两年也有很多研发者找到XQUIC项目，希望这个项目能一举解决大家碰到的所有网络问题；笔者的观点是，这个世界上没有银弹，没有任何技术可以解决所有场景的问题，每一项技术都有它适合的场景和它的局限性。

那么到底什么场景下适合使用QUIC呢？答案是公网传输链路下，作为TCP的替代品，确实具备理想的优势 。我们知道公网的特性是链路长（反应在Round-Trip-Time上）、链路复杂性高（反应在各个节点可能存在的丢包/排队及多流的竞争上）、以及手机端常见的无线信号波动带来的吞吐量抖动（体现在丢包/乱序上），这些问题的解法都是QUIC的强项领域。而在数据中心内部，在链路网络设备可控的情况下，同时追求低性能开销与低成本，TCP/DCTCP仍然表现不错，基于RDMA的一些DC内部解决方案同样也会具备优势。

从原理本质上来说，QUIC带来的最大的原理变化是：将传输层从内核态提到用户态 ，使得传输层可以与应用层进行高度配合，这在过去是无法可想的。这打开了传输层对于应用层传输需求和传输内容理解的天花板，使得传输行为与应用层需求高度匹配具备可行性。有人可能会说这有什么牛逼之处么？我们知道WebRTC在音视频场景下表现出色，其中一部分关键原因就是其RTP的协议传输设计和工程实践，是充分结合音视频内容的传输需求和特性来设计的。因此具备用户态灵活演进的能力，并且能够贴合应用场景进行传输特性的设计，是非常重要的发展和探索方向。此外它基于UDP的多路复用、以及对Steam/Datagram分别支撑可靠传输与非可靠/半可靠场景的传输能力设计，包括0-RTT降低握手延迟这些基础的协议特性带来的优势，就不再多说。

谈谈自研、标准与开源

对于任何一项好用的技术来说，能够先应用起来并且服务好业务需求，永远是第一步。对于任何具备深度和一定壁垒的技术（碰巧网络也属于），一般我们都会经历4个发展阶段：

第一阶段，用好这项技术，首先能用好并切实在业务场景下拿到收益。在当前这个鼓励开源的时代，第一步通过这个领域下已有的开源方案，来验证技术的可行性，并拿到一些初步收益来验证判断和观点，是最快的方式。
第二阶段，原理理解透彻，能够充分理解透彻这项技术的底层原理和机制，并针对业务需求做出调整。在这个阶段往往大家会有两条分叉路径：在已有开源项目上继续修改并发展自己的分支；或者筹备自研。在这个阶段是选择前者还是后者，核心依据有2个：一方面是是对这项技术长期发展所能带来的红利，是否可以cover前期的投入；另一方面是，是否具备自研能力。
第三阶段，具备自研能力， 如果从2到3的判断能够满足自研的前提，就会走上自研道路。因此我们可以看到绝大部分一线互联网大厂，都会对战略性的技术投入方向进行自研，同样自研也能够带来技术壁垒的积累。这一步也是第四阶段的前置门槛。
第四阶段，引领前沿发展， 这个阶段往往又存在两种类型（或两者兼有）：通过开源逐步成为事实标准，或者是参与到行业标准的制定当中。

笔者个人的观点是，每个阶段都需要投入不同的精力，对应着领域的持续深挖和人才的长期培养与团队建设。选择走到哪个阶段，没有绝对的好与坏，而是应该根据实际的诉求、可持续投入情况和发展的观点来判断。

另一方面，作为一个技术人，我们也应当充分尊重技术本身的深度，尊重愿意为了走到第三/四阶段，而投入精力、克服重重困难的技术产品和团队，而非通过一些短期包装和走捷径的方式，避免最终在技术上逐渐空心化，影响技术大环境的发展。如何维护技术环境的一片净土，使得健康的种子能够具备萌芽的条件，这也是技术管理者需要考虑和反思的。

如何应用QUIC/HTTP3来提升传输性能表现

这次IETF发布的RFC 9114和9204分别描述的是HTTP/3.0和配套的Header压缩算法QPACK的协议机制。HTTP/3.0相对于HTTP/2到底有什么本质提升？这需要从HTTP/3底层的QUIC传输机制讲起。

我们都知道，QUIC基于UDP之上的多流（Stream）传输，实现解决原来TCP大管道下的Head-of-Line问题[3]，同时0-RTT等握手机制可以保证连接会话的快速建立和首包的加速。QUIC提供了两种传输模式，基于Steam的可靠传输，和基于Datagram的非可靠传输。基于Stream的模式下，发送方和接收方基于Steam的Offset进行流数据的重排和有序还原，并确保投递给应用层的是有序可靠数据。基于Datagram的模式则适用于实时流媒体类型的场景，针对延迟有强诉求的同时不要求数据完全可靠有序的这类场景，Datagram提供了一种数据封装和ACK通知的方式，帮助半可靠诉求的场景实现数据的快速投递，并向应用层反馈送达情况。

[3] TCP Head-of-line头部阻塞问题：原因是TCP是一条大的传输管道，基于TCP传输的数据，由于TCP的传输机制，需要等待前面的数据包完成送达，后续的数据包才能被完成送达和向应用层投递。这在多路复用的场景下，会导致不同的流数据之间互相block，这在HTTP/2是一个没有被完全解决的问题。

QUIC在丢包检测和重传机制方面也有较大革新。在丢包检测方面，QUIC提供了两大类丢包检测方式，基于packet number的阈值检测，和基于定时器的超时丢包检测。这两类机制相对于传统的TCP检测方式可以带来更快的丢包感知和恢复。在重传恢复方面，QUIC针对每一个packet分配独立的packet number，避免了过去TCP因重传包和原始包复用相同的sequence，导致的RTT测量不准确的问题。准确测量的RTT，作为拥塞控制算法的一维重要输入，能够使得算法对瓶颈段拥塞状况的检测更加准确。

这次发布的HTTP3 RFC，则是在QUIC基础之上，描述了HTTP请求如何通过跟QUIC steam的映射，实现完整的HTTP语义，以及针对基于UDP的多流机制设计的专用头部压缩。因此所有QUIC在UDP之上实现的传输机制革新，HTTP3都可以享受到红利。

那么如何把这项革新的技术用起来呢？XQUIC针对QUIC和HTTP/3协议栈提供了完整的能力实现，并且完全符合IETF标准，并通过了IETF工作组的互通性验证[4]。在手机淘宝我们提供了整套的网络解决方案，包含客户端的SDK和服务端网关的能力支持，各类业务场景核心关注开关和放量情况即可。对于外部开发者，可以移步到XQUIC在github的开源仓库[5]，开源仓库有相对完整的文档说明和RFC译文，同时后续开源版本我们也将逐步更新IETF工作组版本的Multipath[8]多路传输能力，以及Tengine相关的适配版本和模块，方便外部开发者能够更方便地使用。

如何解决服务端UDP性能问题

相信已经在尝试应用QUIC/HTTP3的服务端开发者，或多或少都会经历UDP在内核方面的性能瓶颈问题，考虑到UDP是在近几年才随着QUIC和流媒体传输的场景的逐渐流行，才被逐渐广泛地应用起来，因此内核UDP在性能方面很难与优化了三十年的TCP相抗衡，同时内核的复杂性和通用性要求，也导致一些新的高性能修改难以被迅速接收。因此，在UDP性能优化方面，我们和龙蜥社区的Anolis内核团队联合做了一版bypass内核的用户态高性能udp收发方案。

首先我们需要了解到，ebpf[6]有一类专门用于网卡驱动处理的filter叫XDP[7]，可以实现对于网卡接收和发送的packet进行劫持处理；Anolis内核团队基于XDP实现了一套UDP packet卸载和封装逻辑并封装为XUDP[8]库，而我们则基于XUDP进行UDP packet的收取和发送，实现完全bypass内核的高性能UDP收发。