Кратко

  • Профиль RAW в RFC 3195 передаёт привычные сообщения syslog по BEEP, который гарантирует надёжную упорядоченную доставку в пределах канала; COOKED добавляет структурированные записи с положительным или отрицательным ответом на каждую.
  • Эти механизмы подтверждают разные вещи. Доставленный кадр или <ok/> сами по себе не доказывают источник события, долговременную запись, индексацию или операционную реакцию.

Слово «надёжный» может звучать шире, чем гарантия протокола. RFC 3195 опубликована в ноябре 2001 года как документ Standards Track и отображает syslog на ориентированный на соединение BEEP. Два профиля показывают инженерный выбор. RAW ориентирован на малые накладные расходы и обратную совместимость: формат сообщений остаётся знакомым, а BEEP обеспечивает надёжную доставку в порядке отправки внутри каждого канала. COOKED использует структурированные операции и позволяет ответить ok или error на каждую entry. Такой ответ относится к обмену по протоколу, а не ко всем последующим этапам системы журналирования. (RFC 3195 §§1, 3.1, 4.4.2)

Свидетельства нужно разделять. Отправитель выпускает событие; узел BEEP получает полное сообщение; получатель COOKED принимает или отклоняет запись; затем коллектор может разобрать, записать, индексировать, реплицировать её или создать оповещение. Это разные изменения состояния. RFC 3195 определяет транспорт и обмены профилей, но не универсальную транзакцию хранения. Даже <ok/> не сообщает, сбросил ли коллектор данные на долговременный носитель и увидели ли их потребители ниже по цепочке. error может означать административный отказ: он подтверждает решение политики, а не отсутствие события.

В RAW эта граница видна особенно ясно. Маркер завершения BEEP-кадра отделяет сообщение, а транспорт обеспечивает надёжность и порядок в конкретном канале. Но первое сообщение RAW-получателя не имеет семантики записи syslog; записи передаются в ответах инициатора. Профиль также ограничивает тело каждого события RAW 1 024 байтами, не включая накладные расходы на кадрирование BEEP. Это граница полезной нагрузки, а не обещание долговременного хранения. Она отличается от предела всего пакета и возможного усечения на ретрансляторе по RFC 3164 — это отдельный механизм. (RFC 3195 §3.3; RFC 3164)

RFC 3195 отдельно различает безопасность связи и целостность объекта сообщения. В разделе о безопасности сказано, что скомпрометированное устройство может формировать ложные сообщения, а ретрансляторы и коллекторы могут незаметно изменять, вставлять или удалять их без дополнительных средств обнаружения. Аутентификация, защита от повторов, целостность и конфиденциальность должны настраиваться отдельно. Защищённый канал может удостоверить узел на одном переходе, но его идентичность не обязательно совпадает с именем хоста в событии и не равна сквозной подписи содержимого события. (RFC 3195 §§5, 10; RFC 5425 §4)

Позднейшие работы над syslog ещё яснее показывают это различие. RFC 5848 описывает подписанные блоки, которые могут поддерживать аутентификацию источника, целостность, защиту от повторов, последовательность и обнаружение пропусков. Там же отдельно отмечено, что надёжный транспорт не исключает потерю на уровне приложения — например, когда получатель закрывает TCP- или TLS-сессию. Это не доказывает широкого внедрения RFC 3195 и не означает, что подписи решают все вопросы хранения. Это подтверждает: для доставки, подлинности и полноты нужны разные свидетельства. (RFC 5848 §§1, 8.3–8.7)

Долгосрочная ценность RFC 3195 — в точном разграничении гарантий. RAW отвечает на вопрос: «доставил ли этот канал BEEP сообщение в нужном порядке?» COOKED добавляет вопрос: «ответил ли получатель положительно или отрицательно на эту запись?» Без дополнительных мер оба профиля не устанавливают, подлинно ли событие, пережило ли оно отказ хранилища и последовало ли действие оператора. При разборе инцидента следует отдельно сохранять состояние сессии, ответы на записи, результат проверки подписей, долговременную запись у коллектора и последующую обработку.

RFC задаёт поведение протокола; доступные источники не подтверждают распространённость его реализации или текущие эксплуатационные показатели.

Источники: RFC 3195; текущая запись RFC 3195 в RFC Editor; текст RFC 3195 в IETF Datatracker; RFC 3080, ядро BEEP; RFC 3081, BEEP поверх TCP; RFC 3164, протокол BSD Syslog; RFC 5424, протокол Syslog; RFC 5425, TLS-транспорт для Syslog; RFC 5426, UDP-транспорт для Syslog; RFC 5848, подписанные сообщения Syslog; RFC 6587, Syslog поверх TCP; RFC 2782, DNS SRV; RFC 2119, уровни требований.