摘要

  • Starla所查源码的工作区包版本为0.8.0，共享固件兼容值为5120，测量结果使用mver=2.6.4。这一组结果版本值不能唯一标识实际执行程序。
  • 注册代码已经明确发送Starla名称和编译时的包版本；本篇不声称实现身份在所有界面都不可见，也没有发现任何错误测量或线上事故。
  • 复核跨时间的测量，需要把兼容声明、实际部署构建、执行方法、采集遗漏和独立符合性试验分开。原有结果应当保留，未知的历史不能靠版本号补成已知。

5120可以帮助一个结果被按熟悉的格式理解，却不能独自回答另一个问题：究竟是哪一段程序完成了这次测量？

这不是对RIPE Atlas整个系统的缺失判决，而是Starla公开源码里一个可以具体定位的边界。我们固定检查了2026年9月7日的提交82bf0d9c42883bfe4d8a20d4ee444e7a0f8b55f1：Cargo工作区声明的包版本是0.8.0，共享固件常量是5120，结果格式化路径把mver填为2.6.4。同一份源码里，项目版本和兼容版本属于不同的命名体系，并不互相替代。工作区版本声明，结果格式化代码。

一个研究者若要比较更新前后的细小延迟差异，仅凭结果中的版本值没变，便假定测量程序也没变，这个推理就少了一项证据。程序可能完全等效，也可能存在与研究问题有关的差异；这份源码检查没有裁定任何一种实际结果。它说明的是，不能把兼容性声明当成实际执行程序的唯一身份证明。

开源替代实现的价值，不在于假装没有差别

开发者在2026年4月9日的RIPE NCC论坛帖子中，把Starla介绍为用Rust重写的RIPE Atlas Software Probe，并称它可以直接替代原程序。这是开发者的兼容性主张，不是本研究完成的独立验证。我们没有安装探针、发送测试测量或比较两种实现的发包行为。开发者介绍。

替代实现有正面的制度价值。一个测量服务不必永远等同于一份代码；贡献者也不必只能在原实现支持的环境里参与。保留熟悉的协议和结果格式，可以减少使用者迁移工具的成本。公开代码还让外部读者能够检查一项声明究竟如何落实，而不是只能接受产品介绍。

但“能够兼容”与“就是同一个测量仪器”并不是同义词。即便结果中的字段、数值类型和超时标记都让旧工具顺利读取，执行这些步骤的代码仍有自己的依赖、修正和构建历史。这些差别未必影响某一个研究结论，是否影响也需要证据；不能仅因两个程序选用了同一组兼容数字，就认定差别根本不存在。

Starla的共享定义把两类版本明确分开。FIRMWARE_VERSION设为5120，另一个版本字符串从CARGO_PKG_VERSION取得。固件常量旁的开发者注释，把匹配参考探针版本解释为控制器接受它的条件。注释能说明开发者选择这个值的理由，不能替代对当前控制器规则的独立试验。共享版本定义。

这里尤其不能把源码里的0.8.0写成线上探针的版本分布。一个工作区版本声明，不证明哪一个发布包已经交付，更不证明哪些主机装了它。源代码提交、分发包、实际二进制和正在运行的进程，是需要分别对应的材料。文章发现的是声明之间的关系，不是已部署群体的规模。

先承认已有的版本机制

RIPE Atlas并非完全没有测量代码版本。官方结果文档说明，fw标识探针固件版本，mver标识测量代码版本；后者的主版本变化意味着结果不兼容，次版本变化可以加入新字段而仍让旧解析器读取，修订版本变化则可表示代码修改而输出格式不变。这比单纯标注“某一种JSON格式”更丰富，不能把它说成空白。官方结果版本文档。

问题在于这种数字仍需要一个命名范围。同一条代码谱系按自己的规则编号，使用者可以依此追踪变化；另一种实现若为了兼容也采用相同数值，数值本身就不再足以区分两条谱系。Starla结果格式化路径中的2.6.4，不是该工作区声明的0.8.0。它们同时出现，恰好说明不同声明各有所指。

