摘要

  • RFC 5180 的数值证明某台设备在一套声明过的实验室剖面下产生了某种表现，不能单独证明机框规模、混合流量、生产策略、故障域或用户体验。
  • Hop-by-Hop 测试最能显示边界：它以接口带宽的 1%、10%、50% 注入并观察资源，目标不是普通吞吐量。RFC 8200 后来又使“节点是否显式配置处理”成为当前报告不可缺失的条件。

董事会看到“RFC 5180、线速、零丢包”，常会把三项词汇合成一个决定：这台设备足以承接未来的 IPv6 容量。工程团队如果只补一句“实验室结果仅供参考”，仍没有解决问题。真正缺失的是控制权：谁选择了流量剖面，谁批准把接口结果外推到机框，谁证明被测版本与采购版本相同，谁负责验证生产路径。

RFC 5180 并没有授予任何人这种外推权。它在 2008 年以 Informational RFC 发布，补充 RFC 2544，并采用 RFC 1242 的术语。它要求考虑重复性、方差和少量试验的统计显著性。换句话说，标准提供共同测量语言，不提供跨现实层级的自动授权。

剖面选择是一项决策权

以太网测试列出 64、128、256、512、1024、1280 和 1518 字节。相同链路比特率下，小帧意味着每秒更多次查找、分类和转发决定；大帧更容易给出漂亮的 Gbit/s。只选 1518 字节，不一定造假，却会把“设备在大帧下的表现”改写成“设备容量”。只选 64 字节，也可能把极端包率误当作业务常态。

因此，审批材料应该保留完整曲线，并解释真实业务与曲线的对应关系。物理层假设也要留下：RFC 提醒以太网理论最大帧率存在正负 100 ppm 的时钟偏差；Packet over SONET 还可能受比特填充影响。图表显示到小数点后两位，不代表证据真的精确到两位。

地址分布同样由人选择。单一源目地址对可能持续命中温暖而狭窄的查找路径，随机目的地址会让设备执行不同工作。RFC 5180 要求先测试单一地址对，再用对应范围内的随机目的地址重复；/48、/64、/126、/128 是建议保留的关键边界。删掉这些字段，等于删掉产生数字的机器。

接口、平台与方向不能互相冒名

单端口测试衡量每接口转发性能，多端口测试才触及整个平台的可扩展性。不同端口可能共享交换结构、内存、查找资源或软件路径。把一个端口的值乘以端口数，是容量假设，不是实测事实。

方向也会隐藏约束。RFC 建议所有测试使用双向流量，但明确指出：双向结果只会暴露两个方向中较低的性能。若配置不对称，应增加单向测试作更细的刻画。入口过滤与出口处理不同、请求包与响应包大小不同，都会让相同总带宽执行两条不同路径。

IPv4 与 IPv6 的共存比例是另一项输入。方法包括 IPv4-only、IPv6-only，以及 90/10、50/50、10/90 的混合剖面。纯 IPv6 的优秀结果，不能证明共享缓存、查找与策略资源在真实混合负载下仍有同样余量。生产比例变化后，旧报告也不会自动更新。

Hop-by-Hop 不是吞吐量柱状图

RFC 5180 建议逐一测试扩展头，再测试至少两个扩展头组成的链。比较带扩展头与不带扩展头的小帧时，应使用共同的最小帧长，否则差异可能是测试尺寸制造的，而非协议处理造成的。

Hop-by-Hop 的目标更明确地改变了。测试以接口总带宽的 1%、10%、50% 提供这类流量，同时监控设备资源。它不是普通吞吐量试验，而是处理影响试验。CPU、内存等数据必须带外采集，不能依赖承载测试流量的接口管理数据。只有这样，团队才有机会区分硬件转发、转发引擎再循环、软件慢路径或控制面压力。

但是，2008 年的文字必须放回时间轴。RFC 5180 依据的是 RFC 2460 模型；RFC 8200 后来说明，路径上的节点只有在显式配置时才预期检查处理 Hop-by-Hop。RFC 7045 已经承认高性能路由器可能忽略它或交给慢路径；RFC 9098 又分析了查找深度、再循环、软件转发与丢弃的现实限制。

