sar -n 是最贴近协议层负载监控需求的命令，直接读取内核统计计数器，结果稳定可复现；tcp、udp、ip等参数对应不同统计维度，不可混用，且需确保sysstat已启用并运行cron任务，否则提示“no data”。
用 sar -n 查 TCP/UDP/IP 的连接与包量统计
直接看协议层负载，sar -n 是最贴近需求的命令，它不依赖实时连接状态，而是读取内核统计计数器，结果稳定、可复现。不同协议参数对应不同统计维度，不能混用。
-
sar -n TCP 1 3：输出每秒 TCP 连接建立/关闭数、重传包、失败连接尝试（如active/s、passive/s、retrans/s） -
sar -n UDP 1 3：只显示 UDP 收发包数（idgm/s/odgm/s），不统计连接——UDP 本就没有连接概念 -
sar -n IP 1 3：聚焦 IP 层转发行为，含输入/输出包、丢弃包（irec/s、ierr/s、fwddgm/s） -
sar -n EDEV 1 3：查网络错误，比如idrop/s（因缓冲区满丢包）、odrop/s（发送队列溢出）——这才是真正定位瓶颈的关键指标
注意：sar 默认不启用数据采集，首次运行前需确保 sysstat 已启用且 cron 任务在运行（/etc/cron.d/sysstat）。否则所有 -n 输出会提示“NO DATA”。
netstat -s 和 ss -s 的输出差异与适用场景
netstat -s 输出冗长但字段全，ss -s 更简洁，两者统计来源一致（/proc/net/snmp 等），但解析逻辑略有不同。遇到 “connection refused” 或 “no route to host” 类错误时，应优先看 netstat -s 的 ICMP 和 TCP 错误段。
-
netstat -s | grep -A5 "Tcp:"能快速定位是否大量TCPSynRetrans（SYN 重传）——说明客户端连不上服务端，可能是防火墙拦截或端口未监听 -
ss -s第一行就汇总了总 socket 数、已建立连接数（estab）、timewait 数。如果estab很低但time-wait高，大概率是短连接激增，需检查应用是否主动 close - 两者都不区分网卡，统计的是全系统协议栈行为；若要按接口拆分，必须用
sar -n DEV配合sar -n TCP交叉比对
为什么 ip -s protocol 不适合查协议负载
ip -s tcp、ip -s udp 这类命令实际并不存在——ip -s 只支持 link（网卡）、route、rule 等子命令，不提供协议栈内部统计。试图执行会报错：RTNETLINK answers: Invalid argument 或直接无输出。
真正能拿到协议级底层计数的，只有三个入口：
-
/proc/net/snmp（文本格式，供netstat -s解析） -
/proc/net/snmp6（IPv6 对应项） -
/proc/net/netstat（更细粒度的 TCP 状态迁移、内存分配等）
想写脚本自动提取，直接 awk '/Tcp:/ {print $2}' /proc/net/snmp 比调用外部命令更可靠，也避开了 netstat 已被废弃、ss 不输出全部字段的问题。
容易被忽略的采样时机和单位陷阱
协议负载不是瞬时值，而是滑动窗口内的速率。比如 sar -n TCP 2 5 输出的 retrans/s 是 2 秒内重传包数除以 2，不是单个包的绝对值。很多人拿这个数直接和 QPS 对比，结果完全对不上。
- TCP 的
active/s是主动发起连接数（客户端侧），passive/s是被动接受连接数（服务端侧），两者长期不等，说明存在连接不对称（如反向代理、连接池复用） - UDP 的
idgm/s单位是“数据报”，一个sendto()调用对应一个，但应用层可能把多个逻辑消息拼成一个 UDP 包——所以高idgm/s不一定等于高业务请求量 - 所有
sar的/s后缀都是“每秒平均”，但实际采样间隔由第一个数字决定；设太小（如0.1）会导致内核统计精度下降，输出出现大量 0 或负值
真正在意协议层健康度，别只盯着“流量大不大”，重点看 retrans/s、ierr/s、idrop/s 这几个错误率指标——它们才是网络质量的真实体温计。
