4. 流量数据格式与存储管理

抓包工具把网卡上经过的帧保存成文件，但“保存成什么格式”直接决定了后续取证能做到什么程度。取证分析中最常见的两种容器是 pcap 与 pcapng：前者是 1990 年代随 libpcap 定型的经典格式，后者是 2000 年代后为弥补 pcap 局限而设计的“下一代”格式。理解它们的字节级结构，才能在遇到截断文件、时间戳异常、链路类型不匹配时快速定位问题。

pcap 文件结构：一个全局头加若干包记录

pcap 文件由 24 字节的全局头（Global Header）和紧随其后的一串包记录（Packet Record）组成。全局头字段依次为：4 字节魔数（Magic Number）、2 字节主版本号、2 字节次版本号、4 字节时区修正、4 字节时间戳精度、4 字节最大抓取长度（snaplen）、4 字节链路层类型（LinkType）。魔数是最关键的判据：0xA1B2C3D4 表示大端序、微秒级时间戳；0xD4C3B2A1 表示小端序、微秒级；0xA1B23C4D 与 0x4D3CB2A1 则对应纳秒级时间戳。读文件时先看这 4 个字节，就能确定字节序和时间精度，否则后续所有字段都会解析错位。

每个包记录由 16 字节头加数据组成：4 字节时间戳秒（ts_sec）、4 字节时间戳微秒/纳秒（ts_usec）、4 字节抓取长度（incl_len）、4 字节原始长度（orig_len），随后是 incl_len 字节的包数据。这里有一个取证中极易踩的坑：当 incl_len 小于 orig_len 时，说明抓包时设置了较小的 snaplen，包被截断，原始帧的尾部已经丢失。例如 snaplen 设为 96 字节时，一个 1514 字节的以太网帧只保留前 96 字节，IP 选项、TCP 载荷、应用层内容都可能不完整。分析前必须检查是否存在大量 incl_len < orig_len 的记录，并据此判断能否做载荷级取证。

pcapng：块结构与多接口支持

pcapng 用“块（Block）”组织数据，每个块以 4 字节块类型、4 字节块总长度开头，以相同的总长度结尾，便于从损坏文件中恢复。核心块类型包括：Section Header Block（SHB，含字节序魔数 0x1A2B3C4D）、Interface Description Block（IDB，描述一个抓包接口的链路类型、snaplen、时间戳精度）、Enhanced Packet Block（EPB，携带包数据与接口 ID）、Simple Packet Block（SPB）以及 Name Resolution Block、Interface Statistics Block 等元数据块。

pcapng 相对 pcap 的关键改进有三点：一是支持多接口，一个文件可同时记录 eth0、wlan0 甚至多个采集点的数据，每个包通过接口 ID 关联到对应 IDB；二是时间戳精度可在 IDB 中声明为 10⁻⁶ 或 10⁻⁹ 秒，且用 64 位时间单位表示，避免 2038 年溢出；三是可嵌入注释、抓包主机信息、过滤器字符串等元数据。代价是结构更复杂，部分老旧工具只认 pcap，必要时需用 editcap -F pcap 转换，但转换会丢失多接口与高精度时间戳信息。

链路层类型与时间戳精度

链路层类型（LinkType）告诉解析器“包数据从哪一层开始”。最常见的是 LINKTYPE_ETHERNET = 1，包数据以 14 字节以太网头开始；LINKTYPE_LINUX_SLL = 113 用于 Linux “any” 伪接口，带 16 字节 SLL 头；LINKTYPE_RAW = 101 表示没有链路层头，直接从 IP 开始；无线抓包常见 LINKTYPE_IEEE802_11 = 105。如果 LinkType 判断错误，Wireshark 会把以太网头当成 IP 头解析，出现满屏“Malformed Packet”。取证时若发现解析异常，第一件事就是核对全局头或 IDB 中的 LinkType 是否与实际采集接口一致。

时间戳精度直接影响时序分析。pcap 的微秒字段只有 32 位，纳秒精度文件用同一字段存纳秒值，因此必须靠魔数区分。pcapng 在 IDB 中用 if_tsresol 字节声明精度，常见值 6（微秒）和 9（纳秒）。做多文件关联时，若一个文件是微秒、另一个是纳秒，直接比较时间戳会差三个数量级，必须先统一到同一精度再对齐。此外，抓包主机的时钟可能未与 NTP 同步，文件内时间戳只能保证相对顺序，绝对时间需要结合采集日志校正。

文件元数据与大规模数据组织

取证数据往往不是单个文件，而是按时间、地点、接口切分的成百上千个文件。合理的目录组织应让“定位某时间段某主机的流量”变成一次路径查找，而不是全盘扫描。推荐按“案件/采集点/日期/小时”分层，文件名嵌入起止时间与接口，例如：

case-2024-0317/
├── site-A/
│   ├── 20240317/
│   │   ├── eth0_20240317T0900_1000.pcapng
│   │   └── eth0_20240317T1000_1100.pcapng
│   └── 20240318/
└── site-B/
    └── 20240317/
        └── wlan0_20240317T0900_1000.pcapng

仅有目录还不够，需要建立索引。轻量做法是用 capinfos 批量提取每个文件的包数、起止时间、链路类型、文件大小，汇总成 CSV 索引表；再用 tshark -r file -q -z io,phs 生成协议分层统计。索引表至少包含：文件路径、起止时间、包数、字节数、LinkType、snaplen、是否截断、SHA-256。SHA-256 用于固定证据完整性，任何后续分析都应基于校验通过的文件副本进行。

备份策略与完整性校验

取证数据的备份遵循“原始只读、副本分析、异地留存”原则。原始文件写入后立即计算哈希并记录，之后挂载为只读或存放于写保护介质；分析在副本上进行，副本同样记录哈希。备份采用 3-2-1 思路：至少 3 份数据、2 种介质、1 份异地。对 TB 级流量数据，全量复制成本高，可按“案件 + 日期”做增量归档，但每个归档单元仍需独立哈希清单，避免单点损坏导致整批不可信。

校验流程可固化为：采集完成后计算 SHA-256 并写入 manifest；复制到分析机后重新计算并比对；分析结束导出结论时再次比对，确认分析期间原始文件未被改动。若哈希不一致，必须停止使用该副本，回到原始介质重新复制。下面是一份可直接套用的 manifest 字段示例：

把格式理解、元数据核对、目录索引和哈希校验串起来，流量取证才具备可复现性：任何人拿到同一批文件和 manifest，都能验证数据未被篡改，并按索引快速定位到目标时间段与接口，再依据 LinkType 和时间精度正确解析。格式细节看似底层，却决定了上层分析结论是否站得住脚。