Linux抓包实战：tcpdump、BPF过滤与丢包排查

在运维和后端排查问题的现场，捕获数据包几乎是最后一招，也是最见效的一招。接口返回慢、连接莫名断、偶发超时、三方回调收不到，这些在日志里看不出所以然的问题，一旦把链路上的原始报文摊开来看，往往几分钟就能定位。它不是只有安全方向才用得上的技能，做服务端、做数据库、做网关、做嵌入式联网设备的人，早晚都要碰。这篇内容我按自己在生产环境里的操作顺序来写：先讲清楚抓包在操作系统里到底发生了什么，再讲工具选型和权限怎么配，然后是过滤器怎么写、文件怎么滚动落盘、命令行怎么快速出结论，最后把丢包、时间戳不准、文件爆炸这几个最容易踩的坑摊开说。只要你能在测试机或者自有环境里动手，跟着走一遍就能上手，不需要提前懂协议细节。

1. 抓包这件事到底在抓什么：从网卡到文件的完整链路

1.1 一个数据包在操作系统里要走的几道门

很多人对抓包的理解停留在"软件把网线上的电信号读出来"，其实不是。现代网卡收到帧之后，DMA 把数据写进内核的接收环形缓冲区，触发硬中断，然后走 NAPI 轮询机制进入协议栈，依次经过链路层、网络层、传输层，最后交给 socket 对应的进程。抓包程序要做的事情，是在这条路径上"插一个旁路分支"，把报文复制一份出来。

Linux 上这个旁路分支的入口是AF_PACKET这个协议族。抓包程序创建一个AF_PACKET类型的 socket，绑定到具体网卡，内核在协议栈的特定钩子点把 skb（socket buffer）复制一份投递给这个 socket。复制发生在离开驱动之后、进入上层协议之前，所以你能看到完整的二层帧，包括 MAC 头和可能存在的 VLAN 标签。

这里有个关键点值得记住：复制是有成本的，而且默认情况下每个包都要复制。所以在高流量网卡上抓包，本身就是一种负载。我在一台跑 8Gbps 转发的小机器上试过，不加过滤器全量抓，CPU 的 softirq 直接飙到 90% 以上，业务延迟肉眼可见地涨。这也是后面要反复强调过滤器重要性的原因。

另一个容易忽略的事实是，抓包程序看到的包和你用curl请求时看到的包，可能不是同一份。如果你的程序走的是回环接口，流量根本不经过物理网卡；如果走了隧道或者 overlay 网络，外层还有一层封装。定位问题时先搞清楚"流量到底走哪张网卡"，这一步比什么都重要。

1.2 混杂模式到底改变了什么

新手最常问的问题是："为什么我抓不到别人的包？"答案跟混杂模式（promiscuous mode）有关。

网卡在默认状态下只接收两类帧：目的 MAC 是自己的，以及广播/组播。这叫正常模式。开启混杂模式后，网卡会把线上所有帧都交给内核，不再做 MAC 地址过滤。抓包工具里加-p参数就是明确禁用混杂模式，不加则默认尝试开启。

这里有个常见的误解：以为开了混杂模式就能抓到整个局域网所有人的流量。在早年的共享式集线器时代确实可以，因为那时所有帧物理上会广播到每个端口。但现在的接入设备是交换机，交换机会根据 MAC 地址表做定向转发，A 端口的帧根本不会送到 B 端口。所以在交换机环境下，你开了混杂模式也只看得到本机相关的流量、广播流量，以及交换机的泛洪流量。

注意：这条特性决定了"抓别人的包"在正常情况下是做不到的，也不应该去做。真要看全链路流量，标准做法是在你自己的网络设备上配置端口镜像，或者串接一个网络分流器，前提是这台设备和上面的流量你有管理权限。生产环境里动镜像口之前，先确认镜像会话不会把核心链路打满，我见过因为镜像口配错导致交换机 CPU 被打爆的案例。

