Linux查看TCP重传率及网络优化方法

在Linux系统中，准确评估TCP重传率绝非简单读取一个计数器，而需严谨计算「重传段数/总发包数」的比值，并通过/proc/net/snmp双采样获取真实增量；sar -n TCP,ETCP可快速监控retrans/s瞬时速率辅助盯盘，ss -ti帮助定位问题连接，最终必须用tcpdump+tshark抓包验证重传真实性——因为重传率只是表象，背后可能隐藏路径丢包、接收端处理瓶颈或应用层异常发包等深层问题，唯有分层排查、交叉验证，才能穿透数字迷雾，精准定位网络病灶。

Linux 查看 TCP 连接重传率，不能只看一个数字——TCPRetransSegs 是累计值，不除以发送总量就毫无意义；真正的重传率必须是「重传段数 / 总发出段数」的比值，且需在固定时间窗口内计算。

用 /proc/net/snmp 提取原始 TCP 重传与发包计数

这是最轻量、最可靠的方式，不依赖 net-tools，容器里也能跑。关键字段都在一行里：

cat /proc/net/snmp | grep -A1 Tcp | tail -n1 输出类似：
Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts InCsumErrors
其中第 15 列是 TCPRetransSegs，第 11 列是 TcpOutSegs（注意不是 TcpOutDatagrams）。

• 必须用两次采样：间隔 1–5 秒执行两次 cat /proc/net/snmp，取差值再相除
• 别直接用 netstat -s 的 “segments retransmitted” 行——它不带时间戳，无法算率
• 如果 TcpOutSegs 增量为 0，但 TCPRetransSegs 在涨，说明连接已断或应用停发，此时重传率无业务意义

用 sar -n TCP,ETCP 1 看实时重传速率

sar 是唯一能直接输出每秒重传次数（retrans/s）的命令，适合快速盯盘。但它依赖 sysstat 包，且默认不开启历史收集。

• 运行前确认：systemctl is-active sysstat 应为 active；否则先 sudo systemctl enable --now sysstat
• 输出中 retrans/s 是瞬时速率，但注意它只统计超时重传（RTO-based），不包含快速重传（3×dupACK）
• 若看到 retrans/s > 5 持续超过 10 秒，基本可判定路径存在稳定丢包；> 50 则大概率是链路或网卡问题
• 该值和 /proc/net/snmp 的增量比对不上是正常的——sar 采样逻辑不同，优先信后者做归因

用 ss -ti 定位高重传的具体连接

ss -ti 的 retransmits 字段常被误读：它只在超时重传（RTO timeout）时递增，快速重传、SACK 重传、TLP 都不更新它。

• 正确用法：watch -n1 'ss -ti state established "( dport = :443 )"' | grep -E "(retransmits|timer)"
• 重点观察两件事：一是 retransmits 是否非零且增长；二是 timer 字段是否长期显示 on（表示有未确认数据在等 ACK）
• 若 retransmits=0 但 TCPRetransSegs 持续上涨，说明重传主力是快速重传，应立刻抓包看 dupACK 模式
• 该值在连接关闭后清零，无法回溯——想留痕得自己轮询写入日志

用 tcpdump + tshark 验证重传真实性

所有内核计数器都可能被绕过或滞后，最终验证必须靠原始报文。Wireshark 的 tcp.analysis.retransmission 过滤器易误判，得人工核序列号。

• 抓包命令务必加 -s 0：tcpdump -i eth0 -s 0 -w retrans.pcap port 80
• 提取重传行：tshark -r retrans.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.number -e tcp.seq -e tcp.ack -e tcp.len
• 关键判断：重传包的 tcp.seq 必须等于前一个有效 tcp.ack 值，否则可能是乱序或 Wireshark 误标
• 如果发现大量重传但 tcp.ack 值停滞不动，大概率是接收端丢 ACK，问题不在发端网络而在对端主机或中间设备

重传率本身是个“结果指标”，真正难的是区分它是路径丢包、接收端处理慢、还是应用层发包节奏异常导致的虚假拥塞信号。别只盯着数字，先确认 TCPRetransSegs 和 TcpOutSegs 的采样时机是否严格同步，再决定下一步查链路、查接收端、还是查应用 write() 调用频率。

本篇关于《Linux查看TCP重传率及网络优化方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！