发布时间：2022-08-19 12:03
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的判断能够满足自研的前提，就会走上自研道路。因此我们可以看到绝大部分一线互联网大厂，都会对战略性的技术投入方向进行自研，同样自研也能够带来技术壁垒的积累。这一步也是第四阶段的前置门槛。
第四阶段，引领前沿发展，这个阶段往往又存在两种类型（或两者兼有）：通过开源逐步成为事实标准，或者是参与到行业标准的制定当中。