所以，今天的报告不能只写“按 RFC 测试”。它必须记录设备是否启用处理、选项内容、流量比例、持续时间、保护策略和带外资源曲线。相同的报文外观，在不同配置上可以进入不同执行路径。吞吐量下降只是路径线索，不是攻击抵抗能力证明。

邻居表不是实验前的杂务

RFC 允许静态邻居，也允许动态 Neighbor Discovery；动态方式较受推荐，测试工具在试验期间维持邻居缓存活跃。模拟端点放在被测设备一跳之外，避免 Neighbor Unreachability Detection 引发 NS/NA 风暴。

这意味着邻居状态属于实验条件。静态条目、持续刷新、过期重建会消耗不同工作。若生产问题发生在缓存变更时，一个静态邻居实验没有反驳它，只是没有执行同一机制。

过滤器与路由规模也如此。设备若需穿过扩展头才能找到上层信息，可能使用更深解析或另一转发阶段。一个过滤器和二十五个过滤器不是同一剖面。空策略环境取得的数值，不能替代必须执行安全策略的生产路径。

恢复指标也不能合并。RFC 分别定义过载后的系统恢复与设备或软件重置后的恢复；并因短期处理方差明显，不再推荐 IPv6 的 back-to-back frames 测试。拒绝发布不稳定指标，是证据治理，不是功能缺失。

隔离提高可信度，也限定证明范围

基准网络必须独立，不能把测试流量转入生产，也不能误送到管理网络。测试以黑盒方式从设备外部观察；设备不应存在专为跑分准备的特殊能力。这些约束防止厂商把展示模式冒充日常能力。

同一组约束也说明生产并未被测量。生产包含路由波动、队列竞争、版本漂移、共享故障、策略变更与用户行为。实验室主动移除这些变量，才能隔离某个机制。不能在结论阶段又把被移除的现实悄悄加回去。

地址空间也守着这条线。RFC 原文的基准前缀存在已验证技术勘误，当前 IANA 注册表给出 2001:2::/48，并标注不具全球可达性。正确使用实验地址不是格式礼仪，而是避免实验流量与运营空间混淆。

技术范围还有另一边。RFC 8219 明确指出，翻译与封装型 IPv6 过渡技术超出 RFC 5180 的范围，需要补充方法；有状态转换还要观察状态表与过载。双栈可使用 RFC 2544 与 RFC 5180，并不意味着 NAT64 或封装网关可被同一张普通转发表概括。

领导层应该批准什么

每个数值都应绑定不可变剖面 ID，包含设备与 build、启用功能、端口与介质、拓扑、测试工具与时钟假设、帧长系列、地址与前缀分布、邻居模式、扩展头与选项、过滤和路由、控制流量、方向、IP 混合比、提供负载、试验时长与次数、丢包与时延样本、带外资源证据、恢复方法和所有偏差。

责任必须分开：方法负责人定义问题，实验负责人保留配置，统计负责人判断方差，发布负责人证明版本等价，运营负责人安全验证生产假设。任何一个签名都不能替后一层签字。

这不是对基准测试的不信任。恰恰相反，它让基准保有应有的权威：对已执行的报文、路径与条件负责，而不被迫替一个未测量的系统作证。

来源

  1. RFC 5180 HTML
  2. RFC 5180 纯文本
  3. RFC Editor 信息页
  4. IETF Datatracker 文档页
  5. IETF Datatracker 历史
  6. IETF Datatracker 引用
  7. RFC 5180 勘误
  8. RFC 2544
  9. RFC 1242
  10. RFC 8200
  11. RFC 7045
  12. RFC 9098
  13. RFC 4861
  14. RFC 8201
  15. RFC 6890
  16. IANA IPv6 特殊用途地址注册表
  17. RFC 8219
  18. Heng Lu：现实层级
  19. Heng Lu：最小初始规范与自愿采用
  20. Heng Lu：运行代码优先