因此，解析者和研究者可能从同一个结果得到不同程度的满足。解析者需要知道怎样读出字段；研究者若要把变化归因于网络，则还需要知道观察工具是否维持了与论点相关的连续性。能解码，只解决第一件事。后者需要实际程序身份和方法证据，不能由一个熟悉的版本值自动提供。

这也不意味着每次日常连通性检查都必须核对二进制。要求应当随用途变化。判断某个目的地在某段时间是否有回应，与解释几毫秒的变化来自网络而非仪器，所需证据并不相同。把门槛无限抬高会损害贡献；把所有用途都降到“字段能读”又会制造不应有的确信。

注册已经写出名字，但名字还需要时间范围

对Starla最重要的一项反证，也在它自己的代码里。注册消息的环境字符串包含操作系统、系统版本、架构、starla和编译时包版本。实现不是从所有发往服务端的信息中消失了；注册这一界面已经明确命名它。注册身份构造。

本篇没有审计RIPE NCC全部内部记录、结果加工步骤或公开探针元数据，因而不声称注册身份没有被保存，也不声称所有读者都无法识别Starla。尚未建立的是一个更窄的联系：针对一条历史结果，某个使用者可取得哪些资料，证明它生成时适用哪个实现声明和哪个实际构建。

这个联系必须有日期。主机可以更新程序而保留探针身份；今天的描述也可以完全正确，却只描述今天运行的版本。若研究者打开的是几个月前的一段数据，当前状态不能自动回填过去。包版本同样不能唯一确认二进制，因为构建选项、依赖和分发过程还可能不同。

比一个可变的当前标签更有用的，是分段的生产者历史：哪项声明从什么时候开始适用，什么时候被下一项替代，哪些结果属于这一时段，实际构建是否已知，以及对应材料是自报、留存记录还是经过验证。没有资料的区间应保持未知，而不是从5120和2.6.4推导出一个默认的程序身份。

在这种安排中，服务身份与仪器身份也要分开。认证可以回答“这是哪一个获准连接的探针”，不能独自证明它实际运行哪份二进制，更不能证明该二进制与别的实现测量等效。相反，知道一个构建的身份，也不自动说明服务端接受了哪个声明。这些联系都可有价值，但价值来自各自的证据，而不是名称看起来一致。

库里的选择，不等于普通任务用了那条路径

Starla的ping代码包含Native和Scamper两种执行选择，后者限于Linux。分支执行后，返回的测量仍填入同一共享固件值。traceroute也有两种后端路径，其完整结果行使用同一固件常量和mver=2.6.4。从这些输出构造代码看，这组版本数字不是执行后端的标识。ping实现，traceroute实现。

但继续追到调度器，限制就出现了。固定版本把普通ping和traceroute任务转换成可执行测量时，后端都写为Default::default()；默认选择是Native。不能因为库里有Scamper，就宣称普通控制器任务可以在这条已查路径上选择它，或已经有公开测量使用它。普通任务转换。

这一限制没有消除方法身份的必要性，反而说明为何应当记录实际执行，而不是照抄功能目录。代码仓库可以包含未被某条任务路径使用的能力；一张“支持哪些功能”的表，不是一次测量“用了哪些功能”的记录。两种路径是否输出不同，也需要另行比较，本研究没有做过这样的试验。

即使补齐二进制摘要，独立符合性证据仍不能省略。摘要确认的是某个文件，不是其计时、包构造或错误处理与另一个文件等效。一个合格的比较应说明测试哪个构建、哪些方法、什么条件和哪些例外。程序身份是试验的对象，不是试验已经通过的证明。

数据抵达之前，还经过一次选择

实际程序还有一个容易被成功结果遮住的作用：它决定某些已生成观察能否留到上传时。