混杂模式还有一个副作用常被忽略：在某些虚拟化平台和无线网卡上，开启它会显著增加 CPU 占用，因为内核要处理大量本来会被网卡丢弃的帧。所以当你的目标很明确时（比如只看本机到某个服务的流量），加-p反而是更好的选择。

1.3 工具选型：命令行的抓、图形界面的看、脚本的算

工具这块不用纠结，按"抓"和"看"两个阶段分开选就行。

抓的阶段首推tcpdump，理由很简单：它是几乎所有 Linux 发行版都能一条命令装上的基础工具，依赖极少，跑在最小化安装的生产机上没有负担，而且过滤器语法和pcap文件格式是整个生态的事实标准。dumpcap是 Wireshark 套件里专门负责抓包的组件，它的优势是内置了多线程写盘和更细的缓冲区控制，在高速率场景下比tcpdump更抗丢包。tshark则是 Wireshark 的命令行版本，抓和分析都能干，适合写进自动化脚本。

看的阶段，桌面环境直接上 Wireshark，它的"跟随 TCP 流"、专家信息、IO 图表这些功能，是命令行工具短期内追不上的。服务器上没有图形界面就退回tshark，配合-z系列统计选项和-T fields提取字段，能覆盖八成以上的分析需求。

选型的核心判断依据是在哪里抓、抓多久、谁来看这三件事。生产机上临时抓五分钟定位问题，tcpdump足够；要在边缘节点常驻抓包做回溯，就得考虑dumpcap加环形缓冲；要把分析结果沉淀成报表，只有tshark加脚本这条路。至于图形化工具，永远不要在你不完全掌控的业务机上装，它的依赖链会带来一堆你不想维护的东西。

2. 开工前的环境准备与权限配置

2.1 Linux 下权限怎么给才既安全又够用

抓包需要CAP_NET_RAW能力，开混杂模式还需要CAP_NET_ADMIN。直接用 root 跑是最省事的做法，但在生产机上是坏习惯——一个带缓冲区溢出风险的解析器跑在 root 下，等于把整台机器交出去。

推荐的做法是给二进制文件打上能力标签：

sudo setcap cap_net_raw,cap_net_admin+eip /usr/sbin/tcpdump

打完标签后，普通用户执行tcpdump就不再需要sudo。用getcap可以验证是否生效：

getcap /usr/sbin/tcpdump # 期望输出：/usr/sbin/tcpdump cap_net_admin,cap_net_raw=eip

注意：setcap的结果会在软件包升级时被覆盖。Debian 系升级tcpdump之后大概率要重新打一次标签。如果你的环境用配置管理工具，记得把这条命令写进包管理的 post-hook 里，否则某次自动升级之后定时抓包任务会静默失败，而日志里只有一句权限不足。

Wireshark 在桌面发行版上有个更规范的做法：安装时选择允许非 root 用户抓包，它会创建一个wireshark用户组并把dumpcap的能力限制好，把需要用的账号加进这个组即可。这个机制比sudo wireshark安全得多，因为图形界面本身跑在普通用户权限下，只有底层抓包组件持有能力。

如果环境不允许改二进制能力（比如只读文件系统或者合规要求），退而求其次用sudo加白名单，把tcpdump的绝对路径写进 sudoers，禁止通配符参数。这样至少能防止有人借抓包工具的写文件参数覆盖系统文件。

2.2 抓之前先看三样东西：网卡、缓冲区、时钟

动手之前花三十秒做三个检查，能省掉后面半小时的困惑。

第一，确认网卡名和状态。ip -br link一眼看清所有接口和 UP/DOWN 状态。别想当然地写eth0，现在服务器上动辄ens192、eno1、bond0，容器里更是vethxxxx一堆。抓错网卡是最低级的浪费时间。

第二，看内核缓冲区上限。抓包 socket 的接收缓冲默认值往往偏小，高速率下不够用就会丢包：

sysctl net.core.rmem_max net.core.rmem_default

如果rmem_max只有 200KB 左右，而你要抓的业务峰值在 1Gbps 以上，那基本注定要丢。可以临时调大：

sudo sysctl -w net.core.rmem_max=67108864

