前言

上周五下午4点，某金融公司交易系统突然变慢，运维团队排查了2小时，最后发现是一台交换机的QoS策略把关键业务流量降了优先级。

如果当时有全流量抓包分析，15分钟就能定位。

本文分享5个我在实际工作中常用的Wireshark抓包技巧，帮你快速定位网络延迟问题。

---

技巧一：用 IO Graph 快速发现流量异常

很多人打开Wireshark就开始看单个包，这是最低效的方式。

正确姿势： 先用 Statistics → I/O Graph 看整体流量趋势。

关键设置：

• Y轴选 Bytes，不要选 Packets
• 时间粒度设为 1 second
• 添加过滤器对比不同流量：tcp.port == 443 vs tcp.port == 80

实战场景： 某次排查发现凌晨3点有规律性流量尖峰，最终定位到是备份任务和业务流量抢带宽。

---

技巧二：TCP Stream Graph 分析传输效率

延迟问题80%出在TCP层。用 Statistics → TCP Stream Graphs → Time-Sequence (tcptrace) 可以直观看到：

• 斜率 = 传输速率（斜率越陡越快）
• 平台期 = 等待ACK（可能是拥塞或丢包）
• 锯齿 = 重传

关键指标：

tcp.analysis.retransmission    # 重传包
tcp.analysis.duplicate_ack     # 重复ACK
tcp.analysis.zero_window       # 零窗口

---

技巧三：Expert Information 一键发现问题

Analyze → Expert Information 是Wireshark最被低估的功能。它会自动分类所有异常：

• Error：校验和错误、畸形包
• Warning：重传、乱序、零窗口
• Note：重复ACK、Keep-Alive
• Chat：TCP握手、挥手

实战经验： 90%的网络延迟问题，在Expert Information里都能找到线索。如果重传超过总包数的2%，基本可以确认是网络层问题。

---

技巧四：按响应时间过滤慢请求

HTTP场景下，用这个过滤器找慢请求：

http.time > 1

数据库场景（MySQL）：

mysql.query && frame.time_delta > 0.5

进阶： 用 tcp.time_delta > 0.1 找TCP层面的慢响应，能发现应用日志看不到的问题。

---

技巧五：对比正常和异常时段的抓包

1. 在业务正常时抓一份基线包（30分钟）
2. 在业务异常时抓一份对比包
3. 分别导出 Statistics → Conversations，对比Top Talkers
4. 关注：新出现的IP、流量暴增的会话、协议分布变化

工具推荐： 用 tshark -q -z conv,tcp 命令行快速导出会话统计。

---

抓包的局限性

Wireshark单点抓包有现实问题：

1. 只能看一个点：东西向流量看不到
2. 存储压力大：10Gbps链路每小时约4.5TB
3. 事后回溯难：没抓就错过现场
4. 缺乏自动告警：需要人盯着看

持续全流量监控方案

对于7x24小时全流量监控场景，可以用专业工具。比如 AnaTraf 网络全流量分析仪（www.anatraf.com），支持全流量实时采集、自动化延迟告警、历史回溯（满足等保2.0的180天留存）。社区版免费，支持虚拟机部署。

---

总结

技巧	适用场景	操作路径
IO Graph	发现流量异常时段	Statistics → I/O Graph
TCP Stream Graph	分析传输效率	Statistics → TCP Stream Graphs
Expert Information	快速定位异常类型	Analyze → Expert Information
响应时间过滤	找慢请求	http.time > 1
基线对比	排查变化点	Statistics → Conversations

记住： 先看整体趋势，再定位具体会话，最后分析单个包。