Кратко

  • RFC 3395 добавил прикладные глаголы в идентификаторы RMON, хотя операция могла охватывать несколько пакетов и оба направления обмена, а не читаться из текущего пакета.
  • Каждый пакет всё равно следовало учесть ровно один раз под полной листовой записью. При нескольких глаголах агент выбирал один по собственной политике, которую стандарт не унифицировал.

Зонд видит SNMP Response. Тип ответа известен, но сам пакет не сообщает, был ли исходным запросом Get или GetNext. Чтобы назвать операцию, устройство должно найти в памяти предыдущий запрос из обратного направления и связать их. Так в простом счётчике появляется прошлое.

RFC 3395 вышел в сентябре 2002 года как стандарт и обновил справочник идентификаторов протоколов из RFC 2895. RMON уже разделял трафик по протоколам, однако общая сумма HTTP, SNMP или FTP скрывала операции с разной стоимостью и эксплуатационным смыслом. Документ ввёл общий словарь прикладных транзакций, не создавая нового модуля MIB или новых управляющих операций.

Справочник представлял пакет как распознанный стек. Каждый слой добавлял четыре октета к protocolDirID и один к protocolDirParameters; вся последовательность обозначала конкретный лист инкапсуляции. Прикладной глагол стал ещё одним таким слоем.

Его двоичное представление занимало четыре октета: резервный нулевой октет, затем беззнаковое 24-битное перечисление в сетевом порядке байтов. Явные значения лежали от 1 до 16 777 215, были уникальны внутри родительского протокола и должны были назначаться плотно. К параметрам добавлялся ещё один ноль — не как значение операции, а ради одинаковой формы слоёв.

Ноль уже имел смысл. Любой прикладной протокол неявно получал connect(0) для установления и завершения сеанса, если эти пакеты не относились к другому глаголу. Переопределять номер запрещалось. Само имя глобально не резервировалось: пример HTTP также регистрировал явный метод CONNECT как connect(8). Без родителя и номера знакомая строка могла обозначать разные вещи.

Макрос VERB-IDENTIFIER связывал родительский протокол, обязательное описание, желательную при наличии авторитетного текста ссылку и перечень имён с номерами. Имена учитывали регистр и были уникальны у одного родителя; следовало сохранять официальную терминологию протокола. Общий словарь позволял одинаково подписать результат, но не гарантировал одинакового пути к нему.

В SNMP этот путь требовал состояния: Response и Report в примере не становились самостоятельными глаголами, а учитывались вместе с транзакцией породившего их запроса. В TCP одна операция могла быть разрезана на несколько сегментов. Зонд отслеживал поток и собирал достаточно байтов, прежде чем классификация становилась возможной.

Если от глагола зависело решение о захвате, уверенность могла появиться позднее первых пакетов. Для сохранения начала требовался предварительный буфер. Без него запись, названная операционной, теряла часть той самой транзакции, которую должна была документировать.

Поэтому «глагол» не обязательно совпадал с командой, opcode или типом PDU. Транзакция могла включать несколько сообщений и даже несколько справочных записей. В FTP управляющий диалог и отдельное соединение данных могли относиться к одной полезной операции. Глагол был единицей анализа, а не полем, которое гарантированно присутствует в каждом пакете.

При этом учёт RMON требовал однозначного выхода. Пакет засчитывался один раз под полной листовой инкапсуляцией, причём в счётчик шёл весь его размер. Делить байты между несколькими обнаруженными глаголами было нельзя. Агент обязан был выбрать один.

RFC перечислял возможные правила: первый глагол, наиболее частый, занимающий больше всего октетов либо самый интересный с точки зрения знания протокола. Ни одно правило не стало обязательным. Поэтому два соответствующих стандарту зонда способны по-разному распределить одну трассу, и это само по себе не доказывает ошибку одного из них.

Примеры FTP, POP3, SNMP, HTTP и SMTP делали регистрацию понятной, но не превращали метку в доказательство намерения. Счётчик GET не устанавливает пользователя, полномочия, успех транзакции или полноту видимого содержимого. Он подтверждает, что конкретный агент с доступным состоянием и локальной политикой отнёс пакеты к этому листу.

Раздел безопасности также не называл детализацию нейтральной. Новых MIB-операций не появлялось, но сбор по глаголам раскрывал, какие прикладные действия используются в сети, и мог требовать дополнительной защиты. Более точное наблюдение создавало более точное раскрытие.

Позднее RFC 4502 заменил RFC 2021 в роли спецификации RMON-2 MIB. Эта преемственность объясняет архитектурный контекст, но не доказывает распространённость RFC 3395 или одинаковое поведение продуктов при потерях, шифровании, асимметрии маршрутов и заполнении таблиц состояния. Стандарт даёт проверяемый договор, работающая система — факты.

Принцип Лу Хэна о минимальной начальной спецификации объясняет границу. Документ закрепил кодировку, родителя, имена, нулевое значение, возможности и обязанность выбрать один лист. Таймауты, буферы, сборка и предпочтение глаголов остались локальными, чтобы ранняя эвристика не заморозила все будущие протоколы и ограничения.

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

Исторический урок RFC 3395 не в произвольности измерений. Он в их происхождении. Сеть передавала пакеты, а зонд строил транзакцию. Когда счётчик говорил GET, он сообщал и о трафике, и о том, что машина запомнила, дождалась и предпочла.

Источники