这个值是字节，64MB 对绝大多数场景够用了。抓包工具的-B参数单位是 KB，两者要对上，比如-B 65536对应 64MB 左右。

第三，看时间。抓包的时间戳来自系统时钟，如果机器没做时间同步，你拿着抓包文件和另一台机器的日志对时间，会得出完全错误的结论。timedatectl status看同步状态，chronyc tracking看偏差量。分布式排障场景下，各节点时钟偏差控制在毫秒级是底线。

还有个容易被忽略的检查项：磁盘剩余空间和写入速度。抓包文件写的是顺序 IO，但如果你指定的目录正好在忙的机械盘上，写盘速度可能成为丢包的原因。放到独立的数据盘或者 tmpfs 上是更稳的选择，代价是重启丢数据这个权衡自己判断。

2.3 抓包点选在哪里：本机、容器、还是上游设备

这个问题决定了你能看到什么，比工具选型重要得多。

本机抓是最简单的，直接抓业务网卡。局限是只能看到这台机器收发的流量，看不到它上游设备之间的交互。如果问题是"请求发出去了但对方说没收到"，本机抓只能证明你发出去了，证明不了对方收到没有。

容器里抓要分情况。容器共享宿主机内核，网络命名空间是独立的。在宿主机上抓veth对的一端，能看到该容器的进出流量；如果想在容器内部视角抓，用nsenter进入它的网络命名空间：

# 先拿到容器主进程 PID CONTAINER_PID=$(docker inspect -f '{{.State.Pid}}' my_container) # 进入网络命名空间执行抓包 sudo nsenter -t "$CONTAINER_PID" -n tcpdump -i eth0 -nn -c 100

-n是不做主机名解析、-nn是连端口也不做服务名解析。这两个参数强烈建议常开，否则 DNS 查询会污染你的抓包结果，还会拖慢输出。我在一次排查里就吃过亏：没加-n，抓包文件里混进了大量 DNS 查询包，把原本想看的业务流量淹了。

上游设备抓指的是交换机镜像口或者串接分流器，能看到多台机器之间的完整交互。这条路的前提是设备在你管理范围内、有权限配置、并且经过评估不会影响转发性能。跨机器的问题如果在本机抓不到答案，就该往这个方向走，而不是反复在同一台机器上换工具。

3. BPF 过滤器：把噪音砍掉九成

3.1 过滤器语法的三层结构

BPF 过滤器的语法看着杂，其实就三层维度在组合：类型（type）、方向（dir）、协议（proto）。理解了这三层，剩下的就是排列组合。

类型指的是匹配什么对象，常用的是host（主机）、net（网段）、port（端口）、portrange（端口范围）。方向是src、dst以及它们的组合，不写就是双向。协议是tcp、udp、icmp、arp、ip、ip6这些。

组合规则很简单：省略的部分自动取默认值。写port 443，等价于tcp or udp两种协议、两个方向、端口 443。写src host 10.0.0.8，就是"源地址是 10.0.0.8 的所有协议报文"。

多个条件之间用and、or、not连接，优先级是not高于and高于or，拿不准就加括号。这个优先级规则坑过不少人：host a or host b and port 80实际是host a or (host b and port 80)，如果本意是两个主机都要限定 80 端口，必须写成(host a or host b) and port 80。

提示：过滤器是在内核里执行的，不匹配的包连复制都不会发生，所以它对性能的改善是数量级的，而不是线性的。写一个好的过滤器，等于把抓包对业务的影响从"明显"降到"可忽略"。

3.2 我在现场最常用的几组过滤器配方

下面这张表是我这些年反复用到的组合，基本都是可以直接抄的。

关于"排除抓包自身连接"这一条，值得展开说。你通过 SSH 登录到目标机器上抓包，SSH 会话本身的流量也会被抓到，而tcpdump的输出又会通过 SSH 传回来，形成正反馈。在带宽紧张或者包量大的场景下，这个循环能把链路压死。所以只要是在远程会话里抓，第一件事就是not port 22（或者你实际用的端口）。

