丢包要靠三处交叉验证
判断链路是否真丢包，单一数据源都不够：本机的 TCP 重传计数只能说明自己这一侧的感受，mtr 的逐跳丢包会被 ICMP 限速干扰，对端看到的丢包位置又可能完全不同。可靠的做法是把内核计数、主动探测与业务侧指标放在一起看，确认丢包比例、是否集中在时段，以及是否影响可用性。
基本信息
| 适用平台 | Linux（nstat、ss、/proc/net/snmp）；Windows 用 netstat -s 与 Get-NetTCPConnection |
|---|---|
| 核心指标 | TcpRetransSegs 与 TcpOutSegs 的比值即重传率 |
| 补充指标 | TcpExtTCPLostRetransmit 表示重传也丢了，说明链路质量差 |
| 采集方式 | nstat 适合脚本采集差值，避免手算累计值 |
本机统计
本机统计
nstat -az | grep -E 'TcpRetransSegs|TcpOutSegs|TCPLostRetransmit'
nstat -n TcpRetransSegs TcpOutSegs # 再次执行得到增量，比值即重传率
ss -tin | grep -c retrans # 当前有多少连接处于重传状态
cat /proc/net/snmp | grep -A1 Tcp: # 累计计数原始来源链路探测
链路探测
mtr -rwzc 100 target # 逐跳统计，重点看最后一跳
ping -c 100 -i 0.2 target | tail -3 # 高密度采样看丢包是否连续
ss -tin dst 10.0.0.9 | grep -E 'rtt|retrans' # 单连接 RTT 与重传详情指标读法
| 指标 | 含义 | 异常判断 |
|---|---|---|
| 重传率 | 重传段数除以发送段数 | 内网持续高于 0.1% 值得追查 |
| TCPLostRetransmit | 重传的包也丢了 | 出现即说明链路质量差或严重拥塞 |
| mtr 末跳丢包 | 端到端丢包参考 | 末跳非零且稳定才可信 |
| RTT 波动 | ss 输出的 rtt 与 rttvar | rttvar 持续偏大表示路径不稳 |
mtr 中间跳丢包不一定是问题：路由器对 ICMP 限速很常见，只有最后一跳的丢包与端到端 TCP 重传对得上才说明真实影响。
重传率低也不代表没丢包：SACK 与快速重传修复及时，或应用还没把链路压到瓶颈时，统计上可能看不出异常，所以要结合业务侧耗时分布判断。
采集要连续并带时间戳：丢包常是时段性的（晚高峰、备份窗口、跨网结算时段），单次采样容易得出相反结论，建议按分钟落盘再与业务耗时曲线对齐。