TCP_NODELAY场景下丢包后快速重传异常问题咨询

首先得明确：TCP_NODELAY只负责禁用Nagle算法（不让小报文攒一起发），但管不了TCP的拥塞控制和滑动窗口逻辑——这就是你遇到问题的核心原因。

为什么丢包后会出现「新报文仅在收到新ACK时才发送」？ #

当你的连接发生丢包、触发快速重传后，TCP会进入快速恢复阶段，拥塞窗口（cwnd）的调整逻辑会变得保守：

• 首先把慢启动阈值（ssthresh）降到当前cwnd的一半
• 拥塞窗口会被调整为 ssthresh + 3*MSS（因为3个重复ACK说明接收方已经收到了3个后续报文，有一定的窗口空间）
• 在快速恢复期间，每收到一个重复ACK，cwnd就增加1个MSS；直到收到丢失报文的ACK，才退出快速恢复，把cwnd设为ssthresh

如果你的发送速率（每66ms一个报文）和调整后的cwnd不匹配，比如cwnd被降到了仅1个MSS，那发送方的可用窗口（min(cwnd, 接收窗口rwnd)）就只能容纳一个报文。这时候你每发一个报文，窗口就满了，必须等接收方的ACK回来释放窗口，才能发送下一个——自然就变成了「跟着ACK节奏发」，而不是你预期的每66ms主动发送。

你提到的「窗口大小变大」，大概率是快速恢复阶段cwnd逐步增长的过程，但这个增长是基于ACK触发的，所以发送节奏还是被ACK牵着走。

怎么验证和解决？ #

• 切换拥塞控制算法：默认的CUBIC算法在拥塞后的恢复比较保守，适合高吞吐量场景，但对低延迟持续发送的场景不太友好。可以尝试切换到BBR算法（执行命令 sysctl -w net.ipv4.tcp_congestion_control=bbr），它基于带宽和RTT来调整窗口，更能维持稳定的发送速率。
• 确认应用层发送逻辑：确保你是每66ms生成数据后就立即调用send()，没有在应用层做缓存攒包的操作。
• 调整接收窗口大小：如果接收方的接收窗口（rwnd）过小，也会限制发送方的发送速率。可以让接收方调整TCP接收缓冲区大小（执行命令 sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"），保证rwnd足够容纳多个报文。
• 查看TCP内部状态：用ss -ti <你的连接>或者tcpdump -vv抓取更详细的TCP选项，确认cwnd和rwnd的具体数值变化，定位是拥塞窗口还是接收窗口在限制发送。

你提供的抓包示例 #

10:18:16.622232 IP 184...*.42766 > 193...

内容的提问来源于stack exchange，提问作者laughing