摘要

  • RFC 1761 公布了 Sun 的 Snoop 第二版抓包文件格式，让采集与事后分析可以由不同程序完成。
  • 记录里的原始长度和收录长度会暴露截断；累计丢包数为零，却也可能只是采集程序根本不会数。

网络出了问题，抓包文件一摆上桌，空气里就有了“证据已经到场”的味道。它确实比回忆可靠：字节可以保存、交接、重新解析。可文件的整洁不等于采集过程完整。Brent Callaghan 与 Robert Gilligan 在 1995 年 2 月发布的 RFC 1761，原本是为 Sun 的 Snoop 格式提供互通说明，让别的程序也能生成和读取它。读到字段细节，才发现这份说明还教人怎么质问自己的证据。

文件开头固定为十六字节。前八字节是 snoop 加三个空字节的识别标记；随后四字节标明版本二，另四字节指定链路层类型。以太网的类型码是 4，IEEE 802.3 则是 0。这个区别不是给文件贴标签：后面的每条记录都从链路层头部开始，解析器要靠文件头的类型决定从哪里、按什么格式读起。令牌环、HDLC、FDDI 等也在表中。整数统一采用高位在前的字节序。

文件头之后，一条记录对应一个被采集的数据包，记录长度可以变化。每条记录先交出六个 32 位整数，共二十四字节。排在最前面的两项尤其像一份诚实的收据：原始长度是网络上收到的数据包长度，收录长度是实际写入文件的字节数。后者比前者短，说明采集时截断了。屏幕上把包头显示得再清楚，也读不回没有保存的尾部。

第三项是整条记录的长度，计入这二十四字节、实际保存的数据和可能存在的填充。它告诉程序下一条记录从哪里开始。把“收录长度”当作“记录长度”，程序就可能把填充物误当数据，或者踩进下一包的开头。RFC 公布这个边界，是让不同工具面对同一文件时，不至于各讲各的悬疑故事。

第四项“累计丢包”更值得盯紧。它统计的是采集系统从第一条记录到当前记录之间丢掉的包，而不是一份端到端交付报告。RFC 明说，有些实现无法计数，便可能把它写成零。于是零既可能表示“没有数到”，也可能表示“根本没法数”。拿这个零断言网络上没有别的包，堪称把空白栏当成了见证人。

最后两项把到达时刻拆成自 1970 年 1 月 1 日起的秒数和微秒数。它们帮助重建已保存数据包的时间顺序；至于应用是否收到、对端是否处理、故障究竟出在哪里，单靠文件仍答不上来。RFC 1761 没有替调查者做结论。它给出更好的东西：一个可以交换的格式，以及足够明确的字段，让人知道证据在哪些地方说了话、在哪些地方闭了嘴。