捕获参数核心概念
说实话，刚开始调抓包参数那阵子，我也是一头雾水。明明数据包就在那里，可要么抓不全，要么抓来的文件大到打不开。后来我才明白，问题就出在缓冲区、捕获长度、过滤规则和切片模式这几个关键参数上。这堂课，我把这些年攒下来的经验一次性倒给你。
1. 缓冲区大小
缓冲区，说白了就是网卡或抓包工具临时存放数据包的「蓄水池」。水龙头一直开着（网络流量），蓄水池满了怎么办？要么溢出去（丢包），要么把水倒掉一部分（覆盖）。
我个人习惯，先看场景再定大小：
- 低速链路（如百兆局域网）：128 MB 绰绰有余，够存好几秒钟的流量
- 高速链路（如万兆数据中心）：建议至少 512 MB，有时候我直接给到 1 GB
- 长时间捕获（比如监控一整天）：缓冲区只是临时存储，核心还是靠磁盘写入速度，这时缓冲区设 256 MB 配合旋转文件策略更稳妥
我曾经在抓一个千兆端口峰值流量时，把缓冲区设成了 64 MB。结果每 3 秒就丢一次包，排查了整整一下午才发现是缓冲区太小。后来改成 512 MB，问题立刻消失。
| 链路速率 | 推荐缓冲区大小 | 备注 |
|---|---|---|
| 百兆 | 64 ~ 128 MB | 低并发场景可进一步减半 |
| 千兆 | 256 ~ 512 MB | 峰值流量建议 512 MB |
| 万兆 | 1 GB 以上 | 配合硬件卸载使用 |
2. 捕获长度
捕获长度也叫 snaplen（snapshot length），意思是每个包只抓开头多少个字节。你想想看，如果我只关心 TCP 握手，为什么要把整个 HTTP payload 都抓下来？
- 默认值通常是 65535 字节，但绝大多数情况下用不到。
- 做 协议合规性检查：每个包只抓 128 字节就够了，因为头部信息都在开头。
- 分析 应用层数据：比如 HTTP 请求正文，就得设成 1514（标准以太网 MTU）甚至更大。
我建议先跑一次默认值看看包的大小分布，再针对性地调整 snaplen。比如你发现 90% 的包长度不超过 400 字节，那就设成 512 字节，能省不少磁盘空间。
3. 过滤规则
过滤规则是抓包参数里最容易被低估的。很多人觉得「先全抓了再说」，结果文件几十 G，分析时卡到怀疑人生。
# 只抓某个主机的流量
tcpdump host 192.168.1.100
# 用 BPF 语法抓特定端口 + 非本地环回
tcpdump -i eth0 port 443 and not src net 10.0.0.0/8
# Wireshark 抓包过滤器示例
"ip.addr == 10.10.10.1 && tcp.port == 80"
记住一个原则：过滤在驱动层做，不要在应用层做。BPF 过滤器在网卡驱动里就把无关包扔掉了，CPU 占用率能降低 30%~60%。
嗯，这里要注意：过滤规则越复杂，驱动层处理也越慢。我碰到过一个极端情况——用了 8 层 BPF 逻辑嵌套，结果抓包开始就卡死了。后来精简成 3 层，一切流畅。
4. 切片模式
切片模式，简单说就是「抓多少、剩多少、存多少」。不同的工具对切片行为的叫法有点差异，但核心就两种：
| 切片模式 | 行为 | 典型场景 |
|---|---|---|
| 连续模式 | 缓冲区满了后，新数据覆盖最旧的数据 | 实时监控、滚动侦听 |
| 停止模式 | 缓冲区满了就停止抓包 | 定点调试、复现特定故障 |
| 环形模式 | 类似连续模式，但触发停止条件后可保留触发前后数据 | 触发式诊断、性能问题追溯 |
我通常这样做：调试已知问题时用「停止模式」，缓冲区设 64 MB，够捕获到出问题的瞬间数据。监控未知问题时用「环形模式」，配合触发条件（比如丢包率超过 0.1%），能保存触发前后各几秒的完整数据链。
有一次我在数据中心查间歇性丢包，用了连续模式抓了一上午，回头分析时发现关键事件早就被覆盖了。后来换成环形模式，设置触发条件为「TCP 重传率 > 5%」，当晚就抓到了元凶——一块旧网卡的驱动 BUG。
说白了，切片模式就是「你的捕获策略的最后一环」。缓冲区大小决定蓄水池的容量，捕获长度决定每个水桶的大小，过滤规则决定只放哪些水进来，而切片模式决定了水满了以后怎么办。这四个参数拧在一起，才能让抓包工具在你想要的时间点，拿到你想要的数据，还不把磁盘撑爆。