摘要

  • RFC 3164 所记录的旧式规则要求中继在 PRI 有效、时间戳缺失或格式无效时，补入中继自己的当前本地时间，并尽量补入它所识别的设备名或地址。
  • 补写后的整个包仍不得超过 1024 字节；一旦超限，中继必须从末尾截到 1024 字节，原始消息中最关键的结论也可能随之消失。
  • 后来的标准把发起者、中继、收集器和传输角色分得更清楚，却没有让格式正确的头部、完整的传输帧或 TLS 对端身份自动成为端到端来源证明。

修复格式也会消耗证据

RFC 3164 在 2001 年记录的并不是一种刚刚发明的日志协议，而是已经长期存在的 BSD syslog 实践。它把产生消息的设备、接收后继续转发的中继、以及只接收不再转发的收集器区分开来。发送方甚至不必知道下一跳究竟是哪一种角色。

中继收到包后，先检查尖括号内的 PRI，再检查 TIMESTAMP 是否符合规定格式。如果两者有效，而且转发策略选中了该优先级，中继必须原样转发。这里的“有效”首先是语法判断：中继不必验证时间是否准确，也不必核实 HOSTNAME 是否与网络来源相符。

真正改变消息的是另一条分支。PRI 可以识别，但 TIMESTAMP 缺失或格式不对时，中继必须紧跟 PRI 插入一个时间戳和空格。这个时间不是从原始事件中恢复出来的，而是中继当时的本地时间。中继还应尽量写入 HOSTNAME：使用它所知道的设备名；无法确定名称时，则使用设备的 IP 地址。收到的其余字节被当作 CONTENT 接在后面。

补写让记录多了两个看似重要的坐标：何时到达某个中继，以及中继认为它来自哪里。问题在于 RFC 3164 同时规定整个包不得超过 1024 字节。中继补入字段以后必须重新检查长度；若超过上限，就必须截到 1024 字节。规范明确提醒，原始包末尾的关键信息可能因此丢失。

这不是无害的整理。新增的头部与原始内容争夺同一份字节预算。若错误码、对象名称、操作结果或否定词出现在末尾，中继保留下来的可能是一段格式更规整、叙事却恰好少了结论的记录。

没有 PRI 时，修复占用的空间更多

RFC 3164 还规定了第三种情况：PRI 缺失或无法识别时，中继要插入默认优先级 13，再加时间戳，并尽量加上主机名；原收到的全部内容都退为 CONTENT。之后仍执行同一个 1024 字节检查和强制截断。

经过修复的包传到下一跳时，已经可能具有有效 PRI 和 TIMESTAMP。后续中继可以将它原样转发。仅看收集器里的最终副本，人们未必能知道哪些头字段出自原设备，哪些是第一台中继补上的，也未必能看到被截去过的痕迹。格式的统一反而遮住了变换史。

旧式 TIMESTAMP 本身也缺少年份和时区，只表示月、日和本地时间。收集器可以根据归档时间猜测年份，但跨年、延迟和错误时钟都会削弱这种推断。中继补写的时间更接近“中继在何时观察到这个包”，不能直接替代“事件在源设备何时发生”。

精确知道帧有多长，不等于知道历史上有没有被剪过

2009 年的 RFC 5424 正式区分 originator、relay、collector、transport sender 和 transport receiver，并把 VERSION、TIMESTAMP、HOSTNAME、APP-NAME、PROCID、MSGID 与结构化数据纳入格式。消息大小则由传输映射决定：所有接收端必须支持至少 480 八位组，应该支持至少 2048 八位组，也可以更多。

若消息超过接收端能力，接收端应该截断载荷，或者可以丢弃。选择截断时必须从末尾进行。这样能让前部字段优先存活，却不能保证结果仍是有效 UTF-8 或完整结构化数据。规范还警告，攻击者可能利用截断掩盖关键信息，因此重要内容应尽早出现。

RFC 5425 为 TLS 上的 syslog 使用“十进制长度、空格、消息”的八位组计数。无论一条消息跨过多少 TLS record，接收者都能确定边界。但 TLS 认证的传输发送方身份不一定与消息内 HOSTNAME 相同；这是逐跳保护，不是对远端原始发起者的自动背书。

RFC 5426 要求一个 UDP 数据报只承载一条 syslog 消息，而这条消息可能完整，也可能已被截断。RFC 6587 则记录 TCP 上的八位组计数与终止字符分帧。它们解决“这一帧在哪里结束”，不解决“更早的中继是否曾收到更长版本”。

IANA syslog 参数注册表 可以解释 facility、severity、version 和结构化数据标识符。注册值能帮助解码，却不能证明某种实现已经部署、某个来源真实、某条消息到达或某个尾部从未丢失。

RFC 5424 还定义了可选的 timeQuality 结构化数据。发起者可以声明自己是否知道时区、时钟是否已同步，以及它认为同步精度如何。这比 RFC 3164 中无年份、无时区的时间字段多了重要语境，但仍是发起者声明，不是收集器完成的独立校时。分析者可以据此调整置信度，不能把它当成自动认证。

UDP 的不同最低能力也说明，“syslog 的长度上限”后来不再只有一个数字。RFC 5426 要求 IPv4 接收端至少能接收 480 八位组，IPv6 接收端至少 1180 八位组，并建议所有接收端支持 2048 八位组。这些数字与避免在最低 MTU 环境中产生分片有关。能接收多大、路径能否可靠送达、最终存储是否完整，是三个不同边界。

因此，一个恰好 1024 字节的存档不能单凭长度证明发生过旧式中继截断。它可能原本就是这个长度，也可能在其他环节被缩短。RFC 给出可行机制，具体事件归因仍需要边界两侧字节与配置的共同证据。

RFC 3164 还讨论了伪造、重放、篡改、丢失和乱序。格式良好的消息可能是假的，真实消息也可能迟到或永远不到。调查不能把格式合规、传输成功与事件真实压成一个笼统的“可信”判断；每一层都需要自己的证据。

这也解释了为何保存中继处理日志与保存消息本身同样重要：前者说明发生过何种变换，后者只显示变换之后还剩下什么。

来源