1. 抓到的包到底是什么从网卡到用户态的一次复印很多人第一次接触捕获数据包脑子里想的是我把网络上的东西录下来。真上手之后会发现两件事录下来的东西看不懂以及想录的东西没录到。这两个问题的根源都在同一个地方——你没搞清楚抓包这件事发生在协议栈的哪一层以及你拿到的那份数据到底是谁的视角。1.1 抓包发生在协议栈的哪一层网卡收到一个以太网帧正常的处理路径是网卡 DMA 写入内核内存驱动触发软中断内核协议栈逐层解析以太网头 - IP 头 - TCP/UDP 头 - 交给对应的 socket最后应用层 read 到数据。而抓包工具做的事情是在驱动把帧交给协议栈这个节点上额外复制一份给你。Linux 上这条路径叫 AF_PACKETBSD 和 macOS 上是 BPF 设备节点Windows 上则需要 Npcap 这类驱动配合。它们的共同点是拿到的是链路层视角的原始帧还没经过协议栈的任何加工。这意味着你看到的是网卡实际收到/发出的东西而不是应用层以为自己发出去的东西。这个区别非常关键。应用层调用一次send()发 10KB协议栈可能把它切成 8 个 TCP 段发出去反过来如果开了 TSO/GSO网卡分段卸载你在本机抓包甚至可能只看到一个巨大的伪段因为分段工作被推给了网卡硬件。所以在本机抓包看到的分段结构未必等于链路上真实传输的分段结构。这一点在排查性能问题时特别容易误导人。1.2 为什么你抓到的 TCP 段和应用层日志对不上我见过太多次这样的对话应用日志显示发送了请求 A抓包文件里却找不到对应的包。新手会怀疑抓包工具坏了其实八成是下面几个原因之一。第一个原因是抓包点不在同一条路径上。如果应用访问的是本机另一个进程流量走的是 loopbacklo你在物理网卡 eth0 上是抓不到的。Linux 上-i any可以同时覆盖所有接口但它用的是 cooked capture 模式链路层类型会变成 Linux cookedSLL你看不到真实的 MAC 地址和以太网类型字段某些依赖二层信息的分析会失效。第二个原因是流量被内核提前处理掉了。比如目标地址是本机拥有的 IP内核在协议栈里直接回环压根不会经过出口网卡你在出口抓不到。第三个原因是应用根本没发出去。连接卡在队列里、DNS 还没解析完、TLS 握手没完成——数据包压根没到网络层。提示抓包结果的空是有信息量的但前提是你得先确认抓包链路本身是通的。先跑一次不加过滤的抓包确认能看到任何流量再逐步收紧条件。1.3 抓包点选错再多分析工具也白搭交换网络里有一个很反直觉的事实把网卡设成混杂模式也看不到别人的流量。混杂模式只在共享介质上才有意义——老式的集线器、无线空口。在现代交换网络里交换机会根据 MAC 地址表把帧只转发到目标端口你的网卡就算愿意接收一切交换机也不会送过来。所以想看到两台其他主机之间的流量只有几条路交换机上配置端口镜像SPAN或者串接一个物理 TAP或者在虚拟化/云环境里用平台提供的流量镜像能力。容器和 Kubernetes 场景更简单一些——直接进到对应的 network namespace 里抓比如用nsenter -t pid -n tcpdump ...或者直接落到目标 Pod 的 veth 上。我个人的判断习惯是先问清楚这段流量必然经过哪个设备然后把抓包点放在那个设备上。放在流量不经过的地方后面做的所有分析都是白费。2. 工具怎么挑tcpdump、tshark、dumpcap 各自的舒适区工具本身没有绝对的高下只有场景匹配度。我这些年用下来形成了一套比较固定的选择逻辑这里摊开讲。2.1 服务器上的默认答案是 tcpdumptcpdump 的优势不在于功能最强而在于几乎所有的 Linux 发行版都预装了它或者一条包管理命令就能装上。你在生产服务器上做排障最忌讳的就是先装个工具——装工具本身可能触发变更流程也可能因为网络不通根本装不上。tcpdump 的另一个优势是它的过滤表达式几乎成了行业通用语言。你在任何一篇文章里看到host x.x.x.x and port 443拿去 tcpdump、tshark、dumpcap 甚至 Wireshark 的捕获过滤器里都能直接用Wireshark 的显示过滤器是另一套语法别混淆。我常用的基础命令形态是这样的tcpdump -i eth0 -nn -s 0 -w /tmp/cap.pcap host 10.0.3.21 and port 5432逐个说-i eth0指定接口不写的话 tcpdump 会自己挑一个看起来最像的接口在多网卡机器上很容易挑错-nn表示不解析主机名也不解析端口名避免 DNS 反查引入额外延迟也避免输出里出现一堆难读的域名-s 0表示抓完整包新版本默认就是 262144 字节老版本-s 0代表抓满 65535-w表示直接写文件而不是打印到屏幕。一定要用-w写文件再分析不要靠屏幕输出。屏幕输出是单向的、不可回看的、信息量被截断的出了问题你连原始数据都没有。2.2 为什么长期抓包我推荐 dumpcap 而不是 tcpdump如果只是抓几分钟临时看看tcpdump 完全够用。但一旦涉及挂在那里跑几小时等故障复现我更倾向 dumpcap。它是 Wireshark 的抓包引擎命令行独立性很强几个参数设计得比 tcpdump 更舒服dumpcap -i eth0 -f host 10.0.3.21 \ -b filesize:102400 -b files:50 \ -w /data/cap/rolling.pcapng-b filesize:102400表示单个文件到 100MB 就切下一个-b files:50表示最多保留 50 个文件超了就覆盖最老的。这套环形缓冲写完你手上永远有最近约 5GB 的数据不需要人工干预也不怕把磁盘写满。相比之下 tcpdump 要做同样的事得写-C 100 -W 50而且-C的单位是 100 万字节配合不同版本的行为差异参数含义容易记错。dumpcap 的-b语法可读性好得多。另外 dumpcap 默认就以非 root 身份运行的能力更完善安装时通常已经给二进制设置了相应 capability不用每次 sudo。2.3 各平台自带能力盘点不是所有环境都让你随便装东西有些平台自带的能力其实相当能打。平台自带/常用能力适用场景主要短板Linuxtcpdump、ss、ip生产排障首选无图形化协议解析弱Linux现代发行版pktmon部分、nftables 计数器快速计数不产出标准 pcapWindowspktmon内置Win10 1809无第三方软件时应急分析工具仍需 WiresharkWindowsnetsh trace系统级事件抓取输出格式转换麻烦macOStcpdump系统自带本机排障权限控制较严格容器/K8snsenter tcpdump定位 Pod 网络需要节点权限Windows 上的 pktmon 值得单独提一句。它内置、不需要装驱动、可以按组件过滤抓完之后用pktmon pcapng转成标准格式再丢给 Wireshark 分析。在没有条件安装第三方驱动的受管终端上这是唯一的出路。但它默认只抓包元数据--component和--type控制想抓完整负载需要显式指定我第一次用的时候抓了半天全是头白折腾一轮。3. BPF 过滤表达式抓得少才能抓得准抓包最大的敌人不是抓不到是抓太多。全量抓包在高流量链路上几分钟就能产生几个 GB 的文件分析的时候光加载就卡死真正有用的那几千个包淹没在噪声里。3.1 三类限定词组合出绝大多数过滤需求BPF 过滤表达式本质上是由三类限定词拼出来的类型限定词host、net、port、portrange方向限定词src、dst、src or dst默认、src and dst协议限定词ether、ip、ip6、arp、tcp、udp、icmp不写方向时默认是src or dst这就是为什么port 443会同时匹配进出两个方向的流量——很多人第一次用会以为只抓请求。要严格区分得写dst port 443或src port 443。组合用and、or、not括号可以改变优先级。注意在 shell 里括号需要转义或用引号包起来不然会被 shell 抢先解释掉报出莫名其妙的语法错误。3.2 我常用的几组过滤写法与它们解决的问题下面这些是我实际排障时反复用到的直接抄就行# 只抓某个客户端与某个服务之间的全部交互 tcpdump -i eth0 -nn host 10.0.3.21 and host 10.0.3.80 # 只抓 TCP 握手和挥手包快速判断连接是否建立 tcpdump -i eth0 -nn tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0 # 只抓 RST 包定位连接被谁掐断 tcpdump -i eth0 -nn tcp[tcpflags] tcp-rst ! 0 # 抓大包排查 MTU 相关问题 tcpdump -i eth0 -nn greater 1400 # 抓 ICMP看是否收到不可达或分片需要 tcpdump -i eth0 -nn icmp or icmp6 # 排除掉噪声协议只留业务流量 tcpdump -i eth0 -nn not port 22 and not arp and not udp port 123tcp[tcpflags]这套位运算写法值得单独说一句。它的含义是取 TCP 头里的 flags 字段和指定的标志位做与运算结果不为零。这样一行就能精确命中所有含 SYN、FIN 或 RST 的包比按端口过滤精准得多。我排查连接建不起来这类问题时第一步永远是先跑这条几秒钟就能看到握手到底走到哪一步。3.3 过滤写错的两种症状以及如何避免误判过滤写错会呈现两种截然不同的症状而它们很容易被误读。第一种是抓到 0 个包。这时候大多数人会得出流量没来的结论但如果其实是过滤表达式写错了呢两者在结果上完全一样但结论天差地别。我的做法是先用一个非常宽松的条件比如只写host 目标IP抓 10 秒确认有流量再逐步加限定词每加一次看包数变化。这样能立刻定位是哪个限定词把流量过滤没了。第二种是抓了一堆不该有的包。最典型的是漏了方向限制。比如想看某个服务收到多少请求写了port 8080结果响应流量也被抓进来统计出来的数字翻倍。还有一种隐蔽的坑在-i any上使用二层过滤词。因为any接口用的是 cooked 模式ether host xx:xx:xx:xx:xx:xx这类表达式可能完全失效或者报错。遇到这种情况换回具体接口名就好。注意过滤表达式里的端口和协议写在 BPF 里是在内核层就丢弃的效率远高于抓下来再在 Wireshark 里过滤。能用捕获过滤器解决的绝不要留到显示过滤器。4. 长期抓包与环形缓冲把守着屏幕变成事后翻档间歇性故障是抓包最有价值的应用场景也是最容易做砸的场景。故障一周出现一次你不可能守着屏幕等。必须让抓包在后台安静地跑出问题时能翻回去看。4.1 先算带宽再定文件大小定环形缓冲参数之前先估算流量规模。这个计算不难但跳过它的人特别多结果要么文件太小覆盖太快要么磁盘被写满。假设链路是 1Gbps平均利用率 20%那么平均吞吐是1Gbps × 20% 200Mbps200Mbps ÷ 8 25MB/s25MB/s × 3600s ≈ 90GB/小时这个数字很吓人但它说明一个道理不加过滤的全量长期抓包在生产链路上是不现实的。必须靠两个手段压下来一是收紧 BPF 过滤只留目标主机的目标端口通常能把量压到千分之一二是缩短快照长度。假设过滤后平均只有 2MB/s那么 100MB 一个文件大约能存 50 秒50 个文件能覆盖约 42 分钟的历史窗口。这个窗口对几分钟内复现的故障够用对每周一次的故障就不够了得考虑加大文件数或者把快照长度进一步压缩。4.2 一套可以长期跑的抓包命令模板nohup dumpcap -i eth0 \ -f host 10.0.3.21 and (port 80 or port 443) \ -s 128 \ -b filesize:204800 -b files:100 \ -w /data/cap/svc21.pcapng \ /data/cap/dumpcap.log 21 这里-s 128是个刻意的选择。128 字节只够覆盖以太网头、IP 头和 TCP 头偶尔能带上一点负载。对于判断连接是否建立、是否有重传、时序如何这类问题头部信息已经足够而它能把文件体积压到抓全包的几分之一甚至十几分之一。等确认需要看负载内容了再有针对性地开短时全量抓包。如果确实需要保留完整负载用于协议分析就别用-s限制改成加大磁盘预算、缩短保留窗口。4.3 权限降权与自动清理抓包进程默认以 root 跑这在长期运行的场景里是个隐患。两个改善方式一是给抓包二进制设置 capability避免整个进程提权sudo setcap cap_net_raw,cap_net_admineip /usr/bin/dumpcap二是用降权参数把写文件的操作交给普通用户tcpdump -i eth0 -Z nobody -w /data/cap/x.pcap-Z会让 tcpdump 在打开设备之后切换到指定用户这样即使抓包进程被利用攻击面也小得多。文件清理方面dumpcap 的-b files:N自带环形覆盖不需要额外写脚本。如果你用的是 tcpdump 的-G按时间切分记得配一个定时任务清理超期文件否则迟早写满磁盘。我见过最惨的一次是抓包文件把根分区写满导致机器上所有服务异常——抓包工具本身成了故障源这个幽默感实在不好笑。5. 丢包抓包这件事本身最容易被忽略的失效模式这是我最想强调的一节。抓包工具在高负载下会丢包而丢包是静默发生的——你手上的 pcap 文件看起来完整无缺实际上里面缺了关键的那几个包。基于一份有缺失的数据做分析得出的结论可能是完全反向的。5.1 内核丢包怎么判断tcpdump 在正常退出时会打印一行统计其中有一项是 N packets dropped by kernel。这个数字就是内核缓冲区满了之后丢弃的包数。只要它不是 0你手上的 pcap 就是不完整的。用kill信号终止时也会打印所以用SIGINT停止抓包比SIGKILL好——后者什么统计都不给你。还有个间接判断方法在 Wireshark 里看 TCP 流是否出现大段跳号的序列号或者看tcp.analysis.lost_segment标记。但这些只能提示异常不能确认是链路真丢包还是抓包工具丢包。所以养成看结束统计的习惯成本极低收益极高。5.2 缓冲、快照长度与过滤器的三角权衡缓解内核丢包有三个杠杆它们互相制约手段具体做法效果代价增大缓冲tcpdump-B 32768单位 KiB抗突发能力强内存占用上升缩短快照-s 96或-s 128单包处理量下降看不到负载收紧过滤精确 BPF 表达式从源头减少包量可能漏掉关联流量-B这个参数值得展开说。tcpdump 默认的捕获缓冲在新版本里是 2MB 左右这个量在万兆链路上撑不过几毫秒的突发。改成-B 3276832MB能显著改善代价是每个抓包进程多占 32MB 内存——对现代服务器来说完全可以接受。我一般建议在千兆以上链路抓包时起步就设 16MB 或 32MB。还有一个细节加-v或-vv打印到屏幕会显著增加丢包。因为格式化输出和终端 IO 是同步的、耗时的抓包主线程会被拖住。想要详细信息写文件然后在 Wireshark 里慢慢看。这是我认为新手最应该记住的一条。5.3 高负载场景下的取舍经验在流量特别大的链路上比如核心交换机镜像口单机抓包几乎必然丢包。这时候要接受现实别指望抓全改成抓准。我的做法是分两步第一步用极窄的过滤器单个源 IP 单个目的端口先抓一轮把量压下来第二步如果还是丢就只抓 TCP 头部的某个特征包比如只抓 SYN 和 RST。用tcp[tcpflags]那条表达式包量能下降两三个数量级这时候基本不会丢了。还有一种思路是把抓包点前移。与其在网关的镜像口上抓一整台机器的流量不如进到目标机器的 network namespace 里抓——那里只有这一台机器的流量过滤成本直接降到最低。6. 三个真实故障的抓包排查链路前面讲的都是准备工作和工具知识这一节讲怎么把 pcap 变成结论。我挑三个最有代表性的场景把排查链路完整走一遍。6.1 连接建不起来从 SYN 到 RST 的完整判读症状是应用报连接超时或连接被拒绝但网络看起来是通的能 ping 通。第一步抓握手包tcpdump -i any -nn -c 200 host 10.0.3.80 and tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0然后看结果会落进四种情况之一情况 A只有 SYN没有后续。说明请求发出去了但没回应。可能是对端没监听但这通常会回 RST不是静默丢弃也可能是中间有安全设备或防火墙静默丢弃。要扩大抓包范围把链路中间节点的抓包点也打开对比。情况 BSYN 之后立刻收到 RST。对端明确拒绝。如果 RST 来自目标 IP通常是对端端口没开如果 RST 来自其他 IP那说明中间有设备在拦截这时候要看 RST 的源 IP 和 TTL——TTL 值往往能反推出 RST 是走了多少跳过来的。情况 CSYN、SYN-ACK、ACK 都齐全但之后没有数据。那问题不在网络层在应用层。可能应用收到连接后卡在某个资源等待上。这时候要把抓包继续下去看是否有后续的应用数据交换。情况 DSYN 重传多次。看到同一个 SYN 反复出现间隔递增1s、2s、4s、8s说明对端完全无响应。结合路由追踪判断路径在哪一跳断了。这套判读我用了很多年基本能在五分钟内定位方向。6.2 时快时慢重传、乱序与 MTU 黑洞症状是应用响应时间波动大平均值还行但长尾很难看。这时候抓包要用显示过滤器配合tcp.analysis.retransmission这条显示过滤器能筛出所有重传包。如果重传集中在大包长度 1400 的那些重点怀疑 MTU 问题。MTU 黑洞是个经典且隐蔽的坑。表现是小包比如 TCP 握手、HTTP 头完全正常一旦开始传大数据就卡住。原因是路径中某一跳的 MTU 比两端协商的小而 ICMP 需要分片 消息被中间设备过滤掉了发送方永远不知道要减小包大小。抓包上的特征很好认先看到一个 DF 位置 1 的大包发出去然后重传几次然后应用层就开始用更小的包重试。如果你能同时抓到 ICMP会看到 type 3 code 4 的报文——看到了就基本确认。处理方式要么是调小本机 MTU 做验证要么是让中间设备放行必要的 ICMP。在 overlay 隧道场景下这个问题的出现概率极高因为隧道封装本身会吃掉几十字节的头部空间路径 MTU 不知不觉就变小了。乱序则不同它的表现是包都在只是顺序颠倒了。如果重传和乱序同时大量出现先怀疑链路质量或负载均衡的多路径哈希问题而不是应用代码。6.3 首屏慢DNS 与 TLS 握手的时间线拆解前端反馈页面首次加载慢后端接口本身很快。这种问题的答案几乎全在时序里。抓包思路是先用宽松条件抓一次完整加载过程然后按时间轴拆解tcpdump -i any -nn -w /tmp/page.pcap host 10.0.3.80然后在 Wireshark 里打开按下面四段切第一段DNS 查询与响应。看查询发出到响应返回的间隔。如果间隔在 5 秒左右且反复出现那大概率是 DNS 超时重试——第一次查询就没回应客户端等超时后才用第二个 DNS 服务器。这种问题在抓包上非常显眼同名的 A 记录查询会出现两次第一次没有任何响应。第二段TCP 握手。正常情况下应该在一个 RTT 内完成。如果 SYN 到 SYN-ACK 之间隔了几百毫秒而不是几毫秒说明有额外的网络延迟或者握手被中间设备延迟处理。第三段TLS 握手。ClientHello 到 ServerHello 的往返、证书传输、密钥交换每个环节都占时间。证书链特别长的时候比如中间 CA 证书没做省略证书传输可能占掉几个 RTT。这部分耗时在包数量上体现得很明显——看 ClientHello 之后有多少个来自服务端的包。第四段首字节时间。TLS 握手完成后客户端发出第一个应用请求到服务端返回第一个数据包之间的间隔。这个才是真正的后端处理时间。前面的三段都是连接建立开销。拆完之后你会得到一个清爽的结论慢在哪一段就优化哪一段。DNS 慢就上缓存或者换解析路径TLS 慢就考虑会话复用握手慢就看网络路径。没有拆解所有优化都是猜。7. 抓下来之后把 pcap 变成结论的四个动作拿到 pcap 文件只是开始真正的功夫在分析。我有一套自己固定用的动作顺序能大幅缩短从打开文件到说出结论的时间。7.1 时间线优先先看时序再看内容新手拿到 pcap 的第一个动作通常是看里面的内容是什么然后一头扎进协议细节。我的顺序刚好相反先建立时间线再看内容。具体做法是在 Wireshark 里打开Statistics - Conversations看有哪几对通信、各自的包数和字节数、持续时间。这一步能立刻排除掉大量无关流量锁定出问题的那一对。然后打开Statistics - Flow Graph让 Wireshark 把交互画成时序图。这个视图的价值在于它把谁在什么时候说了什么压缩成了一张可以一眼看完的图。连接建立、请求响应、异常中断全部一目了然。我遇到复杂交互时八成的结论在看完这张图之后就出来了。7.2 专家信息与统计视图的用法Analyze - Expert Information是另一个被严重低估的功能。它会把 Wireshark 在解析过程中发现的所有异常按严重程度分级列出错误、警告、注意、聊天。重传、乱序、连接重置、零窗口全部归类好点进去直接跳到对应的包。这相当于有个经验丰富的人帮你做了第一轮筛选。我通常先看错误和警告两级如果里面有内容问题方向基本就定了如果全空说明网络层大概率没问题该往上找应用层。Statistics - TCP Stream Graphs - Time Sequence (tcptrace)也值得一用。它把 TCP 序列号和时间的对应关系画成曲线重传会让曲线出现平台丢包会让曲线出现断层窗口限制会让曲线斜率变缓。这三种形态看熟了看一眼就知道链路质量如何。7.3 不要把 pcap 当成一次性文件我踩过的坑里有一个是抓完分析完就删。后来遇到一个反复出现的故障第二次复现时想对比上一次的数据发现文件早就没了。后来我改成每个 pcap 文件按日期-问题描述-抓包点命名保留在固定的目录里至少留到问题彻底关闭。对于一个已经定位并修复的问题那份 pcap 就是最好的回归验证材料——修复之后重新抓一份对比两者的差异比看任何日志都有说服力。文件大小方面一个只抓 TCP 头部的 pcap10 万个包也就十几 MB保留成本极低。真的不用心疼磁盘。8. 合规与数据边界pcap 文件里的东西比你想的多这一节我想认真讲因为它在技术文章里经常被跳过但实际工作中最容易出事。8.1 明文协议会把什么暴露出来捕获数据包意味着你把链路上的原始字节复制了一份。如果业务里有任何一个环节用了明文协议那这些内容就在你的 pcap 里躺着HTTP 请求里的表单字段、Basic 认证头里的凭据、数据库查询语句里的业务数据、内网 API 的完整响应体、邮件协议里的正文。即使业务主体走的是加密传输元数据依然丰富谁在什么时间访问了哪个服务、通信频率、数据量大小、客户端和服务端的对应关系。这些信息单独看没什么聚合起来就是一份相当详细的业务行为图谱。我见过有人把生产环境的全量 pcap 随手拷到个人设备上分析也见过把 pcap 挂在共享目录里方便同事下载。这些做法在技术上都方便但都越过了必要边界。8.2 授权、留存与脱敏的实操做法我的做法是三条准则抓包前有明确目的和范围。不写抓一下看看而是写清楚排查 X 服务在 Y 时间段的连接超时问题抓包点为 Z过滤条件为 W。范围越窄风险越小。抓包文件在受控环境内流转。存在专用的分析目录里访问权限收紧不通过聊天工具传输不放个人设备。分析完成后按约定时间清理。需要长期保留时做脱敏。如果确实要保留业务数据用于回归验证可以考虑只保留头部抓包时用-s 128或者用工具把负载部分裁剪掉。对于必须保留完整负载的场景至少做到加密存储和访问审计。还有一点容易被忽略抓包这个动作本身要被记录。在生产环境执行抓包操作时在变更记录里留一笔说明是谁、什么时候、抓了哪个范围、为什么抓。这既是对自己负责也让团队知道这份数据的存在和归属。我个人在实际操作中最大的体会是捕获数据包这个技能的难点从来不在工具本身。tcpdump 的参数就那么几十个一个下午就能背熟BPF 表达式的语法规则也很简单。真正拉开差距的是三件事知道该在哪里抓抓包点选择、知道该抓什么过滤条件设计、知道抓完之后怎么问对问题分析路径。我早期最常犯的错误是拿着全量抓包文件在 Wireshark 里乱翻翻半天翻不出结论。后来养成习惯每次抓包之前先在纸上写下我在验证什么假设——比如我怀疑是服务端没响应 SYN那就只需要抓握手包。带着假设去抓几分钟的事不带假设去翻可能耗掉一整天。另外再分享一个小技巧遇到时有时无的故障与其盯着抓包文件反复翻不如在后台挂一个带环形缓冲的抓包进程同时把故障复现的时间点记在日志里。等故障真的复现了直接按时间窗口去翻环形缓冲里对应的那几个文件。这个组合我用了很多次比临时抓包的命中率高得多——因为你不需要在故障发生的那一刻恰好守在电脑前。