共计 4116 个字符，预计需要花费 11 分钟才能阅读完成。
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 层模型中传输层的倒退方向认识，以及对于底层技术倒退过程中可能碰到的艰难及问题提出一点可行的倡议。
开源仓库：https://github.com/alibaba/xquic
什么场景下适宜抉择 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 收发。
这一套计划相较于 Linux 内核默认的 UDP 收发 + 四元组 hash 查找优化的计划，能够在实在场景下，再晋升 26.3% 以上的服务器协定栈解决性能。Tengine + XUDP + XQUIC 的打包解决计划，咱们后续也会在 Tengine 社区提供开源版本以供内部开发者参考。
写在最初
心愿大家都能在本人的畛域，享受技术后退的高兴。
参考文献
[1] HTTP3: https://datatracker.ietf.org/…
[2] QPACK: https://datatracker.ietf.org/…
[4] 互通性验证：https://interop.seemann.io/
[5] XQUIC 开源仓库：https://github.com/alibaba/xquic
[6] XDP: https://dl.acm.org/doi/pdf/10…
[7] XUDP: https://codeup.openanolis.cn/…
[8] Multipath Extension for QUIC: https://datatracker.ietf.org/…
