原文作者：Roman Arutyunyan - F5 Principal engineer
原文链接：NGINX 中 QUIC 流量控制的提升与优化
转载来源：NGINX 中文社区

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

想象一下，在繁忙的高速公路上，车辆在高峰时段挤进有限的车道。这与计算机网络中，过多数据同时传输的情况类似。就像交通堵塞一样，网络拥堵会显著减慢数据传输速度，而这时流量控制机制就显得尤为重要。

流量控制：确保数据流畅传输

流量控制是防止网络拥堵的关键机制，确保数据在网络中顺畅、高效地流动。每个计算机网络都有其带宽限制，如果数据同时发送过多，可能会导致数据丢失或由于重传引发延迟。为了避免网络拥堵，终端需要知道在某一时刻能传输多少数据。

为跟上 Web 性能的最新进展，NGINX 在最新版本中引入了一种新的流量控制算法——CUBIC。同时，这一版本对 QUIC 协议的实现进行了多个增强，显著提升了下载速度并修复了 BUG。

流量控制如何工作？

流量控制是 TCP 和 QUIC 协议的核心部分。这两个协议通常依赖于确认机制，接收方在成功接收数据包后会发送确认信息，表明数据已成功传输。在确认到达之前，数据包被认为是“在飞行中”。

流量控制算法通过限制“在飞行中”数据的数量来运作，这个数量限制称为拥塞窗口（CWND）。如果对端要发送数据，它要等到前一个数据包的确认到达，并且“在飞行中”的数据量降到拥塞窗口之内。

拥塞窗口从小值开始。当接收到确认后，窗口会增大，允许发送更多的“在飞行中”数据。如果拥塞窗口增长超过了网络的容量，数据包可能会丢失，导致流量控制算法减少窗口大小。

历史上的流量控制算法

最早的流量控制算法之一是 Reno 算法，它自 1980 年代以来一直是 BSD 操作系统中的基础。经过多年的改进，最终版本 NewReno 在 RFC 6585 中定义。NewReno 被认为是 QUIC 的标准流量控制算法，按照 RFC 9002 的规定，它也被实现于 NGINX，从 1.25.0 到 1.27.4 版本中。

Reno 算法的过程从连接的慢启动模式开始。在这一模式下，拥塞窗口从一个较小的值开始呈指数增长。当检测到数据包丢失时，窗口被减少一半，连接切换到拥塞避免模式。在此模式下，拥塞窗口会线性增长，直到下一次数据包丢失为止，然后窗口再次减半，整个过程重复。

为什么选择 CUBIC 流量控制？

Reno 算法的一个主要缺点是无法充分利用高速网络。Reno 使用线性函数增加拥塞窗口，而对于高速网络，这种增长可能过于缓慢。这时，CUBIC 流量控制算法就能发挥作用。

CUBIC（如 RFC 9438 中所述）在拥塞避免阶段使用立方函数，而不是线性函数。这种方法有助于更动态地管理拥塞窗口。当预计发生数据包丢失时，立方函数会减缓拥塞窗口的增长；而当数据包丢失的可能性较小时，窗口增长会加速。

在每次拥塞避免迭代开始时，拥塞窗口刚刚减少，此时数据包丢失的可能性较低。此时，立方函数会加速窗口的增长。当窗口接近之前的丢失点时，立方函数会减慢增长，以避免再次丢失。如果没有丢失，表明之前的丢失可能是偶然的，或者网络带宽有所增加，那么窗口的增长速度会再次加快。这种动态调整使得 CUBIC 能够迅速利用高速网络带宽。

大多数现代操作系统（如 Linux、FreeBSD 14.0+、MacOS 和 Windows）已经将 CUBIC 作为默认的流量控制算法。

NGINX 中流量控制的基准测试

在 NGINX 1.25.0 版本中，首次实验性地支持 QUIC，并使0用 NewReno 流量控制算法，如 RFC 9002 所述。而在 NGINX 1.27.5 版本中，CUBIC 流量控制被添加到 QUIC 中。随着这次更新，QUIC 实现也进行了多项显著改进，减少了流量控制算法的激进性，提升了数据包乱序的容忍度，并修复了 RFC 合规性问题。

这次更新带来了显著的性能提升，下面是基准测试的结果。这些测试对比了 NGINX 1.27.4 与 NGINX 1.27.5，使用 MTU 1500 的接口。

测试网络条件模拟使用了 tc-netem，配置了 6000 个数据包队列和 50ms 的延迟。这相当于 100ms 的 RTT、9M 带宽延迟产品（BDP）和 720Mbps 的带宽。

基准测试结果：

基准测试结果表明，NGINX 1.27.5 在下载速度方面有显著提升，特别是在高 BDP 环境下。这一提升得益于引入了 CUBIC 流量控制算法以及对 QUIC 实现的其他优化。

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号 | B 站