要直接查看连接质量，需要检查延迟、丢包、重传、窗口状态等真实指标。你可以使用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则能揭示协议栈的疲劳状况——这三者相辅相成，缺一不可。
