如何排查涉及TCP中继的TCP连接传输性能过慢问题

排查步骤 #

1. 优先排查中继转发逻辑的性能瓶颈

• 大多数自行实现的TCP中继性能问题都出在转发逻辑上：如果你采用的是recv接收一端数据、再send给另一端的用户态逐次转发模式，没有使用splice、sendfile这类零拷贝系统调用，会在两次系统调用之间引入额外的处理延迟，相当于在两个TCP流之间插入了隐性背压，直接限制了在途字节（Bytes in flight）的上限，你抓包中163200的在途字节远低于10MB的接收窗口，大概率和这个有关。
• 检查中继进程的CPU占用、上下文切换频率，确认是否存在单线程转发算力不足、内核态软中断占比过高的问题。

2. 排查丢包与拥塞控制触发的限制

• 除了接收窗口满告警，还要在Wireshark中过滤tcp.analysis.lost_segment、tcp.analysis.duplicate_ack、tcp.analysis.retransmission三类告警：哪怕是千分之一级别的偶发丢包，在60ms RTT场景下，也会触发拥塞控制算法把拥塞窗口砍半，直接拉低吞吐量。
• 检查两端设备、中继设备的TCP拥塞控制算法配置，确认有没有启用流量整形、端口限速规则。

3. 排查Nagle算法与延迟ACK的冲突问题

• 检查你的业务应用、中继服务有没有开启TCP_NODELAY选项：如果未开启，Nagle算法会自动攒小包发送，刚好和TCP默认的200ms延迟ACK机制冲突，在60ms RTT场景下会产生额外的等待间隙，直接把吞吐量限制到远低于理论值。
• 你抓包中速度下降前「上次PSH flag后已发送217600字节」的特征，和Nagle攒包的表现高度吻合，可以重点核对。

4. 校验TCP选项透传完整性

• 确认TCP握手阶段的SACK允许、窗口缩放系数等选项有没有被中继正确透传：如果SACK被禁用，丢包后的快速恢复机制无法生效，高RTT场景下的吞吐量会出现明显的波动和下降。

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