一次从丢包到定位根因的网络故障排查实战
凌晨两点，业务方反馈核心业务偶发超时，监控只显示入口延迟飙升，但 CPU、内存、磁盘都不高。真正的问题不是“资源不够”，而是链路中某一段出现了间歇性抖动。
排查时最怕两件事：第一，只有现象没有证据；第二，抓了一堆包却不知道先看哪里。正确做法不是盲抓全网，而是先锁定时间窗口、业务路径和异常指标，再决定抓包点位。
第一步先看现象是否稳定复现。把报警时间轴和用户报障时间对齐，如果发现都是在固定几分钟窗口发生，就优先怀疑链路抖动、微突发或者特定策略触发。第二步看南北向还是东西向，如果只有特定业务访问异常，而其他业务正常，范围就能迅速缩小。
接着做流量侧验证。重点不是包抓得越多越好，而是抓对位置。入口交换机镜像口、服务器网卡、出口防火墙前后，这几个位置通常足够构成最小闭环。若入口有重传、出口无重传，说明问题更靠近业务侧；若入口正常、出口异常，就继续盯中间设备。
然后看几个高价值指标：TCP 重传、重复 ACK、窗口缩小、RTT 突增、突发流量峰值。如果 RTT 平时稳定在 2ms，异常窗口突然抬到 80ms，同时伴随重传升高，这一般不是应用代码锅，而更像网络链路或设备缓存压力问题。
很多团队会在这一步掉进“设备没告警所以没问题”的坑。现实是，大量网络故障根本不会以红色告警形式出现，它们只会表现为轻微抖动、瞬时丢包、会话不稳定。没有流量证据，排查就只能靠猜。
这类场景下，更有效的方法是把抓包分析和流量回溯结合起来：先用全局流量视角找出异常会话，再回到具体包级别看三次握手、重传和时延演变。这样不会陷入在海量 pcap 里裸游。
最终这次问题定位到接入层一台老旧设备在高峰期出现缓存拥塞，导致上行业务流量间歇性排队，进而让应用侧感知为“偶发卡顿”。替换设备并优化突发流量整形后，问题消失。
经验总结很简单：网络排障别从“猜是谁的锅”开始，要从“证据链是否闭合”开始。先缩窗口，再定点位，再看关键指标，最后做链路对照。这样比一上来全网抓包高效得多。
如果团队经常遇到类似的抖动、丢包、性能回退问题，可以借助 AnaTraf 这类全流量分析工具，把异常时段、异常会话与抓包证据串起来，更快完成定位。官网：www.anatraf.com
