TCP重传过多是网络路径、设备状态、服务负载及协议行为共同作用的结果，需通过重传频率、集中性与持续性判断真实瓶颈，再结合ss、tcpdump、mtr等工具定位链路拥塞、CRC错误、路由抖动、网卡异常、CPU过载或配置不当等问题。
Linux系统中TCP重传过多，通常不是单一原因导致的，而是网络路径、设备状态、服务负载或协议行为共同作用的结果。关键不在于“有没有重传”，而在于重传是否频繁、是否集中、是否持续——这些信号能帮我们快速定位真实瓶颈。
常见网络层原因
重传最常暴露的是底层传输问题，而非应用本身：
- 链路拥塞：专线打满、交换机队列溢出、带宽突增（如批量任务启动），会导致中间节点主动丢包，触发超时重传；这类问题往往有周期性，且影响范围广。
- CRC校验错误：网卡、光模块、网线老化或接触不良，造成数据帧在物理层损坏；表现为持续性重传，Wireshark中常伴随大量“TCP Dup ACK”和“TCP Retransmission”，但ping延迟可能正常。
- 路由抖动或路径变更：BGP收敛、策略路由切换、多路径负载不均，可能导致部分报文走高延迟/高丢包路径，RTT剧烈波动，使RTO（Retransmission Timeout）估算失准，引发误重传。
主机侧软硬件因素
服务器自身状态直接影响TCP行为的稳定性：
- 网卡或驱动异常：如RX ring buffer溢出、TSO/GSO配置不当、中断合并过度，会造成接收端丢包，进而让发送端收不到ACK，被动重传。
- CPU或内存过载：当内核处理软中断（NET_RX）不及时，或socket receive queue积压，ACK生成与发送延迟增大，发送方RTO超时后重传；此时ss -i可能显示rto值异常升高、retrans值持续增长。
- 时间戳或乱序干扰：开启tcp_timestamps但对端不支持，或网络存在严重乱序，会影响RTT采样精度，导致RTO低估，重传提前发生。
协议机制与配置影响
TCP自身的重传逻辑并非“越快越好”，不合理配置反而放大问题：
- RTO初始值或退避策略激进：Linux默认min_rtt为200ms，若实际链路RTT仅5ms（如IDC内网），初始RTO过高会拖慢首次重传响应；反之，若调得太低（如设为10ms），易在轻微抖动时引发无谓重传。
- 快速重传被抑制：未开启tcp_sack或tcp_dsack，接收端无法精确反馈丢包位置，只能靠超时重传，效率远低于收到3个Dup ACK就触发的快速重传。
- 重传上限过低：net.ipv4.tcp_retries2默认值为15（对应约13～30分钟重传窗口），若设为5，在弱网环境下连接可能过早断连，掩盖真实丢包率，反而不利于诊断。
如何快速聚焦问题源头
别一上来就翻代码或改内核参数，先用轻量命令圈定范围：
- 查实时重传率：ss -i 观察每个连接的retrans字段；配合netstat -s | grep -i "retran"看全局统计。
- 抓包过滤确认：tcpdump -i eth0 'tcp[tcpflags] & (tcp-rst|tcp-syn) != 0 or tcp.analysis.retransmission'，重点看重传是否集中在某IP或端口。
- 对比RTT基线：mtr --report -c 10 target_ip 和 ss -i 中的rto、rtt、rttvar数值是否匹配；明显偏离说明采样异常。
- 检查队列堆积：cat /proc/net/dev 看RX/TX drop；cat /proc/net/snmp | grep -i "Tcp:" 查InSegs、OutSegs、RetransSegs比例。
