1. 抓包这件事到底解决什么问题捕获数据包说白了就是把网卡上流过的那一串串二进制字节原封不动地记录下来再交给工具去翻译成人能看懂的东西。我做了这么多年网络相关的活真正让我意识到抓包价值的不是某次高深的技术攻关而是一个特别琐碎的场景一个内部服务偶尔超时日志里干干净净什么都没写监控面板上一切正常但用户就是偶尔要等三秒。这种问题翻代码翻不出来看指标也看不出来最后是抓了一次包才在 TCP 层看到对方 SYN 发出去之后的重传规律不对定位到中间一台设备的会话表被打满了。这就是抓包的核心意义它给你的是未经任何应用层加工的一手事实。日志是程序想让你看到的东西监控是指标体系定义好的东西只有抓包拿到的是链路本身真实发生过的通信。这两者之间的差别在排查疑难问题时是决定性的。1.1 三类最典型的适用场景第一类是本地调试与联调。两个服务对接明明参数看着一样对面就是报错这时候抓一次包看看请求体的字段名大小写、编码格式、Content-Type 对不对问题往往几分钟就明朗。我见过太多我传的是 JSON结果实际发出去是 form-urlencoded 的情况。第二类是性能与延迟定位。一个接口在业务日志里显示耗时 200ms但用户体感是两秒中间那一秒八去哪儿了抓包能看到 DNS 解析耗时、TCP 三次握手耗时、TLS 握手往返次数、请求发出到首个响应字节的间隔TTFB把这些阶段拆开哪一段慢一目了然。第三类是协议学习与安全自查。想搞清楚 HTTP/2 的多路复用到底怎么在一个连接里跑并发流或者想确认自己服务返回的响应头有没有把敏感信息暴露出去抓包是最直接的方式。这属于对自己系统做体检是合规且必要的技术手段。1.2 抓包的边界在哪里有件事得先说清楚抓包只能解决通信层面的问题解决不了逻辑层面的问题。如果 bug 出在业务代码的算法里抓包抓一万次也看不出来因为报文本身是对的——只是它承载的业务数据算错了。我早期就犯过这个错一个金额计算偏差的问题我盯着抓包看了两个小时报文里传的数值确实就是那个错误值说明问题出在发出去之前白折腾。另一个边界是加密流量。现在绝大多数生产流量走 TLS抓到的只是密文。你能看到的只有握手过程、证书信息、包长、时序、SNI 域名看不到具体请求内容。想看到明文前提是你拥有对应会话的密钥材料并且是在你自己的系统上操作。这个前提很重要越界的抓包不叫排查问题性质完全不同。所以判断要不要抓包我的习惯是先问自己一句这个问题是数据没按预期传还是数据按预期传了但处理错了前者抓包后者去加日志、去看数据流本身。2. 抓包工具选型桌面端与命令行端的取舍工具这块没有绝对的最优解只有场景匹配。我自己的组合是桌面分析用 Wireshark服务器现场用 tcpdump 加 tshark长期监控用轻量的抓包库自己写脚本。下面把这几个的实际差别摊开讲。2.1 桌面端图形化工具分析效率的天花板Wireshark 几乎是绕不开的它的强项不在抓而在看。抓包这件事本身门槛不高难的是从几万个包里快速找到那几十个有问题的。Wireshark 的显示过滤器、着色规则、跟随 TCP 流、协议分层展开这些功能在手工分析阶段能省下大量时间。它的典型工作流是先抓一个全量包存成文件然后用显示过滤器一层层收窄。比如tcp.port 8080 http只看 HTTP再http.response.code 400只看错误响应。这个先抓后筛的思路很重要因为现场往往只有一次复现机会抓的时候宁滥勿缺分析的时候再精准。注意把 Wireshark 直接装在跳板机或者生产服务器上长期跑是我非常不建议的做法。图形界面依赖一堆运行库资源占用不小而且很多服务器环境根本没有显示环境。2.2 命令行工具服务器现场的标配tcpdump 是服务器上真正干活的那把刀。它足够轻几乎所有 Linux 发行版都自带或者能一条命令装好不需要图形环境抓完把 pcap 文件拉到本地再分析就行。它的过滤器语法也就是 BPF 语法是通用标准学会一套Wireshark、tshark、很多抓包库都能用。我个人习惯是服务器上永远只用 tcpdump 抓绝不在服务器上分析。因为抓包分析是个反复试错的过程需要不断换过滤器、翻流、对比这些操作对 CPU 和内存都有开销放在生产机上不合适。正确姿势是抓一个时间窗口的包限制文件大小然后下载到本地用 Wireshark 慢慢看。tshark 是 Wireshark 的命令行版本可以理解为能在服务器上做初步分析的 tcpdump。它支持 Wireshark 的显示过滤器语法可以输出指定字段非常适合写自动化脚本。我做过一个持续抓包统计各个接口响应时间分布的小工具就是用 tshark 定时取样再聚合跑了很久很稳。2.3 工具能力对照工具运行环境核心优势明显短板我的使用场景Wireshark桌面可视化分析、协议解析全面不适合服务器长期运行离线深度分析tcpdump任意 Linux轻量、通用、稳定分析能力弱服务器现场抓取tshark服务器支持显示过滤器、可脚本化输出处理需要额外加工自动化统计与监控语言级抓包库应用进程能直接拿到解密后的应用数据需要写代码、改动服务应用层数据采集最后一行值得展开说。像 Python 的 scapy、Go 的 gopacket或者直接在各语言生态里的应用层采集方案它们能拿到进程内部发送和接收的数据绕开了网卡加密的问题。代价是要动代码、要考虑性能损耗。适合的场景是你确实需要长期观察应用层通信而且抓包这个动作本身是你自己系统的一部分。3. 抓包底层原理数据是怎么被截下来的用好一个工具的前提是理解它背后的机制不然遇到抓不到包就只能瞎猜。抓包这件事的原理不复杂但有几个关键点决定了你能抓到什么、抓不到什么。3.1 网卡混杂模式与数据包的可见范围正常情况下网卡只接收目标 MAC 地址是自己或者是广播/组播的帧其他帧直接丢掉。抓包工具要做的事是让网卡把所有经过它的帧都交给上层这个状态叫混杂模式Promiscuous Mode。在集线器时代开混杂模式真能看到同一网段所有机器的通信换成交换机之后交换机会按 MAC 表精确转发别人的流量根本不会到你网卡上混杂模式也就看不到邻居的包了。这一点解释了一个常见困惑为什么我在自己电脑上抓包看不到同一个 WiFi 下别人手机在传什么。答案是交换机或者无线 AP的隔离机制在起作用不是工具的问题。那为什么服务器上抓包能看到那么多连接因为服务器本身就是通信的一端或者它处在转发路径上。你能抓到的本质上只有经过你这台机器网卡的流量。想在网络中间某处抓那需要在该位置有投放抓包能力这就涉及镜像端口、流量分光这些网络设备层面的配置了属于另一个话题。3.2 BPF 过滤器抓得准还省资源抓包有个很现实的矛盾你要抓得足够全才不会漏掉关键包但抓得太多CPU、磁盘、内存都扛不住而且把自己淹没在数据里。解决办法是在抓取阶段就用内核级过滤器把不要的包丢掉而不是先全抓再筛。BPFBerkeley Packet Filter就是干这个的。它的过滤器在内核里执行不符合条件的包在进入用户态之前就被丢弃了对 CPU 的额外开销很小。这就是为什么tcpdump那种带表达式的写法既高效又精准。过滤器的写法是分层的我按从粗到细的顺序列一下常见形式# 只抓指定主机的流量 tcpdump -i eth0 host 10.0.0.15 # 只抓指定网段 tcpdump -i eth0 net 10.0.0.0/24 # 只抓指定端口不区分方向 tcpdump -i eth0 port 8080 # 组合来源是 A目标是 B且端口是 8080 tcpdump -i eth0 src 10.0.0.15 and dst 10.0.0.20 and port 8080 # 排除某个端口比如排除噪音很大的监控探针 tcpdump -i eth0 port 8080 and not port 9100 # 只抓 SYN 包快速看连接建立情况 tcpdump -i eth0 tcp[tcpflags] tcp-syn ! 0最后那条用到了 TCP 标志位的位运算。tcp[13]是 TCP 头里标志位所在的那个字节tcp-syn是 0x02两者按位与不为零就说明这是个 SYN 包。这种写法在做连接建立分析时特别好用因为 SYN 包数量少、信息量大不用被海量数据包干扰。提示过滤器写错了会直接抓不到任何包而且不报错。第一次写复杂过滤器建议先用一个已知有流量的场景验证一下确认能抓到了再上生产。3.3 抓包文件的体积估算与落盘策略抓包文件大到把磁盘撑爆这件事我踩过。估算一下一个满速千兆链路的全量抓包理论上每秒能产生上百 MB 的数据几分钟就能写满几十 GB。即便你的业务流量没那么大一个高并发服务如果抓全量包一小时的量也可能到几十 GB。控制体积有三招第一招是用过滤器减少抓取范围前面说的 BPF 就是干这个的能砍掉七八成的无关流量。第二招是限制单个文件大小并轮转。tcpdump 的-C参数指定单个文件多少 MB-W指定保留多少个文件写满一轮就覆盖最早的。这样磁盘占用是有上限的不会失控# 每个文件 100MB最多保留 20 个约 2GB 上限文件名带序号 tcpdump -i eth0 -C 100 -W 20 -w /tmp/capture.pcap port 8080注意-C和-w配合时tcpdump 会自动在文件名后面加序号capture.pcap会变成capture.pcap0、capture.pcap1这样不要被文件名对不上搞困惑。第三招是只抓包头。很多排查场景根本不需要完整的 payload只要看五元组、标志位、时序就够了。-s参数指定抓取的字节数-s 96大概能覆盖 TCP/IP 头加一点内容tcpdump -i eth0 -s 96 -w /tmp/headers.pcap包头抓取的体积能降到全量的十分之一甚至更低长期挂着的监控场景很适合这么干。当然代价是看不到应用层内容得根据目的取舍。4. 完整实操从零抓到一个能分析的包前面讲的是原理和选型这一节把它串成一条能直接照做的链路。我用一个真实遇到过的问题当例子某服务调用下游接口偶尔返回超时需要抓包确认是网络层重传还是下游处理慢。4.1 环境准备与权限配置先说权限。抓包需要访问网卡原始数据的能力Linux 下普通用户没有这个权限。最省事的做法是用 root但我不建议因为抓包命令一旦带上高权限误操作的影响面就大了。更稳的做法是给 tcpdump 二进制加CAP_NET_RAW和CAP_NET_ADMIN这两个能力然后普通用户就能执行sudo setcap cap_net_raw,cap_net_admineip $(which tcpdump)设完之后用getcap $(which tcpdump)验证一下能看到两个能力就说明配好了。这样运维和开发同学不用 sudo 也能抓出事的时候少一道申请流程很实用。接着确认网卡名。别想当然以为都是 eth0现在很多环境是 ens33、enp0s3 这种命名ip -br addr输出里找到承载业务流量的那块网卡记住它的名字。还有个坑是容器环境容器里的网卡是虚拟的看到的流量跟宿主机不一样要抓宿主机上的 veth 或者直接进宿主机的命名空间抓抓之前先确认自己在哪一层。4.2 过滤器编写实战与相关参数计算回到场景。已知下游服务地址是 10.0.0.20端口 8443本机是 10.0.0.15。最直接的过滤器是tcpdump -i eth0 -nn -s 0 host 10.0.0.20 and port 8443这里-nn是不做主机名和端口的反向解析避免每次抓包都去查 DNS 拖慢速度也能防止把 IP 显示成一堆看不懂的主机名。-s 0表示抓完整包不截断。如果想进一步聚焦只看跟连接建立和可能的异常相关的包可以加上标志位条件。但实际上我更倾向于全抓再分析因为超时问题的原因可能藏在任何地方事先过滤太严反而容易漏掉关键线索。再说说为什么选这个时间窗口。我们的目标是复现那个偶尔超时所以要抓足够长的时间。按经验偶发问题如果能通过压力工具在几分钟内触发抓 5 分钟就够如果频率很低就得靠轮转文件长时间挂着等复现之后再从轮转的包里回溯。这里补充一个实际的计算假设这个接口的 QPS 是 50平均每个请求和响应合计约 2KB那么一小时的数据量是50 × 2KB × 3600 ≈ 360MB。用-C 100 -W 10就是 1GB 的上限能覆盖好几个小时的轮转窗口对磁盘压力也可控。这种估算在动手之前花两分钟做一下能避免后面抓爆磁盘或者抓的时间不够两种尴尬。4.3 抓取、停止与文件落盘启动抓取的时候我习惯带上时间戳和文件名规律方便回溯sudo tcpdump -i eth0 -nn -s 0 -C 100 -W 10 \ -w /tmp/latency_$(date %Y%m%d_%H%M).pcap \ host 10.0.0.20 and port 8443命令跑起来之后tcpdump 会打印一行listening on eth0, link-type EN10MB看到这行说明抓取开始了。如果这行后面一直没有任何包数量增长大概率是过滤器写错了或者网卡选错了别等立刻停下检查。停止的方式是 CtrlC正常情况下会打印一句X packets captured这就是本次抓到的包总数。如果这个数字是 0同样是过滤器或者网卡的问题。抓完之后先确认文件存在且有大小再考虑下载。这里有个细节值得注意信号处理导致的文件不完整。在包量非常大的场景下如果存储设备反应慢或者抓取进程被强杀kill -9pcap 文件的结尾可能没写完导致文件损坏打不开。所以抓包进程尽量用 CtrlC 或者 SIGTERM 正常停止让它有机会把缓冲刷到磁盘。4.4 用 Wireshark 做初步定位文件下载到本地用 Wireshark 打开第一步不是急着翻包而是先看统计菜单里的Conversations会话和Expert Information专家信息。Expert Information 会把 Wireshark 识别出的异常分类列出来比如重传、重复 ACK、乱序、零窗口这些是网络层问题的信号灯。针对我们这个超时场景具体的分析路径是这样的。先在显示过滤器里输入tcp.port 8443 tcp.flags.reset 1看看有没有 RST 包。RST 是连接被对端或中间设备强制中断的标志如果有说明连接是被掐断的不是处理慢。如果没有 RST就找重传tcp.analysis.retransmission这个过滤器会标出所有被判定为重传的包。如果重传集中在某几个时间段而超时就发生在这些时间段那基本可以确定是网络层丢包导致的延迟而不是下游处理慢。接下来可以顺着重传包的 TCP Stream 号去看tcp.analysis.ack_rttACK 往返时间如果 RTT 突然飙高配合重传就是链路抖动的典型表现。我用这套路径解决过一个很隐蔽的问题下游服务商说他们处理很快我们这边显示超时。抓包一看重传全集中在特定时间段推测链路上有设备在特定时间做流量整形。把这个证据甩过去对方才承认是他们的某个环节有周期性限速。抓包最有价值的地方之一就是把我觉得变成数据证明沟通成本直接砍半。如果整个流里既没有 RST 也没有重传时序也很平稳那问题很可能在下游应用层。这时候排除网络因素把注意力转到对端的日志和指标上方向就清楚了。5. 常见问题与排查技巧实录抓包这事儿工具会用不代表能抓到有用的东西。下面这些坑都是我在实际工作里反复遇到的整理出来能省不少时间。5.1 抓不到包四种常见原因速查现象可能原因排查方法完全没包网卡名写错ip -br addr确认容器里注意命名空间完全没包过滤器写错先去掉过滤器抓全量确认有流量再逐步加条件有包但不是目标流量抓错了网络层确认流量走的是物理网卡还是虚拟网卡/隧道有包但看不到内容流量被加密只能看握手和元信息这属于正常现象第一行的坑我踩得最多尤其是容器和虚拟化环境。一个 Pod 里抓包看到的网卡是 eth0但那是容器命名空间里的宿主机上对应的是一个 veth 对名字是一串随机字符。在错误的命名空间里抓就是抓了个寂寞。过滤器写错的坑也值得说。前面提过过滤器写错 tcpdump 通常不报错只是安静地抓不到东西。判断方法是看包数量计数有没有增长别看日志。养成先无过滤器验证有流量再加条件的习惯能规避这个问题。5.2 丢包、时间戳异常与性能影响tcpdump 在高流量下会报告packets dropped by kernel这是内核缓冲区没来得及交给用户态导致的丢包。这个数字很重要如果丢包率很高说明你抓到的数据是不完整的基于不完整数据做判断可能被误导。解决办法是增加内核抓包缓冲区大小tcpdump 的-B参数可以指定单位是 KB# 缓冲设成 64MB适合高流量场景 tcpdump -i eth0 -B 65536 -w /tmp/high.pcap注意这里的单位在一些版本里是 1KB所以要写成 65536 才是 64MB具体数值随版本有差异调大之后观察 dropped 计数有没有下降来验证。时间戳异常是另一个隐蔽的坑。抓包依赖系统时钟如果服务器的时间同步出问题了pcap 里的时间戳会漂移做时序分析时结论就错了。抓包之前对一下时间用date和 NTP 状态确认这已经成了我的固定动作。还有一个容易被忽视的点抓包本身对目标服务有性能影响。网卡把数据复制一份给抓包进程这部分拷贝是要消耗 CPU 的。流量越大影响越明显所以生产上长时间抓包要评估影响尽量用过滤器减少数据量别在高峰期抓全量。5.3 加密流量到底能看出什么这一节得说清楚边界。TLS 加密之后你抓到的 payload 确实是密文但握手阶段的信息是明文的这里面的信息量比你想象的大。证书里的 SAN 字段能告诉你访问的目标域名SNI 扩展里也有域名信息。握手往返次数和耗时能反映 TLS 版本协商、证书链验证的开销。握手用的密码套件能看出双方协商的水平如果还在用很老的套件这是个安全自查的信号。包的长度和时序分布某种程度上能做业务特征的侧面推断比如请求密度和响应大小。至于具体请求体没有密钥材料是看不到的。在自有系统的合规前提下可以通过配置密钥日志的方式来获取会话密钥进而在抓包工具里解密。但这件事的适用面有限且必须严格在自有环境做更多时候我们依赖应用层日志、分布式追踪和指标来观察请求内容抓包主要负责网络层这一段。我个人的经验是别把抓包当成万能钥匙。它擅长的是连接、重传、时序、握手这些网络层问题以及在明文的联调环境里看应用数据。加密后的业务内容观测交给日志和追踪链路更合适。6. 我在长期使用中沉淀的几条习惯最后分享几个用了很多年之后固定下来的做法都是那种文档里不会写但真省事的。第一条抓包永远先想清楚要带什么过滤器、抓多久、文件多大三个参数都在脑子里过一遍再动手。无脑tcpdump -i any -w all.pcap是不负责任的。这个习惯帮我避免过好几次把磁盘抓满的事故。第二条文件名带上时间、问题关键词和主机标识。我见过太多/tmp/1.pcap、/tmp/test.pcap这种过两天自己都不知道哪个是哪个。/tmp/latency_10.0.0.15_20240612_1430.pcap这样的名字回溯的时候救过命。第三条抓完先看统计再看详情。会话统计、专家信息、包计数这三样能在最短时间内告诉你这次抓的东西有没有用、值不值得深挖。很多人上来就翻具体的包翻半小时才发现这一批里根本没有目标流量很浪费。第四条对比优于单点。一个问题如果只抓了出问题的时候往往看不出什么因为正常的时候是什么样你不知道。有条件的话抓一段正常期间和一段异常期间对比差异部分自然就浮出来了。这个思路在排查偶发问题上特别有效。抓包这门手艺门槛不高但要真正用得顺手靠的是对协议层的理解和大量的实操积累。工具换来换去底层逻辑不变让网卡把经过的字节交出来用过滤器控制范围用分析工具把字节翻译成故事。剩下的就是多抓、多看、多对比。
抓包从原理到实战：tcpdump、Wireshark 与 BPF 过滤器排障
1. 抓包这件事到底解决什么问题捕获数据包说白了就是把网卡上流过的那一串串二进制字节原封不动地记录下来再交给工具去翻译成人能看懂的东西。我做了这么多年网络相关的活真正让我意识到抓包价值的不是某次高深的技术攻关而是一个特别琐碎的场景一个内部服务偶尔超时日志里干干净净什么都没写监控面板上一切正常但用户就是偶尔要等三秒。这种问题翻代码翻不出来看指标也看不出来最后是抓了一次包才在 TCP 层看到对方 SYN 发出去之后的重传规律不对定位到中间一台设备的会话表被打满了。这就是抓包的核心意义它给你的是未经任何应用层加工的一手事实。日志是程序想让你看到的东西监控是指标体系定义好的东西只有抓包拿到的是链路本身真实发生过的通信。这两者之间的差别在排查疑难问题时是决定性的。1.1 三类最典型的适用场景第一类是本地调试与联调。两个服务对接明明参数看着一样对面就是报错这时候抓一次包看看请求体的字段名大小写、编码格式、Content-Type 对不对问题往往几分钟就明朗。我见过太多我传的是 JSON结果实际发出去是 form-urlencoded 的情况。第二类是性能与延迟定位。一个接口在业务日志里显示耗时 200ms但用户体感是两秒中间那一秒八去哪儿了抓包能看到 DNS 解析耗时、TCP 三次握手耗时、TLS 握手往返次数、请求发出到首个响应字节的间隔TTFB把这些阶段拆开哪一段慢一目了然。第三类是协议学习与安全自查。想搞清楚 HTTP/2 的多路复用到底怎么在一个连接里跑并发流或者想确认自己服务返回的响应头有没有把敏感信息暴露出去抓包是最直接的方式。这属于对自己系统做体检是合规且必要的技术手段。1.2 抓包的边界在哪里有件事得先说清楚抓包只能解决通信层面的问题解决不了逻辑层面的问题。如果 bug 出在业务代码的算法里抓包抓一万次也看不出来因为报文本身是对的——只是它承载的业务数据算错了。我早期就犯过这个错一个金额计算偏差的问题我盯着抓包看了两个小时报文里传的数值确实就是那个错误值说明问题出在发出去之前白折腾。另一个边界是加密流量。现在绝大多数生产流量走 TLS抓到的只是密文。你能看到的只有握手过程、证书信息、包长、时序、SNI 域名看不到具体请求内容。想看到明文前提是你拥有对应会话的密钥材料并且是在你自己的系统上操作。这个前提很重要越界的抓包不叫排查问题性质完全不同。所以判断要不要抓包我的习惯是先问自己一句这个问题是数据没按预期传还是数据按预期传了但处理错了前者抓包后者去加日志、去看数据流本身。2. 抓包工具选型桌面端与命令行端的取舍工具这块没有绝对的最优解只有场景匹配。我自己的组合是桌面分析用 Wireshark服务器现场用 tcpdump 加 tshark长期监控用轻量的抓包库自己写脚本。下面把这几个的实际差别摊开讲。2.1 桌面端图形化工具分析效率的天花板Wireshark 几乎是绕不开的它的强项不在抓而在看。抓包这件事本身门槛不高难的是从几万个包里快速找到那几十个有问题的。Wireshark 的显示过滤器、着色规则、跟随 TCP 流、协议分层展开这些功能在手工分析阶段能省下大量时间。它的典型工作流是先抓一个全量包存成文件然后用显示过滤器一层层收窄。比如tcp.port 8080 http只看 HTTP再http.response.code 400只看错误响应。这个先抓后筛的思路很重要因为现场往往只有一次复现机会抓的时候宁滥勿缺分析的时候再精准。注意把 Wireshark 直接装在跳板机或者生产服务器上长期跑是我非常不建议的做法。图形界面依赖一堆运行库资源占用不小而且很多服务器环境根本没有显示环境。2.2 命令行工具服务器现场的标配tcpdump 是服务器上真正干活的那把刀。它足够轻几乎所有 Linux 发行版都自带或者能一条命令装好不需要图形环境抓完把 pcap 文件拉到本地再分析就行。它的过滤器语法也就是 BPF 语法是通用标准学会一套Wireshark、tshark、很多抓包库都能用。我个人习惯是服务器上永远只用 tcpdump 抓绝不在服务器上分析。因为抓包分析是个反复试错的过程需要不断换过滤器、翻流、对比这些操作对 CPU 和内存都有开销放在生产机上不合适。正确姿势是抓一个时间窗口的包限制文件大小然后下载到本地用 Wireshark 慢慢看。tshark 是 Wireshark 的命令行版本可以理解为能在服务器上做初步分析的 tcpdump。它支持 Wireshark 的显示过滤器语法可以输出指定字段非常适合写自动化脚本。我做过一个持续抓包统计各个接口响应时间分布的小工具就是用 tshark 定时取样再聚合跑了很久很稳。2.3 工具能力对照工具运行环境核心优势明显短板我的使用场景Wireshark桌面可视化分析、协议解析全面不适合服务器长期运行离线深度分析tcpdump任意 Linux轻量、通用、稳定分析能力弱服务器现场抓取tshark服务器支持显示过滤器、可脚本化输出处理需要额外加工自动化统计与监控语言级抓包库应用进程能直接拿到解密后的应用数据需要写代码、改动服务应用层数据采集最后一行值得展开说。像 Python 的 scapy、Go 的 gopacket或者直接在各语言生态里的应用层采集方案它们能拿到进程内部发送和接收的数据绕开了网卡加密的问题。代价是要动代码、要考虑性能损耗。适合的场景是你确实需要长期观察应用层通信而且抓包这个动作本身是你自己系统的一部分。3. 抓包底层原理数据是怎么被截下来的用好一个工具的前提是理解它背后的机制不然遇到抓不到包就只能瞎猜。抓包这件事的原理不复杂但有几个关键点决定了你能抓到什么、抓不到什么。3.1 网卡混杂模式与数据包的可见范围正常情况下网卡只接收目标 MAC 地址是自己或者是广播/组播的帧其他帧直接丢掉。抓包工具要做的事是让网卡把所有经过它的帧都交给上层这个状态叫混杂模式Promiscuous Mode。在集线器时代开混杂模式真能看到同一网段所有机器的通信换成交换机之后交换机会按 MAC 表精确转发别人的流量根本不会到你网卡上混杂模式也就看不到邻居的包了。这一点解释了一个常见困惑为什么我在自己电脑上抓包看不到同一个 WiFi 下别人手机在传什么。答案是交换机或者无线 AP的隔离机制在起作用不是工具的问题。那为什么服务器上抓包能看到那么多连接因为服务器本身就是通信的一端或者它处在转发路径上。你能抓到的本质上只有经过你这台机器网卡的流量。想在网络中间某处抓那需要在该位置有投放抓包能力这就涉及镜像端口、流量分光这些网络设备层面的配置了属于另一个话题。3.2 BPF 过滤器抓得准还省资源抓包有个很现实的矛盾你要抓得足够全才不会漏掉关键包但抓得太多CPU、磁盘、内存都扛不住而且把自己淹没在数据里。解决办法是在抓取阶段就用内核级过滤器把不要的包丢掉而不是先全抓再筛。BPFBerkeley Packet Filter就是干这个的。它的过滤器在内核里执行不符合条件的包在进入用户态之前就被丢弃了对 CPU 的额外开销很小。这就是为什么tcpdump那种带表达式的写法既高效又精准。过滤器的写法是分层的我按从粗到细的顺序列一下常见形式# 只抓指定主机的流量 tcpdump -i eth0 host 10.0.0.15 # 只抓指定网段 tcpdump -i eth0 net 10.0.0.0/24 # 只抓指定端口不区分方向 tcpdump -i eth0 port 8080 # 组合来源是 A目标是 B且端口是 8080 tcpdump -i eth0 src 10.0.0.15 and dst 10.0.0.20 and port 8080 # 排除某个端口比如排除噪音很大的监控探针 tcpdump -i eth0 port 8080 and not port 9100 # 只抓 SYN 包快速看连接建立情况 tcpdump -i eth0 tcp[tcpflags] tcp-syn ! 0最后那条用到了 TCP 标志位的位运算。tcp[13]是 TCP 头里标志位所在的那个字节tcp-syn是 0x02两者按位与不为零就说明这是个 SYN 包。这种写法在做连接建立分析时特别好用因为 SYN 包数量少、信息量大不用被海量数据包干扰。提示过滤器写错了会直接抓不到任何包而且不报错。第一次写复杂过滤器建议先用一个已知有流量的场景验证一下确认能抓到了再上生产。3.3 抓包文件的体积估算与落盘策略抓包文件大到把磁盘撑爆这件事我踩过。估算一下一个满速千兆链路的全量抓包理论上每秒能产生上百 MB 的数据几分钟就能写满几十 GB。即便你的业务流量没那么大一个高并发服务如果抓全量包一小时的量也可能到几十 GB。控制体积有三招第一招是用过滤器减少抓取范围前面说的 BPF 就是干这个的能砍掉七八成的无关流量。第二招是限制单个文件大小并轮转。tcpdump 的-C参数指定单个文件多少 MB-W指定保留多少个文件写满一轮就覆盖最早的。这样磁盘占用是有上限的不会失控# 每个文件 100MB最多保留 20 个约 2GB 上限文件名带序号 tcpdump -i eth0 -C 100 -W 20 -w /tmp/capture.pcap port 8080注意-C和-w配合时tcpdump 会自动在文件名后面加序号capture.pcap会变成capture.pcap0、capture.pcap1这样不要被文件名对不上搞困惑。第三招是只抓包头。很多排查场景根本不需要完整的 payload只要看五元组、标志位、时序就够了。-s参数指定抓取的字节数-s 96大概能覆盖 TCP/IP 头加一点内容tcpdump -i eth0 -s 96 -w /tmp/headers.pcap包头抓取的体积能降到全量的十分之一甚至更低长期挂着的监控场景很适合这么干。当然代价是看不到应用层内容得根据目的取舍。4. 完整实操从零抓到一个能分析的包前面讲的是原理和选型这一节把它串成一条能直接照做的链路。我用一个真实遇到过的问题当例子某服务调用下游接口偶尔返回超时需要抓包确认是网络层重传还是下游处理慢。4.1 环境准备与权限配置先说权限。抓包需要访问网卡原始数据的能力Linux 下普通用户没有这个权限。最省事的做法是用 root但我不建议因为抓包命令一旦带上高权限误操作的影响面就大了。更稳的做法是给 tcpdump 二进制加CAP_NET_RAW和CAP_NET_ADMIN这两个能力然后普通用户就能执行sudo setcap cap_net_raw,cap_net_admineip $(which tcpdump)设完之后用getcap $(which tcpdump)验证一下能看到两个能力就说明配好了。这样运维和开发同学不用 sudo 也能抓出事的时候少一道申请流程很实用。接着确认网卡名。别想当然以为都是 eth0现在很多环境是 ens33、enp0s3 这种命名ip -br addr输出里找到承载业务流量的那块网卡记住它的名字。还有个坑是容器环境容器里的网卡是虚拟的看到的流量跟宿主机不一样要抓宿主机上的 veth 或者直接进宿主机的命名空间抓抓之前先确认自己在哪一层。4.2 过滤器编写实战与相关参数计算回到场景。已知下游服务地址是 10.0.0.20端口 8443本机是 10.0.0.15。最直接的过滤器是tcpdump -i eth0 -nn -s 0 host 10.0.0.20 and port 8443这里-nn是不做主机名和端口的反向解析避免每次抓包都去查 DNS 拖慢速度也能防止把 IP 显示成一堆看不懂的主机名。-s 0表示抓完整包不截断。如果想进一步聚焦只看跟连接建立和可能的异常相关的包可以加上标志位条件。但实际上我更倾向于全抓再分析因为超时问题的原因可能藏在任何地方事先过滤太严反而容易漏掉关键线索。再说说为什么选这个时间窗口。我们的目标是复现那个偶尔超时所以要抓足够长的时间。按经验偶发问题如果能通过压力工具在几分钟内触发抓 5 分钟就够如果频率很低就得靠轮转文件长时间挂着等复现之后再从轮转的包里回溯。这里补充一个实际的计算假设这个接口的 QPS 是 50平均每个请求和响应合计约 2KB那么一小时的数据量是50 × 2KB × 3600 ≈ 360MB。用-C 100 -W 10就是 1GB 的上限能覆盖好几个小时的轮转窗口对磁盘压力也可控。这种估算在动手之前花两分钟做一下能避免后面抓爆磁盘或者抓的时间不够两种尴尬。4.3 抓取、停止与文件落盘启动抓取的时候我习惯带上时间戳和文件名规律方便回溯sudo tcpdump -i eth0 -nn -s 0 -C 100 -W 10 \ -w /tmp/latency_$(date %Y%m%d_%H%M).pcap \ host 10.0.0.20 and port 8443命令跑起来之后tcpdump 会打印一行listening on eth0, link-type EN10MB看到这行说明抓取开始了。如果这行后面一直没有任何包数量增长大概率是过滤器写错了或者网卡选错了别等立刻停下检查。停止的方式是 CtrlC正常情况下会打印一句X packets captured这就是本次抓到的包总数。如果这个数字是 0同样是过滤器或者网卡的问题。抓完之后先确认文件存在且有大小再考虑下载。这里有个细节值得注意信号处理导致的文件不完整。在包量非常大的场景下如果存储设备反应慢或者抓取进程被强杀kill -9pcap 文件的结尾可能没写完导致文件损坏打不开。所以抓包进程尽量用 CtrlC 或者 SIGTERM 正常停止让它有机会把缓冲刷到磁盘。4.4 用 Wireshark 做初步定位文件下载到本地用 Wireshark 打开第一步不是急着翻包而是先看统计菜单里的Conversations会话和Expert Information专家信息。Expert Information 会把 Wireshark 识别出的异常分类列出来比如重传、重复 ACK、乱序、零窗口这些是网络层问题的信号灯。针对我们这个超时场景具体的分析路径是这样的。先在显示过滤器里输入tcp.port 8443 tcp.flags.reset 1看看有没有 RST 包。RST 是连接被对端或中间设备强制中断的标志如果有说明连接是被掐断的不是处理慢。如果没有 RST就找重传tcp.analysis.retransmission这个过滤器会标出所有被判定为重传的包。如果重传集中在某几个时间段而超时就发生在这些时间段那基本可以确定是网络层丢包导致的延迟而不是下游处理慢。接下来可以顺着重传包的 TCP Stream 号去看tcp.analysis.ack_rttACK 往返时间如果 RTT 突然飙高配合重传就是链路抖动的典型表现。我用这套路径解决过一个很隐蔽的问题下游服务商说他们处理很快我们这边显示超时。抓包一看重传全集中在特定时间段推测链路上有设备在特定时间做流量整形。把这个证据甩过去对方才承认是他们的某个环节有周期性限速。抓包最有价值的地方之一就是把我觉得变成数据证明沟通成本直接砍半。如果整个流里既没有 RST 也没有重传时序也很平稳那问题很可能在下游应用层。这时候排除网络因素把注意力转到对端的日志和指标上方向就清楚了。5. 常见问题与排查技巧实录抓包这事儿工具会用不代表能抓到有用的东西。下面这些坑都是我在实际工作里反复遇到的整理出来能省不少时间。5.1 抓不到包四种常见原因速查现象可能原因排查方法完全没包网卡名写错ip -br addr确认容器里注意命名空间完全没包过滤器写错先去掉过滤器抓全量确认有流量再逐步加条件有包但不是目标流量抓错了网络层确认流量走的是物理网卡还是虚拟网卡/隧道有包但看不到内容流量被加密只能看握手和元信息这属于正常现象第一行的坑我踩得最多尤其是容器和虚拟化环境。一个 Pod 里抓包看到的网卡是 eth0但那是容器命名空间里的宿主机上对应的是一个 veth 对名字是一串随机字符。在错误的命名空间里抓就是抓了个寂寞。过滤器写错的坑也值得说。前面提过过滤器写错 tcpdump 通常不报错只是安静地抓不到东西。判断方法是看包数量计数有没有增长别看日志。养成先无过滤器验证有流量再加条件的习惯能规避这个问题。5.2 丢包、时间戳异常与性能影响tcpdump 在高流量下会报告packets dropped by kernel这是内核缓冲区没来得及交给用户态导致的丢包。这个数字很重要如果丢包率很高说明你抓到的数据是不完整的基于不完整数据做判断可能被误导。解决办法是增加内核抓包缓冲区大小tcpdump 的-B参数可以指定单位是 KB# 缓冲设成 64MB适合高流量场景 tcpdump -i eth0 -B 65536 -w /tmp/high.pcap注意这里的单位在一些版本里是 1KB所以要写成 65536 才是 64MB具体数值随版本有差异调大之后观察 dropped 计数有没有下降来验证。时间戳异常是另一个隐蔽的坑。抓包依赖系统时钟如果服务器的时间同步出问题了pcap 里的时间戳会漂移做时序分析时结论就错了。抓包之前对一下时间用date和 NTP 状态确认这已经成了我的固定动作。还有一个容易被忽视的点抓包本身对目标服务有性能影响。网卡把数据复制一份给抓包进程这部分拷贝是要消耗 CPU 的。流量越大影响越明显所以生产上长时间抓包要评估影响尽量用过滤器减少数据量别在高峰期抓全量。5.3 加密流量到底能看出什么这一节得说清楚边界。TLS 加密之后你抓到的 payload 确实是密文但握手阶段的信息是明文的这里面的信息量比你想象的大。证书里的 SAN 字段能告诉你访问的目标域名SNI 扩展里也有域名信息。握手往返次数和耗时能反映 TLS 版本协商、证书链验证的开销。握手用的密码套件能看出双方协商的水平如果还在用很老的套件这是个安全自查的信号。包的长度和时序分布某种程度上能做业务特征的侧面推断比如请求密度和响应大小。至于具体请求体没有密钥材料是看不到的。在自有系统的合规前提下可以通过配置密钥日志的方式来获取会话密钥进而在抓包工具里解密。但这件事的适用面有限且必须严格在自有环境做更多时候我们依赖应用层日志、分布式追踪和指标来观察请求内容抓包主要负责网络层这一段。我个人的经验是别把抓包当成万能钥匙。它擅长的是连接、重传、时序、握手这些网络层问题以及在明文的联调环境里看应用数据。加密后的业务内容观测交给日志和追踪链路更合适。6. 我在长期使用中沉淀的几条习惯最后分享几个用了很多年之后固定下来的做法都是那种文档里不会写但真省事的。第一条抓包永远先想清楚要带什么过滤器、抓多久、文件多大三个参数都在脑子里过一遍再动手。无脑tcpdump -i any -w all.pcap是不负责任的。这个习惯帮我避免过好几次把磁盘抓满的事故。第二条文件名带上时间、问题关键词和主机标识。我见过太多/tmp/1.pcap、/tmp/test.pcap这种过两天自己都不知道哪个是哪个。/tmp/latency_10.0.0.15_20240612_1430.pcap这样的名字回溯的时候救过命。第三条抓完先看统计再看详情。会话统计、专家信息、包计数这三样能在最短时间内告诉你这次抓的东西有没有用、值不值得深挖。很多人上来就翻具体的包翻半小时才发现这一批里根本没有目标流量很浪费。第四条对比优于单点。一个问题如果只抓了出问题的时候往往看不出什么因为正常的时候是什么样你不知道。有条件的话抓一段正常期间和一段异常期间对比差异部分自然就浮出来了。这个思路在排查偶发问题上特别有效。抓包这门手艺门槛不高但要真正用得顺手靠的是对协议层的理解和大量的实操积累。工具换来换去底层逻辑不变让网卡把经过的字节交出来用过滤器控制范围用分析工具把字节翻译成故事。剩下的就是多抓、多看、多对比。
