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/…
发表回复