摘要

  • 2026年的同行评审研究估算，与重建出的RPKI事件相关的UPDATE不足观测到的BGP UPDATE总量的1%。
  • 研究把收敛窗口中的所有更新都计为关联消息，因此估算分子可能偏大。
  • 这个比例不衡量每个邻居的处理负载、路径变化、Route Refresh或用户可达性。

先问清楚，这个比例在数什么

这项结果值得认真看待。Samuele Quinzi、Cristel Pelsser和Giuseppe Di Battista在《Proceedings of the ACM on Networking》发表同行评审研究，估算ROA变化事件前后观测到的BGP UPDATE量。论文摘要报告，即使RPKI部署和路由表都在扩大，相关更新仍不到观测总量的1%。它回答的是一个具体问题：在这组观测里，RPKI事件是否主导了路由消息流？答案是否定的。

Quinzi在APNIC Blog的客座文章介绍了方法：研究者用历史RPKI资料重建事件，再把选定收敛窗口中的所有UPDATE都算作相关更新。窗口内的一些消息可能来自其他原因，全部计入会扩大分子。因此，这个比例表示按宽窗口归因的时间关联消息量，并不证明每一条UPDATE都由RPKI触发。

网络稳定性有不同的度量单位

分子是关联事件的UPDATE，分母是全部观测UPDATE。它不是受影响路由器的比例、验证状态改变的前缀比例、最佳路径变化的比例，也不是用户流量中断的比例。UPDATE承载路由信息，但不能直接说明应用是否仍然可达。

RIPE RIS通过BGP对等会话收集路由信息。其RRC00采集器位于阿姆斯特丹，采用多跳连接，文档标注为全球范围。这里的“全球”描述采集范围，并不意味着测量了每条转发路径、每台路由器的CPU工作量或每位用户的连接体验。总体比例也没有说明消息是否集中在少数邻居。

反过来说，UPDATE很多也不能证明用户失去服务。消息量、邻居处理负载、路径选择变化、收敛时间和数据平面可达性有关联，但不是可以互相替换的指标。

Route Refresh是另一类负载

RFC 9324记录了另一个与RPKI有关的机制：收到新的验证数据后，一些实现曾向邻居请求Route Refresh，以重新评估路由。RFC指出这可能把显著的资源负担转给邻居，并建议保留相关路由来避免不必要的刷新请求。文中还记载了关闭ROV和解除对等连接的部署案例。

这说明的是一种具体风险及缓解办法，并非所有实现都会如此，也没有推翻研究中的UPDATE比例。Route Refresh请求及其后续路由重发，与事件窗口里的UPDATE计数是不同的观测对象，应分别测量。

扩大证据范围，但不要混用指标

更完整的回答不需要用一个标题数字替代另一个。可以分别公布按事件和邻居统计的UPDATE、Route Refresh请求和重发路由量、路由状态稳定所需时间、路径变化的频次与持续时间，以及可能获得的独立可达性信号。每项指标都应注明观测点、时段、分母和缺失数据处理。

RIPE历史RPKI Archive采用每日快照。APNIC文章提醒，短时变化可能发生在两次快照之间。RPKI-Flutter以更高频率记录较近时期的事件；文章称两种方法在重叠时段估出的UPDATE量相近。这为被比较的消息量提供交叉校验，却不能自动证明邻居负载或用户体验。

公平的结论既不是“RPKI没有风险”，也不是“RPKI会让BGP不稳定”。研究削弱的是一个更窄的担忧：在所观测序列中，RPKI事件并没有占据UPDATE总量的大头。这是有用的安心证据。要谈更广义的稳定性，必须先说明要保护哪项资源、路径或服务。

来源

主要来源与协议文件：