姬轩亦先说一个真实发生过的场景。凌晨一点，线上服务突然变慢，任何一个接口都像被按住了暂停键。开发兄弟第一反应是查数据库、查磁盘、揪 CPU，全部正常，内存也宽松得很。又怀疑是线程池满了，一看连接数也没到上限。最后抓了 tcpdump，才发现问题根本不在应用层：链路上塞满了重传包和重复 ACK，数据往返时延从平时的几毫秒涨到了几百毫秒。那一刻，你才真正意识到，TCP 拥塞控制不是一个只出现在计算机网络课上的名词，它是随时会在生产环境咬人的那根弦。
我当时处理完故障后，把 TCP 拥塞控制从头到尾翻了一遍，越翻越觉得以前背过的“慢启动”“拥塞避免”太虚了。这篇就把梳理出来的内容整理出来，适合正在学网络基础的同学，也适合经常遇到“机器资源充足但服务就是慢”这种问题的后端、运维和嵌入式开发者。你可以把它当成一份从理论到排查的实用参考，看完之后，再去抓包看窗口变化，理解会完全不一样。
围绕 TCP 和拥塞控制这两个核心关键词，这篇文章会从一次故障现场讲起，然后把慢启动、拥塞避免、快速重传、快速恢复这些核心机制拆开讲清楚，再对比常用拥塞控制算法各自的取舍，最后给出 Linux 环境下可落地的观察和调优手段。不是背概念，而是把这些机制放在真实网络里看它们怎么配合、怎么失效、怎么救场。
1. 拥塞现场：为什么资源充足，请求却卡死
1.1 拥塞的本质：一条共享管道里的堵车
拥塞并不是网络“坏了”。恰恰相反，它往往是网络设备按照设计工作时的副产物。以太网和 IP 网络天生就是统计复用的，多个数据包共享路由器和交换机的缓冲区。当多个发送方同时往同一段链路灌流量，链路出口的缓存队列就会慢慢膨胀。队列满了之后，新到的数据包只能被丢弃。丢包之后，TCP 发现收不到 ACK 或者收到重复 ACK，就会立刻执行减速动作；减速之后链路空出来了，带宽又没跑满，于是又开始加速探测。如此循环往复，产生了教科书上那句话：TCP 的发送速率会围绕链路容量上下振荡。
我看到过太多人把“卡”归到应用代码头上，结果排查到最后，罪魁祸首是网络设备缓存溢出。所以理解拥塞控制，首先要建立一个基本认知：TCP 发送方无法直接知道网络中间设备当前是什么状态。路由器忙不忙、交换机队列排了多长，这些信息 IP 协议根本不会回传。TCP 唯一能看到的信号，就是 ACK 回来得有多快、有没有重复、有没有超时。拥塞控制本质上就是在对网络状态一无所知的前提下，通过丢包和延迟这些有限信号来猜测链路拥挤程度，再反过来调整自己的发送速率。这就像你开车看不到前方几公里外的路况，只能通过前方车辆的刹车灯来猜测是不是堵了。
1.2 流量控制与拥塞控制：两个窗口，别混为一谈
很多教材喜欢把流量控制和拥塞控制放在一起讲，但对初学者来说，这两件事的触发对象完全不同。流量控制解决的是“接收方能吃多少”：接收方在自己的接收缓冲区快满时，会通过 ACK 报文里的 window 字段告诉发送方“兄弟你先停一下”。这个窗口叫接收窗口，记作 rwnd，只在通信双方之间起作用。拥塞控制解决的是“网络中间能不能扛住”：瓶颈可能发生在任何一条链路上、任何一个路由器上，接收方根本无从知道，只能由发送方自觉处理。这个窗口叫拥塞窗口，记作 cwnd。
实际发送数据的限制不是单独看某一个窗口，而是两者取小：有效发送窗口 = min(rwnd, cwnd)。你本地内存和接收方缓冲区再大，网络不行，吞吐照样上不去；网络状态很好，但接收进程读数据太慢，rwnd 被压到几 KB，发送方怎么提速也没用。生产环境中见过不少案例，接收进程读取慢，接收窗口被压到几 KB，发送方再怎么调拥塞控制算法也飞不起来。所以在排查吞吐问题时，同时看两端的 socket buffer 是非常重要的一步。
1.3 TCP 探测网络的三类信号：ACK、重复 ACK 和超时
TCP 的发送方只能依赖三种信号来感知网络拥塞。第一类是正常 ACK：每个报文段被确认，说明路径还算通畅，发送方可以继续加码。第二类是重复 ACK：收到相同序号的 ACK 说明接收方期待的数据包里有一部分没到，网络可能正在丢包。第三类是 RTO 超时：很长时间收不到任何 ACK，大概率是链路已经拥堵到缓存全满，甚至网络中断。慢启动、拥塞避免、快速重传、快速恢复这些机制，追根究底全都围绕这三种信号做文章。
这三种信号对应的处理力度也是从轻到重。出现轻微乱序时只看到一个两个重复 ACK，发送方基本不理会；连续出现三个重复 ACK，发送方会认为丢包并进入快速重传；RTO 超时则是 TCP 最不愿看到的场景，因为一旦超时，整个窗口都要清零重来，代价极高。理解了这个信号强度阶梯，后面看算法行为就会非常清晰。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 慢启动与拥塞避免：TCP 的油门和刹车
2.1 慢启动：从试探开始，指数扩张
慢启动这个名字，说实话很有误导性。它单次发送的数据量确实很小，但增速是指数级的。TCP 在新建连接时不敢一口气把带宽全部占掉，因为系统根本不知道链路可用带宽是多少。所以早期规范把初始拥塞窗口设得很小，老协议栈甚至只有 1 个 MSS，也就是 1460 字节左右。后来 RFC 6928 把初始值提高到 10 个 MSS，大约 14KB。这个值相当于你刚上高速时先踩到 60，而不是一脚油门顶满。
为什么说它指数扩张？因为发送方每收到一个 ACK，就允许自己多发送 1 个 MSS 的新数据。换句话说，一个 RTT 内所有已发送数据全部被确认后，窗口就翻倍。比如初始 cwnd 是 10 个 MSS，第一个 RTT 发出 10 个包；这些包全部确认后 cwnd 变成 20 个 MSS；下一个 RTT 就是 40、80、160……几个 RTT 下来，窗口就非常可观。压缩在时间轴上，就是“小步子快跑”的状态。
这种激进增长当然有风险：如果网络实际容量只有当前窗口的一半，很快就会丢包。但 TCP 的决策是宁可先冲一下，再通过丢包信号立刻减速，也不能慢吞吞地探测浪费带宽。大多数链路在连接建立初期都是空闲的，快速占满管道能显著降低小文件的传输时间。对短连接场景而言，整个 HTTP 请求可能都发生在慢启动阶段，这时初始窗口大小甚至会直接影响页面首屏时间。
2.2 ssthresh 与拥塞避免：过了阈值就老实加性增长
拥塞避免阶段由 ssthresh 这个慢启动阈值决定。当 cwnd 小于 ssthresh 时，走慢启动；当 cwnd 超过 ssthresh 时，进入拥塞避免。现代 Linux 的初始 ssthresh 通常被设成最大值，比如 2^30 字节左右，意思是连接建立初期全部走慢启动，直到真正遇到丢包信号，ssthresh 才会被拉下来，成为后续增长的约束线。
拥塞避免的策略是加性增长：每个 RTT 周期，cwnd 只增加 1 个 MSS。慢启动是指数扩张，拥塞避免是线性增长，两者的对比非常明显。为什么超过阈值以后要小心翼翼？因为此时窗口已经接近之前探测到的链路容量上限，再大步试探很容易制造拥塞。线性增长相当于在“基本够用的窗口”上逐步加码，一点点往上蹭，用更谨慎的节奏换取稳定。
计算机网络教材通常把这一整套策略叫 AIMD，也就是加性增加、乘性减小。加性增加就是刚才说的拥塞避免阶段，每个 RTT 只加一个 MSS；乘性减小则是指出现丢包信号后，把 ssthresh 立刻减半。AIMD 的美妙之处在于它足够简单，而且在多个 TCP 连接共享同一条瓶颈链路时，能收敛到大致公平的带宽分配。不同连接的 cwnd 会围绕公平点来回震荡，但整体能维持相对均衡。
2.3 用带宽时延积理解窗口到底要多大
看拥塞控制光理解窗口还不够，还需要把窗口和链路物理特性挂钩。给定 MSS 和 RTT 的情况下，TCP 单连接理论极限吞吐约等于 cwnd 乘以 MSS 再除以 RTT。而实际限制窗口的是 min(rwnd, cwnd)。这里引出一个网络里非常重要的概念：带宽时延积，即物理带宽乘以 RTT，它表示一条链路在某个时刻能容纳的在途数据总量。
假设一条链路物理带宽是 100Mbps，RTT 是 40ms，那么这条链路能容纳的在途数据是 100Mbps 乘以 0.04 秒，大约 500KB。要让这条链路跑满，发送窗口必须达到 500KB 以上。如果接收窗口只有 64KB，那么吞吐上限就锁死在 64KB 除以 0.04 秒，约 13Mbps。很多线上“带宽明明很足但传得慢”的问题，就是这样被窗口掐死的。拥塞控制算法的目标可以理解为：在不造成持续丢包的前提下，让 cwnd 尽量接近链路容量对应的窗口值。
3. 快速重传与快速恢复：丢包后的自我救赎
3.1 靠超时等待太慢，于是有了重复 ACK
TCP 发现丢包的第一反应机制是超时重传。发送端设置一个 RTO，超过这个时间还没收到 ACK，就重传对应报文。RTO 不是固定值，内核会根据 RTT 的波动动态计算。RTT 越平稳，RTO 越接近 RTT；RTT 抖动越大，RTO 越被拉长，避免误判。经典算法是 SRTT 和 RTTVAR 的加权组合，RFC 6298 里有完整定义，这里不展开公式，只要记住它是“跟随 RTT 变化的自适应重传计时器”就够了。
但 RTO 有一个致命短板：太慢。早期网络拥塞时 RTO 动辄几百毫秒甚至一秒，而一个 RTT 本身可能只有几十毫秒。为了等一个重传计时器，整个发送窗口都可能停摆。于是快速重传机制出现了。接收方收到乱序包时，会把最后一个按序到达的包的序号作为 ACK 回给发送方，而不是确认乱序数据本身。发送方连续收到 3 个相同的重复 ACK，就可以判定有报文丢在了路上，立即重传它，完全不必傻等 RTO 到期。
3.2 为什么偏偏是三个重复 ACK
新手常问的一个问题是：为什么不是 2 个、4 个，非得是 3 个？这个阈值本质上是工程经验与误判风险的妥协。只出现 1 个重复 ACK 太容易误判——网络里乱序现象很常见，包延迟抖动也会让接收方暂时缓存一小段数据，从而产生一次重复 ACK。如果发送方看到重复 ACK 就重传，会导致大量不必要的重传，反而加剧拥塞。阈值定到 3，既保证“已经有几个包过去了但目标没有按序确认”这个证据链足够扎实，又不会拖延太久。
收到 3 个重复 ACK 后，发送方会把 ssthresh 更新为 cwnd 的一半，同时把 cwnd 降低到 ssthresh 的水平，然后重传丢失的报文。注意这里是乘性减半，而不是退回到初始窗口，也不是直接清零。因为收到重复 ACK 至少说明后续数据包还在继续到达接收端，网络并没有完全瘫痪，只是出现了拥塞迹象。保留一半窗口，就是为了让链路继续维持一定的吞吐。
3.3 快速恢复：窗口减半，但保持管线不空
光有快速重传还不够，如果重传丢包后窗口立刻清零，链路会瞬间出现空闲，这在高速长距离链路上是巨大的浪费。快速恢复的思路是：既然收到了重复 ACK，说明后续数据包大部分都已经到达接收端，因为接收端能正常发回 ACK，链路还没有被堵死。那就在重传之后，每收到一个重复 ACK，把 cwnd 临时增加 1 个 MSS，允许发送端继续发送后续新数据，填补丢包造成的管道空档。等到收到确认新数据的 ACK 后，cwnd 回落到砍半后的 ssthresh，退出快速恢复。
这里有一个很微妙的点：快速恢复期间，cwnd 是在被临时“抬高”的，这并不代表链路真的能接受这么多数据，而是 TCP 在猜测“这些重复 ACK 对应的数据已经从网络里清出去了，网络腾出了一点空间”。这种猜测在大多数场景下是成立的。经典 Reno 算法在处理同一窗口多个丢包时并不完美，NewReno 用部分 ACK 机制做了修正，Linux 默认的 Cubic 又在这个基础上叠加了更复杂的窗口函数，但“收到重复 ACK 就重传、窗口减半、恢复期间继续注入数据”这套底层思想仍然不变。
3.4 超时重传与快速重传的代价对比
快速重传相比超时重传，最核心的优势是省掉了等待 RTO 的时间。假设一个 RTT 是 100ms，RTO 是 300ms，超时重传需要空等 300ms 才能做第一次补救，而快速重传在接收端发现乱序后立刻回重复 ACK，发送端收到 3 个重复 ACK 时可能只过去了 100 到 200ms。在延迟敏感的互动场景里，这个差距直接决定用户是否感知到卡顿。
但如果整个窗口的数据包全部丢失，接收端根本收不到数据，也就不会发重复 ACK，此时只能依赖 RTO 兜底。这也是为什么 RTO 不能取消，快速重传只是把“丢包检测”的效率提升了一个等级，而基础保障仍然是超时重传。两者是互补关系，而不是替代关系。
4. 从 Reno 到 BBR：拥塞控制算法的演进逻辑
4.1 Reno 和 NewReno：教科书上的经典组合
Reno 算法把拥塞控制拆成四个状态：慢启动、拥塞避免、快速重传、快速恢复。它用 ssthresh 划了一条线，线上走慢启动，线下走拥塞避免；遇到重复 ACK 进入快速重传和快速恢复；遇到 RTO 则一切归零。这套模型简单清晰，至今仍是学习拥塞控制的必修内容。但它的缺点是：一旦出现多个丢包在同一窗口内发生，经典 Reno 的处理效率就很低，因为它每处理一个丢包就会退出快速恢复，剩下的丢包得等下一个重复 ACK 才能被发现，结果多次减半，吞吐恢复很慢。
NewReno 的改进在于引入了部分确认的概念。当快速恢复期间收到的是部分 ACK，也就是只确认了一部分重传数据，发送方会继续留在快速恢复状态，直到所有丢包都被重传完。这样即使一个窗口里丢了多个包，也只需要一次降窗，恢复速度显著提升。NewReno 是 Linux 内核长期支持的算法之一，虽然现在已经不是默认选项，但很多嵌入式设备和老旧系统还在用，理解它仍然是理解后续算法的基础。
4.2 Cubic：Linux 默认算法的设计思路
Cubic 是 Linux 内核从 2.6.19 版本开始使用的默认拥塞控制算法，专门针对高带宽、大延迟的“长肥网络”做了优化。它最特别的地方是窗口增长不再用固定线性斜率，而是用一个三次函数曲线来决定 cwnd 的恢复节奏。丢包发生后，窗口会快速上升，逼近上次发生丢包时的窗口值；接近那个值时，增长放缓，在一个相对平稳的区间保持较高的吞吐；如果长时间没有丢包，窗口又开始缓慢上爬，继续探测链路余量。
这种设计的价值在哪里？Reno 在高带宽链路上恢复太慢，每个 RTT 只增加 1 个 MSS，对于 100MB 级别的 cwnd 来说，要恢复到丢包前需要数万秒。Cubic 记住了“上次到达过的最大窗口”，并在它附近稳定，不会因为一次丢包就长期处于低吞吐状态。这也是为什么 Cubic 能成为默认算法，它在普遍场景下足够稳健，对大部分 Web 服务、视频传输、文件下载都有良好的表现。
4.3 BBR：放弃丢包信号，改用带宽和时延
谷歌提出的 BBR 可以说是对传统拥塞控制理念的一次大颠覆。传统算法把丢包当作拥塞的主要信号，窗口一砍再砍；BBR 却认为，现代网络里很多丢包是路由器缓冲区设计不当、无线链路误码等原因造成的，不一定代表链路真的拥堵。如果纯粹按丢包降速，会在高质量链路上浪费大量带宽。所以 BBR 直接测量两个物理量：瓶颈链路带宽和链路最小 RTT。两者相乘，就得出了瓶颈管道的容量，然后让发送速率在这个容量附近精确巡航。
BBR 在跨洋高延迟链路、有一定随机丢包的无线上网场景中，往往能比 Cubic 跑出高得多的吞吐。但它不是银弹。一个常见副作用是：如果中间路由器的缓冲区很深，BBR 会主动占满缓冲区，造成较大排队延迟。在共享瓶颈链路上，BBR 对流抢占带宽的能力比 Cubic 强，可能挤压其他连接的带宽。所以生产环境选择 BBR 还是 Cubic，不能拍脑袋，最好拿真实业务流量做对比测试。
4.4 主流算法怎么选：一张对照表
| 算法 | 拥塞信号 | 窗口增长特点 | 适用场景 | 注意事项 |
|---|---|---|---|---|
| Reno | 丢包 | 加性增加，乘性减小 | 教学实验、老旧系统 | 高带宽下恢复慢 |
| NewReno | 丢包 | 支持部分确认 | 嵌入式、兼容性要求高的环境 | 功能可靠，性能一般 |
| Cubic | 丢包 + 时间函数 | 三次函数曲线增长 | Linux 默认通用场景 | 最稳妥的默认选择 |
| BBR | 带宽 + 最小 RTT | 按链路容量巡航 | 高带宽高延迟、随机丢包链路 | 注意排队延迟和公平性 |
选择算法时，我个人的经验是：如果你的业务是短连接为主，Cubic 已经够好，没必要换 BBR；如果是跨地域长连接、内网大文件传输、或者公网长链路，可以开 BBR 做个灰度实验，重点观察延迟和同链路其他业务的体验变化。
5. 动手验证：用 Linux 命令观察并调优拥塞窗口
5.1 用 ss 命令查看当前连接的真实窗口状态
了解了理论，接下来就是把拥塞窗口“拉出来遛遛”。Linux 下最常用的观察命令是 ss 的扩展输出。建立一个持续连接后用 ss -tni 查看，你会看到类似这样的输出：
code复制State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 192.168.1.10:5000 192.168.1.20:443
cubic rto:204 rtt:17.112/21.912 ato:40 mss:1460 pmtu:1500
cwnd:128 ssthresh:65535 bytes_acked:1048576 bytes_received:512000
retrans:0 rttvar:6.5
关键字段要看得懂：rtt 是内核实时统计的平均往返时延，后面跟着方差；cwnd 是当前的拥塞窗口，单位是 MSS；ssthresh 是当前慢启动阈值；retrans 是连接累计重传次数。如果 retrans 持续增加，说明链路有丢包；如果 cwnd 长时间停留在几百甚至更低，而物理带宽很高，就要怀疑是拥塞控制算法太保守还是接收窗口太小。
测试时不要用浏览器或普通工具，建议用 nc 或 iperf3 建立一条稳定连接，同时观察另一边的输出。发送大文件时用 iperf3 -c 目标IP -t 60 就能轻松拉出一条连续流量，此时再看 ss 的 cwnd 变化，比看抽象公式直观太多。
5.2 用 tc netem 人为制造丢包和延迟
想验证拥塞控制行为，最可控的办法是人为制造网络损伤。Linux 自带的 tc 配合 netem 模块可以模拟延迟、丢包、乱序。比如给 eth0 网卡加 5% 丢包和 50ms 延迟：
bash复制tc qdisc add dev eth0 root netem loss 5% delay 50ms
跑一轮 iperf3，对比没有丢包时的吞吐，同时观察 ss -tni 里的 cwnd 和 retrans 变化。做完实验要记得清理：
bash复制tc qdisc del dev eth0 root
这个实验能非常直观地验证一个结论：丢包率上升到一定程度后，TCP 传输吞吐会断崖式下降，不是线性下降。原因就在于拥塞控制算法会不断把窗口砍半，然后又在慢启动和拥塞避免之间往返。网上几乎所有“TCP 吞吐上不去”的案例分析，最后都能追溯到链路丢包和窗口限制这两个因素。在你自己可控的实验环境里亲手复现一次这个现象，比看十篇理论文章都管用。
5.3 服务端 sysctl 参数调优的几个关键开关
生产环境里，和拥塞控制直接相关的内核参数其实不多，但每个都很关键。最常用的几个如下：
bash复制# 查看当前拥塞控制算法
sysctl net.ipv4.tcp_congestion_control
# 切换为 bbr（需要内核支持）
sysctl -w net.ipv4.tcp_congestion_control=bbr
# 空闲一段时间后是否重置 cwnd，默认 1，长连接高频率发送可关闭
sysctl -w net.ipv4.tcp_slow_start_after_idle=0
# 发送和接收缓冲区范围，决定 rwnd 上限
sysctl net.ipv4.tcp_wmem
sysctl net.ipv4.tcp_rmem
# 是否缓存连接的历史指标，跨连接优化时可能关闭
sysctl -w net.ipv4.tcp_no_metrics_save=1
tcp_slow_start_after_idle 这个参数值得多解释一句。默认开启时，一条连接空闲几秒后，内核会把 cwnd 重置回初始值，这是为了给其他连接腾出共享带宽。但如果你维护的是一批长连接、长时间保持心跳、随时可能发送关键消息，重置 cwnd 会导致第一条消息又要重新走一次慢启动，加快初始化。
tcp_wmem 和 tcp_rmem 控制的是 socket 缓冲区的动态范围，它们通过影响 rwnd 间接影响吞吐。默认值通常是 4096 到 16MB 之间，内核会根据实际流量自动调整。手动调大缓冲区的意义在于：当链路带宽和 RTT 都很高时，系统需要足够的缓冲区才能容纳整个带宽时延积，否则窗口被缓冲区卡住，再好的拥塞控制算法也白搭。
6. 线上排障时容易忽略的拥塞相关坑
6.1 先看窗口，再看丢包，别一开始就怀疑代码
处理过几次线上“服务慢但资源正常”的故障后，我形成了一套相对固定的排查顺序。先看两端 socket 缓冲区是否充裕，用 ss -tni 看 rwnd 有没有被收到很小；再观察 RTT 是否异常增大、retrans 是否持续上涨；最后才回到应用层看业务耗时。很多团队一遇到慢请求就堆日志、查 SQL，反而忽略了 TCP 层正在发生猛烈重传。
举个例子，有次只看到整体响应变慢，所有 CPU、内存、磁盘指标都正常，最后发现是两台机器之间走了跨公网专线，链路丢包率在高峰期达到 3%。3% 的丢包率对 TCP 来说就是一场灾难，因为它会频繁触发快速重传和窗口减半，实际吞吐掉到理论值的三分之一以下。这种问题用 tcpdump 抓 30 秒包，数一数重复 ACK 的数量，立刻真相大白。
6.2 慢启动重置对高频长连接的影响
另一个容易被忽略的坑是 tcp_slow_start_after_idle。默认情况下，空闲的连接会被重置 cwnd。很多内部服务用长连接做推送或心跳，平时流量很小，关键时候突然要传一个大对象，结果第一个 RTT 只能用初始窗口发送，要经过好几轮慢启动才能把速度提起来。
如果你的业务对冷启动第一个请求有较高的性能要求，而这类长连接又确实需要频繁传输数据，可以考虑在服务端把这个参数设为 0。但要注意，这样做会让空闲连接在恢复传输时直接沿用之前的窗口，对共享链路上的其他连接可能造成一定不公平。是否开启，取决于业务对流量的敏感度和链路的余量。
6.3 BBR 不是万能的，实际使用要灰度
在租用的云服务器上开启 BBR，往往能立刻看到下载速度的提升，我也这么干过。但放到复杂业务组网里，BBR 的表现不一定那么美好。它为了探测瓶颈带宽，会周期性以略高于估算带宽的速率发送数据，在路由器缓冲区较深时容易造成延迟上升。如果同一条链路上还有其他交互型业务，很可能出现“大流量下载拉高了整体延迟”的情况。
所以我现在的习惯是：先在小范围服务器上开启 BBR，对比开启前后的 P99 延迟、重传率和丢包率，再决定是否全量。尤其注意那些既承载实时接口、又承载文件下载的网关机器，BBR 带来的带宽收益可能被延迟劣化抵消，必须用数据说话。
6.4 容器网络环境下的额外注意点
现在大量服务跑在容器里，排查拥塞问题时要有“看整体”的意识。容器内部的 TCP 状态统计在宿主机网络命名空间里，ss 看到的是宿主机视角的连接信息。当容器网络使用 bridge 或 overlay 模式时，还会引入额外封装和转发延迟，这些都会被计入 RTT 和重传统计。在容器里抓包有时候看不到完整握手过程，因为外部流量经过了 NAT 或 DNAT，这时需要在宿主机上抓到 eth0 的包才完整。
另外，容器文件系统层和宿主机之间的网络路径也可能成为瓶颈，比如经典的“容器跨节点互访带宽受限”问题，很多情况下不是 TCP 拥塞控制导致，而是 overlay 网络本身封装开销过大。此时单纯调拥塞控制参数没什么用，先缩短物理链路和降低封装层级才是正路。把拥塞控制机制搞清楚，能帮你把问题定位到真正需要处理的网络层，而不是在错误的方向上反复调参。
我个人的体会是，拥塞控制最考验人的不是概念背得有多熟，而是能否把“窗口变化”和“线上现象”对应起来。多用 ss 观察、多抓包分析，把慢启动那一轮轮的指数增长、快速重传那一次次的窗口减半变成你对网络状态的直觉，之后再遇到任何“卡顿”问题，你会先从 TCP 层的信号里找答案，而不是瞪着 CPU 使用率发呆。这些机制一旦内化成常识，排查效率会提升得非常明显。