Linux TCP 重传过多需从协议行为、系统状态、链路质量、应用层配合四层面交叉验证，重点判断重传是否异常、集中环节及增长趋势。
Linux 上 TCP 重传过多，不是单纯“网络差”就能解释的，得从协议行为、系统状态、链路质量、应用层配合四个层面交叉验证。重点不是看有没有重传（TCP 本就会重传），而是判断重传是否异常、集中在哪个环节、是否持续增长。
一、确认重传是否真高：看内核统计基线
先别急着抓包，用轻量命令快速定位是否超出合理范围：
- 查全局重传总量：
cat /proc/net/snmp | awk '/Tcp/ {print $17}'（第 17 列是TcpRetransSegs，即重传段数）；或netstat -s | grep -i "retrans" - 查实时连接级重传 ：
ss -i | grep -E "(retrans|rtt)"，观察单个连接的retrans值和rtt/rto——若某连接retrans≥3 且rto> 1000ms，需重点关注 - 对比基线 ：局域网环境，每小时重传段数通常应<50；公网或跨 IDC 链路，可容忍数百，但若
TcpRetransSegs每分钟增长>50，就属于异常活跃重传
二、区分重传类型：超时重传 vs 快速重传
不同重传机制反映的问题完全不同：
- 超时重传（RTO 触发）：说明 ACK 长期未返回，常见于链路丢包、中间设备拦截、接收端宕机或 receive buffer 满。在 Wireshark 中表现为：同一 seq 反复出现，间隔呈 2 倍增长（1s→2s→4s……）
- 快速重传（3×重复 ACK 触发）：说明数据包乱序或局部丢包，但链路基本可达。Wireshark 过滤
tcp.analysis.retransmission && tcp.analysis.fast_retransmission可直接标出。这种重传对延迟影响小，但会立即减半拥塞窗口，拖慢吞吐 - 快速验证方法：
sudo tcpdump -i any -w /tmp/retrans.pcap 'tcp and (tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) == 0)' -c 2000，再用 Wireshark 打开，用“Statistics → TCP Stream Graphs → Time-Sequence Graph (Stevens)”直观查看重传模式
三、逐层排查根因：从链路到应用
按“通路→协议→服务→系统”顺序缩小范围：
- 链路连通性 ：用
ping -c 10 目标 IP看丢包率；用mtr -r -c 20 目标 IP定位哪一跳开始丢包或延迟突增 - 端口 与服务可达性 ：用
nc -zv 目标 IP 端口测试三次握手是否完成；若失败，检查服务端ss -tnlp | grep 端口是否监听、防火墙iptables -L -n -v是否拦截 SYN - 接收端状态 ：登录目标机器，查
ss -i dst 源 IP | grep -E "(rcv_space|retrans|qsize)"，若rcv_space长期为 0 或极小，说明应用读取太慢、buffer 积压；若qsize持续>1000，可能应用处理阻塞 - 系统资源瓶颈 ：检查
vmstat 1 5看 si/so（swap）、free -h看内存、cat /proc/net/softnet_stat第 1 列是否持续增长（软中断处理不过来，丢包前兆）
四、关键内核参数快查与调优建议
某些参数配置不当会放大重传表现，适合快速核对：
-
net.ipv4.tcp_retries2：默认 15，决定 RTO 重传上限。若链路 RTT 波动大（如无线、跨境），可临时设为 8～10，避免过久等待 -
net.ipv4.tcp_syn_retries：SYN 发不出去时的重试次数，默认 6。若服务端 SYN 队列满（netstat -s | grep "SYNs to LISTEN"有溢出），可适当调低防雪崩 -
net.core.netdev_max_backlog：网卡收包队列长度，默认 1000。高并发下若/proc/net/softnet_stat第 1 列增长快，可加大至 2000～5000 - 所有修改后用
sysctl -p生效，生产环境建议先echo 值 > /proc/sys/……临时验证效果
重传本身是 TCP 的自我保护，排查核心在于“为什么 该 ACK 没回来”——是包丢了？被拦了？还是对方根本没处理？抓住这个主线，结合统计 + 抓包 + 状态交叉印证，问题通常能准确定位。
