为什么下载不能立刻到达最快速度——从一个现象看拥塞控制算法

前言

不知道你有没有注意到一个细节：当你打开 Steam 下载一个几十 GB 的游戏，或者在浏览器下载一个系统镜像时，下载速度往往不是“秒切”到满速的。

通常情况下，速度会从几百 KB/s 开始，像爬坡一样在几秒钟内迅速攀升，最后才稳定在你的带宽上限（比如 30MB/s 或 100MB/s）。

按理说，既然带宽是固定的，服务器也是现成的，为什么不能从第一秒起就火力全开？这其实不是因为你的电脑“没反应过来”，而是网络协议为了保护互联网不崩溃，故意设计的一套“试探”机制——拥塞控制算法（Congestion Control）。

为什么要“试探”？如果不试探会怎样？

不少人可能会觉得：即使不试探，设备直接按预设的最高速度发不就行了吗？速度设低了顶多慢点，设高了反正也会被物理带宽限制住。

但现实远比这残酷。早在上世纪 80 年代，早期的互联网就尝试过这种“简单粗暴”的处理方式，结果导致了严重的网络拥塞崩溃。

想象一下城市早高峰的主干道，如果所有车主都为了赶时间，不管前方路况如何，一上路就直接把油门踩到底提速，结果会怎样？

瞬间塞满：车流瞬间填满所有车道（相当于路由器队列），车与车之间完全没有缓冲余地。
连锁反应：一旦有一辆车刹车或发生小擦碰（丢包），后方会瞬间引发大规模追尾和停滞，触发重传风暴。
全面瘫痪：本来能高效通行的带宽，因为混乱和事故，实际能通过的车子反而越来越少，最后整个网络“寸步难行”。

为了解决这个问题，TCP 拥塞控制算法应运而生，它就像是一套精密的“交通管制规则”。

慢启动（Slow Start）：试探性的起步

这就是导致“下载速度慢慢变快”的最直接原因。

当一个 TCP 连接刚刚建立时，发送方并不知道当前网络的承载能力。为了稳妥起见，它会从一个很小的值开始发送（通常是 10 个 MSS，即约 14KB 的数据）。

这个过程就像车辆刚驶上高速时，起初加速迅猛，但司机会时刻观察前方。在 TCP 中，每收到一个确认（ACK），发送量就会翻倍。虽然名字叫“慢启动”，但它的增长其实是指数级的。

拥塞避免（Congestion Avoidance）：稳扎稳打

当速度加到一定程度，接近网络的承载极限时，路由器或交换机的缓存队列会迅速堆满。为了防止延迟失控，网络设备会采用“主动作废”策略：直接丢弃新到的数据包。

这就像高速公路上的收费站（缓存队列）发现车距已经过短，为了避免追尾，会直接拦下新车不允许进入。这个“拦下”的动作，就是主动丢包。

当 TCP 发送端感知到丢包信号后，就会意识到已经接近极限，于是切换到“拥塞避免”阶段。此时，增长不再是翻倍，而是线性增长（每次只增加一点点）。这就像司机发现前方车流逐渐密集，提速变得非常谨慎，努力保持安全车距。

进化：从“撞车才懂刹车”到“预判路况”

Reno：保守的“事后处理”

传统的拥塞控制算法（如 Reno）比较保守，它就像一个只看有没有撞车的司机：不断加速，直到真的发生追尾（丢包）才猛然把车速降到一半，然后再慢慢提速。这会导致网络利用率不高，速度忽快忽慢。

CUBIC：有“记忆”的智能算法

目前主流的 CUBIC 算法（Windows、Linux、macOS 的默认算法）则聪明一些。它有“记忆”，会记得上次出事前的最高安全速度，然后快速接近那个速度，再小心翼翼地试探能否更快。

CUBIC 在拥塞避免阶段使用了一个三次函数来调整窗口大小，这使得它能在更大的带宽上更快地找到合适的速度，比 Reno 相比不会频繁掉速，更能合理利用资源。

BBR：基于带宽与时延的“预判大师”

而 Google 开发的 BBR 算法则更进一步。它不再依赖“丢包”这个滞后的信号，而是通过实时测量瓶颈带宽和最小往返时间（RTT）来建模。

用司机的例子来说：

Reno/CUBIC：撞一下（丢包）才懂收敛，属于“事后处理”。
BBR：随时观察路面的最大通行能力，并记住不堵车时的最短通勤时间。如果发现时间变长了，说明开始堵了，主动减速；如果时间恢复了，再主动提速。

这种“试探—反馈—调整”的闭环机制，让 BBR 能够更平稳地利用带宽，减少“走走停停”的尴尬。

为什么丢包不总是拥塞信号？

随着互联网环境愈加复杂，仅依靠丢包来判断网络拥堵开始暴露出问题。“等丢包再反应”就像在高速公路上单纯依赖追尾事故来感知车流密度。如果车流过多，等到追尾（丢包）发生时，虽然能提醒司机减速，但代价不小：依旧会发生车辆受损（应用层性能下降）、车道受阻（队列重传带来的额外带宽消耗）等问题。

而且有的时候丢包并不是网络阻塞的信号。比如，线路质量差、无线信号衰减、硬件故障，甚至是防火墙或策略丢弃，都会出现丢包的情况。这类丢包并不意味着网络已经“挤满”，却会误导拥塞控制算法，以为必须收紧发送速率，从而造成实际吞吐量被不必要地压低。

这便引出了新的思路：能否在“追尾”发生之前，就提前感知前方车流的紧张程度？就像在高速上设置电子限速屏或每辆汽车里都追尾提醒，让司机无需看到事故才减速，而是能够更平滑地调整车速。

实际应用：如何查看和调整你的拥塞控制算法？

如果你对技术细节感兴趣，可以查看你的系统当前使用的拥塞控制算法：

在 Linux 上：

1	sysctl net.ipv4.tcp_congestion_control

在 macOS 上：

1	nettop -m tcp

在 Windows 上：
可以通过 PowerShell 查看网络适配器的 TCP 配置。

如果你想尝试 BBR 算法（在 Linux 上），可以参考我之前写的《为你的Linux服务器开启BBR网络加速》这篇文章。

总结

所以，下次当你看到下载速度“爬坡”时，不用担心是网速不稳定。那其实是 TCP 协议在默默地进行“压力测试”，寻找一个既能让你下得快，又不会让整条街的网络瘫痪的最佳平衡点。

这种分布式、低成本的调节机制，让每一台设备在互不通信的情况下，依然能维持整个互联网的秩序。从早期的 Reno 到现代的 CUBIC 和 BBR，拥塞控制算法也在不断进化，让我们的网络体验越来越流畅。

好了，关于下载速度的小知识就聊到这里。如果你对网络优化感兴趣，强烈建议去折腾一下 BBR，真的能让你的服务器访问体验提升一个档次。

下次见！

Kaku的个人博客