问题定位-02-Wireshark分析网络问题的基本套路

发表于 分类于 本文字数： 2.3k 阅读时长 ≈ 8 分钟

第一次用 Wireshark 时，通常都会有同一个感受：

  • 信息很多
  • 很强大
  • 但一打开包，还是不知道先看什么

这也是 Wireshark 最容易被用偏的地方。
它不是“看到什么分析什么”的工具，而是一个把杂乱流量压缩成少数关键事实的工具。

如果 tcpdump 更像现场先钉住“包有没有来回”，那 Wireshark 更像是在第二步回答：

  • 到底是哪一段开始慢
  • 是谁先断的
  • 是建连问题、传输问题还是应用问题
  • 这些现象能不能串成一条完整时间线

所以这篇文章不讲菜单大全，只讲一个更实用的问题：

抓到包之后，怎么用 Wireshark 按套路把问题快速看清楚。

一、Wireshark 最先解决的，不是“看懂每个包”，而是“先缩小范围”

很多分析失败，不是因为看不懂协议，而是因为包太多、范围太大。

我用 Wireshark 的第一步几乎从来都不是点开某个包细看，而是先把范围收窄到：

  • 某一条会话
  • 某一组端口
  • 某一个目标 IP
  • 某一种异常现象

如果这一步不先做，后面很容易淹在噪音里。

二、更常用的一套基本分析顺序

如果是网络或接口问题，通常按下面顺序看。

1. 先找关键会话

最先做的是把问题对应的那条流量找出来。

常见收敛方式：

  • 按目标 IP
  • 按目标端口
  • 按时间范围
  • 按 tcp.stream
  • 按协议类型，比如 http、dns

例如先用显示过滤器把范围收窄：

1
ip.addr == 10.10.10.12 && tcp.port == 443

如果是 HTTP 问题，也可能先看：

1
http

或者：

1
dns

2. 再看这条会话的时间线

范围缩小后，最先看的通常不是字段细节，而是时间线。

重点回答：

  • TCP 三次握手是否正常
  • 建连花了多久
  • 请求什么时候发出
  • 首个响应什么时候回来
  • 中间有没有重传、RST、窗口异常

只要时间线拉清楚，很多问题方向就会很快变明白。

3. 再判断异常是发生在建连、传输还是应用阶段

这一步非常关键。

典型判断方式：

  • 握手都没成功：更像端口、链路、路由、防火墙问题
  • 握手正常但请求发不完整：更像发送路径或连接异常
  • 请求发出正常但响应迟迟不回：更像应用处理慢或下游慢
  • 响应回来途中出现异常：更像中间层或回包路径问题

4. 最后才看更细的协议内容

比如：

  • HTTP 状态码
  • DNS 响应内容
  • TLS 握手阶段
  • 某些具体字段是否异常

如果一开始就钻字段，很容易在错误层级上花太久时间。

三、最有价值的 5 个高频观察点

如果只说最常用的，通常优先盯下面这 5 类现象。

1. TCP 三次握手

先看：

  • SYN
  • SYN, ACK
  • ACK

它能最快回答：

  • 端口是否可达
  • 对端是否有响应
  • 建连是否慢

如果这里就不正常，后面大多数应用层分析都没必要太早展开。

2. 重传

看到大量 Retransmission，通常先考虑：

  • 丢包
  • 链路不稳
  • 某段网络质量差
  • 对端没及时回应

重传不是根因，但它很能提示方向。

3. RST

看到 RST 时，会特别注意：

  • 是哪一端发的
  • 是建连阶段还是传输阶段
  • 是立即拒绝还是中途异常断开

这经常能快速判断：

  • 端口没监听
  • 服务主动断开
  • 某层代理提前断链

4. DNS 请求与响应

很多“服务超时”最后不是服务慢，而是：

  • 域名没解出来
  • 解析到了错误地址
  • DNS 请求发出后没回

这类在 Wireshark 里非常容易看清楚。

5. 首包响应时间

如果 TCP 正常、请求发出正常，但响应首包很久才回来，那方向通常更偏：

  • 应用处理慢
  • 数据库慢
  • 下游服务慢
  • 线程池或连接池耗尽

四、几个非常实用的显示过滤思路

显示过滤器不是越复杂越好，能快速把范围缩到问题点最重要。

1. 看某个 IP

1
ip.addr == 10.10.10.12

2. 看某个端口

