tcpdump 是什么
tcpdump 是 Unix/Linux 上基于 libpcap 的命令行抓包工具，从 BSD 时代沿用至今，主流发行版的软件仓库都自带。它把网卡切到混杂模式（Linux 上走 AF_PACKET 直接收包），按 BPF 过滤表达式筛选报文，再以一行一条的摘要打印，或把原始字节原样写入 pcap 文件。它自身只做有限解码，好处是开销小、能长时间运行；协议语义的深入分析交给 Wireshark/tshark 读同一个文件完成。没有图形界面的服务器上，它通常是定位连接失败、丢包与超时的第一手段。
基本信息
| 适用平台 | Linux / Unix（BSD、macOS 亦有）；Windows 侧对应的是 Npcap 环境下的 windump |
|---|---|
| 依赖 | libpcap |
| 语法 | tcpdump [选项] [BPF 过滤表达式] |
| 权限 | root，或具备 CAP_NET_RAW 能力的普通用户 |
| 安装 | yum install tcpdump / apt install tcpdump |
典型使用场景
- 复现偶发连不上：抓一段建连报文，确认 SYN 是否真的发出、对端是否回了 SYN-ACK
- 排查慢请求：落盘后统计重传与握手时延，区分网络丢包与应用处理慢
- 验证防火墙或安全组改动：看请求是否真的到达主机，判断是路径被丢弃还是本机拒绝
- 对接第三方排障：抓出对方实际发送的报文字节与顺序，不靠口头描述推断
- 取证与留痕：把原始报文落盘归档，事后可从任意角度复核
常用示例
常用示例
tcpdump -D # 先列出可用接口，确认网卡名
tcpdump -i eth0 -nn -c 20 # 在 eth0 抓 20 个包，关闭名称解析
tcpdump -i any -nn port 443 -w /tmp/tls.pcap # 落盘：443 流量存成 pcap
tcpdump -i eth0 -nn 'host 10.0.0.9 and tcp port 3306' # 只看某客户端访问数据库
tcpdump -nn -r /tmp/tls.pcap | head -30 # 回读 pcap，看前 30 行摘要
tcpdump -i eth0 -nn -s 0 -A 'tcp port 80' # 明文 HTTP：直接打印载荷
tcpdump -i eth0 -nn -ttt -c 50 port 22 # 相对时间戳，方便看包间隔
timeout 60 tcpdump -i any -nn -w /tmp/a.pcap port 8080 # 加超时兜底，避免忘记停输出逐列读法
| 位置 | 含义 | 要留意什么 |
|---|---|---|
| 时间戳 | 形如 13:20:01.123456；配 -ttt 时是相对上一包的间隔 | 间隔突然放大往往对应重传或应用卡顿 |
| 源地址.端口 | 发送方 IP 与端口 | 客户端端口多为随机高位端口，服务端口固定 |
| 箭头方向 | 报文方向，如 10.0.0.5.52344 > 10.0.0.9.443 | 结合抓包点判断这是出向还是入向 |
| Flags [S] 等 | TCP 标志位：S=SYN、S.=SYN-ACK、.=ACK、P.=PSH-ACK、F.=FIN-ACK、R=RST | 建连、关闭、复位三种流程全靠它辨认 |
| seq / ack / win | 序列号、确认号与接收窗口 | 同一 seq 反复出现即重传；win 0 表示对端窗口关闭 |
| length | 载荷字节数，length 0 多为纯 ACK | 只有长度非 0 的包才承载应用数据 |
不加过滤表达式时，tcpdump 会把接口上能看到的报文全部打印。生产环境先想好条件再动手；交互式运行用 Ctrl+C 停止，脚本里建议配 timeout，避免无人值守时无限抓包。
-nn 之外还有 -v/-vv/-vvv 提升解码详细度，-X 以十六进制加 ASCII 显示整包，-e 附加二层头部。这些打印选项只影响显示，写文件时内容不变。
落盘与回读
落盘与回读
tcpdump -i any -s 0 -w /tmp/issue_$(date +%F_%H%M).pcap 'host 10.0.0.9 and port 443' # 按时间命名便于归档
tcpdump -nn -r /tmp/issue_20261013_1010.pcap -c 20 -tttt # 回读时同样支持过滤器与打印选项
tshark -r /tmp/issue.pcap -Y 'tcp.analysis.flags' | head # 交给 tshark 做异常标注排障思路
- 先在客户端抓：确认请求是否真的发出，源地址与目的端口是否符合预期
- 再去服务端抓：同一时刻同一端口上是否看到同一个请求进来
- 两端都看到请求却不通用：重点看回程，检查路由、策略与中间安全设备
- 服务端看到请求却无响应：查监听进程、连接队列与内核参数，问题多不在网络
- 只有单向抓包可用时，用标志位与序列号推断另一侧发生了什么，并写明推断依据
- 抓到异常先落盘再分析：文本摘要只能看到一部分事实，原始字节才能定论
抓包进程本身也会丢包：高负载机器上 tcpdump 可能来不及落盘，观察到的缺口未必发生在网络里，判断时要说明抓包点与丢包可能性。