问题定位-01-tcpdump在问题定位中的高频用法

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

很多网络问题一到现场，最容易出现的局面是：

  • 客户端说请求发出去了
  • 服务端说自己没收到
  • 中间层说监控没看到异常

然后每个人都在描述自己的视角，但没人能先把最基础的问题回答清楚：

  • 包到底有没有出来
  • 包到底有没有到
  • 对端到底有没有回
  • 是哪一段先开始不对

这就是 tcpdump 在问题定位里最实际的价值。

它不是为了让你背更多参数，而是为了在最短时间内把“到底有没有流量、流量在哪开始异常”这件事先钉住。

这篇文章不打算写成命令手册，而是按现场排障的方式讲：

  • tcpdump 最常见的几类高频用法
  • 怎么抓包才不至于抓一堆没用数据
  • 抓到之后先看什么
  • 哪些现象最值得优先判断

一、tcpdump 最值得先回答的，不是细节问题，而是路径问题

现场排障时，通常不会一上来就看协议细节。
更优先的问题通常是这几个：

  • 请求有没有从本机发出去
  • 请求有没有到目标主机
  • 目标主机有没有回应
  • 回应有没有被中间链路挡住
  • 是 DNS、TCP 建连、应用响应还是回包路径出了问题

tcpdump 最适合先解决的，就是这些路径问题。

因为只要这一步还没搞清楚，后面所有“是不是应用 bug”“是不是服务慢”“是不是鉴权有问题”的讨论都很容易跑偏。

二、最常用的 5 类抓包场景

如果按现场频率排，最常抓的是下面 5 类。

1. 连通性和端口可达性

典型问题：

  • 请求打过去完全没反应
  • 服务端口疑似没开
  • 防火墙或安全组怀疑拦截

这时最先看的不是应用日志，而是：

1
sudo tcpdump -i any host 10.10.10.12 and port 8080 -nn

重点先确认：

  • 有没有 SYN
  • 有没有 SYN, ACK
  • 有没有立即 RST

如果只有 SYN 没有回应，通常先看：

  • 对端没收到
  • 对端没监听
  • 中间链路丢了

如果直接 RST，通常更像：

  • 端口没监听
  • 主机直接拒绝

2. DNS 解析问题

典型问题：

  • 域名偶发解析失败
  • 接口超时，但实际是名字没解出来
  • 同一服务在不同机器上表现不一致

这时先抓：

1
sudo tcpdump -i any port 53 -nn

先回答：

  • DNS 请求有没有发出去
  • 发给了哪个 DNS 服务器
  • 是否有响应
  • 是否频繁重试

很多“服务不可用”最后根因并不在服务，而在 DNS。

3. TCP 建连慢或偶发失败

典型问题：

  • 接口不是每次都失败，但偶发超时
  • 建连阶段就拖很久
  • 某个环境特别慢

这种场景会更关注三次握手是否正常，以及重传情况：

1
sudo tcpdump -i any host 10.10.10.12 and tcp port 443 -nn -tttt

重点看：

  • SYN 到 SYN, ACK 的时间差
  • 是否有重复 SYN
  • 是否有大量重传

4. 应用层有问题，但先确认是不是网络问题

典型问题：

  • 页面报超时
  • 接口返回慢
  • 服务端说自己处理很快

这时抓包的价值不是马上看 HTTP 内容，而是先把时间分层：

  • 建连花了多久
  • 请求发出花了多久
  • 对端第一个响应包多久回来
  • 是网络卡住，还是应用处理慢

5. 回包路径异常

典型问题：

  • 客户端说没收到响应
  • 服务端说自己已经回了

这个时候 tcpdump 最重要。

因为你可以分别在：

  • 客户端
  • 服务端
  • 中间代理节点

抓同一条流量，然后回答：

  • 哪一端最后一次看到正常包
  • 哪一段之后包消失了

这比反复争论“我这边没问题”有用得多。

三、更常用的一套最小抓包方法

tcpdump 抓包失败，常见原因不是不会用，而是一上来抓太大、太杂，最后文件一堆但没有证据。

更常用的最小方法是：

1. 先明确 4 个信息

抓之前先确定：

  • 抓哪台机器
  • 抓哪个网卡
  • 抓哪对 IP
  • 抓哪个端口或协议

如果这 4 个信息都不清楚，抓包通常会很散。

2. 先抓最小过滤条件

例如：

1
sudo tcpdump -i any host 10.10.10.12 and port 8080 -nn

或者：

1
sudo tcpdump -i eth0 tcp and host 10.10.10.12 and port 443 -nn

不要一开始就把整个网卡所有包都抓下来，现场很容易把自己淹没。

3. 先看终端，再决定要不要落文件

如果只是确认连通性、握手、有没有重传，很多时候先看终端就够了。

如果需要后续复盘、给别人分析，再落 pcap：

1
sudo tcpdump -i any host 10.10.10.12 and port 8080 -nn -w issue-20210513.pcap

4. 只在必要时提升抓包范围

先抓：

  • 单 IP
  • 单端口
  • 单协议

如果证据不够，再逐步放大，不要一开始就全网卡全协议全量抓。

四、几个最有用的高频命令

