-s 在做什么
-s 设置每个报文最多抓取多少字节，也就是快照长度。抓完整报文写 -s 0；只关心头部、想节省空间时可以给一个较小的值。这个选项直接决定事后能分析到什么程度：被截断的报文里没有完整的应用层载荷，TLS 握手内容、HTTP 请求体都会缺失，而且无法恢复。各版本默认值不一致，排查应用层问题时显式写 -s 0 是最省心的做法。
基本信息
| 语法 | tcpdump -s <字节数>，-s 0 表示不截断 |
|---|---|
| 默认值 | 各版本不同，不能想当然认为默认就是完整 |
| 影响面 | 只影响写入文件的字节数，不影响过滤是否命中 |
| 代价 | 抓全量会显著放大文件体积与磁盘写入量 |
| 推荐 | 应用层排查一律 -s 0 |
典型使用场景
- 排查应用层内容问题：必须抓完整载荷，否则关键字段缺失
- 高流量口长时间抓包：用较小的快照长度换取更长的抓包时间
- 只看连接与握手行为：头部信息足够，截断能省大量空间
- 分析 TLS 握手：截断会让证书与扩展字段不完整，需要完整快照
- 估算磁盘占用：按包数与平均长度推算，决定是否加过滤条件
常用示例
常用示例
tcpdump -i any -s 0 -w /tmp/full.pcap port 3306 # 完整载荷，排查应用层
tcpdump -i eth0 -s 0 -nn -A 'tcp port 80' # 完整载荷并直接看文本
tcpdump -i eth0 -s 96 -nn 'tcp[tcpflags] & tcp-syn != 0' # 只看握手头部
tcpdump -i eth0 -s 128 -w /tmp/small.pcap port 443 # 折中：抓头部省空间
capinfos /tmp/full.pcap # 核对是否出现截断标记快照长度参考
| 取值 | 覆盖范围 | 适用判断 |
|---|---|---|
| 0 | 完整报文，不截断 | 应用层排查、TLS 握手分析、抓 HTTP 内容 |
| 64 到 96 | 以太网头、IP 头与 TCP 基本头 | 只看连接与标志位，快速统计 |
| 128 左右 | 头部加部分 TCP 选项 | 折中方案，可以省空间但仍能看握手细节 |
| 几百字节 | 部分载荷 | 不确定时不要选这种中间值，容易被截断误导 |
| 默认值 | 因版本而异 | 生产排查不要依赖默认，明确写出取值 |
被截断的报文在分析工具里会显示长度受限提示，用户数据部分不可读。看到这类提示基本可以判断当时的快照长度设置偏小，需要重抓而不是猜测内容。
抓完整报文会让文件体积明显增大。在高流量接口上不加过滤条件全量抓取，几分钟就能写满磁盘，务必同时使用过滤条件、数量上限或环形分卷。
体积与截断核对
体积与截断核对
capinfos -c -s /tmp/full.pcap # 看包数与文件大小，估算平均长度
tshark -r /tmp/full.pcap -Y 'frame.cap_len < frame.len' | head # 快速找出被截断的报文
ls -lh /tmp/*.pcap # 对照实际占用与预留空间判读要点
- 怀疑应用层内容缺失时先确认是不是截断造成的，而不是先怀疑应用没有发送
- 同一批抓包文件里混用了不同快照长度，分析时要注意对比条件是否公平
- 排查 TLS 握手问题必须抓完整，截断后的证书字段无法用于判断
- 长时间抓包的分卷文件如果快照长度太小，事后想复核内容只能重抓