TCP拥塞控制详解：从慢启动到BBR，实战排查网络变慢

1. 网络为什么会变慢：先把拥塞这件事弄明白

讲拥塞控制之前，我先抛个场景。你在某机房的两台服务器之间传一个 2GB 的文件，scp 跑起来，结果速度从 800Mbps 掉到 200Mbps，然后又慢慢爬回去，反复横跳。你第一反应是网线问题，换了口、换了模块，还是这样。最后抓包一看，TCP 窗口一直在萎缩，重传一堆，这就是拥塞控制在起作用。

很多学《计算机网络》的人把拥塞控制当成“TCP 的一章”来背，背完慢启动、拥塞避免这几个词就过了。但实际排查问题的时候，拥塞控制是默认开启的、一直在运行的机制，它决定了你的传输能跑多快、什么时候降速、什么时候恢复。不懂它，你就看不懂 iperf 的曲线，调不明白长肥网络的带宽，更别提理解 BBR 为什么能在一半丢包率下还跑得动。

拥塞控制解决的核心问题是：发送方不知道网络中间节点的真实状态，它只能通过丢包、时延、显式反馈这些间接信号来猜“路况”。猜得太激进，会把路由器队列打爆，造成全局丢包；猜得太保守，带宽白扔，链路利用率上不去。这个度怎么把握，就是拥塞控制算法的全部内容。

这篇文章我把拥塞控制的完整脉络拆开：先讲它到底在保护什么，再逐行拆经典算法族的每个状态和参数，然后用抓包的方式带你看真实网络里 cwnd 是怎么变的，最后聊到 Cubic、BBR 这些现代算法和实际调参手段。适合正在啃教材的学生，也适合上了几年班但没系统理过这块的工程师。

2. 拥塞控制到底在图什么：几个必须搞懂的核心指标

2.1 丢包不是唯一信号，但它是经典算法的起点

TCP 的拥塞控制最早面对的现实是：网络没有中央调度器，每个发送方各行其是。如果每个人都按自己带宽上限猛发，路由器缓存瞬间被打满，新到的包直接丢弃。丢包之后发送方只能靠超时重传兜底，效率极低，甚至引发重传风暴。

经典拥塞控制的基本逻辑就是一句话：把丢包视为拥塞的证据，一旦丢包就降速，没丢包就试探性加速。这听起来简单，但工程实现上有三个指标是算法设计的基石。

第一个是拥塞窗口 cwnd（congestion window），它代表发送方允许在途（已发送但未确认）的数据量。真实网络中 cwnd 不是静态的，它随反馈动态调整。这里的“在途数据”概念很关键：TCP 的发送窗口等于 min(cwnd, rwnd)，rwnd 是接收方通告窗口，反映接收缓冲区大小，而 cwnd 反映网络容量。

第二个是慢启动门限 ssthresh，它是快速和谨慎的分界线。cwnd 小于它时走指数增长，大于等于它时走线性增长。这个值不是配置死的，每次丢包后都会被重算。

第三个是 RTT（往返时延），它衡量一个包从发出到收到确认的耗时。RTT 直接参与计算，比如带宽时延积 BDP = 带宽 × RTT，它决定了某个链路上“在途数据”理论上应该有多大。如果链路带宽是 100Mbps、RTT 是 50ms，BDP 就是 0.625MB（约 625KB）左右。cwnd 小于 BDP，发送方就喂不满管道；cwnd 远大于 BDP，多余的数据就会堆积在路由器队列里。

这三个指标是所有拥塞控制算法都要面对的。经典算法和现代算法的分歧，本质上是对“怎么判断拥塞”这件事的信号选择不同。

2.2 从单连接视角看拥塞控制的意义

我见过不少人把拥塞控制理解成“TCP 为了公平而主动限速”，这个说法不准确。拥塞控制的首要目标是保护网络本身，其次才是公平性。

你可以想象一条高速公路：每个 TCP 连接是一辆车，路由器缓存是收费站前的排队区。如果每辆车都不顾前方排队、猛踩油门往收费站挤，结果是所有车都堵在排队区，谁也别想走。拥塞控制就是让每辆车都学会“看到排队（延迟增大）就缓一脚”“闻到刹车灯（丢包）就减速”“路况好就逐渐加速”。

