摘要

  • 同一型号的安全测试报告与性能报告，不一定证明相应保护能力和处理速度在同一种配置下同时成立。
  • RFC 9411 要求性能测试保持受测配置一致，其安全效果评估附录还把测试环境与配置联系起来；允许的功能缺省也必须交代原因及性能影响。
  • 当配置、工作负载或运行环境发生相关变化时，需要重新判断旧成绩适用于什么，而不是把型号旁的吞吐量当成永久属性。

续购时，上一行表格还算数吗

续购同一型号，常常意味着不必从头认识一个产品。但不必从头认识产品，与不必重新理解证据，是两回事。

设想一个未指向任何真实企业的场景：上次采购时，比较表记录了某设备的阻断表现与吞吐量；这次增购，团队沿用已经获批的那一行，却准备让设备承担更多检查。数字没有改，型号没有改，审批者甚至可能因此更放心。真正变化的，是新系统要做的工作。

此时应追问的不是旧表有没有填错，而是那两列当初如何连在一起。保护表现与处理速度来自什么配置？现在增加的工作，当时是否属于受测范围？一份材料被批准使用过，只能说明组织作出过一次判断，不能独自证明它适用于后来扩大的用途。

这也不是主张每次续购都把旧证据作废。本文没有进行产品测试，没有调查出某家厂商降低安全设置，也没有给任何具体采购作出结论。它关心的是，如何保留旧结果的价值，同时让新决策承担的新前提留在明处。型号相同可以减少认识成本，却不能替代配置之间的核对。

方法文件把连接写在了哪里

RFC 9411 于 2023 年 3 月发布，是 IETF 的信息类文件，取代 RFC 3511，但并非互联网标准轨规范。它讨论新一代网络安全设备的性能基准方法，不是某个型号的安全认证。

文件第 4.2 节要求，第 7 节各项性能测试使用相同的受测设备或系统配置。配置中的参数与安全功能应对应实际或典型部署，设备以内联方式主动检查流量，选定的保护功能在各项测试中保持一致。测试结果还必须附带配置概述，包括已经启用的功能。

受测条件还包括关闭故障时不经检查便放行流量的行为，并启用日志与报告功能。文件为日志粒度等设计差异保留了说明空间。因此，“设备开着”与“按什么条件履行检查任务”并不是同一层信息。

这条约束解决的不只是复现实验的方便程度。同一设备承担的检查工作变了，成绩所能支持的判断也可能随之改变。外壳相同、许可证名称相同，甚至功能开关都被概括成“安全已启用”，仍然可能不足以说明实际工作相同。

更关键的连接出现在附录 A。安全效果评估与性能基准测试要使用同一测试环境，受测配置也要相同。客户端和服务器的地址范围、加密测试所涉及的密码配置等，还提供了进一步的比较条件。文件试图让“检查是否有效”和“在这些条件下能处理多少工作”保持可识别的联系。

这不意味着所有客户必须使用一套永久不变的配置。它意味着，成绩应当跟着取得成绩时的条件走，而不能仅仅跟着产品名称走。

功能可以不启用，解释不能被省去

把配置一致理解成“所有功能全部打开”，同样会误读文件。RFC 9411 区分推荐功能与可选功能，也承认具体部署可能没有在这个位置启用某项推荐功能的需要。

这种例外不必然是不当优化。例如，某种部署方案可能确实不需要在该设备上承担某项检查。对这样的方案，一份明确说明缺省功能的性能结果仍然可能有用。

但文件要求说明未启用推荐功能的原因，并注明该缺省可能影响性能。这里存在两道不同的判断：测试方交代了什么，采购方是否接受那样的工作范围。前者完成，并不会自动替后者作出决定。

如果买方计划运行的配置恰好符合所披露的范围，报告可能与需求相符。如果买方准备增加被省去的功能，则需要判断原有成绩是否仍能回答新的问题。不能因为例外是透明的，就认为它对比较没有影响；也不能因为存在例外，就认定报告不诚实。

最容易丢失的是这层有条件的适用关系。摘要为了便于决策而简洁，本来有价值。但如果简洁意味着把“在这些功能条件下”删掉，简化后的材料就可能从结果说明变成没有依据的组合承诺。

安全效果不是一个附赠标签

RFC 9411 主要关注性能，但建议先通过安全效果评估验证功能配置。如果没有进行这项评估，报告必须说明其影响。因此，一份材料引用了该 RFC，并不意味着它必然包含完整的安全效果验证。

附录 A 观察的也不只是阻断数量。未被阻断的漏洞、背景流量的表现，以及设备报告是否准确，都属于所记录的结果。背景流量的验证条件包括不得出现误报。这样，保护功能对正常工作的影响才不会从讨论中消失。