Starla的有界内存队列在容量满时，先从前端移除最旧结果，再接收新结果。失败上传的回填顺序不同：旧工作被放回前端，超出容量时从后端删减。因此，把全部丢弃路径概括成“永远优先丢最旧数据”是不准确的。处理器另有按年龄和重试次数清理的逻辑。队列与回填顺序。

处理器的默认队列上限为10,000条，结果最大年龄为3,600秒，还设有重试和周期清理参数。这些是源码默认值，不是经核实的运行配置；清理分支的存在，也不证明任何一次线上丢失已经发生。处理器默认值和清理。

限制内存和陈旧工作的占用并不难辩护。贡献测量的主机没有义务在上传受阻时提供无限空间；无限重试也可能让旧工作持续挤压新观察。但分析者收到的序列，可能是成功保存和送达的样本，而不是所有已尝试测量的清单。边界应当被说明，而不是被误解成所有结果必然完整。

假如某段序列出现空缺，目的地无回应、任务没有执行、传输受阻、当地保留策略，都可能需要调查。没有尝试清单和安全的遗漏计数，就不能从一个空缺直接挑出其中一项。尤其不能拿源码默认值当作真实损失的诊断。已知一个实现如何可能处理拥塞，与知道某次空缺为什么出现，是两回事。

所以，生产者身份与采集完整性既有关联，也不可合并。知道当时运行什么程序，可以帮助解释采集规则；知道程序身份，却仍不保证全部尝试都已抵达。把二者分开，研究者才能明确哪些变化在方法上有证据，哪些样本选择仍然未知。

保留旧结果，而不是替它制造新身份

合理的第一步应是附加信息。原有结果、原有字段和原有版本值都保留；有证据的历史关联可以旁挂，没有证据的区间不能默认为参考实现，也不能默认为Starla。缺少来源材料，不等于已有测量虚假，更不能成为删除、隐藏或拒绝整段历史的理由。

这让使用者可以按问题作选择。只需观察基本可达性时，未知构建可能不影响用途；需要把微小差异归因于网络调整时，就应寻找方法历史、分组比较或受控试验。较强的结论需要较强的联系，而不是要求所有数据一开始就承担最严苛的用途。

Starla的代码公开了可以讨论的细节，注册也已经写出身份，Atlas既有的版本字段同样有用。公平的分析应同时保留这些事实。本文要求澄清的不是“这个替代实现是否应存在”，而是“某项研究假定的仪器连续性，究竟由哪项材料支持”。版本值熟悉，不能代替这个答案。

把符合性试验与部署证明分开

如果使用者确实需要比较两种实现，可以先把问题收窄到与结论有关的测量方法，而不是笼统问“是否完全相同”。例如，试验应说明哪些输入、超时条件、错误返回和计时行为被比较，测试对象是哪一个构建，运行环境如何保持可比。这里只是在说明一个可复核的试验应包含什么，不是在声称已有试验遗漏这些项目，更不是本研究已经发现某种行为差异。

试验报告与历史结果之间，还需要另一段联系。一个构建在受控条件下表现符合预期，不证明某台主机当时就运行它；某台主机记录了安装包，也不证明研究需要的每一种行为都曾被测试。前者回答方法在何种范围内可比，后者回答测量是否属于被比较的对象。把两个问题混在一起，认证消息、包版本和测试结论就容易互相借用不属于自己的证明力。

这种分离允许采用适度证据，而不要求把整个测量服务重新认证一遍。使用者可以声明自己的比较只适用于某个方法、某段部署时间和已知构建；对未知区间另列限制。即使试验通过，也保留原结果与原声明，不替历史补上无法证实的运行身份。可复核的结论来自范围清楚的证据，而不是“兼容”二字带来的全面保证。

资料来源

上述链接包括固定在9月7日提交上的九个Starla源文件、开发者4月的论坛介绍，以及2026年9月14日获取的Atlas官方结果版本文档。本研究没有安装、注册或执行探针，没有创建付费测量，也没有独立验证符合性、部署规模或数据损失。代码说明的是所查实现路径，实际运行与历史资料可得性仍须分别核实。