3.3 过滤器写错了有多贵：两个真实验证方法

过滤器写错有两种后果：写得太严，抓不到想要的包，白跑一趟；写得太松，文件爆炸，分析时找不到重点，还可能把业务拖慢。所以写完之后一定要验证。

第一种验证方式是先计数不落盘。用-c限定包数或者直接看输出，跑十秒钟按 Ctrl+C 看统计：

sudo tcpdump -i ens192 -nn -p 'tcp port 443 and host 10.0.0.8' -c 20

如果能迅速打出 20 个包，说明过滤器命中了目标流量；如果跑半分钟一个都没有，要么过滤器写错了，要么流量确实不存在——这两种情况需要区分，别急着改过滤器。

第二种验证方式是用-w落盘后立即统计协议分布，确认抓到的内容符合预期：

sudo tcpdump -i ens192 -nn -p -w /tmp/check.pcap -c 2000 'tcp port 443' tshark -r /tmp/check.pcap -q -z io,phs

-z io,phs会输出协议分层统计，一眼就能看出抓到的包里 TCP 占多少、有没有混进 ARP 和 DNS。如果发现八成都是 ARP，说明过滤器太松或者抓错了网卡。这个两分钟的自检流程，比我见过的任何事后补救都便宜。

4. 实操：一次完整的抓包与落盘分析流程

4.1 环形缓冲区：让抓包文件不撑爆磁盘

生产环境常驻抓包最大的风险是磁盘被写满。解决办法是环形缓冲区：限定单个文件大小和文件数量，写满一个就滚动到下一个，超过数量上限就覆盖最旧的。

sudo tcpdump -i ens192 -nn -p -s 0 \ -C 100 -W 20 \ -w /data/capture/edge_$(hostname).pcap \ 'tcp and not port 22' &

这里每个参数都有讲究。-C 100表示单个文件 100MB，-W 20表示最多保留 20 个文件，那么总占用上限就是 100MB × 20 = 2000MB，也就是 2GB。这个容量规划要按"最长需要回溯多长时间"来倒推：如果业务峰值是 20Mbps，2GB 大概能存 13 分钟左右（2000MB × 8 ÷ 20Mbps ≈ 800 秒），够不够用来抓偶发问题，自己判断。

-s 0表示抓完整包长度。早期版本的tcpdump默认snaplen是 96 字节，只抓头部，如果只想看握手和头部信息，用-s 96能大幅减小文件体积，代价是看不到应用层负载。排查 TLS 握手或者 HTTP 内容时，必须-s 0抓全，否则载荷被截断，分析工具会报"包被截断"。

后台运行时记得记录 PID，方便之后优雅停止：

echo $! > /var/run/capture.pid # 停止时 sudo kill -TERM "$(cat /var/run/capture.pid)"

用SIGTERM而不是SIGKILL，因为tcpdump收到SIGTERM会正常关闭文件并写入统计信息，包括丢包计数——这个计数是后面排查的关键依据，用-9强杀就丢了。

4.2 时间戳、快照长度与文件格式的取舍

这几个参数看起来是细节，但它们直接决定了你事后能不能分析出结论。

时间戳精度：默认是微秒级，在高频交易或者高精度性能分析场景下不够用，可以开启纳秒精度。但要注意，纳秒精度需要网卡和驱动支持硬件时间戳，否则内核算出来的纳秒位是不可信的。查看方式是在输出里看小数点后的位数，以及和系统时间对比。

时间戳显示格式：-tttt输出人的可读日期时间，-tt输出 Unix 时间戳，不指定则是相对时间（从第一个包开始算）。跨设备对比日志时必须用绝对时间，用相对时间等于给自己挖坑。

文件格式：默认是pcap，通用性最好。数据量特别大的场景可以考虑pcapng，它支持多接口、注释和更丰富的元数据，但兼容性稍差，老版本的解析库可能读不了。除非有明确需求，我一般还是用pcap，省得给后面的分析工具找麻烦。

写入缓冲：-U参数让每个包到达就立刻写盘，不缓冲。这么做的好处是实时性高，程序崩溃时已经抓到的数据不会丢；坏处是写盘次数暴增，在高包量下会明显增加 CPU 和 IO 压力。判断标准很简单：如果抓包是用来实时监控告警的，加-U；如果是事后回溯分析，不加，让内核做批量写。

4.3 从抓包文件到结论：命令行里最有效的几条命令

抓完包才是真正的工作开始。Wireshark 图形界面适合精细分析，但在服务器上我用得最多的是下面这几条tshark命令。

先看整体画像，确认抓到的流量构成是否正常：

tshark -r trace.pcap -q -z io,phs

再看会话排行，找出流量最大的那几对通信：

tshark -r trace.pcap -q -z conv,tcp

排查重传和乱序，这两个指标基本能反映链路质量：

# 统计重传包数量 tshark -r trace.pcap -Y "tcp.analysis.retransmission" 2>/dev/null | wc -l # 统计乱序包数量 tshark -r trace.pcap -Y "tcp.analysis.out_of_order" 2>/dev/null | wc -l

想快速看某个连接的时间线，把关键字段提出来排成表：

tshark -r trace.pcap -Y "tcp.port == 443" \ -T fields \ -e frame.time_relative \ -e ip.src -e tcp.srcport \ -e ip.dst -e tcp.dstport \ -e tcp.flags.str -e tcp.len \ -E header=y -E separator=, > /tmp/flow.csv

导出的 CSV 直接丢进表格工具做透视，比在几百兆的pcap里肉眼翻要快得多。这套"命令行提取字段 → 表格分析"的路子，是我处理大文件时的标准打法。

如果流量是加密的，你拿不到应用层内容，但元数据依然能说明很多问题：握手阶段的 SNI 字段能告诉你访问的是哪个域名，证书有效期能告诉你服务端配置有没有过期风险，包长分布和时序能反映是否存在重传密集或者响应被拆成小包。很多时候问题不在内容而在时序，加密反而无所谓。

5. 抓包丢包、时间不准、文件过大：三个高频坑的排查

5.1 丢包怎么判断：先看内核计数，再定位原因

抓包丢包是最隐蔽的问题，因为丢掉的包不会出现在文件里，你会以为"这个包根本没发出来"，从而得出完全错误的结论。

判断方法很直接：tcpdump在正常退出时会打印一行统计，形如N packets captured、M packets received by filter、K packets dropped by kernel。这三个数字的关系是：内核收到的（M）中有一部分因为缓冲区满被丢弃（K），最终成功处理并写出的（N）通常等于 M 减去 K 和其他过滤损耗。只要K不为零，就必须警惕。

看到一个真实的数字感受一下：一次抓包结束显示"500000 packets captured, 512300 packets received by filter, 12300 packets dropped by kernel"。丢包率约 2.4%。如果一个 TCP 会话恰好丢在了关键的重传时刻，你的分析结论可能完全反过来。

丢包的常见原因和对应处置，我整理成表：

提示：如果无论如何都丢，而你又必须抓到每一帧，那就该换技术路子了——用交换机镜像口配合独立抓包设备，让抓包这件事彻底离开业务机。在业务机上死磕丢包率，性价比很低。

5.2 时间戳不准：分布式排障里最容易被冤枉的环节

跨机器分析时，时间戳对不上会带来非常离谱的结论。比如 A 机器日志显示 10:00:00.100 发出请求，B 机器抓包显示 10:00:00.050 才收到请求，你会以为时钟倒流了？其实只是两台机器的时钟差了 100 毫秒左右。

处理这个问题的顺序是：先确认同步服务状态，再看偏差幅度，最后决定要不要修正时间戳再做分析。

timedatectl status chronyc tracking # 或者 ntpq -p，取决于用的同步方案

chronyc tracking输出里的System time一项就是本机相对于参考源的偏差，单位是秒。偏差在毫秒级以内，跨机分析基本可以直接用原始时间戳；偏差到了几十毫秒以上，就必须做修正，或者在分析时明确记录这个偏移量。

