摘要

  • RFC 3195 的 RAW 配置用 BEEP 传送熟悉的 syslog 消息，保证单个通道内可靠且有序地交付；COOKED 配置则增加结构化条目，并为每一条返回肯定或否定应答。
  • 两类机制证明的事情不同。帧已交付或收到 <ok/>，本身不能证明事件来源真实、日志已持久写入、完成索引或引发运维响应。

“可靠”一词听起来可能比协议实际承诺的范围更大。RFC 3195 于 2001 年 11 月发布，属于 Standards Track 文档；它把 syslog 映射到面向连接的 BEEP 框架。两个配置呈现了设计上的取舍。RAW 重视轻量和兼容：消息保留传统 syslog 格式，BEEP 则在各自通道内提供可靠、有序的传递。COOKED 使用结构化操作，允许每个 entry 收到 ok 或 error。这只是协议交换对该条目的回应，不是日志系统后续所有环节的收据。(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 Editor 上的 RFC 3195 现行记录；IETF Datatracker 上的 RFC 3195 正文；RFC 3080：BEEP 核心；RFC 3081：BEEP over TCP；RFC 3164：BSD Syslog 协议；RFC 5424：Syslog 协议；RFC 5425：Syslog 的 TLS 传输映射；RFC 5426：Syslog UDP 传输；RFC 5848：签名 Syslog 消息；RFC 6587：Syslog over TCP；RFC 2782：DNS SRV；RFC 2119：规范用语级别。