摘要

  • RFC 5136 要求容量数字带上协议层、包群、源、目的、开始时刻与测量区间。
  • 名义物理链路容量只是理论上限，不等于某类 IP 流量能够获得的容量。
  • IP 层容量统计目的端正确收到的 IP 比特；有效分片即使无法形成应用对象也可能计入。
  • Type P 定义被测包群，因为标记、队列、ACL、路由策略与负载均衡会改变待遇和路径。
  • 使用量是实际正确收到的流量；利用率是使用量除以同样经过限定的容量。
  • 可用链路容量是测量区间内未被占用的部分；可用路径容量取各链路余量的最小值。
  • 最小容量所在的窄链路，不一定是最小可用容量所在的紧链路。
  • 脱离 T 与 I 的测量，既不能安全比较，也不能自动升级为当前状态。
  • 采样周期若与业务周期同步，重复测量可能稳定地重复偏差。
  • 重复包、首部与重传会消耗网络资源，却不一定增加应用获得的唯一有效数据。
  • Bulk Transfer Capacity 是拥塞感知的传输层观测，与 RFC 5136 的 IP 层量并不等价。
  • 管理者应把物理能力、IP 观测、当前余量、合同权利和应用结果拆成独立回执。

数字没有错，主语丢了

资产系统显示某个端口运行在 10 Gbit/s，这可能完全正确。它说明接口的物理模式与理论上限，却没有说明指定源和目的之间能正确收到多少 IP 比特，没有说明某类包进入哪条队列，也没有说明业务高峰时还剩多少余量。更没有说明应用是否在截止时间前收到了完整且唯一的数据。

RFC 5136 把物理层的这个量称为 NomCap(L)。它通常稳定，但文档也指出动态启用卫星转发器之类的反例。关键不在于它是否恒定，而在于它只是上限。编码、成帧、底层差错、包长和设备处理能力都会介入物理标签与 IP 结果之间。

因此，端口速率是一张必要回执，却不是通行所有层级的授权书。把“接口可以按这个速率工作”改写成“路径可以提供这个速率”，再改写成“用户有权获得这个速率”，最后变成“应用已经获得这个结果”，每走一步都增加了原记录没有测量的新主张。

RFC 5136 没有否定容量数字，而是为数字找回主语。在哪一层、对哪些包、从哪里到哪里、从何时开始、观察多久，这些限定词共同构成测量对象。

IP 计数器究竟承认什么

文档把 IP 层比特定义为：对目的端 D 在 [T,T+I] 内正确收到的所有 IP 包，从 IP 首部第一个八位组到负载最后一个八位组计数，再乘以八。T 和 I 不是附加标签，而是结果身份的一部分。

底层损坏、无法交给 IP 层的数据不能计入；IP 首部校验不通过的包也不能计入。但这不是应用有效性指标。上层内容不必被理解，IP 选项不自动使包无效，可正确处理的分片即使最终不能重组，也消耗了链路资源，因此可以计入。

这解释了为什么网络指标绿色与用户失败并不矛盾。首部、孤立分片、重复负载和重传都可能是真实的链路工作，却不是新的应用价值。IP 层指标准确回答“网络处理了多少”，不能被擅自改成“用户得到了多少”。

时间边界还会切到一个包内部。RFC 5136 不计入边界内的部分包。长时间、大流量观察中影响可能很小；短窗口、稀疏流量中却可能形成偏差。若只保存最终速率，后来就无法判断这个偏差。

Type P 把策略带回测量

同一对端点之间的包并不必然获得同样待遇。业务标记可能选择不同队列，ACL 可能过滤某种协议，路由策略与负载均衡可能改变路径，带 IP 选项的包可能进入特殊处理。RFC 5136 用 Type P 表示被测的流或流集合。

运营方可以选择宽泛 Type P，以观察整体资源；应用方可以选择狭窄 Type P，以贴近真正关心的业务。两个视角都合理，但不能互相冒充。一个受到优待的探针不能自动代表普通流量；一个特定应用的结果也不能自动代表整个链路。

共享路径的其他流量同样影响意义。在优先队列空闲时跑出的结果，不是永恒的网络属性。包长也会改变底层开销；首部压缩可能减少线上物理比特，而 RFC 5136 仍按解压后的 IP 层长度计数。这些差异不是计数器冲突，而是层级转换需要被记录。

所以，一份可审计报告至少应保留包类型、标记、大小、队列、路径和共同竞争的流量。仅有“测速成功”四个字，甚至没有说清被测对象是谁。

容量、使用量与余量不是同一列

C(L,T,I) 表示 Type P 的 IP 比特在区间内从 S 发送、并由 D 正确收到的最大速率。路径容量 C(P,T,I) 取路径各链路容量的最小值。这个最小值所在链路通常称为窄链路。

Used(L,T,I) 则是区间内实际正确收到的 IP 流量，来源可以是任何主机。它不是最大值。利用率 Util 是 Used/C。因此，一个没有说明分母的百分比并不完整：改变层级、Type P 或区间，百分比的意义也会改变。