另一个常见坑是时区。抓包文件的时间戳默认是 UTC，而你的应用日志大概率是本地时间。用-tttt显示出来的时间是本地时间，但用工具解析pcap时拿到的往往是 UTC。我曾经在这个问题上绕了半小时，以为请求延迟了八小时，其实是时区换算没对齐。稳妥做法是所有分析环节统一用 UTC，只在最后呈现给业务方时转本地时间。

5.3 文件过大：从抓的时候就该想好怎么分析

抓一个几 GB 的文件很容易，分析它才是折磨。控制文件体积的手段有三层，按优先级排：

第一层是过滤器，这是效果最好的，前面已经详细说过。把无关流量挡在内核外面，文件能小一到两个数量级。

第二层是快照长度。如果只关心连接行为和时序，不关心应用层内容，-s 128就够覆盖以太网头、IP 头、TCP 头和一部分选项。这样单个包最多存 128 字节，对比 1500 字节的完整包，文件体积能压到十分之一以下。但要注意，snaplen太小会导致 TCP 选项被截断，某些分析功能会失效，实践中 96 到 128 是常见的平衡点。

第三层是边抓边切分和分析。不要指望抓完之后一次性加载，用editcap或者tshark按时间片或连接切分：

# 按每 100 万包切分 editcap -c 1000000 big.pcap /tmp/split.pcap # 只提取某个 IP 相关的包 tshark -r big.pcap -Y "ip.addr == 10.0.0.8" -w /tmp/filtered.pcap

预处理之后再分析，内存占用和等待时间都会舒服很多。我在处理一个 12GB 的抓包文件时，先按主机提取出目标的 300MB，再用图形工具打开，从"打不开"变成"秒开"。

6. 常见问题速查表与实操心得

这一节把前面散落的问题集中成速查表，方便动手时直接对照。

关于实操心得，有几条是我踩过坑之后才真正记住的。

第一条：抓包文件是敏感数据，比你想的更敏感。即使流量是加密的，元数据里也包含内网拓扑、服务地址、访问频率这些信息，未加密的协议更是直接把凭据和业务数据明晃晃写在里面。抓下来的文件要有明确的保留期限，排查完之后该删就删，需要长期留存的做脱敏处理。共享给别人之前，先用editcap裁剪掉无关会话，别整个文件甩过去。

第二条：不要在问题发生之后才开始抓。偶发问题的特点就是抓不住。真正有效的做法是在关键节点上常驻低成本的环形缓冲抓包，平时默默滚动，出问题时把时间窗口内的文件捞出来回溯。这个方案的成本是一个进程加 2GB 磁盘，收益是从"复现不了"变成"随时可查"。

第三条：先用统计数据形成假设，再针对性看包。新手容易一上来就在几千个包里从头翻，翻到眼睛发花还没结论。正确的顺序是先看会话统计和重传统计，判断问题出在哪个连接、哪个方向，然后过滤出那个连接看时间线。工具是用来验证假设的，不是用来帮你产生假设的。

第四条：把常用的抓包和分析命令存成脚本。我给团队维护过一个小工具集，把按主机提取、统计重传、导出关键字段这几步封装成带参数的命令。出问题时一条命令就能拿到初步画像，不用每次重新想参数怎么拼。这种投入一次、复用多年的东西，收益比想象中高。

第五条：记录抓包的环境信息。光有一个pcap文件，过两周之后你根本想不起来是在哪台机器、哪个网卡、什么时间段抓的。我习惯在同目录下放一个同名的说明文件，记录主机名、网卡、过滤器、开始时间和当时的业务现象。这个习惯帮我省过不止一次返工。

最后说一个容易被忽略的细节：抓包时顺手看一眼系统的软中断分布。用mpstat -P ALL 1观察，如果某一个 CPU 核的%soft明显高于其他核，说明网卡中断集中在那一个核上，抓包会放大这个问题。把中断亲和性分散开，往往能同时改善业务延迟和抓包丢包率，一举两得。这个操作的成本很低，但收益经常超出预期，尤其是在虚拟化环境里。