Linux怎么查看具体的网络连接质量监控报表
Linux 系统原生并未内置开箱即用的网络连接质量监控报表。要构建完整的质量视图,需要组合运用多项工具:通过 ss -i 抓取 TCP 连接级的 RTT、rttvar 和重传数据,读取 /proc/net/snmp 获取全局 TCP/IP 统计信息,利用 ping 或 tcpping 进行主动探测,
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 栈的缓冲和调度逻辑。

