可用链路容量是 C*(1-Util)；可用路径容量取各链路可用容量的最小值。这个最小余量所在的链路称为紧链路。窄链路与紧链路可以不是同一条：较慢的链路若很空闲，余量可能反而高于一条承载大量竞争流量的高速链路。

这一区别直接影响扩容。升级窄链路会提高理论路径上限，却可能完全没有缓解紧链路。迁移流量或改变调度可能改善余量，却没有改变物理速率。每一种变化都应按自己的层级命名，而不是统称“增加了带宽”。

没有时间窗，就没有“现在”

流量在各种时间尺度上变化。可用容量因此比容量本身更易波动。RFC 5136 要求报告开始时刻与区间，并建议使用一系列测量来描述变化。单次测量并非无效，只是边界明确。

系列本身也会骗人。若采样频率恰好是某个周期性负载的整数倍，探针可能每次都落在安静阶段，或者每次都落在高峰。更多样本只是更稳定地复制同一偏差。需要记录采样计划、抖动、缺失运行、路由变化与业务周期。

新鲜度是另一个判断。昨晚的测量可以是昨晚的优质证据，却不能因为它仍是仪表板里的“最新值”就自动证明现在。路由、队列、维护、流量组合或端点软件变化都可能使旧记录失效。

重复包让链路更忙，却没有让用户得到更多

RFC 5136 的一般定义会计算正确收到的硬件重复包。对原始资源消耗来说合理：两份副本确实各自占用了链路。对关心唯一信息的用户来说，第二份没有增加结果。此时应通过 Type P 或额外唯一性规则区分原始工作量与有效工作量。

这揭示了一个反直觉事实：更高的数字可能意味着更多浪费。若仪表板只保存总速率，造成浪费的重复机制反而被隐藏。故障调查往往需要同时保留两组数，而不是争论哪一组“才是真的”。

RFC 3148 的 Bulk Transfer Capacity 位于传输层，关注拥塞感知连接传递的唯一数据，排除首部和重传。丢包、时延、乱序与恢复算法会改变它。RFC 5136 的 IP 容量则包含 IP 首部，并不关心负载是否重复。两者从不同角度观察同一路径，不应强行相等。

RFC 9097 等后续工作给出了更具体的单向 IP 容量方法；RFC 9946 规定了受控 UDP 测试协议。它们可以提高测试复现性，但仍不产生订户权利、SLA 裁决或应用成功证明。

建立从可能性到结果的回执链

第一张回执记录介质、接口模式、协商状态与 NomCap(L)。第二张记录源、目的、完整路径及可能形成最小值的每条链路。第三张记录层级、Type P、包长、标记、正确接收、差错、分片与重复规则。第四张记录 T、I、时钟与采样计划。

在此基础上，才解释逐链路容量、路径最小值、实际使用量、利用率分母、逐链路余量与紧链路。路由、队列与负载均衡状态应与结果同行。主动测试还要记录注入负载与安全限制，避免测试制造自己声称在观察的拥塞。

合同层另行提供承诺速率、突发规则、百分位算法、免责条件与裁决权。应用层提供唯一数据、完成时间、完整性、重试与用户可见结果。RFC 5136 没有替这些层填写答案。

各层不一致时，差异本身就是诊断线索。物理端口健康而某类流受限，IP 容量高而当时余量低，余量足而传输控制环表现差，传输完成而业务超时，都需要不同处置。一个绿色数字无法裁判整条链。

薄协调层与厚实的本地证明

RFC 5136 展现了克制的协调方式。共同规范负责给量命名，使研究者、工具作者、运营方与用户可以比较同一对象。它不安装资源、不预留容量、不选择路径、不授权测试负载，也不解释合同结果。

本地系统仍需用运行代码、配置与观测承担后果。从物理可能性到 IP 事实，从 IP 事实到当时余量，再到传输与用户结果，每一步都要新增证据。标准的权威不应越过它真正定义的边界。

领导者要防止某一团队用自己控制的计数器给整个服务评分。资产团队证明名义能力，网络测量证明受限定的 IP 观察，运营团队判断新鲜度，商业权威解释承诺，应用与用户证明结果。

端口上的 10G 可以一直是真的。RFC 5136 要阻止的，只是让这个真数字替它从未观察过的现实说话。

来源

  1. RFC 5136 HTML
  2. RFC 5136 纯文本
  3. RFC Editor 条目
  4. IETF Datatracker 条目
  5. RFC 5136 历史
  6. RFC 5136 勘误检索
  7. RFC 1812
  8. RFC 2330
  9. RFC 2544
  10. RFC 3148
  11. RFC 4656
  12. RFC 6349
  13. RFC 6703
  14. RFC 7312
  15. RFC 8337
  16. RFC 9097
  17. RFC 9473
  18. RFC 9946
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary