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 包，且默认不开启历史收集。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行前确认：
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() 调用频率。
