sar -n TCP 输出TCP协议栈统计快照，需通过多次采样计算差值评估重传率（≈retrans/s÷oseg/s）及异常指标（atmptf/s、estres/s、orsts/s），配合sar -n ETCP可获取更精确增量数据。
sar -n TCP 是查看 Linux 协议栈 TCP 层统计信息的核心命令，但它不支持“实时刷新”模式（即不能像 sar -n DEV 1 那样持续滚动输出），而是每次运行都输出一个时间点的累计值快照。要监控重传率与异常指标，关键在于理解其输出字段、识别关键阈值，并结合多次采样做差值计算。
明确 sar -n TCP 能看什么
执行 sar -n TCP 1 3（每秒一次，共三次）会输出类似以下内容：
- active/s：每秒主动发起的 TCP 连接数（客户端调用 connect）
- passive/s：每秒被动接受的连接数（服务端 accept）
- iseg/s：每秒接收的 TCP 段数（in-segments）
- oseg/s：每秒发送的 TCP 段数（out-segments）
- atmptf/s：每秒失败的主动连接尝试（如 SYN 发出但未收到响应）
- estres/s：每秒因超时或重置而异常关闭的 ESTABLISHED 连接数
- retrans/s：每秒重传的 TCP 段数 —— 这是重传率的直接分子
- orsts/s：每秒发出的 RST 包数（非正常终止，如端口无服务、连接被拒绝）
重传率不是直接给的，需要自己算
Linux 内核不直接提供“重传率百分比”，retrans/s 是绝对值。要评估是否异常，需结合 iseg/s 和 oseg/s 粗略估算：
- 重传比例 ≈
retrans/s ÷ oseg/s（仅作趋势参考，非 RFC 定义） - 健康系统中该比值通常 5% 往往说明网络丢包、拥塞或对端处理慢
- 注意：
oseg/s包含纯 ACK，实际数据段更少，所以这个比值偏保守——重点看retrans/s是否突增，而非纠结精确百分比
盯住这几个异常信号
以下字段持续升高，往往预示协议栈层面的问题：
- atmptf/s > 0 且稳定存在：客户端反复连不上服务端，可能是防火墙拦截、服务未监听、SYN flood 防御触发
- estres/s 显著上升：已有连接频繁异常中断，常见于后端进程崩溃、Keepalive 超时、中间设备（如负载均衡器）强制断连
- orsts/s 突增：大量连接被 RST 重置，典型场景包括：向已关闭端口发包、应用层主动 close 后又发数据、TCP 保活探测失败
-
retrans/s + estres/s + atmptf/s 三者同步飙升：大概率是网络路径严重丢包或延迟抖动，建议立刻配合
mtr或ping -i 0.1查延迟和丢包
补充验证：搭配 sar -n ETCP 看细节
sar -n ETCP 提供扩展 TCP 统计，含更敏感的错误计数：
- retransmit：总重传段数（累计值，对比前后两次差值得到增量）
- orsts：总 RST 数
- inerrs：接收 TCP 校验和错误数（硬件或驱动问题）
- timewait：当前 TIME_WAIT 连接数（过高可能耗尽端口，但现代内核一般影响不大）
- 运行
sar -n ETCP 5 2，取两次输出的差值，比单次TCP更准
不复杂但容易忽略：sar 的 TCP 数据是内核全局统计，无法关联到具体进程或 IP。真要定位谁在重传，得用 ss -i（看单连接重传队列）、tcpdump 抓包分析序列号，或 netstat -s | grep -A 5 "retransmitted" 查历史汇总。
