摘要

  • RFC 8210 将缓存序列号定义为一个缓存谱系内循环递增的逻辑版本；不同缓存、会话或协议版本之间的序列号不可直接比较。
  • 路由器是否完整接收数据、缓存会话、刷新与过期计时，以及上游验证记录是彼此独立的证据，不能从序列号单独推导。
  • 新鲜度监控应保存有明确观察时间的同步账本，而不是按序列号对缓存做全局排序。

一种看似直观的比较是：缓存 A 报告序列号 90,000，缓存 B 报告 12,000，于是仪表盘把 A 排在前面并标为更新。每个数字都可能完全准确，但这个结论仍没有依据。

RFC 8210 把 Serial Number 定义为一个会循环回绕、严格递增的 32 位无符号整数，用来表示某个缓存的逻辑版本。缓存从父缓存或主要 RPKI 数据源成功取得更新后才增加该值，而且在获取完成之前不得暴露新序列号对应的数据。

这确实形成一种顺序，但只在正确边界内成立。同一 RFC 明确指出，不同缓存或不同协议版本的序列号不可通约，而且缓存重置后无须延续。Session ID 标识一个缓存实例，并把该实例生成的序列串联起来。只有协议版本、会话标识和序列号三者同时一致，比较才有意义。

因此，序列号更像一条本地序列上的位置，而不是通用时钟。刚启动的缓存可以在很小的序列号上持有最新数据；运行已久的缓存也可能拥有很大的序列号，但最后一次成功上游刷新更早。脱离身份比较数字，等于丢掉了赋予数字意义的上下文。

路由器与缓存之间的交换还保留了另一条边界。路由器发送 Serial Query，请求当前值之后的变化。如果缓存仍保留足够历史，就返回使路由器同步所需的最小合并变更集；如果没有，就要求 Cache Reset 并传送完整数据。路由器只有完整收到响应后，才采用 End Of Data PDU 中的序列号。

这个完成事件很重要。缓存可能已经进入新的逻辑版本，而路由器尚未取得它。通知只是提示路由器轮询。路由器当前保存的序列号，证明的是它从该缓存完整接收的最后一个数据集，而不是其他地方可用的最新状态。

RFC 8210 也把时间与序列分开处理。Refresh 与 Retry 间隔控制后续查询；Expire 间隔限制在没有再次成功查询时，旧数据最多可继续使用多久。倒计时从收到 End Of Data PDU 开始。序列号本身不能说明过期额度还剩多少。

存储库清单进一步说明了这种区别。RFC 9286 使用单调递增的 manifestNumber，同时另外携带 thisUpdate 和 nextUpdate 时间，并规定如何检查过期或过早签发的清单。即使在同一发布谱系中，序列顺序和墙上时钟有效期也是不同证据。

因此，可靠的新鲜度账本至少应记录缓存身份、协议版本、Session ID、序列号、成功收到 End Of Data 的时间、公布的刷新/重试/过期间隔、最近一次成功上游验证的观察时间，以及信任锚与策略上下文。若有上游存储库证据，其清单时间应单独记录，不能从 RTR 序列号猜测。

这种结构也能明确不确定性。路由器可以证明自己在 10:04 完整接收了会话 X 的序列号 200，并且数据尚未过期。但仅凭这些事实，它不能证明另一缓存没有更晚的上游状态、所有存储库已经收敛，或另一台路由器在同一时刻收到相同载荷。

本文不指控任何缓存故障或陈旧路由事件。关键是证据边界：序列号之所以有用，正因为它在可通约的谱系内排序状态。要求它充当全局时间，反而会移除使其可信的范围。

来源