从单连接视角来看，拥塞控制看起来像“给发送方戴了脚镣”，但从全局视角看，如果链条容量是有限的，不控制的结果是所有人一起丢包、一起超时、一起断流。这就是为什么拥塞控制被称为 TCP 的“交通警察”。

另外注意一个点：拥塞控制不是 TCP 独有，QUIC 也有自己的拥塞控制，算法沿用自 TCP 但可插拔实现。如果你做 UDP 可靠传输，同样要自己实现拥塞控制，否则一上公网就会被丢包教做人。理解了 TCP 的机制，换到 QUIC 只是换接口，思想完全通用。

3. 经典算法族拆解：慢启动、拥塞避免、快速重传与快速恢复

3.1 慢启动：指数增长不是乱猜，是有明确目标的试探

很多教材把慢启动讲成“从 1 开始慢慢增加”，这个“慢慢”其实非常有误导性。慢启动一点也不慢，cwnd 是翻倍增长的。

新连接建立时，cwnd 初始值通常是 10 个 MSS（最大段大小，常见为 1460 字节，即约 10KB 左右，不同操作系统有差异）。每收到一个 ACK，cwnd 增加 1 个 MSS。你仔细算一下：一个 RTT 内如果发出 N 个包、收到 N 个 ACK，cwnd 就翻倍。

举个例子，初始 cwnd = 10 MSS，第一个 RTT 发 10 个包，收到 10 个 ACK 后 cwnd = 20 MSS；第二个 RTT 发 20 个包，收到 20 个 ACK 后 cwnd = 40 MSS。经过 k 个 RTT，cwnd = 初始 × 2^k。这就是为什么叫指数增长。

但指数增长不能一直持续，否则顷刻间就会灌爆链路。所以慢启动设了门限 ssthresh。当 cwnd >= ssthresh 时，慢启动阶段结束，转入拥塞避免。

慢启动存在的意义是：连接刚建立时，你完全不知道这条链路的容量，所以要用指数级试探快速逼近可用带宽。这个阶段可能只持续几个 RTT。我实测过一个跨机房场景，RTT 约 30ms，慢启动用了 4 个 RTT 就把 cwnd 从 10 推到了 160 MSS，对应的传输速率早已超过了链路带宽的合理值，随后开始丢包、触发降速。论文里讲慢启动“慢”，是相对于旧实现从 cwnd = 1 起步而言的，但现代实现里它的增长速度实际上非常快。

慢启动阶段的一个重要细节是：窗口增长依赖 ACK 的到达。如果网络丢包导致 ACK 不回来，cwnd 就停止增长，倒逼发送方把发送速率降下来。这就实现了“发送速率自动跟随网络反馈”的核心逻辑。

3.2 拥塞避免：加性增、乘性减的守恒博弈

进入拥塞避免阶段后，cwnd 的增长方式变成：每经过一个 RTT，cwnd 增加 1 个 MSS。也就是说，线性增长。这一步的目标是慢慢探测链路的余量，尽量避免触发丢包。

拥塞避免的典型实现是：每收到 1 个 ACK，cwnd += MSS / cwnd（这里的 cwnd 单位是字节）。粗看是“每 ACK 加一点点”，但累计一个完整 RTT 内所有 ACK 之后，cwnd 恰好增加一个 MSS。为什么这么设计？因为如果每 ACK 固定加 1 个 MSS，cwnd 会以 ACK 频率为倍率暴涨，又变成指数级，违背了“避免拥塞”的初衷。

拥塞避免的“避免”其实是保守探测：网络看起来没事，就每次增加 1 个 MSS 并把窗口推大一点，直到碰到丢包。

当丢包发生时，经典 TCP Tahoe 的做法是：ssthresh = cwnd / 2，cwnd 直接回到初始窗口，重新走慢启动。这虽然简单但有明显代价：丢包后带宽瞬间归零，再慢慢爬回来，对高带宽链路太伤。

