yd_214179807的论坛回复_云社区-华为云

先说结论：TCP 拥塞控制是发送方在“不知道网络还剩多少容量”的前提下，用拥塞窗口 cwnd 做“试探—反馈—调整”的闭环。收到 ACK 说明路还通畅就涨窗口，丢包或超时说明网络吃紧就降窗口，目标是把吞吐推到接近瓶颈带宽，同时不把中间设备的队列打爆。下面按题主要求逐一说明。一、慢启动（Slow Start）目标是连接建立之初快速探测可用带宽，但又不敢一上来就发满。做法：cwnd 从初始窗口（现代 Linux 内核约 10 个 MSS）起步，每收到一个 ACK 就把 cwnd 加 1 个 MSS，效果是每个 RTT 翻一倍，指数增长。当 cwnd 达到慢启动阈值 ssthresh，或发生丢包时，就转入拥塞避免或退让。名字有迷惑性：“慢”是相对“上来就按接收窗口全速发送”而言的，它其实是四个机制里涨得最快的。二、拥塞避免（Congestion Avoidance）进入条件是 cwnd >= ssthresh。做法改为“加性增”：每收到一个 ACK，cwnd 增加 MSS×MSS/cwnd，相当于每个 RTT 只涨约 1 个 MSS，线性增长，小心翼翼地继续试探剩余带宽。这和丢包时的“乘性减”合在一起，就是经典的 AIMD（加性增、乘性减）。三、快速重传（Fast Retransmit）信号是连续收到 3 个重复 ACK。逻辑：后续报文还能到达接收方，说明链路没堵死，只是中间丢了个别包；于是干脆不等重传定时器（RTO）超时，立即重传疑似丢失的那个段。注意乱序也会产生重复 ACK，“3 个”是一个工程上的经验阈值，代表“大概率真的丢了”，不能把它当成丢包的铁证。四、快速恢复（Fast Recovery）紧随快速重传之后。既然链路还能通，就不必像超时那样把窗口打回 1：把 ssthresh 设为当前 cwnd 的一半，cwnd 设为 ssthresh（Reno 还会临时加上已确认的重复 ACK 数），然后直接进入拥塞避免继续线性增长。关键区分要记住“超时归零、重传减半”：RTO 超时被视为网络严重拥塞，cwnd 回到 1 MSS 重新慢启动；3 个重复 ACK 只是轻度拥塞，减半即可。补充一个容易混淆的点：发送方实际在途字节数上限 = min(cwnd, rwnd)。rwnd 是接收方通告的接收窗口，管“对端接不接得住”；cwnd 由拥塞控制决定，管“网络允不允许发”。两者是两套独立的约束。五、CUBIC 与 BBR 的思路差异相同点：都是为了解决 Reno 在高带宽时延积（BDP）链路上一个随机丢包就腰斩窗口、吞吐损失过大的问题。CUBIC（曾长期是 Linux 默认）：仍是“丢包驱动”。窗口按距离上次丢包事件的时间做三次函数增长——离峰值越远涨得越快，接近历史峰值时涨得越慢，避免一下子冲过头。优点是对 RTT 不敏感，长肥管道上恢复快；缺点是只有丢包才降速，在路由器缓冲区很大的链路上会把队列填满，推高延迟，也就是 bufferbloat。BBR（Google 提出，Linux 4.9+ 可选）：改成“模型驱动”。不再把丢包当拥塞信号，而是持续测量瓶颈带宽（BtlBw）和最小 RTT（RTprop），按 BDP = 带宽 × RTT 算出“网络正好装满”的发送量，并周期性探测更高带宽、排空队列。优点是延迟更平稳，随机丢包链路（WiFi、跨洋）下吞吐更稳；缺点是多条 BBR 流共存、或与 CUBIC/Reno 混跑时，公平性不如传统算法。一句话区分：CUBIC 问“上次丢包时窗口是多大，我往那个方向逼近”；BBR 问“这条路实际能走多快、最小延迟是多少，我按算出来的量发”。六、动手验证（Linux）1. 看当前算法：cat /proc/sys/net/ipv4/tcp_congestion_control；切换算法先在测试机验证：sysctl -w net.ipv4.tcp_congestion_control=bbr。2. 看窗口实时变化：ss -ti，关注 cwnd、ssthresh、rtt、retrans 字段，直接判断窗口在涨还是在退。3. 先算 BDP 再谈调参：例如 100 Mbps × 50 ms ≈ 625 KB，窗口到不了 BDP 就跑不满带宽，别先怪算法。云上小提示：如果在云服务器上遇到“带宽没跑满、单连接吞吐低”，先确认是不是 RTT 大导致的 BDP 未满足；另外 EIP/共享带宽的限速丢包从发送方看和链路拥塞一模一样，会触发不必要的窗口回退，判断方法是丢包集中在带宽打满时刻、且 RTT 没有同步上升，先确认是不是真拥塞，再谈调算法。