1. 看指定主机和端口

1
sudo tcpdump -i any host 10.10.10.12 and port 8080 -nn

适合：

  • 先确认流量有没有来回

2. 看 DNS

1
sudo tcpdump -i any port 53 -nn

适合：

  • 域名解析失败
  • DNS 重试

3. 落包文件供后续分析

1
sudo tcpdump -i any host 10.10.10.12 and port 443 -nn -w api-timeout.pcap

适合：

  • 后续用 Wireshark 复盘
  • 把问题交给网络或中间件同学继续看

4. 按时间看握手和重传节奏

1
sudo tcpdump -i any host 10.10.10.12 and tcp port 443 -nn -tttt

适合：

  • 看超时点
  • 看重传节奏

5. 只看少量样本快速确认

1
sudo tcpdump -i any host 10.10.10.12 and port 8080 -nn -c 20

适合：

  • 先抓几个包快速判断方向

五、抓到包之后，先看什么

如果只是现场快速判断，通常按下面顺序看。

1. 先看有没有请求出去

没有请求出去，优先怀疑：

  • 应用根本没发
  • 请求发错网卡或发错地址
  • 本机路由有问题

2. 再看对端有没有回应

没有回应时，优先考虑：

  • 对端没收到
  • 对端没监听
  • 中间链路丢弃

3. 再看是不是被拒绝

看到 RST 时，通常方向会更清楚：

  • 端口没开
  • 服务拒绝
  • 某层代理直接断开

4. 再看有没有重传和超时

大量重传通常说明：

  • 丢包
  • 链路不稳
  • 某段网络质量差

5. 最后才考虑是不是应用层慢

如果 TCP 路径正常、握手正常、请求发出正常，但响应首包很久才回来，那才更像：

  • 应用处理慢
  • 下游依赖慢
  • 线程池或连接池耗尽

六、现场最容易踩的几个坑

1. 抓错网卡

很多机器有：

  • eth0
  • docker0
  • cni*
  • lo

如果抓错网卡，结论很容易完全错掉。
所以我现场经常直接先用 -i any 快速确认方向。

2. 过滤条件太宽

一上来抓整个 443 或整台机器全流量，很容易看花。
更好的方式是先按“单主机 + 单端口”收窄。

3. 只抓一边就下结论

有些问题如果只抓客户端，很容易判断成服务端没回；
但如果服务端抓一下，可能会发现服务端其实已经回了，只是中间链路没回来。

4. 只看有没有包，不看时间

很多问题不是“完全没包”，而是：

  • 很慢
  • 重试很多次
  • 第一次失败第二次才成功

所以时间维度非常重要。

七、真实案例：为什么服务端说已经回了，客户端还是一直超时

场景

一个内部接口在压测环境里频繁超时。
客户端同学说：

  • 请求已经发出
  • 页面一直转圈，最后超时

服务端同学说：

  • 应用日志里已经处理完成
  • 响应也正常返回了

看起来双方都很确定，问题却一直对不上。

执行

我没有先看应用代码，而是先在两边同时抓包。

客户端抓：

1
sudo tcpdump -i any host 10.20.8.15 and port 8080 -nn -tttt

服务端抓：

1
sudo tcpdump -i any host 10.20.8.21 and port 8080 -nn -tttt

现象

抓包结果非常清楚：

  • 客户端能正常发出请求
  • 服务端也确实收到了请求
  • 服务端处理完成后也发回了响应包
  • 但客户端侧始终收不到对应的响应

也就是说：

  • 应用层不是主因
  • 真正的问题在回包路径

排查

继续结合网络路径排查后发现，中间一层负载均衡配置变更后，回包链路走偏了，导致响应没有按预期返回到客户端侧。

这类问题如果只看应用日志，服务端会一直觉得“我明明回了”。
如果只看客户端现象，客户端会一直觉得“服务端根本没回”。

而双端抓包一下就把边界切清楚了：

  • 请求路径正常
  • 回包路径异常

修复

最终修复动作很明确：

  1. 调整中间层回包路由
  2. 复测同一条流量
  3. 确认客户端已能收到响应首包
  4. 将这类场景加入网络变更后的专项回归

这个案例很典型地说明：

tcpdump 最大的价值，不是解释所有协议细节，而是先把“哪一段开始不对”钉住。

八、怎么把 tcpdump 变成长期高价值能力

更合适的做法是把它沉淀成一套现场动作，而不是想到才用。

至少固定这几条：

  • 先问清楚抓包目标：哪台机、哪张网卡、哪对 IP、哪个端口
  • 先小范围抓，确认方向后再扩大
  • 先看是否有请求、有响应、有重传、有 RST
  • 关键问题尽量双端抓包
  • 抓到后把时间线和现象对应起来

这样 tcpdump 才不是一个“懂点命令的人会用”的工具，而是真正能在现场把排障往前推进的一步。

九、写在最后

tcpdump 在问题定位里最有用的地方，并不是它参数很多，而是它能帮你先把争议最小化：

  • 包有没有出来
  • 包有没有到
  • 对端有没有回
  • 哪一段先开始异常

只要这四件事先清楚了，后面的应用排障、网络排障、代理排障才不会一直绕圈子。