Linux无开箱即用的网络连接质量监控报表，需组合ss -i（查TCP连接级RTT/rttvar/retrans）、/proc/net/snmp（全局TCP/IP统计）、ping/tcpping（主动探测）及sar -n edev（接口错误）等命令构建质量视图。
没有“网络连接质量监控报表”这种现成的、开箱即用的系统级报表。Linux 内核不生成带延迟、丢包率、抖动等 QoS 指标的汇总报表，你得靠组合命令 + 业务逻辑拼出质量视图。
ss -i 能看到每个 TCP 连接的实时质量指标
ss -i 是唯一能在单条命令里直接暴露连接级质量数据的工具，但它只对 TCP 生效，且输出字段含义容易误解：
-
rtt是当前平滑 RTT（单位毫秒），不是历史平均；rttvar是 RTT 方差，值越大说明抖动越剧烈 -
retrans表示该连接至今重传过的总次数，不是每秒重传率；qloss（如果显示）是队列丢包数，仅在启用了tcp_metrics时出现 - 必须加
-t和-n才能稳定输出：例如ss -tini | head -20，否则可能卡住或漏字段 - 它不显示 UDP 连接质量——UDP 本身无重传/RTT 机制，质量需靠上层协议（如 QUIC）或应用日志推断
/proc/net/snmp 提供 IP/ICMP/TCP 层全局错误统计
这是最接近“质量报表”的内核源，但它是累计值，不是速率，字段名也不直观：
-
TCP: InSegs和InErrs的比值可粗估入向校验失败率；TCPLostRetransmit高说明重传后仍丢包，可能是链路层问题 -
ICMP: InErrors非零通常表示接收端 IP 层处理异常（如内存不足），不是网络中间路径问题 - 字段顺序固定，可用
awk '/^Tcp/ {print $1,$2,$3,$15}' /proc/net/snmp抽取关键列（$15 是TCPLostRetransmit） - 注意：这些数字从启动开始累加，重启后归零；单次读取无意义，要写脚本定时采集差值
ping + tcpping 组合才能测出真实连接质量
内核统计无法替代主动探测，尤其对非本机发起的连接（如客户端到服务端）：
-
ping -c 10 -i 0.2 example.com看丢包率和min/avg/max/mdev，mdev（均方根抖动）比avg更反映稳定性 -
tcpping -x 10 -w 1 example.com 443测指定端口的 TCP 握手延迟，比 ICMP 更贴近真实业务路径 - 别只跑一次：连续 3 分钟每 5 秒测一次，再用
awk '{sum+=$7} END{print sum/NR}'算平均延迟，否则瞬时波动会误导判断 - 容器环境里，
tcpping可能因 netns 隔离失败，优先用nsenter -t $(pidof your-app) -n tcpping ...
sar -n edev 显示接口级错误趋势，但不等于连接质量
sar -n edev 1 输出的是网卡驱动上报的硬件/链路层错误，和上层连接质量相关但不等价：
-
rxerr/s和txerr/s持续 > 0 表明物理层有问题（网线、光模块、交换机端口），这时所有连接质量都会恶化 -
coll/s（冲突计数）在全双工交换环境下应为 0，若非零说明协商失败或设备故障 -
drop/s高不一定代表丢包——可能是防火墙规则iptables -j DROP主动丢弃，需结合iptables -L -v -n排查 - 它不区分“连接内丢包”和“连接建立前丢包”，比如 SYN 包被丢，
sar记为rxerr，但ss -i根本看不到这个连接
真正难的是把链路层错误、传输层重传、应用层超时这三层数据对齐——同一时间点的 sar -n edev 错误突增，未必对应 ss -i 里某个连接的 retrans 上升，中间隔着内核 TCP 栈的缓冲和调度逻辑。
