摘要

  • RFC 9971 描述 Multiple Loss Ratio Search（MLRsearch）：它在声明过的系统和流量条件下，针对一个或多个损失率目标搜索并报告相应边界。
  • 该结果是对试验过程的证据，包含系统边界、试验载荷与时长、流量配置、损失目标和精度；它不是生产容量、服务等级、应用体验或供应商履约的证明。
  • 可靠的做法是保留完整的基准记录，用真实生产范围的独立证据连接它，并让扩大结论的人明确承担批准和回退责任。

数字必须带着护照

RFC 9971 的目标是为网络数据平面建立更可重复、可比较的实验室基准方法，尤其考虑在通用 CPU 服务器上运行的软件网络功能。它不是寻找某台设备神秘而恒定的“真实吞吐量”。它定义了多损失率搜索：在若干载荷和持续时间的试验中，按照明确的 Search Goal 形成可报告的结果。

因此，结果不是一个裸露的速率。它必须说明：受刺激的是哪一个系统；发送了什么帧大小、方向和流量形状；每轮试验持续多久；目标是零丢失还是某个非零损失率；可接受的上下边界间隔是多少；哪些观察形成了这些边界。少了这些字段，读者无法比较两个数，也无法判断一个数究竟回答了什么问题。

RFC 9971 是 Informational RFC。它使用 BCP 14 的规范性措辞，是为了让声称符合 MLRsearch 的测试程序具有明确含义，并不是要求所有运营者采用该方法，更不是给任何产品发证。它还明确说明自己独立于 RFC 2544，既不修改也不废弃后者。某个单目标配置可以满足 RFC 2544 的条件，但那是由具体程序和报告证明的事实，不能由“用了 RFC 9971”这一标签替代。

被测系统不等于一段代码

RFC 9971 延续 DUT 和 SUT 的区分。DUT 是关心的转发设备或功能；SUT 是实际接收激励、实际输出响应的整体系统。对软件功能而言，SUT 可能包含主机、固件、操作系统、虚拟化层、网卡、I/O 路径和共享资源的其他负载。相同版本的程序处在不同的 SUT 中，得到不同的试验结果并不矛盾。

规范把难以可靠拆分的变化称作 noise。它既可能来自共享 CPU、调度、内存或 I/O 压力，也可能来自功能内部的波动。有限的帧试验不能逐一判定每次损失的最终原因。MLRsearch 的诚实之处在于承认这种不确定性，并用试验、目标和边界来记录它，而不是把变动伪装为一个不受环境影响的产品属性。

这也划定了证据权限。基准可以说明“这个声明过的 SUT，在这个流量配置下，得到这些边界”。它不能说明“这段软件在任何环境都有此能力”，更不能说明由路由变化、重试、存储依赖、客户行为和故障状态共同构成的生产服务将具有同样表现。

多个损失目标把价值判断放回原处

RFC 1242 将吞吐量定义为不丢失任何所提供帧时的最大速率。这一概念仍然重要。但在靠近极限的软件系统中，短暂波动可能造成稀有损失；更高载荷的一轮试验甚至可能出现更低的损失率。若只公布一个数字，外界无法知道是谁选择了时长、精度和如何处理不一致结果。

MLRsearch 将这些选择暴露出来。Manager 配置相关实体并输出 Test Report；Controller 选择试验载荷与时长；Measurer 执行试验。这是概念角色，并不要求购买三个独立系统。每个 Search Goal 有自己的条件；常规结果依赖 relevant lower bound 与 relevant upper bound 按照宣告的 goal width 收敛。

规范允许同时寻找多个损失目标，却没有宣布非零小损失在任何业务中都可接受。它指出不存在一个行业公认的最佳通用目标，且试验损失与高层性能的关系并不简单。对 TCP、实时会话、存储复制、支付交易或安全控制，相同损失比例的后果都可能不同。选择阈值是一项本地价值判断，应由承担后果的一方说明，而不是由测试工具代为决定。

可重复不等于代表真实世界

重复性有价值：在固定实验室配置中，它可以帮助团队发现小回归。但它也可能极其稳定地重复一个不代表生产的流量形状。RFC 9971 故意不规定 Controller 的内部选载启发式，也不规定普适的目标参数。这里不是可以用市场宣传填平的空白，而是必须由本地运营者保留、解释和审计的选择。

这正合乎 Heng Lu 所强调的 Running-Code Primacy。首要证据是实际运行的测试代码、配置、真实发送的流量和原始观察，不是基准名称的声望。最小初始规范与本地化未来决策则补上制度边界：共同方法让不同团队交换结果，却不把可接受损失、卖出的容量或上线风险的决定权转移给方法的制定者。

把测量和承诺之间的桥建出来

需要保留四份互不替代的记录。第一份是基准记录：软件构建、硬件与虚拟化范围、流量轮廓、帧大小、目标、时长、原始结果和工具版本。第二份是解释记录：结果只支持哪一个狭窄命题，例如某配置在实验室没有相对基线回归。第三份是生产证据：真实范围内的队列、CPU、I/O、重试、事务、错误预算和服务探针。第四份是决策记录：谁能批准发布、购买、容量预留或回退，条件是什么，例外多久失效。

基准可以成为采购输入，却不能替代验收负载和合同条件；可以成为容量计划输入，却不能替代峰值分布、故障余量和竞争负载的权利安排；可以支持发布评审，却不能替代兼容性、安全、渐进部署和回滚证据。一个 SLA 是关于定义好的服务和时段的承诺，不会因为曾经有一次帧试验表现良好而自动成立。

保守的下界也不是未来资源的预订。反过来，一次失利试验也不自动证明供应商违约或线上事故根因。两者都应触发可验证的假设，而非把实验室数字当作裁决。

来源