ss -i 的 retransmits 字段仅统计超时重传（rto timeout）次数，不包含快速重传、sack 重传或 tlp；它对应 /proc/net/snmp 中的 tcptimeouts，而非 tcpretranssegs。
Linux 没有直接输出“重传率”的命令，但你可以用 ss -i 查单连接重传次数、用 /proc/net/snmp 提取系统级重传段数和总发包数，再手动算出瞬时重传率——这才是真正可靠的做法。
ss -i 的 retransmits 字段到底代表什么
ss -i 输出里的 retransmits 值只统计超时重传（RTO timeout）次数，不包含快速重传（3×dupACK）、SACK 重传或 TLP。这意味着：
- 即使网络丢包严重、
TcpRetransSegs持续上涨，retransmits也可能长期为 0 - 该值在连接关闭后清零，无法回溯历史
- 它和
/proc/net/snmp中的TCPTimeouts字段对应，不是TCPRetransSegs - 想确认是否真有超时重传？优先看
TCPTimeouts，而不是盯着retransmits看
从 /proc/net/snmp 算真实重传率
重传率 = 重传段数 ÷ 总发送段数，必须用同一时间窗口内的增量计算，不能直接拿绝对值除：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 执行
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列是RetransSegs，第11列是OutSegs - 用
watch -n1 'cat /proc/net/snmp | grep -A1 Tcp | tail -n1'轮询 10 秒，记录两组值，算差值 - 重传率 ≈ (
RetransSegs₂ - RetransSegs₁) ÷ (OutSegs₂ - OutSegs₁) - 若结果 > 0.5%，说明链路已出现明显丢包；> 2% 就该立刻排查
为什么 netstat -s 不如 /proc/net/snmp 可靠
netstat -s 是对 /proc/net/snmp 的文本封装，但它依赖 net-tools 包，在容器或最小化系统中常不可用；更重要的是：
- CentOS 7+、Ubuntu 22.04+ 默认不预装
net-tools，而/proc/net/snmp是内核原生接口，永远存在 -
netstat -s | grep -i retrans输出字段名不统一（比如有的写TCPRetransSegs，有的写RetransSegs），解析脚本容易出错 -
/proc/net/snmp格式稳定、列序固定，适合自动化采集（比如 Prometheus 的 node_exporter 就直读它） - 别被
netstat -s的可读性迷惑——它只是个“人肉友好”层，底层数据源仍是/proc/net/snmp
ss -i 配合过滤定位高重传连接
要聚焦到具体问题连接，得组合状态、端口和地址过滤：
- 先查所有 ESTABLISHED 连接：
ss -t state established - 加
-i显示重传信息，并限制目标端口（如 443）：ss -ti state established dport = :443 - 如果发现某连接
retransmits持续增长，用ss -tunap找出 PID，再结合lsof -p $PID或cat /proc/$PID/cmdline定位应用 - 注意：加
-n避免 DNS 解析延迟，加-t排除 UDP 干扰，这是生产环境排查的最小安全组合
真正难的不是“怎么查”，而是区分哪些重传来自链路丢包、哪些来自接收端处理延迟、哪些是 RTO 估算失准导致的虚假重传——这需要把 ss -i 的 rto、rtt、retransmits 和 /proc/net/snmp 的 TCPTimeouts、TCPSpuriousRtx 对着看，缺一不可。
