摘要

  • RFC 3511 把预期负载、实际提供负载、转发率、包长、发送与转发数量、规则、NAT、缓存和认证放在同一测试记录里；延迟只能在最高零丢包吞吐点上解释。
  • RFC 9411 在 2023 年取代该方法，为现代内联安全设备加入安全有效性配置、应用流量、TLS/QUIC、持续阶段与失败阈值。两份文档都没有把实验室数字变成生产安全证明。

数字没有造假。测试仪确实发送了流量，设备也确实在那一轮没有丢包。问题发生在数字离开实验室之后：包长被删除，方向被删除，规则被删除，提供负载与持续时间也被删除。

最后留下的“零丢包”看起来比原始事实更简洁，也更强。它不再回答一次实验发生了什么，而开始暗示设备在任何条件下都不会丢包。

RFC 3511 于 2003 年 4 月以信息类 RFC 发布，定义防火墙转发、连接、延迟与过滤测试。RFC 9411 于 2023 年 3 月明确使它过时，因为现代设备承担的安全与应用层工作已经改变。方法变化本身就是指标来源的一部分。

吞吐量不是一个孤立数值

RFC 3511 的 IP 吞吐量表格同时保留包长、预期速率、实际提供速率、最终吞吐与转发率。它还记录发送包数和转发包数。

这些字段不是为了让报告显得完整。64 字节包与大包消耗的每包处理、总线和队列资源不同；单向与双向流量可能走过不同状态；多个网段的聚合吞吐不能冒充任一网段的单独能力。

如果只保存最高值，读者无法知道设备处理的是每秒更多决策还是更大的有效载荷，也无法重放同一个负载。小数点后的精度保住了格式，却没有保住被测对象。

“零丢包”属于一个测试点

RFC 3511 继承的吞吐定义要求寻找无丢包的最高提供负载。它又规定，只有在该吞吐点测得的值才能合法称为延迟。

因此“零丢包”有明确分母：多少包、什么包长、什么负载、哪条路径、何种规则、持续多久。它不是设备永久属性，也不是故障免疫证书。

把负载提高一点、改变流量混合、填满状态表或打开检查功能，都可能得到另一个结果。新的结果并不推翻旧结果；它回答另一个问题。

严谨的系统应显示“在这一坐标上通过”，而不是把坐标压缩成绿色徽章。

规则决定每个包要做多少工作

RFC 3511 把规则集定义为允许或拒绝流量的访问控制策略。它建议未定义流量默认拒绝，并要求报告保留配置的规则。

规则数量、排列和命中分布会改变处理路径。第一个条目就拒绝的包，与经过多次匹配、建立状态、记录日志并进入应用检查的流量不是同一负载。

如果实验采用最小规则，而生产采用复杂策略，硬件名称相同也不能让两个路径相等。需要保存规则导出、哈希、命中统计与默认动作，才能说明零丢包发生在什么政策之下。

NAT、缓存与认证改变边界

NAT 会增加地址翻译与状态工作。RFC 3511 建议分别在启用和禁用时测试，并强制报告其状态。

缓存可能直接从内部内存返回 HTTP 对象，省去源服务器路径。认证可能依赖外部服务，带来网络与处理延迟。两者都能让“防火墙性能”包含或排除别人的工作。

记录必须区分缓存命中与回源、本地与外部认证、依赖服务的响应、NAT 类型与表压力。否则系统边界会随着汇报需要移动。

连接数字拥有自己的分母

RFC 3511 分开测试并发 TCP 连接容量、最大连接建立率和最大关闭率。一个大状态表不能证明设备快速接纳新连接；快速建立也不能证明资源及时释放。

HTTP 传输又增加对象大小、每连接请求数、完整请求与响应、超时、重传和 goodput。链路上有字节不等于应用事务完成。

如果失败、RST 与未完成关闭不进入分母，丢弃工作反而可能提高指标。完整收据必须保存连接从建立、承载、关闭到状态回收的时间线。

快速放行不是安全有效

RFC 3511 包含拒绝非法流量与受拒绝服务负载影响的测试，但它的安全考虑明确声明：防火墙安全评估不在文档范围内。

非法流量测试必须报告本应禁止却被允许的连接数量与比例。缺少这个字段，全部放行可以看成最高性能。DoS 测试只测一种规定负载对特定连接或传输率的影响，不能代表所有攻击。

策略执行、检测覆盖、误报、漏报、性能与应用结果需要分别留证。性能数字不会自动继承安全结论。

RFC 9411 先定义现代安全对象

现代 NGFW 与 NGIPS 可能执行 TLS 检查、IDS/IPS、反恶意软件、应用识别、日志与深度包检查。RFC 9411 先固定安全有效性配置，再进入性能测试。

推荐功能应启用并在整个套件中保持一致；不启用的功能及其可能影响必须说明。适用时还应使用现实数量的 ACL。

实验环境必须隔离，并在没有 DUT/SUT 时先做参考测试。交换机、路由器、虚拟交换、物理链路、其他工作负载或热降频都不能偷偷成为设备限制。

加密流量把更多条件写进结果

RFC 9411 要求公开应用与七层协议、加密比例、方向和对象大小。HTTP/1.1、HTTP/2、HTTP/3、TCP 与 QUIC 的处理并不相同。

HTTPS 基线使用 TLS 1.2 或更高版本，做完整握手，并关闭会话复用；QUIC 基线关闭 0-RTT 与 early data。这是为了形成可复现的负载，并不意味着真实浏览器总按此运行。

TLS 版本、cipher、密钥大小、record 大小、证书、SNI、ALPN、恢复策略与是否检查都属于坐标。删除它们之后，“HTTPS 吞吐量”已经没有稳定比较对象。

持续阶段决定结果能否成立

RFC 9411 区分初始化、升载、持续与降载。升载阶段不计 KPI；持续阶段才观察可维持的检查吞吐。

应用事务失败与异常 TCP RST 必须低于规定验证门槛；使用 HTTP/3 时还要观察意外错误导致的 QUIC 失败。一次成功事务必须传完全部数据并获得有效状态。

时间序列能看到状态表填充、检查队列增长、缓存变化与热限制。短暂峰值在持续窗口中失效，就不能冒充可持续能力。

过时意味着比较合同改变

RFC 9411 没有抹去依据 RFC 3511 生成的历史数据。只要原配置与上下文存在，旧结果仍能回答旧问题。

但它不能直接与加入安全有效性、应用混合、TLS、QUIC 和新验证规则的结果连成同一趋势线。方法版本之间必须标明断点。

如果图表把合同变化解释成产品进步或退步，它展示的是编辑行为，而不是运行代码。

证据边界

本文不点名厂商、产品、版本、实验室、客户或部署，不提供任何实际吞吐分数、漏洞测试、市场排名、攻击结果或事故结论。

RFC 3511 被准确描述为 2003 年 4 月的信息类方法，并已由 RFC 9411 取代。RFC 9411 是 2023 年 3 月的信息类方法，不是认证或生产保证。其 0.001% 等验证门槛不是通用安全失败容忍率。

Heng Lu 的最小初始规范与运行代码优先原则是公开的编辑框架：共享层只保留可比较收据，生产映射由本地负责人承担。它们不是防火墙测量数据。

结论很窄：零丢包可以完全真实，但一旦测试坐标消失，它就不再是可用证据。

Sources