为什么满屏都是确认包
抓包里全是长度为 0 的确认包时，先别急着当成异常。请求-响应型的应用本身就确认密集：一次小请求换来一次小响应，每个数据段都要被确认。此外接收方还可能在确认延迟机制下凑够若干段才回一次确认，或者反过来对每个段都立即确认。判断是否正常要同时看确认包的占比、间隔分布、方向与是否伴随重传。
基本信息
| 过滤表达式 | tcp.len == 0 && tcp.flags.ack == 1 表示长度为 0 的纯确认 |
|---|---|
| 观察维度 | 确认包占比、间隔分布、方向对称性、是否伴随重传 |
| 正常形态 | 请求-响应型应用中交互密集属正常 |
| 异常形态 | 确认数量与有效载荷比例严重失衡并伴随重传 |
| 相关字段 | 重复确认 tcp.analysis.duplicate_ack 说明对同一序号重复提示 |
| 命令行统计 | 按字段导出后计数，比逐帧看更快 |
典型使用场景
- 流量构成分析：说明某条链路上报文数量为何很高而实际载荷很少
- 性能评估：确认包占用的带宽与设备处理资源，评估小包转发压力
- 异常筛查：确认与数据比例严重失衡并伴随重传时，提示链路或接收端存在问题
- 协议教学：对比两种确认策略下的报文数量差异
- 容量规划：按确认包比例估算设备的包转发需求
统计与判读
统计与判读
# 统计纯确认包数量
tshark -r a.pcap -Y 'tcp.len == 0 && tcp.flags.ack == 1' -T fields -e frame.number | wc -l
# 按下行方向分别统计, 看是否对称
tshark -r a.pcap -Y 'tcp.len == 0 && tcp.flags.ack == 1 && ip.src == 10.0.0.5' -T fields -e frame.number | wc -l
# 重复确认与重传要对起来看
tshark -r a.pcap -Y 'tcp.analysis.duplicate_ack || tcp.analysis.retransmission' -T fields -e frame.number -e tcp.stream | head -20
# 与有效载荷比例对照
tshark -r a.pcap -Y 'tcp.len > 0' -T fields -e frame.number | wc -l现象与推断
| 现象 | 可能的含义 | 下一步 |
|---|---|---|
| 确认包占比高但不含重传 | 请求-响应型业务特征 | 结合业务模型确认是否正常 |
| 确认包密集且间隔均匀 | 对每个段立即确认 | 评估设备包处理压力 |
| 重复确认成串出现 | 对同一序号反复提示 | 配合重传判断是否丢包 |
| 确认与数据比例失衡并伴随重传 | 链路或接收端存在问题 | 先查丢包再看接收侧处理能力 |
| 某一方向确认明显偏多 | 单向大流量传输的典型形态 | 确认接收方向是否在批量索取 |
纯确认包的开销本身很小，真正值得关注的是确认与数据比例严重失衡，并且伴随重传或重复确认同时出现的情况。
把确认密集判定为攻击之前，先确认业务模型：轮询、心跳、交互式交易类应用天然报文数量多，单看包速率会得出错误结论。