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没回来”——是包丢了？被拦了？还是对方根本没处理？抓住这个主线，结合统计+抓包+状态交叉印证，问题通常能准确定位。