Wireshark 分析：三步定位一次慢请求

打开文件，先看医生的诊断书

几千个包逐个看是下策。Wireshark 的 Expert Information（分析菜单）把异常先汇总好：错误级的 Reset、Warning 级的重传和乱序、Note 级的窗口变化——相当于体检报告的异常指标栏，直接告诉你这堆包里藏着什么病。

三步定位法

第一步：Follow TCP Stream（右键可疑包 → 追踪流）
  还原出这次对话的完整往返，像聊天记录一样可读
  ← 确认问题发生在哪一次请求

第二步：加时间维度
  时间列改成「相对上一个包的间隔」（View → Time Display Format）
  哪两个包之间沉默最久，慢就慢在哪
  常见三段：握手慢？服务端处理慢（请求后长时间无响应）？传输慢？

第三步：统计视图收口
  Statistics → Conversations：哪条连接流量最大/RTT 最高
  Statistics → I/O Graph：慢的时间段和流量尖峰是否吻合
  过滤器 tcp.analysis.flags：一键列出所有重传/乱序/零窗口

重传与 RST 的读法

过滤器 tcp.analysis.flags 列出所有异常包，逐类判断：TCP Retransmission 集中在某条链路——那条路丢包，查中间设备；DUP ACK 连成串——收方在催丢的包，和重传结对出现；Zero Window——接收方应用处理不过来，缓冲区满，锅在应用不在网络；RST 出现在响应中途——看 RST 由谁发出：服务端应用崩了、连接被 LB 闲置回收、还是防火墙动了手，RST 前的时间戳和最后活跃时间一对比就有方向。

案例：那个偶发慢 2 秒的接口

现象：P99 接口偶发 2 秒+，日常 20ms，监控无异常

抓包 → Follow Stream → 时间列归零看间隔：
  t=0.000   请求发出（PSH）
  t=0.021   响应回来（200 OK，完整）
  t=2.018   下一次请求才发出          ← 间隔在客户端侧！

结论：服务端 21ms 就回了，慢在客户端发起前发了 2 秒呆
再查：客户端连接池 maxWait 排队 2 秒 —— 池子太小，借连接排队
修复：调大池上限 + 修掉一个串行锁 —— P99 恢复 20ms

// 抓包的价值：把「网络慢」的默认怀疑，用证据排除或坐实

这个案例的思维方式比结论值钱：先定位慢发生在哪一侧（请求前/等待响应/传输中），再进那一侧深挖。2 秒恰好是很多连接池的默认 maxWait、也是很多重传定时器的量级——数字本身就是线索。

常用过滤器速查

tcp.analysis.flags              # 全部 TCP 异常
tcp.analysis.retransmission     # 仅重传
tcp.analysis.zero_window        # 零窗口
http.time > 1                   # 应用层响应超 1 秒的 HTTP 事务
tls.handshake.type == 1         # 所有 ClientHello（TLS 慢就过滤它）
tcp.stream eq 42                # 只看第 42 条流
dns.flags.response == 0         # 只看 DNS 查询（看解析耗时）

下一篇：把前十八篇的方法论收拢成一本故障排查手册——ping 通但端口不通、间歇超时、TIME_WAIT 堆积，见招拆招。