Linux怎么查看具体的网络连接质量监控报表

Linux 系统原生并未内置开箱即用的网络连接质量监控报表。要构建完整的质量视图，需要组合运用多项工具：通过 ss -i 抓取 TCP 连接级的 RTT、rttvar 和重传数据，读取 /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 栈的缓冲和调度逻辑。