Wireshark 抓到一个 TCP 重传包，数据RTT 从 12ms 跳到 340ms，包分但丢包率显示为零。析实这事我遇到过三次，战详每次都是数据同一类问题：中间设备在悄悄改写 TCP 窗口字段。

数据包分析的包分核心不是"看包"，是析实"对比"。单个包不说明问题，战详你得把前后 200 个包拉出来排时间线。数据我习惯先用 tcp.analysis.flags 过滤异常，包分再按 tcp.stream eq N 锁定会话。析实Wireshark 的战详"专家信息"面板能直接标出重传、乱序、数据零窗口，包分但别全信——它会把正常的析实快速重传也标黄，得结合 tcp.time_delta 判断。

一个真实案例：HTTP 接口偶发超时

某次排查一个订单接口，前端报 3% 超时，后端日志干净。抓包后过滤 http.request.uri contains "order"，发现每次超时前都有一个 200ms 的停顿。展开 TCP 流看，是客户端发完请求后，服务端 ACK 了但迟迟不推数据。再查 tcp.window_size，服务端窗口从 65535 缩到 2048。不是网络问题，是服务端某个线程池打满，接收缓冲区被应用层读得太慢。

这个案例教我一件事：窗口字段比丢包更能反映应用层状态。丢包是网络的事，窗口是端系统的事。很多人一看到重传就查链路，方向错了。

过滤器的写法决定效率

别用 ip.addr == x.x.x.x 这种粗过滤，几千个包能翻到你眼花。组合条件才是正道：tcp.port == 8080 && tcp.len > 0 && !tcp.analysis.retransmission。想找慢请求，直接上 http.time > 1。我见过有人手动翻 5000 个包找异常，花了半小时——用 frame.time_delta > 0.5 三秒定位。

Wireshark 的 tshark 命令行更狠。批量分析 200 个 pcap 文件，一条 shell 循环加 -T fields -e tcp.analysis.ack_rtt，直接导出 CSV 排序。图形界面是给单次排查用的，批量对比必须上命令行。

时间戳的坑

默认 Wireshark 显示的是抓包机本地时间，不是包到达网卡的时间。高精度场景要开 --time-stamp-precision nano，并且确认网卡支持硬件时间戳。我吃过亏：两台机器抓同一个流，时间差 8ms，查了半天以为是网络抖动，结果是系统时钟没同步。后来养成习惯，抓包前先 ntpdate，抓包后看 frame.time_epoch 和 frame.time_relative 的差值。

个人判断：别迷信自动化工具

现在很多 APM 工具能自动标记"慢网络"，但它们的判定逻辑往往是 RTT 阈值。RTT 高不等于网络差——可能是服务端处理慢导致 ACK 延迟。我坚持手动看三个东西：TCP 握手时间、首个数据包到达时间、窗口变化曲线。这三个指标比任何 AI 告警都准。

数据包分析到最后，拼的不是工具熟练度，是对协议栈的理解深度。你知道 tcp.analysis.zero_window 意味着接收方应用没读数据，就知道该去查代码而不是查交换机。这种判断，自动化工具给不了。

(责任编辑：综合)