Reno 改进了这个方案，把“丢包后的反应”细分成了快速重传和快速恢复，这也是今天所有教材重点讲的部分。

3.3 快速重传和快速恢复：用 ACK 的节奏判断丢包

快速重传基于一个观察：接收方收到乱序包时，会重复确认期望收到的那个序号（即重复 ACK）。发送方连续收到 3 个重复 ACK，说明后面的包到了，但前面某个包丢了。这时候基本可以断定不是网络拥塞导致整个链路断掉，而是“小规模丢包”，所以不必像超时那样重置 cwnd。

收到 3 个重复 ACK 后：

• ssthresh = cwnd / 2（不低于 2 个 MSS）
• cwnd = ssthresh + 3 × MSS（加上已触发重传的 3 个重复 ACK 对应的包）
• 进入快速恢复阶段，cwnd 临时膨胀，每收到一个重复 ACK 就 cwnd += MSS，这样允许发送方发新包，填补被丢包占用的管道空间
• 当收到对新数据的 ACK（恢复 ACK，即确认了丢失包之后的数据），退出快速恢复，cwnd = ssthresh

Reno 的关键点是：快速恢复不是回到慢启动，而是直接从减半后的窗口开始线性增长，节省了一次指数爬坡的往返时延。在丢包率不太高的局域网场景，这个机制效果明显；但丢包率稍高（比如超过 1%）时，Reno 的 cwnd 会被反复打回一半，带宽利用率骤降。

3.4 经典算法对带宽探测的局限：用丢包做信号的天花板

经典拥塞控制把丢包当作拥塞的唯一信号，这导致了三个不可避免的问题。

第一，路由器队列缓冲越大，丢包信号越迟钝。因为路由器不会立刻丢包，而是把多余的数据缓存在内存里，时延越来越大，但 TCP 还在傻傻地线性增长。直到缓存彻底打满才开始丢包，此时网络已经被额外排队延迟拖垮。这叫缓冲膨胀（Bufferbloat），是现代网络的常见病。

第二，对非拥塞丢包无差别惩罚。无线网络的瞬时干扰、光模块瞬断、路由器的随机早期丢包等，都会让 TCP 误判为拥塞并降速一半。我在某局域网里做过实验：正常有线链路里边角丢包率 2%，之类场景 TCP 吞吐量比理论的一半还要低。

第三，RTT 大、带宽高的链路更难收敛。比如卫星链路 RTT 500ms，cwnd 每次只能根据 ACK 反馈来调整，ACK 回来已经很晚了，等检测到丢包再减速，早就错过了最佳反应时间。

Lees 举一个直观对比：如果一条链路 BDP 是 1.5MB，Reno 需要超过 1000 个 RTT 才能在丢包后把 cwnd 拉回峰值。在 100ms RTT 的公网上，这个时间是 100 多秒，用户早就切走了。这就是为什么业界后来开始研究更激进的算法。

4. 用抓包把拥塞控制“看”出来：实操记录

4.1 怎么确认一条连接处于慢启动还是拥塞避免

理论说了这么多，最直接的学习方式是抓包看窗口变化。我在某实验室的虚拟环境里搭了一对 Ubuntu 虚机，用 iperf3 灌流量，同时在发送端用 tcpdump 抓包，观察 cwnd 的演变。

首先开启 SS 命令的拥塞窗口输出。Linux 下可以这样：

bash复制ss -tni | grep -E "send-q|cwnd|rtt" 

或者用 tcpdump 抓包后分析：

bash复制sudo tcpdump -i eth0 -s 100 -nn tcp port 5201 -w /tmp/cwnd_test.pcap

然后在另一台机起 iperf3 -s，发送端执行：

bash复制iperf3 -c 192.168.1.20 -t 10 -P 1

抓包完成后，用 Wireshark 打开，展开任意 TCP 包，在 TCP 头部里能看到 [TCP Window Full] 之类的标记，但注意这一项是接收窗口 rwnd，不是 cwnd。要观察 cwnd 的变化，要用 Wireshark 的 “Tcptrace” 之类的图形化统计功能，或者直接解析 CAck 计数。

