2. Wireshark部署与高并发采集环境搭建
说实话，很多工程师用 Wireshark 好几年，还停留在「打开软件 → 点开始 → 看颜色」的阶段。我见过不少同事，抓了一堆包，面对几千行数据一脸茫然，最后只能靠猜来定位问题。
这一章，咱们把基础打扎实。我会结合自己踩过的坑，把抓包过滤器、显示过滤器、TCP 流跟踪和时间分析这几个核心功能讲透。你想想看，如果连工具都玩不转，怎么去定位那些棘手的并发问题？
核心要点：Wireshark 的威力不在于「能抓到包」，而在于「能快速从海量数据中找到你要的那几个包」。过滤器和时间分析，就是你的两把手术刀。
2.1 抓包过滤器 vs 显示过滤器：别搞混了
这是新手最容易混淆的地方。我刚开始学的时候也犯过这个错——在抓包过滤器里写了个复杂的表达式，结果啥都没抓到，还以为是网卡坏了。
| 对比维度 | 抓包过滤器 (Capture Filter) | 显示过滤器 (Display Filter) |
|---|---|---|
| 作用时机 | 抓包开始前，决定哪些包进入内存 | 抓包完成后，从已抓到的包中筛选显示 |
| 语法风格 | BPF (Berkeley Packet Filter) 语法 | Wireshark 专有表达式语法 |
| 性能影响 | 高流量场景下必须使用，否则内存爆炸 | 只影响显示，不影响已抓到的数据 |
| 典型场景 | 只抓特定 IP 或端口，减少抓包体积 | 从全量数据中精确过滤出异常报文 |
| 示例 | host 10.0.0.1 and tcp port 80 |
ip.addr == 10.0.0.1 and tcp.port == 80 |
我曾经踩过的坑：有一次在生产环境抓包，我用了显示过滤器的语法写到了抓包过滤器里，结果 Wireshark 直接报语法错误，白白浪费了 10 分钟。记住：抓包过滤器用 host、port、and、or；显示过滤器用 ip.addr、tcp.port、&&、||。
2.1.1 抓包过滤器实战
我个人习惯在抓包前先想清楚：我要关注什么？如果是排查服务并发问题，通常只需要关注目标服务的 IP 和端口。比如我们的后端服务跑在 10.0.0.100:8080：
# 只抓目标服务的流量
host 10.0.0.100 and port 8080
# 排除 SSH 等干扰流量
host 10.0.0.100 and not port 22
# 抓整个网段的 TCP 流量
net 10.0.0.0/24 and tcp嗯，这里要注意：抓包过滤器不支持「等于」符号，它用的是空格分隔的关键词。我第一次用的时候写了个 ip.addr == 10.0.0.1，结果抓了个寂寞。
2.1.2 显示过滤器实战
显示过滤器才是真正的利器。抓完包之后，几千行数据摆在你面前，怎么快速找到问题？我一般会从这几个维度切入：
- 按 IP 和端口过滤：
ip.addr == 10.0.0.100 and tcp.port == 8080 - 按 TCP 标志位过滤：
tcp.flags.syn == 1 and tcp.flags.ack == 0（只看 SYN 包，排查连接建立问题） - 按重传过滤：
tcp.analysis.retransmission（这是排查并发问题的黄金过滤器） - 按响应时间过滤：
tcp.time_delta > 0.5（找出延迟超过 500ms 的包）
小技巧：在 Wireshark 的显示过滤器输入框里，输入 tcp.analysis. 之后按 Tab 键，会弹出所有可用的分析字段。我经常用这个功能来探索 Wireshark 能自动检测哪些异常。
2.2 TCP 流跟踪：把对话串起来看
单看一个个的包，就像看拼图的碎片。TCP 流跟踪功能，能把一次完整的 TCP 会话中的所有包按顺序排列出来。我在排查并发连接泄漏问题时，这个功能帮了大忙。
操作很简单：右键点击任意一个 TCP 包 → Follow → TCP Stream。Wireshark 会自动过滤出这个 TCP 连接的所有包，并按时间顺序展示。
为什么这个功能对并发问题特别重要？我给你举个例子：
- 你怀疑某个客户端占用了连接不释放。通过 TCP 流跟踪，你能看到这个连接从三次握手开始，到数据传输，再到四次挥手（或者没有挥手）的完整过程。
- 你怀疑服务端处理请求太慢。通过流跟踪，你能看到客户端发送请求后，服务端过了多久才回复。
- 你怀疑有半连接状态。通过流跟踪，你能看到 SYN 包发出后，有没有收到 SYN-ACK。
我的经验：在排查并发问题时，我通常会同时打开 3-4 个 TCP 流跟踪窗口，对比不同客户端的行为差异。比如，为什么客户端 A 的连接正常释放，客户端 B 的连接却一直卡在 FIN_WAIT_2？这种对比往往能快速定位问题根因。
2.3 时间列与 Delta 时间分析
时间，是排查并发问题的另一个关键维度。Wireshark 默认显示的是「绝对时间」（包被抓到的时刻），但在分析性能问题时，我们更关心「相对时间」——也就是两个包之间的时间间隔。
2.3.1 添加 Delta 时间列
我个人习惯在 Wireshark 的包列表里添加两列：
- Delta time (显示): 当前包与上一个显示出来的包之间的时间差
- Delta time (捕获): 当前包与上一个被捕获的包之间的时间差
添加方法：右键点击列标题 → Column Preferences → 添加新列 → 选择 Delta time displayed 或 Delta time captured。
为什么要区分这两种？我遇到过这样的情况：用显示过滤器只显示了重传包，这时候「Delta time (显示)」能告诉我两次重传之间隔了多久；而「Delta time (捕获)」则能告诉我原始捕获顺序中，这个重传包和它前面的正常包之间隔了多久。
2.3.2 用 Delta 时间定位并发问题
在并发场景下，Delta 时间能帮你发现很多隐藏的问题：
| Delta 时间特征 | 可能的问题 |
|---|---|
| 请求发出后 Delta > 1s 才收到响应 | 服务端线程池耗尽，请求在排队 |
| 连续多个 SYN 包 Delta 极短（< 1ms） | 客户端并发创建大量连接，可能触发连接风暴 |
| 重传包的 Delta 呈指数增长（0.2s → 0.4s → 0.8s） | TCP 超时重传机制被触发，网络或服务端有瓶颈 |
| FIN 包之后长时间没有 ACK | 连接处于 CLOSE_WAIT 状态，服务端未及时关闭 |
注意：Delta 时间分析要结合具体场景。有一次我看到请求响应 Delta 是 2 秒，以为是服务端慢，结果发现是客户端在发送请求前先做了个 DNS 查询，那 2 秒其实是 DNS 解析时间。所以，一定要看完整的 TCP 流，别被单个 Delta 值误导。
2.4 本章知识体系
下面这张图，把本章的核心知识点串了起来。你可以把它当作一个快速索引，以后遇到问题就知道该用哪个功能。