NGINX 中 QUIC 流量控制的提升与优化
当前位置：点晴教程→知识管理交流
→『 技术文档交流 』
 想象一下，在繁忙的高速公路上，车辆在高峰时段挤进有限的车道。这与计算机网络中，过多数据同时传输的情况类似。就像交通堵塞一样，网络拥堵会显著减慢数据传输速度，而这时流量控制机制就显得尤为重要。 流量控制：确保数据流畅传输 流量控制是防止网络拥堵的关键机制，确保数据在网络中顺畅、高效地流动。每个计算机网络都有其带宽限制，如果数据同时发送过多，可能会导致数据丢失或由于重传引发延迟。为了避免网络拥堵，终端需要知道在某一时刻能传输多少数据。 为跟上 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。 阅读原文：原文链接 该文章在 2025/12/31 9:46:23 编辑过 |
关键字查询
相关文章
正在查询... 
|
400 186 1886