在 Wireshark 里可以添加一列 tcp.analysis.bytes_in_flight，这个值是“在途字节数”，它直接受 cwnd 约束。如果你看到它在短时间内成倍增长（1、2、4、8、16 倍这种节奏），说明连接正在慢启动阶段；如果看到它每次只增加一个 MSS 左右，则处于拥塞避免阶段。实测里这个变化非常直观，跑一次你就能把教材里的曲线和真实网络对上。

“在途字节数”这个概念我想再强调一下：它不等于 cwnd，它是实际发出的、还没被 ACK 的数据量。正常情况下它被 cwnd 限制，但由于 ACK 是异步到达的，瞬时值可能略高或略低。你可以在 Wireshark 的 IO 图表里把 tcp.analysis.bytes_in_flight 和 tcp.analysis.ack_rtt 叠在一起画，会看到数据量和时延之间的联动。这是观察 Bufferbloat 最直接的证据工具。

4.2 模拟丢包：直观看到 ssthresh 减半和快速恢复

如果你想亲眼看到丢包触发快速重传，最简单的办法是用 netem 模拟丢包，不需要物理搞坏链路。

bash复制# 在接收端或者中间路由器模拟 1% 丢包
sudo tc qdisc add dev eth0 root netem loss 1%

然后重新跑 iperf3。在 Wireshark 里你会看到大量的 [TCP Dup ACK] 出现，连续三个 Dup ACK 之后，TCP 会发出一个重传包，这是快速重传的现场；紧接着发送速率不会跌零，而是在几毫秒内恢复一些状态，这就是快速恢复的体现。

我用 1% 丢包模拟跑出来的数据是：连接在 4 秒内经历了 12 次快速恢复，cwnd 峰值只有理论值的 60% 左右。这个数字很能说明问题——经典算法在 1% 丢包的公网上，带宽利用率已经损失明显，这也是为什么后来出现 Cubic 时代的新算法。

4.3 用 tc 命令查看当前算法的活跃状态

说一个很实用的排查技巧：在 Linux 上查看一条 TCP 连接的实时状态时，使用：

bash复制ss -i

输出里能看到 cwnd、ssthresh、rtt、delivery_rate 等字段。其中 delivery_rate 是内核估算的发送速率，结合 cwnd 和 rtt 可以快速判断当前连接是否处于满速状态：

• 如果 delivery_rate 明显低于链路带宽，但 cwnd 小于 BDP，说明还有增长空间，可能在慢启动过程中；
• 如果 cwnd 大于 BDP，delivery_rate 上不去，同时 RTT 在攀升，说明数据正在路由器队列里排队，这就是 Bufferbloat 的表现。

这个命令比我用过的很多可视化工具都实用，尤其是排查跨机房传输慢的问题时，先 ss -i 看 cwnd 是不是远小于 BDP，再决定是调窗口还是调算法。少走很多弯路。

4.4 抓包中容易被忽略的细节：初始窗口大小与 ACK 延迟

抓包时还有两个细节值得留意。

第一，不同操作系统默认的初始窗口大小不同。早期实现是 2~4 个 MSS，后来 RFC 6928 将初始窗口提高到 10 个 MSS（约 14KB 左右的现象，Linux 近几年是 10 个 MSS）。这意味着慢启动的起点就不一样。某些老设备、老内核的接收端如果通告了很低的 rwnd，实际发送窗口会被限制在 rwnd 上，再好的拥塞控制也没用。

第二，接收方的 ACK 延迟策略会影响窗口增长的节奏。Linux 默认启用延迟 ACK，即接收方会把 ACK 合并在最多 40ms 内发送。如果发送方已经按慢启动发了 20 个包，但 ACK 合包回来，cwnd 增长的速率会比理论慢。传输小文件时这可能不明显，但传输海量小数据包时影响很大。解决方案是禁用延迟 ACK 或调整 tcp_quickack，不过生产环境一般不建议全局改，我建议按连接级别实验后再动。

5. 现代算法与内核调参：从 Reno 到 Cubic、BBR

5.1 Cubic：高带宽网络的默认选择

随着网络链路带宽不断提高，Reno 的线性增长在长肥网络里显得太慢。Cubic 的改进思路是把窗口增长曲线从线性改成三次函数：窗口增长在接近上次拥塞点时会变缓，离开拥塞点后会迅速恢复。

它的核心行为是：丢包后 cwnd 减半，但之后会以一个可调节的曲线“快速追回”到丢包前的窗口值，而不是像 Reno 那样每 RTT 只加 1 MSS。这个设计在带宽高、丢包少的现代数据中心链路上收益非常明显。

Linux 从内核 2.6.19 开始把 Cubic 设为默认拥塞控制算法，Windows 和 macOS 也都默认采用类 Cubic/Compound 算法。你日常看到的绝大多数传输，都是 Cubic 在管。Cubic 比 Reno 更适合高带宽长时延链路，这句话在教材里很常见，但实际验证起来需要构造高 BDP 环境，普通办公网模拟不出来。

5.2 BBR：不再用丢包当信号，而是用带宽和时延建模

BBR（Bottleneck Bandwidth and Round-trip propagation time）是近几年最受关注的算法。它和经典算法的本质区别在于：它不把丢包当作拥塞信号，而是持续测量瓶颈带宽和最小 RTT，建立一个管道模型，然后以这个模型的最优点为控制目标。

BBR 的出发点是：真实的网络链路容量是客观存在的，你只要测出瓶颈带宽 BW 和传播时延 RTprop，就能算出 BDP = BW × RTprop。发送速率贴着 BDP 走，既不会缓冲排队，又能打满链路。丢包如果发生但未造成瓶颈带宽下降，BBR 可以无动于衷，不减速。

我在某跨云场景实测过：一条 100Mbps 链路，RTT 约 40ms，常规 Cubic 的吞吐量在 80Mbps 左右徘徊；切到 BBR 后，吞吐量稳定在接近 95Mbps。原因很经典：链路或路由中间有一层小缓存，Cubic 把缓存打爆触发丢包后减半，再爬回来又打爆，来回震荡，而 BBR 把队列控制在一个低水位，不触发大量丢包。

当然 BBR 不是银弹。它追求低延迟和满带宽时，可能对链路中其他数据流造成挤压，尤其在有大量背景流量的公网上，BBR 的激进测速行为有时会挤占 Cubic 流的带宽，导致公平性问题。生产环境要不要切 BBR，需要你在自己的链路条件下做 A/B 测试，别盲目抄网上结论。

5.3 Linux 下的算法切换与参数调整实操

修改默认拥塞控制算法非常简单：

bash复制echo bbr > /proc/sys/net/ipv4/tcp_congestion_control

或者更稳妥地写在 /etc/sysctl.conf：

bash复制net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

注意 BBR 建议配合 fq（公平队列）qdisc 使用，否则效果可能打折扣。另外可以用下面命令查看当前支持哪些算法：

bash复制sysctl net.ipv4.tcp_available_congestion_control

如果要回归 Reno 传统行为，改成：

bash复制sysctl -w net.ipv4.tcp_congestion_control=reno

除了算法切换，Linux 下还有几个和拥塞控制强弱相关的参数：

• net.ipv4.tcp_slow_start_after_idle：连接空闲一段时间后，是否重新慢启动。局域网/数据中心链路如果频繁空闲再传数据，建议置 0，否则每次重启连接都要重新爬坡。
• net.ipv4.tcp_notsent_lowat：控制发送缓冲区低水位，能影响发送速率的上限。
• net.ipv4.tcp_rmem / net.ipv4.tcp_wmem：接收/发送缓冲区范围，它限定了 rwnd 的上界。BDP 大于缓冲区时，先调大它们才有意义。

注意调参前先确认你是 root 或有权限修改 /proc/sys，生产环境改完记得持续观察 RTT 和吞吐曲线，别一次改多个变量导致没法定位。

5.4 数据中心场景下的特殊拥塞控制

