真正反映 tcp 重传问题的是 tcpretranssegs 与 tcpoutsegs 的比值，而非 tcpretranssegs 单独数值；前者统计自启动累计重传段数（含 fast 和 timeout），后者为总发出段数，比值可消除流量规模干扰，避免低流量下误判偶发丢包或高吞吐下忽略真实异常。
netstat -s 输出里哪些字段真正反映 TCP 重传问题
直接看 TcpRetransSegs 和 TcpOutSegs 的比值，比单纯盯 TcpRetransSegs 本身更有意义。linux 内核 4.15+ 的 netstat -s 输出中，这个值来自 /proc/net/snmp 的 TCP 段，统计的是已发出但被上层重传的段数（含 fast retransmit 和 timeout retransmit），不是重传次数本身。
常见误判点：
- 把
TcpRetransSegs单独放大解读——低流量下几十次重传可能只是偶发丢包；高吞吐下每秒几百次才值得查 - 忽略
TcpOutSegs基数：若它每月只增长 1000，TcpRetransSegs是 50 就很异常；若TcpOutSegs是 1e9/天，5000 重传其实正常 -
TcpRetransSegs不包含 SACK 重传块的重复计数，它只按段（segment）计，和 wireshark 显示的 “retransmission” 行不完全对齐
sar -n TCP 输出中 retran/s 和 netstat -s 的 TcpRetransSegs 不一致的原因
sar -n TCP 的 retran/s 是采样周期内重传段速率（单位：段/秒），而 netstat -s 的 TcpRetransSegs 是自启动以来累计值。两者数值不可直接对比，但可以交叉验证趋势。
关键差异点：
-
sar默认每 10 秒采样一次，如果重传集中在某几秒爆发（如突发丢包），retran/s可能远高于平均值，而netstat -s看不到时间分布 -
sar -n TCP在较老内核（如 3.10）中统计来源是/proc/net/snmp的Tcp行，但部分发行版打过补丁后改用/proc/net/snmp6或内核 tracepoint，导致和netstat -s数值微差（通常 -
sar的retran/s包含 IPv6 TCP 重传（只要启用了 IPv6 协议栈），而netstat -s默认只显示 IPv4 统计，除非加-s -A inet6
用 /proc/net/snmp 替代 netstat -s 查实时增量更准
netstat -s 是快照命令，每次执行都重新读取并格式化，有轻微延迟且无法做毫秒级差值。真要监控重传突增，直接读 /proc/net/snmp 更可靠。
实操建议：
- 用
awk '/^Tcp:/ {print $12}' /proc/net/snmp提取TcpRetransSegs字段（位置固定，第 12 列） - 两次读取间隔 1 秒，差值即为该秒重传段数，比
sar -n TCP 1 1更低开销 - 注意：/proc/net/snmp 每行末尾可能有空格或换行符，
awk要用$12+0强转避免字符串拼接错误 - 该文件无锁，多进程并发读安全，但不要用
tail -f监控——它不会实时刷新，得轮询
排查时别漏掉 conntrack 对重传统计的干扰
启用 nf_conntrack 且连接超时设置过短（如 net.netfilter.nf_conntrack_tcp_timeout_established = 300）时，连接被强制踢出 conntrack 表后，后续 ACK 可能被 DROP，触发应用层重发，这部分会记入 TcpRetransSegs，但根本原因不在网络链路。
判断方法：
- 检查
conntrack -S | grep -i 'insert_failed|drop'，有非零值说明 conntrack 表满或插入失败 - 对比
ss -s显示的 total established 连接数，和conntrack -C返回值是否接近上限（默认 65536） - 临时关闭 conntrack 测试：
echo 0 > /proc/sys/net/netfilter/nf_conntrack_enable（仅限测试环境，勿在生产 NAT 设备上操作）
重传统计本身不区分是路径 MTU 问题、中间设备限速、网卡驱动 bug 还是应用 write() 后没等 ACK 就 close()，得结合 ss -i 的 rtt/rto、tcptrace 或 eBPF 工具定位具体连接行为。数值只是入口，不是结论。