Linux tcpdump 的 -C / -W / -G 滚动捕获与 Wireshark 离线分析结合

tcpdump滚动捕获必须用-c配合-w，单独-g会丢包；-c按大小轮转、-w限制文件数，确保i/o可控；-g与-c混用会导致轮转逻辑异常，二者应择一使用。

tcpdump 滚动捕获必须用 -C + -W 配合，单独 -G 会丢包

linux 下想让 tcpdump 自动轮转文件、避免单文件过大或内存耗尽，-G 看起来最直观（按秒切），但实际运行中常发现中间几秒的流量完全丢失。这是因为 -G 触发轮转时，tcpdump 需要关闭旧文件、打开新文件，期间内核接收缓冲区若满，包就直接被丢弃——它不暂停抓包，也不排队。

真正可靠的做法是用 -C（按大小轮转）配合 -W（限制总文件数），让写入始终在内存和磁盘 I/O 可控范围内进行：

• -C 100 表示每个文件最多 100MB（注意：单位是 MB，不是 KB 或字节）
• -W 5 表示最多保留 5 个循环文件（capture_00001.pcap → capture_00005.pcap，然后覆盖最早的）
• 加上 -w capture_%Y-%m-%d_%H:%M:%S.pcap 也能带时间戳，但仅作命名，不参与轮转逻辑——轮转动作只由 -C 和 -W 控制

wireshark 打不开 tcpdump -C 轮转出的多个 pcap 文件？检查文件是否完整截断

tcpdump 用 -C 切文件时，会在达到大小阈值的**下一个 packet 写入前**立即切换文件。这意味着最后一个文件大概率不包含完整的 TCP 会话（比如 TLS 握手断在中间），但 Wireshark 本身能处理这种“不完整 pcap”——只要文件头没损坏。

真正打不开的常见原因是：tcpdump 进程被 kill -9 或系统崩溃导致当前文件没写完文件尾（pcap 的 magic number 或 section header 损坏）。这时 Wireshark 报错类似 File appears to have been cut short 或直接拒绝加载。

• 用 file capture_00003.pcap 看输出是否含 pcap capture file —— 不是则文件已损坏
• 用 tcpdump -r capture_00003.pcap -c 1 快速验证能否读取第一条包；失败说明头部异常
• 生产环境建议加 -Z nobody 降低权限，避免因权限问题导致写入中断

为什么 -G 和 -C 不能混用？参数冲突会静默失效

tcpdump 文档里没明说，但源码中 -G 和 -C 共享同一套轮转状态机。一旦同时指定，-C 的大小判断优先级高于 -G 的时间判断——也就是说，即使设了 -G 60（每分钟切），只要还没到 -C 设的大小，就不会切；而一旦先触发 -C，-G 的计时器就重置，不再按固定间隔执行。

• 现象：你期望每分钟一个文件，结果可能连续 3 分钟都写进同一个文件，直到它涨到 100MB
• 更糟的是：如果 -C 值设得太小（如 -C 1），会频繁 open/close 文件，I/O 毛刺明显，甚至拖慢抓包速率
• 结论：需要定时切用 -G，需要控体积用 -C+-W，二者选一，别混

离线分析时，Wireshark 合并多个轮转 pcap 的正确方式

tcpdump 轮转出的 capture_00001.pcap、capture_00002.pcap… 是严格按时间顺序写的，但它们之间**没有跨文件的 TCP 重组上下文**。Wireshark 直接依次打开多个文件，不会自动把一个 http 请求的 request 和 response 拼到一起（尤其当它们落在不同文件里）。

• 不要用 “File → Merge” —— 它只是拼接数据包列表，不重建流状态，对深度协议分析（如 TLS 解密、HTTP2 stream tracking）基本无效
• 推荐做法：用 mergecap -w merged.pcap capture_*.pcap 合并为单个 pcap，再用 Wireshark 打开；mergecap 会重排时间戳并修复部分跨文件边界问题
• 如果原始抓包启用了 -s 0（全包抓取），合并后可正常做 TCP 重组；若用了 -s 68 等截断长度，合并也没法恢复被丢掉的 payload

滚动捕获真正难的不是命令怎么写，而是得提前想清楚：你要的是精确时间边界，还是可控文件体积；要不要跨文件分析；磁盘空间和 I/O 能不能扛住频繁 write/fsync。这些决定了 -C、-W、-G 里哪个参数该设、设多大。