高延迟（175ms）链路吞吐量异常：TCP慢启动提前退出原因排查

• 拥塞窗口触达慢启动阈值：多数操作系统的TCP栈默认慢启动阈值（ssthresh）并不高（比如部分Linux版本默认是10个MSS），当发送第11个段后，拥塞窗口（cwnd）刚好达到ssthresh，TCP会自动从慢启动的指数增长模式切换到拥塞避免模式——此时吞吐量改为线性增长，而非继续指数上升。你可以通过服务器端的ss -ti <目标套接字>或netstat -s命令查看当前cwnd和ssthresh的具体数值来验证。

• TCP拥塞控制算法的自适应调整：如果服务器使用了BBR这类现代拥塞控制算法，其带宽探测阶段的行为和传统慢启动差异明显，可能让你误以为是退出慢启动。另外，部分算法会对高延迟链路的RTT抖动更敏感，哪怕没有丢包，微小的ACK延迟（比如你提到的1ms偏差）也会被判定为潜在拥塞，触发速率增长放缓。

• 应用层或TCP栈的流量控制：即便网络层接收窗口未填满，若服务器端应用没有及时读取TCP接收缓冲区的数据，TCP栈会主动限制发送速率；或者开启了Nagle算法或延迟ACK策略，导致报文发送节奏改变，看起来像是吞吐量增长停滞。

• ACK携带隐式拥塞信号：第11个段的ACK可能携带了ECN（显式拥塞通知）标记，或者该ACK的RTT较之前出现异常抖动，被TCP栈解读为轻微拥塞信号，从而提前退出慢启动进入拥塞避免状态。

抓取服务器端pcap后，建议重点排查：

• Wireshark中TCP头部的cwnd、ssthresh数值（可通过TCP分析面板查看）
• 第11个段及其对应ACK的ECN标记、RTT变化
• 服务器端发送队列长度及应用层的读写操作时序

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