Linux无直接输出TCP重传率的命令，必须用/proc/net/snmp中TCPRetransSegs与TcpOutSegs的增量比值计算：重传率≈(RetransSegs₂−RetransSegs₁)÷(OutSegs₂−OutSegs₁)，>0.5%需关注，>2%应立即排查。
查 TCP 重传率：看 /proc/net/snmp 增量比
这是最轻量、通用、容器友好的方式，所有内核版本都支持：
- 执行
cat /proc/net/snmp | grep -A1 Tcp | tail -n1，输出类似：Tcp: RtoAlgorithm RtoMin RtoMax InSegs OutSegs RetransSegs InErrs ...
第11列是 OutSegs（总发出段数），第15列是 RetransSegs（已重传段数） - 不能直接用绝对值相除——必须取两组时间点的差值：
重传率 ≈ (RetransSegs₂ − RetransSegs₁) ÷ (OutSegs₂ − OutSegs₁) - 用
watch -n1 'cat /proc/net/snmp | grep -A1 Tcp | tail -n1'观察 5–10 秒，手动记下两组值即可计算 - 结果 > 0.005（0.5%）需关注；> 0.02（2%）说明链路存在明显丢包，应立刻排查
查 TCP 重传趋势：用 nstat 或 sar -n TCP
nstat 和 sar 是更省事的增量统计工具，适合监控和告警：
-
nstat -z -t 1 | grep -E "TcpRetransSegs|TcpOutSegs"输出第二列是「上一秒内的增量」，例如：TcpRetransSegs 42 0.0和TcpOutSegs 8400 0.0→ 当前秒重传率 ≈ 42 / 8400 = 0.5% -
sar -n TCP 1 3输出中重点关注：
retrans/s（每秒重传段数）、oseg/s（每秒发段数）、atmptf/s（失败连接尝试）、estres/s（异常关闭连接）
重传比例可粗略估算为 retrans/s ÷ oseg/s（注意：oseg/s 含纯 ACK，该比值偏保守，仅作趋势参考） - 若 retrans/s、atmptf/s、estres/s 三者同步突增，大概率是路径丢包或延迟抖动，建议立即配合
mtr -n或ping -i 0.1验证
查单连接重传次数：ss -ti 的 retransmits 字段要慎读
这个字段常被误用，它只反映超时重传（RTO timeout），不是全部重传行为：
-
ss -ti state established中每行末尾的 retransmits 值，对应内核统计中的TCPTimeouts，而非TCPRetransSegs - 它不包含快速重传（3×dupACK）、SACK 重传或 TLP，因此即使网络严重丢包，该值也可能长期为 0
- 该值在连接关闭后清零，无法回溯；仅当持续增长且 > 0 时，才说明该连接路径存在稳定丢包问题
- 真要定位高重传流：先用
ss -tunap找目标四元组（IP+端口），再加-i查其 retransmits
查丢包发生位置：不能简单算“dropped / packets”
ifconfig、ip -s link、/proc/net/dev 等工具只提供绝对计数器，分母不统一、层级不同，直接相除无意义：
-
Rx-DRP：包进 Ring Buffer 后被协议栈丢弃（如 socket buffer 满、无监听端口）
Rx-OVR：Ring Buffer 溢出导致硬件级丢包（ethtool -G eth0 rx 4096可调大） -
ethtool -S eth0 | grep -E "(rx_|tx_).*[dD]rop|fifo|miss|crc)"查驱动级错误：rx_fifo_errors（FIFO 满）、rx_missed_errors（vCPU 调度不过来，虚拟化关键）、rx_crc_errors（线缆/光模块问题） - 检查是否人为限流：
tc -s qdisc show dev eth0，重点看 dropped 列是否上涨——CNI 插件（Calico/Cilium）可能在 cali+ 或 lxc+ 接口上配置了 loss 规则 - 端到端验证用
ping -c 50 目标IP（看 packet loss %）或mtr -r -n -c 50 目标IP（定位逐跳丢包节点）
