Кратко

  • RFC 869 задал общий формат, по которому центр мониторинга мог опрашивать узлы, сопоставлять ответы, запрашивать состояние и статистику и получать спонтанные уведомления. Документ не требовал, чтобы все устройства сообщали одинаковые сведения.
  • RFC 823 показывает, как это работало для шлюза: можно было сообщать об интерфейсах, соседях, достижимых сетях, матрице трафика и счётчиках отброшенных пакетов, но форматы отчётов и управления зависели от типа узла.

Анализ

Шлюз должен был сообщать, что происходит внутри

Host Monitoring Protocol (HMP) служил не только проверкой, отвечает ли машина. Спецификация DARPA Internet Gateway, опубликованная в 1982 году, описывала сбор показателей и состояния шлюзов средствами HMP. В сообщение о состоянии входили сведения об интерфейсах, соседних шлюзах и сетях, до которых устройство могло добраться. Host Traffic Matrix считала датаграммы по IP-адресам источника и назначения и номеру протокола. Отдельное сообщение о пропускной способности содержало счётчики принятых, пересланных и отправленных пакетов, а также потерь с разбивкой по интерфейсам и соседям.

Эти показатели позволяли из другой точки сети видеть часть внутренней работы шлюза. Матрица помогала понять, какие сочетания источника, назначения и протокола проходили через устройство; счётчики отбрасываний указывали на определённый класс потерь. Однако ни один из них сам по себе не подтверждал, что пользовательское приложение достигло адресата. RFC 823 описывает инженерный проект, а не независимую перепись фактически установленных шлюзов.

Общим был формат обмена, но не словарь устройств

Роберт Хинден опубликовал RFC 869 в декабре 1983 года, заменив прежнюю спецификацию IEN 197. В RFC HMP назван транзакционным транспортным протоколом без установления соединения. Заголовок содержит тип системы, тип сообщения, порядковый номер, поле «пароль или возвращённый порядковый номер» и контрольную сумму. Сочетание типа системы и типа сообщения определяет формат данных. В перечне есть IMP, терминальные контроллеры доступа (TAC), шлюзы и другие системы; номер протокола HMP в IP — 20.

Общий заголовок позволял распознавать запросы и связывать ответ с опросом. Но показатели пропускной способности шлюза не становились универсальным описанием любого узла. RFC 869 указывает, что типы сообщений задавались для каждого типа системы с учётом его потребностей. В приложениях приведены примеры сообщений для IMP, TAC и шлюзов, но введение подчёркивает: эти примеры не входят в сам протокол HMP. Общим было то, как спросить и сопоставить ответ; значение ответа по-прежнему определялось форматом конкретного устройства.

Трапы, состояние и статистика давали разные свидетельства

RFC 869 помещал большую часть логики мониторинга в центр. Узел собирал сведения и отправлял их по запросу или самостоятельно; центр отвечал за надёжное получение запрошенных данных. Состояние и статистику центр получал опросом и мог повторить запрос после тайм-аута. Порядковые номера помогали связать ответ с запросом и обнаружить повтор статистического сообщения. Статистика сохранялась в течение периода сбора, чтобы потерянный ответ можно было запросить снова.

Трапы работали иначе. При событии узел отправлял датаграмму, но HMP не требовал подтверждения или повторной передачи. Трап мог быстро сообщить о событии, но не гарантировал полный журнал событий. Состояние тоже имело узкий смысл: центр мог судить, доступен ли узел, по ответам на опросы. Если ответа не было, нельзя было определить, сломался ли узел, путь, сам запрос или ответ. А полученный ответ не доказывал исправность сервиса более высокого уровня.

Центр мог не только наблюдать, но и менять узел

Запрос мог читать параметры или передавать управляющие данные. RFC 869 приводит примеры настройки переключателей и таймеров измерений, а также управления самим узлом с помощью переключателя перезапуска. Узел обрабатывал данные и возвращал подтверждение управления либо сообщение об ошибке, если не мог их обработать. Формат и значение данных зависели от типа узла. Подтверждение фиксировало обмен, предусмотренный протоколом, но RFC не называет его доказательством того, что пользовательский сервис заработал после команды.

RFC 1157 о SNMP, опубликованный в 1990 году, полезен как сопоставление, но не подтверждает прямое происхождение SNMP от HMP. RFC 1157 называет Simple Gateway Monitoring Protocol (SGMP) предшественником SNMP и описывает модель чтения и изменения переменных с ограниченным числом спонтанных уведомлений. Историю HMP следует рассматривать отдельно: общий формат сообщений позволял разным устройствам выдавать собственные отчёты и принимать команды, смысл которых зависел от типа узла.

В апреле 1983 года список официальных протоколов RFC 840 присвоил HMP статус “Elective” и сообщил, что протокол используется для мониторинга интернет-шлюзов и TAC, а также отладки реализаций на небольших удалённых компьютерах. RFC 869 тоже описывает применение HMP на шлюзах и TAC, тогда как реализации для других узлов ещё проектировались. Это свидетельство ограниченного использования в тот период, а не повсеместного внедрения. Исторически важно другое: общий обмен сделал удалённое наблюдение возможным, но смысл отчёта оставался связан с отправившим его узлом.

Источники