Linux怎么查看网络连接的实时质量

要直接查看连接质量，需要检查延迟、丢包、重传、窗口状态等真实指标。你可以使用ss -ti来查看单个连接的实时质量（如rtt/cwnd/retrans等），用mtr定位链路劣化的跳点，通过/proc/net/snmp分析协议栈级别的异常。只有将这三者结合起来，才能进行精准的诊断。

直接看连接质量，不能只盯带宽数字——得查延迟、丢包、重传、窗口状态这些真实影响业务的指标。用 ss 和 mtr 组合，基本覆盖绝大多数场景。

用 ss -ti 查单个 TCP 连接的实时质量信号

ss -ti 是最轻量、最贴近内核反馈的方式，它直接读取 TCP 控制块（tcp_info），不依赖抓包，也不触发额外开销。

• 常见错误现象：只用 netstat 或 ss -t 看 ESTABLISHED 状态，却不知道这个连接是否在频繁重传、RTT 是否飙升、接收窗口是否被堵死
• 关键字段含义：rtt（当前往返时延）、cwnd（拥塞窗口大小）、retrans（已重传次数）、lost（标记为丢失的段数）、rcv_space（接收缓冲区剩余空间）
• 实用命令示例：ss -ti 'dst 192.168.1.100:8080'，定位到具体目标连接后，重点关注 retrans 是否持续增长、cwnd 是否长期卡在小值（如 ≤10）、rtt 是否远高于基线（比如平时 5ms，现在 200ms+）
• 性能影响：几乎无开销，可每 2–5 秒执行一次；但不要对成百上千连接全量执行 ss -ti，应先用 ss -tn sport = :80 | head -10 缩小范围

用 mtr 定位链路中哪一跳开始劣化

当 ss -ti 显示某连接质量差，但不确定是本地、中间网络还是对端问题时，mtr 是唯一能分跳诊断的工具。

• 常见错误现象：ping 整体通，但应用超时；或 curl 偶发卡住——这类间歇性问题靠单次 ping 或 traceroute 很难复现
• 必须加的参数：-n（跳过 DNS，避免解析延迟干扰）、-c 20（发 20 包保证统计意义）、-i 0.5（0.5 秒间隔，比默认 1 秒更敏感，又不至于触发对方 ICMP 限速）
• 重点关注三列：Loss%（某跳突然升至 >5%，且后续跳同步升高 → 该节点出口异常）；A vg 与 Best 差距（>50ms 说明抖动严重）；StDev（持续 >15ms 就值得警惕）
• 容易忽略的细节：某跳显示 100% 丢包，但下一跳通 → 大概率只是该设备禁 ICMP，不算故障；真正要盯的是“从某跳开始，Loss% 和 A vg 同步恶化”

结合 /proc/net/snmp 看协议栈级异常累积

单次连接质量好，不代表整体健康。/proc/net/snmp 记录了内核 TCP 协议栈的全局计数器，适合发现慢速攻击、SYN Flood 遗留、TIME_WAIT 泛滥等“温水煮青蛙”类问题。

• 典型使用场景：用户投诉“偶发连接失败”，但 ss -s 看 ESTABLISHED 数正常 → 此时查 TcpAttemptFails（主动连接失败数）和 TcpExtListenOverflows（监听队列溢出次数）是否近期突增
• 快速提取方法：awk '/Tcp:/ {print $1,$NF}' /proc/net/snmp | grep -E "(AttemptFails|ListenOverflows|EstabResets)"
• 注意单位：所有数值都是自系统启动以来的累计值，需对比历史增速（例如 5 分钟内 TcpAttemptFails 增加 500 次，而平时每小时才增 10 次 → 异常）
• 兼容性提醒：该文件格式稳定，但字段顺序在旧内核（如 3.10）和新内核（5.10+）略有差异，建议用字段名匹配而非位置索引

真正棘手的并非发现丢包，而是要精准判断丢包究竟发生在哪一层，是否具备可恢复性，以及是否正在扩散。别只依赖单一工具，ss -ti能为你提供连接快照，mtr可告知你路径中的病灶所在，/proc/net/snmp则能揭示协议栈的疲劳状况——这三者相辅相成，缺一不可。