摘要

  • RIPEstat 2026 年第三季度计划把 Routing History 列为下一项高价值可视化重建工作，并明确将长期维护与启用 Content Security Policy 作为理由。
  • 公共 Data API 是界面的唯一数据源，但软行数上限、观测 peer 门槛、首跳选项、可见度归一化、查询时段与缺失值处理，都会影响同一响应最终呈现出的结论。
  • 最小补丁是一份版本化语义对照记录：固定测试响应，写明两版界面的参数与默认值、预期差异、边界样本、修订链和旧版退场条件。

九个 peer 与十个 peer 之间

假设一条前缀公告在某段时间被九个 RIS 全表 peer 看见，随后变成十一个。使用 Routing History 默认的十个 peer 门槛，折线可能从后一段才开始；降低门槛后，前一段也会出现。数据没有自相矛盾，路由也未必发生异常，画面却给出了两个不同的“开始时间”。

这正是界面迁移最容易被忽略的控制面。RIPE NCC 在 RIPEstat 2026 年第三季度计划中说，下一项要更新的可视化是 Routing History，因为它对内部与外部用户都很有价值。计划还称，旧可视化需要改用新技术并更新外观，以便长期维护，同时让 RIPEstat 能启用 Content Security Policy（CSP）。目前状态是“进行中”。

先承认改造的最好理由。老前端不必出故障，也会逐渐变成安全负担。脚本、样式和资源加载的旧假设，可能妨碍严格的浏览器策略。W3C 的 CSP Level 3 规范把 CSP 定义为控制页面可以获取或执行哪些资源，以及其他安全相关行为的机制；它还提供只报告模式，使团队能在强制执行前观察违规。清理妨碍这道纵深防线的依赖，是正常的工程责任，并不等于 RIPEstat 已遭入侵。

语义一致也不要求像素一致。提高色彩可辨识度、改善键盘顺序、重新设计窄屏摘要，都可能使新旧截图不同。RIPEstat 历年季度计划显示，团队过去已经完成过新旧 UI 功能对齐，引入自动化 UI 测试，谨慎发布过 widget 依赖升级，也监测过 RIS 数据处理迁移的影响。现有材料不能证明 RIPE NCC 没有内部回归测试。

但 CSP 验证与语义验证回答的不是同一个问题。前者确认新程序能在更严格的浏览器规则下运行，后者确认用户面对相同的路由观测时，不会因为阈值、排序或缺失值画法不同而作出另一项判断。一个没有 CSP 违规的页面，仍可能把同一时间线讲成另一段故事。

API 是锚点，不是自动生成的含义

RIPEstat 对权责边界写得很清楚。Data API 说明称，API 是 RIPEstat 的公共数据接口，也是 widget 和 UI 的唯一数据源；RIPEstat 入门页则把服务拆成两部分：API 提供数据并回答查询，UI 展示这些数据可以怎样可视化。

因此，API 响应是新旧视图对照的天然锚点。但响应并不会自行决定图表含义。当前 Routing History endpoint为 2.3 版，使用 RIS route collector 的数据，按 origin 和 prefix 返回公告时间段。几个参数尤其关键。

max_rows 默认是 3000，而且是软上限：到达上限时，已纳入 origin 的全部已记录路由仍会返回，但后续 origin 不再进入结果。若界面排序不同，被截掉的对象也可能不同。include_first_hop 会把首跳 ASN 加进 origin 表达，使一条来源线拆成多条组合线。normalise_visibility 计算看见该路由的全表 RIS peer 比例。min_peers 默认是 10，低于门槛的低可见度或局部公告会被排除。starttime 与 endtime 则决定时间窗口；没有显式结束时间时，终点随最新可用 BGP 数据移动。

返回值里还有一个不能被当作普通数值的状态。peer 信息缺失或不可靠时，归一化可见度可能是 -1。它不是零。在基线上画出它，会暗示已经测得“无人看见”；无标记地删掉，会暗示时间线连续；跨过去连线，又会创造一次不存在的观测。具体视觉方案可以改变，但“未知”必须始终与“零”分开。

观测范围也必须跟着图走。Routing History 文档明确说数据来自 RIS collector；相关的 Routing Status 文档多次使用“由 RIS 观测”这一限定，还说明某个 AS 可能拥有未被 RIS 看见的邻居。RIPEstat 图表是来自已知观测系统的高价值公共证据，却不是互联网全景。

时间新鲜度会制造另一种假差异。RIPEstat 说明，数据何时变得可见取决于采集频率、数据存储更新、处理延迟、故障与缓存。若两版界面分别查询正在变化的后端，两张截图不同并不能证明 UI 语义不同。对照测试需要冻结响应、记录抓取时间与哈希，并使用同一查询区间。实时查询仍要做，但它验证的是服务健康，不是两种显示的等价性。

一份小记录应当回答什么

无需成立新委员会，也无需永久养着两个 UI。RIPE NCC 可以在发布新视图时，为一组代表性样本附上一份版本化记录。

每个样本至少列出：旧版与新版 build；Routing History endpoint 及方法版本；查询资源；UTC 起止时间；显示时区；所有显式参数；最终采用的默认值；冻结响应的时间和哈希；两版界面的分组、排序、截断和缺失值规则。

测试样本不能只挑最整齐的一条线。它应包括单一 origin 前缀、多 origin 情形、足以触发软上限的响应、位于 peer 门槛两侧的时间段、开启首跳、peer 信息不可靠、末段仍开放，以及键盘与窄屏阅读。测试目标不是证明两张图长得一样，而是确认关键事实是否出现、消失、换组或移动了时间边界。

预期差异应被明确记录。为了无障碍而换色不是失败；为了降低误读而重排图例可能更好；把本地时间统一为 UTC 也可以成立，前提是界面、提示框和导出文件都说清楚。写下理由，还能防止后来的维护者以“恢复一致”为名把改进撤回。

记录最后需要责任人、未解决例外、复查日期、修订与替代链接，以及旧版退场规则。旧代码不该等到每个装饰细节都相同才退休。真正的边界是：所有会改变决策的差异已经关闭或被明确接受，无障碍场景通过，新视图能依据保存的请求重现自己的读法。

证据没有证明什么

现有来源没有证明当前 Routing History 显示错误，也没有证明新版已经上线或发生失败；没有证据表明 CSP 会改变路由数据、存在可利用漏洞、RIPE NCC 丢失了观测，或团队缺少内部测试。季度计划是工作计划，不是交付报告；公共 API 文档也不是完整的内部质量清单。

所以，这是一项面向未来的建议。其价值在于保留三层区别：RIS 提供有边界的观测，API 以公开契约返回数据，特定 UI build 决定人眼最先看到什么。安全加固因此可以快速推进，而语义连续性不必依靠口头保证。

来源