数据中心是拥塞控制的另一个极端场景：带宽从 10G 到 400G，时延极低，队列极浅，传统丢包信号几乎不可用。谷歌早年提出了 DCTCP（Data Center TCP），它依赖交换机显式拥塞通知（ECN）反馈来精确控制窗口；后续还有 TIMELY、HPCC 等基于时延或带内遥测的算法。

这些算法普通开发者未必用得上，但理解它们背后的共同思路对你面试和排查问题都有帮助：拥塞控制的核心，就是在可用的反馈信号（丢包、时延、ECN、排队深度）里选一个或者几个来建模链路容量，然后围绕模型做控制。抓到这条主线，你再看任何新算法，都会觉得似曾相识。

6. 常见问题与排查技巧实录

6.1 问题速查表：根据现象反推拥塞控制问题

我在实际工作中整理过一份速查清单，遇到传输慢的问题可以直接对着查：

这张表覆盖了我遇到过的绝大多数“链路明明很空但速度上不去”的情况。排除拥塞控制问题之前，先用 iperf3 测出单向极限带宽，再用 ss -i 对照 TCP 状态，能省掉大量抓包时间。

6.2 超时重传与快速重传的区分：为什么有时候 RTO 大

很多人分不清超时重传和快速重传的区别。超时重传是发送方等待确认超时后直接重发，RTO 默认根据 RTT 的动态波动计算，最小下限通常 200ms（Linux 早期默认）或 1s（老规范）。快速重传则不需要等超时，靠 3 个重复 ACK 触发，可用带宽不至于断崖下跌。

你可以这样记忆：

• 快速重传 = 路上的包丢了，但路还通，后续包还能回来，所以通过重复 ACK 就能感知；
• 超时重传 = 可能整条路都堵了，后续包也回不来，只能等超时信号，必须把窗口彻底重置。

在实际排查里，如果你看到重传包都是通过超时触发的，往往意味着丢包率极高或路径中断；如果只是快速重传，说明网络还在工作，只是偶发丢包。

6.3 实测：丢包率从 0 到 2% 时拥塞控制吞吐量的变化

我做过一组简单的对比测试，发出来供参考。环境是两台 Linux 虚机，物理机在同一台宿主机，虚拟网卡模拟 1Gbps 链路，RTT 约 0.5ms，关闭接收端延迟 ACK 干扰，分别用 Reno、Cubic、BBR 跑 iperf3 单流，丢包率用 netem 注入：

同一链路、同一网卡，丢包率到 2% 时 Reno 几乎跑不动，而 BBR 还能维持六成以上。这组数据很直观地解释了为什么公网、无线链路等有丢包的场景，很多人选择切 BBR。

但要注意，测试环境是干净的虚拟链路，真实公网上 BBR 的公平性争议仍在，所以我的建议是：如果你是服务器端应用、能接受占用较多带宽，切 BBR 往往收益明显；如果是常规终端用户、多人共享带宽，保持 Cubic 更稳妥。

6.4 独门排查心得：抓包之后先看这三个值

最后分享一个我常用的排查顺序。抓完包不要先数重传，先看三个值：

第一是 RTT。如果 RTT 持续上升但吞吐量不再上升，拥塞窗口已经把队列打满了，这是 Bufferbloat 的典型特征。第二是 Bytes-in-flight 的曲线形状。如果图形是锯齿状规则起伏，说明拥塞控制反复进入快速恢复；如果是平台期加低谷，说明超时重传在主导。第三是接收窗口。如果 rwnd 远小于网卡带宽的 BDP 估算，瓶颈根本不在网络而在接收方。

这三个值扫完，90% 的 TCP 拥塞问题都能定位到大方向。再往下挖，就是丢包发生在哪个跳点的问题了，那是另一个话题。

我个人的体会是，拥塞控制学到最后，不是背出五个算法名字就能算懂。不亲手抓一次包，你很难体会一个 ss -i 里从 10 到 640 的 cwnd 跳动意味着什么。哪怕在你本机的回环接口跑一次 iperf3，观察窗口在慢启动阶段的翻倍节奏，都比看十遍教材管用。把这个思路带到你的项目里，以后再遇到“网速很奇怪”的问题，你至少知道第一眼看哪里。