摘要

  • RRDP 更新失败后，验证器可能继续使用既有缓存、下载更大的完整快照，或延迟切换到 rsync；这不是由一个全球统一的计时器决定的。
  • delta 保留期、manifest 新鲜度和验证器阈值，把带宽、恢复时间与重放风险分摊给仓库运营方、网络运营商和资源持有者。
  • 运营团队需要的是逐仓库的恢复回执与独立验证结果对比，而不仅是一个显示绿色的 HTTP 探针。

上午九点，验证器去 RPKI 仓库取下一份增量文件。通知文件里有引用，目标文件却没有。第一台验证器继续使用上一次成功抓取的缓存；第二台改下完整快照；第三台等随机退避结束，再尝试 rsync。三种动作都可能有合理的工程依据，但它们不会在同一分钟得到同一份“最新状态”。

这就是恢复路径成为路由控制面的原因。RPKI 常从签名对象讲起：资源持有者授权某个起源，依赖方验证，路由器再应用源验证策略。实际链条更长。签名意图要离开发证机构，经过发布服务，通过仓库传输抵达验证器，经过 manifest、证书和撤销检查，最后才形成可交付给路由器的验证载荷。签名没有坏，运输环节仍然可以改变后续策略看见的证据。

从增量到快照，再到备用通道

RFC 8182 为 RRDP 定义了三块关键材料：通知文件标识仓库会话和序列号，delta 传递增量变化，snapshot 提供完整的当前视图。若本地序列与远端之间存在连续的 delta 链，验证器可以沿着小而便宜的路径更新；链条缺失或被拒绝时，就要转向完整快照。

两条路径的成本并不对称。增量可能很小，快照却可能达到数十乃至数百 MB。2026 年 5 月最新版的 SIDROPS 发布服务工作组草案 写明了一条级联路径：一个或多个 delta 抓取失败后，依赖方通常会尝试更大的快照；快照再失败，就可能回退到 rsync；下一轮重新尝试 RRDP 时，往往仍从快照开始。于是，服务越拥塞，恢复动作反而越重。分布式系统偶尔也很会写黑色幽默。

这仍是一份进行中的工作组草案，并非 RFC，使用其中数字时必须保留范围。草案给出一个 2024 年 1 月的大型仓库样本：通知文件包含覆盖 14 小时的 144 份 delta，通知流量为 251 GB，而总流量为 55.5 TB，占比不足 0.5%。多保留一些 delta，可以让落后的验证器增量追赶；代价是所有验证器都要读取更长的通知文件。少保留则节省常态字节，却把更多落后客户端推向快照。草案还记录，一些依赖方实例在 2024 年每一到两小时才同步一次，因此建议至少保留四小时 delta。这不是一个免费的参数，只是在选择让谁、在什么时候支付带宽。

验证器本身又加了一层政策。当前 Routinator 文档 为 RRDP 失败后的 rsync 回退公开了三种策略：never、stale 和 new。文档默认值是 stale：只要本地 RRDP 副本仍被视为当前，就继续使用；超过为各仓库随机选择的时间后才尝试 rsync。默认最大回退时间为 3,600 秒，并在刷新周期与该上限之间做随机化，目的是避免所有验证器同时挤向备用入口。

同一份文档还列出会改变恢复路径的默认阈值：需要超过 100 份 delta 时改用快照；通知列出超过 500 份 delta 时把列表视为空；RRDP 资源总抓取可用 600 秒，读操作默认 10 秒，rsync 命令默认 300 秒。这些是某一产品当前版本的默认值，不是 RPKI 的自然常数。运营商一旦改动，同一场仓库故障就会变成不同的请求序列与缓存决策。

缓存本身就是证据链的一环

RFC 9286 规定了 failed fetch 之后的基本方向：在后续成功抓取解决问题前，依赖方应使用上一次成功抓取得到的缓存。这能避免把一个不完整的仓库视图直接解释成路由意图改变，也意味着“端点现在是否可达”不能单独代表路由器最终看到的证据有多新。

manifest 为这种连续性划定边界。它列出签发者打算发布的对象，帮助验证器发现删除、替换或压制。它能揭示本地视图不完整或过期，却不能修复缺失对象。thisUpdate、nextUpdate、CRL 与对象有效期共同把缓存复用限制在一个有限窗口内。

2026 年的发布服务草案把取舍说得很清楚：manifest 和 CRL 有效期越长，运营团队处理突发故障的时间越多，但重放窗口也越长；有效期越短，重放暴露收窄，重复签发和分发的负荷上升。草案记录，某大型仓库把重签周期从 24 小时改为 48 小时后，数据用量约下降一半，因为大部分变化是 manifest 与 CRL 的重签，而不是新增 ROA 或 ASPA。这个约 50% 只属于该样本，不能被写成全网换算公式，却足以显示权力关系：CA 设定节奏，仓库和所有依赖方承担处理成本。

标准仍在补齐恢复边界。2026 年 5 月发布的 RFC 9981 处理 manifest 序号达到上限的极端情况。文档记录，在新规则之前，有些实现要等当前 manifest 过期才接受新的，有些则会无限期拒绝。正常计数几乎不可能触顶，更实际的原因是错误配置或软件缺陷。这个案例的价值不在发生频率，而在它直接证明：当恢复语义没有写清，不同实现可能对同一仓库给出实质不同的可用结果。

容量与安全不会朝同一方向改善

回退到 rsync 可能提高可达性，却削弱传输边界。RRDP 通过 HTTPS 分发可缓存的不可变增量和快照；rsync 每条连接需要服务器做更多工作，也不自带通道机密性与完整性。Routinator 威胁模型 明确指出，路径上的攻击者可以阻断或降速，并把传输从 RRDP 降级到 rsync；此时签名对象和 manifest 检查要承担更多防御责任。

NLnet Labs 在 2020 年解释早期回退策略时做过一个面向未来的模型：15 万个验证器每十分钟轮询一次，约等于每秒 250 个请求，而当时备用 rsync 服务日常可能只处理每秒约三个。那不是 2026 年遥测数据，不能冒充现状；它说明了为什么“立刻全部回退”会制造惊群，也解释了今天为什么需要随机化。

一个明确标注为敏感性分析的算例即可看出杠杆：假设一万个验证器平时各取 1 MB 增量，完整压缩快照为 100 MB。全部走增量，一轮约 10 GB；若仅 20% 被迫改下快照，就变成约 208 GB——八千份 1 MB 增量，加两千份 100 MB 快照。重试与 rsync 的服务器计算成本还没有算进去。决定峰值的，不只是验证器数量，还有恢复请求被挤在多窄的时间窗里。

因此，仓库即使“在线”，也可能提供一件坏掉的恢复产品。负载均衡器可能先让某个后端暴露通知文件，而被引用的快照或 delta 尚未抵达其他后端；故障切换期间，一条旧 keepalive 连接可能返回较早的会话。最新 SIDROPS 草案要求多个后端保持一致视图，并指出 RFC 8182 没有为序列号倒退规定唯一行为，一些实现会改取快照。HTTP 探针看到的是 200，验证器看到的是一条断裂的时间线。

现有来源没有给出全网验证结果分歧率，也没有证明任何具名仓库导致过路由事故。它们证明的是机制、可配置选择和成本转移。这已经足以构造一次可复现的演练。