1
tcp.port == 443

3. 同时限定 IP 和端口

1
ip.addr == 10.10.10.12 && tcp.port == 443

4. 看 DNS

1
dns

5. 看 HTTP

1
http

6. 看单条 TCP 会话

1
tcp.stream == 7

这个特别好用。
很多复杂问题一旦锁定到一条 tcp.stream，分析难度会直接降很多。

五、更常用的最小实战骨架

如果拿到一个 pcap 文件，通常会这样开始。

1. 先定位问题时间段

例如业务方说：

  • 10:21 左右开始超时

那先看这个时间窗附近，而不是从头翻。

2. 再定位目标会话

例如：

  • 某个目标 IP
  • 某个服务端口
  • 某个请求路径对应的 HTTP 会话

3. 再沿时间线看四件事

  • 是否成功建连
  • 请求是否完整发出
  • 响应是否回来
  • 异常是在哪个时刻第一次出现

4. 最后再把结论写成一句人能看懂的话

例如：

  • 握手正常，请求发出正常，但服务端首包 8 秒后才返回，问题更偏应用处理慢
  • 客户端能发出 SYN，但服务端没有任何响应，问题更偏链路或服务未监听
  • 服务端已回包，但客户端未收到，问题更偏回包路径异常

Wireshark 分析如果最后不能落成一句清楚的话，就说明分析还没收住。

六、最容易踩的几个坑

1. 一上来就看字段细节

这通常会让人陷进局部，却没先搞清楚整体时间线。

2. 没把范围缩到单条流

只在全局流量里来回翻，容易把不同请求混在一起。

3. 把“看到重传”直接当根因

重传本身只是现象。
真正还要继续判断：

  • 为什么会重传
  • 是谁先不回应

4. 不结合抓包之外的信息

Wireshark 很强，但它通常要和下面这些一起看更准：

  • 应用日志
  • 监控时间线
  • 请求发起时间
  • 服务端处理时间

只看包，不看上下文，也容易误判。

七、真实案例：为什么接口超时看起来像服务慢，最后却不是服务本身的问题

场景

一个内部接口偶发超时，前端侧表现是：

  • 点击查询后长时间等待
  • 最后报超时

服务端侧的第一判断是：

  • 是不是查询逻辑太慢

因为应用日志里也能看到少量慢请求。

执行

先拿到了对应时间段的抓包文件，然后在 Wireshark 里按下面顺序收敛：

  1. 先过滤目标 IP 和端口
  2. 再定位到具体 tcp.stream
  3. 按时间线看握手、请求、响应

现象

看下来发现：

  • TCP 建连本身是正常的
  • 请求报文也完整发出了
  • 但服务端响应前，客户端侧已经出现了明显的重传
  • 同一时间段还有多个流出现类似现象

这就说明问题不像单个请求逻辑慢，更像链路层面有异常。

排查

继续结合网络侧排查后，定位到某段链路在特定时间窗丢包明显，导致请求和响应过程中都出现了重传和延迟放大。

也就是说：

  • 服务端确实有少量慢日志
  • 但那不是主因
  • 主因是链路抖动导致整体时延被放大

修复

最终修复动作并不是优化接口代码，而是：

  1. 先处理异常链路
  2. 再复测相同场景
  3. 确认抓包中的重传明显下降
  4. 再回头看服务端慢日志是否仍异常

这个案例很典型地说明：

Wireshark 的价值，不只是“看到包”，而是把看起来像应用慢的问题，及时纠偏到真正异常的那一层。

八、怎么把 Wireshark 用成稳定能力

更合适的做法是把它沉淀成一套固定动作：

  • 先收窄范围，不先钻细节
  • 先看时间线，不先看字段
  • 先判断问题层级，不先急着定根因
  • 先把结论压缩成一句话，再继续细化

只要这几个动作固定下来，Wireshark 就不会只是“会用界面的人能看两眼”的工具，而会真正变成排障里的第二层证据工具。

九、写在最后

Wireshark 最有用的地方，不是把包看得更复杂，而是把问题看得更清楚。

很多时候你真正需要的并不是解释每一个包，而是把下面这几件事讲明白：

  • 哪条流有问题
  • 问题先出现在哪个时刻
  • 异常更像建连、传输还是应用
  • 现象和结论之间能不能连起来

如果这几件事能用 Wireshark 快速回答，它在问题定位里的价值就已经出来了。