这些条件仍然属于所选测试集合与测试环境。它们不能证明设备能阻止所有攻击，也不能推导出某个生产系统此后不会误报。本文不把实验方法扩展成无限的安全保证。

不过，对采购表中那一个“同时具备”的判断来说，范围有限的验证已经足够重要。买方需要知道，接受效果评估的是哪套配置，性能报告描述的又是哪套配置。如果两者的联系尚未建立，增加报告页数并不能代替补足这项联系。

反过来，确认配置相同，也不意味着其余问题都已经回答。所选攻击集合、业务流量与真正运行环境是否足够相关，仍然需要分别判断。配置一致是一项重要条件，不是包办所有适用性问题的万能结论。

方法不覆盖的功能，不能悄悄算进成绩

第 3 节还有一项明确边界：这套性能方法并不面向依靠机器学习或行为分析的系统；存在这些功能时，文件提出在应用该方法的测试中将其关闭。

这不是让运营者在生产网络中关闭这些保护。它限定的是测量所描述的系统。如果采购方案恰好依赖此类能力，那么报告中没有包含的工作，不能因为同属一个产品就被默认纳入性能结论。

把边界保留下来，也不等于否定报告。对它实际覆盖的功能，测量仍可能有用。需要另行判断的是，如何从这个受限的观察走到计划使用的组合，而不是让产品说明书中的功能清单替代这一步。

被测到的限制，未必来自安全设备

测试环境有自己的处理上限。流量发生器、外围交换与路由功能，或者虚拟化主机资源，都可能影响结果。如果环境先成为瓶颈，就不能轻易把观察到的限制归给安全设备。

RFC 9411 因而要求在性能基准之前做参考测试。参考测试可以去掉受测设备，或使用最简单的快速转发配置，检查发生器是否有足够余量、外围设备是否引入丢包和延迟，以及环境是否保持稳定。

这里有一个很具体的误用风险：为确认测试环境能力而得到的简单转发结果，不能被当成安全功能开启后的设备成绩。两次测试都可能正确，但它们回答的问题不同。参考测试的价值，是帮助解释后续结果应归因于谁。

对于虚拟化设备，主机资源分配尤其不能只被当成背景。其他工作负载、虚拟机迁移，以及高负荷发热导致的处理器降频，都可能改变测试条件。文件的环境稳定性讨论正是为了保留这些解释路径。

如果两次结果不同，首先应当识别配置和环境中哪些条件变了。主机资源变化不等于安全软件退化；保护策略变化也不会因为主机相同就自动失去影响。这种区分可能决定下一步应补哪项证据，避免把测试预算花在没有回答争议的问题上。

工作负载也会进入成绩的含义

设备并不是在处理一种抽象的“流量”。它处理的是特定连接、事务和对象，以及这些工作所触发的检查。端点协议参数、应用组合和加密流量设置，都会影响测试究竟要求设备做什么。

RFC 9411 把负载过程分为初始化、升载、持续、降载和收集阶段，测量发生在持续阶段。该阶段的建议最短时间为 300 秒，原始结果采集和统计计算的采样间隔必须小于两秒。这些是方法条件，不是客户应用在某次业务切换中的时限承诺。

报告还应按不同基准分别给出指标。受检查吞吐量对应已经检查并获准转发的流量；比较吞吐量时，测量所在的协议层也需要说明。精确到小数位的数字，不能补救没有交代清楚的工作范围。

因此，采购方不必把每项技术参数都搬上决策首页，但应当能够沿着首页的结论找到相应条件。如果只有数字被保留，而功能、负载和环境被当成可丢弃的附件，那么最需要再次核对的时候，比较的依据可能已经不在了。

RFC 6815 对隔离测试环境的说明提供了另一条边界：这类实验室方法不应直接搬到承载真实用户流量的共享生产网络上。缺少一项证据，不等于可以进行一次不受控制的线上压力试验。本文也没有提出这样的操作。

不需要制造一个不诚实的角色

这项分析没有识别产品赢家，没有测量开启某项功能会损失多少吞吐量，也没有统计采购者把不同配置报告混用的频率。它说明的是一个可以直接从方法中辨认的条件：安全表现和性能表现的结合，不能仅由型号替它们完成。

Lu Heng 关于现实而非倡导的文章，提供的是本文的编辑立场：把结构讲清楚，而不是寻找一个适合承担剧情的反派。他讨论代理问题的文章则提示另一个问题：谁有权作出选择，谁承担选择的后果。其关于注册管理机构的判断，不是针对安全设备厂商或测试人员的经验证据。

一份好的报告，可以使买方有条件进行判断，却不能免去判断本身。真正重要的交接，是有人明确说明：我们准备运行的系统，与这份成绩所描述的系统，在哪些方面相同，在哪些方面还存在需要承担的差异。