拥塞控制只是TCP可靠性机制的一部分
除了拥塞控制,TCP还依靠序列号、确认应答和重传计时器来保证数据完整、有序地到达。拥塞控制专门解决的是整个网络的公平性和稳定性问题——如果没有它,少数激进的发送方就可能拖垮共享链路上所有人的体验。
你通常能查看正在使用的算法,却很少能真正切换
大多数消费级操作系统和浏览器都不会开放切换拥塞控制算法的选项,因为这一设置在服务器端的影响远大于客户端。Linux服务器通常可以通过内核参数查看并切换Cubic、BBR等可用算法,这也是为什么繁忙网站、视频平台和CDN的运维人员格外关心这个选择。
在Linux上查看当前设置
在Linux上,命令sysctl net.ipv4.tcp_congestion_control可以显示默认算法,net.ipv4.tcp_available_congestion_control则列出已加载的算法。ss命令加上-i选项,可以打印每条连接的拥塞窗口、往返时延和重传次数等信息,在排查传输变慢时很有用。修改默认算法通常需要管理员权限,并且作用于整个系统,所以应当先在非关键机器上测试,并用实际提供的流量进行测量。
运维人员该如何选择算法
Cubic多年来一直是Linux内核的默认算法,在很多条件下表现稳定,是合理的基准。BBR在洲际链路这类长距离、丢包多或时延大的路径上可能有优势,但结果取决于缓冲区大小以及共享瓶颈的其他流量,并且自2016年首次发布以来已经多次修订。可靠的办法不是看通用的基准测试,而是用真实流量做A/B测试,比较吞吐量、时延和重传率。
QUIC:拥塞控制转移到应用层
QUIC在2021年被标准化为RFC 9000,运行在UDP之上,并在应用的库中实现自己的丢包恢复和拥塞控制,而不是依赖操作系统。这使浏览器和服务器无需等待内核升级就能更新算法。规范中给出了类似New Reno的默认控制方式,具体实现通常也提供Cubic或BBR。对用户来说,本页介绍的原理同样适用于HTTP/3流量,只是代码所在的位置不同。
常见问题
我可以更换设备使用的拥塞控制算法吗?
在Linux系统上可以,内核提供了在Cubic、BBR等算法之间切换的设置。而Windows、macOS以及大多数移动操作系统都不会向普通用户开放这一设置,实际上连接中服务器一端对体感速度的影响通常比客户端更大。
通过UDP传输的视频通话或游戏流量也会受拥塞控制影响吗?
UDP本身并没有内置的拥塞控制机制,因此行为不规范的UDP应用可能在网络拥塞时依然持续发送数据,给共享同一链路的其他用户造成负担。构建在UDP之上的现代协议,例如QUIC,则实现了自己的拥塞控制逻辑,以更负责任的方式运作。
丢包一定意味着拥塞吗?
不一定。丢包可能来自拥塞,也可能来自无线干扰、线缆故障或设备过载。传统TCP假定丢包就是拥塞,所以在质量较差的无线链路上可能无谓地降速。
为什么下载刚开始很慢,后来才变快?
这是慢启动在起作用。连接从很小的窗口开始并快速增长,小文件可能还没跑满速度就已经传完了。这也是为什么许多短连接往往比少数长连接更慢,以及HTTP/2等协议强调连接复用的原因之一。
换更高速度的宽带套餐,单个下载就会变快吗?
不一定。单条连接可能受往返时延、窗口大小或路径上的丢包限制,而不是受套餐带宽限制。从遥远的服务器下载时,即使套餐很大也未必能跑满,而更近的服务器或CDN则可能做到。
吞吐量曲线中的锯齿形说明什么?
它是线性增长后在丢包时急剧下降,如此反复的结果。如果曲线更平滑,可能是使用了基于时延或实测带宽进行调整的其他算法,或者路径上有充足的余量。