Linux 系统本身并没有内置可直接使用的网络连接质量监控报表。想要搭建完整的网络质量监控视图,通常需要组合多种命令与工具:通过 ss -i 获取 TCP 连接级别的 RTT、rttvar 和重传信息,读取 /proc/net/snmp 提取全局 TCP/IP 统计数据,使用 ping 或 tcpping 做主动连通性与延迟探测,再配合 sar -n edev 观察网卡接口错误与异常趋势。

Linux 并不存在“网络连接质量监控报表”这种现成的、开箱即用的系统级输出。Linux 内核不会自动生成包含延迟、丢包率、抖动等 QoS 指标的汇总报表,因此通常需要依靠命令行工具配合监控脚本与业务逻辑,手动拼接出可用的网络连接质量分析视图。
ss -i 可以查看每个 TCP 连接的实时网络质量指标
ss -i 是少数能够在单条命令中直接展示连接级网络质量数据的工具,但它只适用于 TCP,且部分输出字段很容易被误读:
rtt表示当前平滑 RTT(单位毫秒),并非历史平均延迟;rttvar是 RTT 波动方差,数值越大通常说明网络抖动越明显retrans表示该 TCP 连接截至当前发生过的重传总次数,并不是每秒重传率;qloss(如果有显示)代表队列丢包数,通常只会在启用了tcp_metrics时出现- 建议同时加上
-t和-n参数,才能更稳定地输出结果,例如ss -tini | head -20,否则可能出现卡顿或字段缺失 - 它无法直接显示 UDP 连接质量,因为 UDP 本身没有重传和 RTT 机制,相关质量判断通常只能依赖上层协议(如 QUIC)或应用日志来分析
/proc/net/snmp 提供 IP/ICMP/TCP 层面的全局错误统计
如果想在 Linux 中查看接近“网络质量报表”的底层数据来源,/proc/net/snmp 是非常关键的内核接口,不过它提供的是累计统计值而非实时速率,而且字段名称也不够直观:
TCP: InSegs与InErrs的比值可以大致评估入方向校验失败率;如果TCPLostRetransmit持续偏高,往往说明重传之后依然发生丢包,可能与链路层异常有关ICMP: InErrors不为 0 时,通常代表接收端 IP 层处理出现异常,例如内存不足,而不一定是网络中间路径故障- 字段顺序固定,因此可以使用
awk '/^Tcp/ {print $1,$2,$3,$15}' /proc/net/snmp抽取关键列,其中 $15 对应TCPLostRetransmit - 需要注意的是,这些数值会从系统启动后持续累加,服务器重启后才会清零;因此单次读取意义不大,通常需要定时采集并计算差值,才能形成有效的网络监控报表
ping + tcpping 组合使用,才能更准确测出真实连接质量
仅依赖内核统计并不能完全替代主动探测,尤其是在排查客户端到服务端这类非本机主动发起的网络连接质量问题时:
ping -c 10 -i 0.2 example.com可以查看丢包率以及min/a vg/max/mdev,其中mdev(均方根抖动)相比a vg更能体现网络稳定性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 协议栈的缓冲、重试与调度逻辑。
