摘要

  • RFC 3342 的 reportAfter 到期时会生成暂时性时间报告，但明确不影响交付；中继仍要把原数据发往下一跳。
  • noLaterThan 才能在预算耗尽时停止转发，returnTrip 又单独限制末跳报告的返程，因此告警、阻断、回执到达和应用结果是四层证据。

APEX 核心提供的是“立即、尽力而为”的应用层数据报服务。没有选项时，中继不可用可能导致静默丢弃。RFC 3342 增加了排队、计时和报告能力，却没有把所有计时器压成同一种“成功/失败”信号。这份克制恰好揭示了现代可观测系统最常见的越权：监控先看见异常，控制面便假设执行已经终止。

如果告警只是告警，它可以与仍在运行的工作同时为真。协议将这件事写得很明确。

软阈值耗尽的是观察预算

dataTiming 按跳处理，所以发起者必须把 targetHop 设为 all，并把 mustUnderstand 设为 true。每个中继在把数据发往下一跳前，会从 reportAfter 中扣除本地处理时间，包括查找下一中继、成功完成绑定并准备发送所消耗的时间。

当余额小于或等于零时，中继把它固定为零，调用报告服务生成暂时性时间报告；无论如何，原数据元素仍会发往下一中继。在最后一跳，如果中继没有在剩余 reportAfter 时间内收到接收端点的 ok，也会生成同类报告。

报告中的 statusResponse 沿用计时选项的事务标识符，并为原收件人写入 350 这一暂时成功指示。它记录的是报告阈值已经越过，不是数据已丢弃，也不是业务已失败。消息后来抵达，不会让先前的延迟告警变成错误；消息最终没有抵达，也不能由这一份告警单独解释。

这要求事件账本保留时间和作用域。告警发生在哪一跳、扣除了多少本地处理时间、原消息是否继续、后续又发生了什么，都不能被一个红色状态覆盖。

硬上限改变了执行路径

noLaterThan 同样逐跳递减，但语义完全不同。中继在转发前扣除本地处理时间；若余额降至零或以下，处理发生错误，数据不会再发往下一中继。若 reportErrors 为真，报告服务还会生成时间错误报告。

到了接收端点，中继会用剩余预算等待端点返回 ok。超时同样属于时间错误。软阈值的动作是“报告并继续”，硬上限的动作是“到此为止”。若平台把二者都写成 timeout，表面上简化了字段，实际上丢掉了最重要的控制事实：原工作究竟还活着，还是已经被协议停止。

硬上限也只证明有限事实。它说明这次传递在某个处理点没有于剩余预算内完成，却没有自动证明原因。消耗预算的可能是本地计算、慢连接、不可用中继、拥塞或尚未附着的端点。即使端点及时返回 ok，这份确认也只覆盖协议所定义的处理边界，不能替代用户或业务结果。

报告本身也要经历一次交付

当数据成功传给收件端点且 returnTrip 非零时，中继调用报告服务发送末跳报告。报告并不会瞬间出现在发起者账本中。它是另一项 APEX data 操作，新操作携带的 dataTiming.noLaterThan 等于原选项的 returnTrip。

于是，原消息的交付和交付证据的返程形成两条独立路径。原消息可能已经到达，报告也已经生成，但报告仍可能在回程预算内未能送达。期限过后，发送者可以推定报告丢失；它不能反过来推定原消息没有到达。

一份可靠记录至少要拆开：入口中继受理、剩余软阈值、暂时报告生成、告警后继续转发、剩余硬预算、停止位置或端点确认、末跳报告生成、返程预算、报告是否收到、应用实际结果。把这些状态压成一个字段，只会让后来的审计把“不知道”误读成“没有发生”。

队列、跳数和附着各有边界

hold4Endpoint 允许在收件端点尚未附着时排队等待。如果没有 noLaterThan 一类交付上限，数据可能无限期留在队列。RFC 3342 特别指出这会便利拒绝服务攻击，管理员可以施加限制，例如要求同时携带短寿命的硬上限。进入队列只是存储状态，不是交付承诺。

dataHopping 则重新引入类似 IP TTL 的跳数限制，用来发现中继环路。它在转发前递减 noMoreThan，耗尽时停止下一跳。跳数预算回答“还能穿过几个中继”，时间预算回答“还能等待多久”。一条消息可能跳数很少却耗尽时间，也可能迅速耗尽跳数而尚未超时。

attachOverride 允许新应用以同一端点附着并终止旧应用。旧应用等待的数据可能交给后来者，这正是 RFC 3340 的生命周期和请求所有权边界，已有独立文章负责。RFC 3342 在这里提供的提醒更窄：时间报告不会自动证明当前接收应用拥有处理旧工作的权限。

Historic 记录没有扩大证据

RFC 3342 于 2002 年 7 月以标准化进程文档发表，目前被标记为 Historic；RFC Editor 的检索没有列出匹配勘误。IETF 在 2012 年 7 月 29 日的历史记录中写道，据其所知，RFC 3340 至 3343 没有已部署的实现，相应功能已由广泛部署的 XMPP 提供，依据为 RFC 6120 和 RFC 6121。

这是一项带限定语的历史判断，不是因果结论。它没有说计时选项导致 APEX 未部署，也没有提供真实延迟数据、实现故障或安全事故。规范还提醒，dataTiming 可能暴露私有网络拓扑，因此管理员可以只在管理域入口和出口启用。可观测性有诊断价值，也有信息暴露成本；它从未因此获得替业务结果发言的权力。

今天重读这份文档，应当保留三个问题：哪一个阈值只负责提醒，哪一个阈值真正改变执行，哪一个阈值限制回执本身的送达。告警出现时要确认工作是否停止；工作停止时要确认停止点证明什么；回执到达时要确认它由哪一层签发。只有这样，监控才不会变成未经授权的执行者。

来源