Кратко

  • RFC 1761 описал формат файлов Snoop Version 2 компании Sun, чтобы программы могли независимо записывать и анализировать один и тот же тип сетевого захвата.
  • В записи раздельно указаны исходная длина пакета и число сохранённых байтов. Нулевой счётчик потерь иногда означает, что система вообще не умела их считать.

Когда на разборе аварии открывают файл с пакетами, разговор становится увереннее. Вот байты, вот время, вот порядок. Но уверенность файла ограничена тем, что устройство сумело поймать. В феврале 1995 года Brent Callaghan и Robert Gilligan из Sun опубликовали RFC 1761: описание второй версии формата Snoop, пригодное для сторонних программ. Главная цель — отделить сбор трафика от последующего анализа. Попутно документ оставил полезную инструкцию к недоверию: каждая запись сообщает, где её собственные границы.

Первые шестнадцать октетов — заголовок файла. Восемь из них образуют метку snoop с тремя нулевыми октетами. Далее идут четырёхоктетный номер версии 2 и четырёхоктетный тип канального уровня. Код Ethernet — 4, IEEE 802.3 — 0. Эта разница определяет, как читать начало каждого сохранённого пакета: данные включают канальный заголовок. В перечне есть также Token Ring, HDLC, FDDI. Все целые числа записаны старшим байтом вперёд. Совместимость не случается от одного знакомого имени файла; она начинается с одинаковой трактовки этих шестнадцати октетов.

После заголовка идут записи переменной длины. Каждая начинается с шести 32-битных чисел, вместе это 24 октета служебных данных. Первое число — исходная длина пакета, полученного из сети. Второе — включённая длина, то есть сколько байтов попало в файл. Когда второе меньше первого, часть пакета обрезана. Красиво показанный заголовок протокола не вернёт хвост, которого в файле никогда не было. Это не спор о качестве программы просмотра; это свойство собранного доказательства.

Третье число — длина записи целиком, включая служебные 24 октета, данные и возможное выравнивание. Оно указывает, откуда читать следующую запись. Перепутать его с включённой длиной — значит принять байты заполнения за трафик или сдвинуться внутрь чужого пакета. Поэтому у формата есть строгий порядок байтов и разные поля длины. Без них два аналитика могли бы честно прочесть один файл и получить два разных события.

Четвёртое число подсчитывает пакеты, потерянные системой захвата с первой записи до текущей. Здесь документ наносит удар по самоуверенному нулю: некоторые реализации не умеют считать потерянные пакеты и могут всё равно записать ноль. Следовательно, ноль нуждается в проверке прибора. Он может означать отсутствие учтённых потерь или отсутствие самой возможности учёта. И даже ненулевой показатель говорит о потере при захвате, а не автоматически о судьбе пакета у приложения.

Последние два числа задают время прихода: секунды с 1 января 1970 года и микросекунды. Они позволяют упорядочить сохранившиеся пакеты. Чтобы установить причину сбоя, придётся сопоставить эту последовательность с другими журналами и наблюдениями. Вклад RFC 1761 состоит не в обещании всеведения. Он позволил переносить сетевые следы между инструментами и читать их пропуски столь же внимательно, как содержимое.