Кратко

  • RFC 2013 определил четыре счётчика Counter32 только для чтения на уровне всей UDP-реализации: датаграммы, переданные пользователям UDP, принятые без приложения на порту назначения, не доставленные из-за иных ошибок и отправленные данным узлом.
  • Строка udpTable индексировалась только локальным IPv4-адресом и локальным портом. Удалённого адреса и порта, процесса, экземпляра socket и идентификатора датаграммы в ней не было.
  • RFC 4113 добавил типы, значения и порты локальной и удалённой сторон, номер экземпляра и идентификатор процесса. Это улучшило атрибуцию endpoint, но не доказательство обработки приложением и результата сервиса.

Итоговые числа не хранили отдельные эпизоды

Каждый из четырёх объектов имел точный знаменатель. udpInDatagrams считал передачу датаграмм пользователям UDP. udpNoPorts — принятые датаграммы без приложения на порту назначения. udpInErrors — остальные случаи невозможности доставки входа. udpOutDatagrams — датаграммы, отправленные узлом.

Эти различия полезны внутри UDP. Но все значения относятся ко всей сущности. У них нет индекса endpoint, удалённой стороны, процесса, времени, идентификатора сообщения или связи между входом и выходом. Одновременное изменение двух итогов лишь совместимо с одной историей, а не доказывает её.

RFC 1902 задавал дополнительную границу: Counter32 растёт до 2^32−1 и оборачивается в ноль, не имеет определённого начального значения, а единичное чтение обычно не несёт информации. Переинициализация системы управления может разорвать последовательность. Для разности нужны две точки и доказательство непрерывности. Даже такая разность остаётся общей для узла.

В адресной книге была только локальная сторона

udpTable описывала endpoint, где локальное приложение в данный момент принимало датаграммы. Индекс состоял из udpLocalAddress и udpLocalPort. Значение 0.0.0.0 означало готовность принимать на любом локальном интерфейсе; порт лежал в диапазоне 0–65535.

Строка подтверждала узкое утверждение: в момент опроса management agent представлял эту локальную IPv4-координату как listener. Она не указывала отправителя конкретной датаграммы. Не называла процесс, не различала несколько sockets с одной группой и не связывала строку с общими счётчиками.

Слова «приложение принимает датаграммы» не означают завершение работы приложения. Строка не показывает, прочитан ли payload, прошёл ли он проверку, разрешена ли операция и изменилось ли состояние. Нет доказательства ответа, его удалённой доставки или результата для пользователя. Номер двери не является стенограммой разговора.

Передача пользователю UDP была промежуточной границей

Формулировка udpInDatagrams сильнее простого появления пакета на интерфейсе: датаграмма передана пользователю UDP. Это реальный результат транспортного слоя. Но до результата приложения остаётся ещё одна граница.

Счётчик не фиксирует чтение buffer программой, разбор или действие. udpNoPorts подтверждает отсутствие приложения назначения для своего общего числа, но не хранит отправителя. udpInErrors объединяет остальные причины. udpOutDatagrams заканчивается отправкой с узла и не подтверждает приём удалённым host или приложением.

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

RFC 4113 расширил поверхность идентичности

RFC 4113 заменил RFC 2013 в 2005 году. Он сохранил четыре базовых счётчика, добавил высокоёмкие варианты и объявил старую таблицу устаревшей по двум причинам: только IPv4 и невозможность описать «connected» UDP endpoint. Первая причина не является тезисом этой статьи. Вторая показывает предел чисто локального индекса.

udpEndpointTable могла представить listener с wildcard удалённой стороной или endpoint с конкретными удалёнными адресом и портом. Индекс включал тип, значение и порт локально и удалённо, а также udpEndpointInstance. Номер экземпляра различал процессы на одной группе, включая SO_REUSEADDR и SO_REUSEPORT. udpEndpointProcess сообщал ID системного процесса либо ноль и мог сопоставляться с host-resource или application MIB.

Это более точная management identity, а не надёжная сессия. PID может отсутствовать или использоваться повторно. Настроенный remote описывает ограничение socket, но не состоявшийся обмен. Ни одно поле не подтверждает parse, авторизацию, ответ или эффект сервиса.

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

Сильное заключение сохраняет масштаб источника

RFC 2013 не обещал журнал разговоров. Ошибка возникает, когда общий прирост приписывают одному сервису, локальный порт превращают в собеседника, «отправлено» — в «доставлено», а передачу пользователю UDP — в деловой результат.

Доказуемое высказывание сохраняет единицу: между непрерывными выборками увеличился счётчик всей сущности; в данный момент agent показывал локальный listener. Атрибуция требует связанного packet или event. Обработка требует квитанции приложения. Доставка требует наблюдения на другой стороне. Успех требует определения и измерения на уровне сервиса.

Порт — координата, счётчик — знаменатель, разговор — атрибутированная цепочка событий. RFC 4113 сделал больше звеньев явными, но не создал финальную квитанцию.

Источники

Границы доказательств

Источники подтверждают историю документов, определения объектов, семантику счётчиков и модель-преемник. Они не подтверждают реализацию производителя, распространённость, текущие настройки, дефект, инцидент, SLA, измеренный трафик или завершённый результат приложения.