同一条路径为何会有两个都成立的容量数字：RFC 3148

摘要

• RFC 3148没有给网络容量规定一个普适数字，而是把批量传输能力视作一组必须写明传输行为的测量。
• 丢包模式、重传超时和 TCP 确认时钟可以帮助解释速率差异，却不能把一个测试流变成对所有应用和用户体验的裁决。

数字比实验看起来简单

设想两台主机通过同一条路径传送一个大文件。两次测试都试图填满同一个瓶颈，并用唯一有效数据除以经过的时间。结果都以每秒比特数表示。但一种拥塞控制算法能较快从成组丢包中恢复，另一种算法丢失了由确认驱动的发送节奏，只能等待重传定时器到期。路径没有变化，测得的速率却变了。

这不是算错了。RFC 3148要揭示的正是这个问题。该文件于2001年7月以Informational RFC发布，题为《A Framework for Defining Empirical Bulk Transfer Capacity Metrics》。它把Bulk Transport Capacity（BTC）描述为一个拥塞感知传输连接的长期平均速率，通常以TCP为例。文件给出简单的量：唯一数据位数除以经过时间，同时提醒读者，数字背后藏着实现选择。

“容量”容易让人以为它是链路的固定属性。RFC 3148没有这么说。它把单个理想TCP实现的长期平均速率作为直观参照，但IETF允许多种拥塞控制算法，并容许算法内部存在实现差异。如果这些合规选择让测量彼此不可比，那么“这条路径的BTC”就不是一个无需说明的数值，必须把方法一并写出来。

合规的TCP实现并非同一台仪器

传输标准确立共享行为，却没有冻结所有实现细节。例如RFC 5681描述TCP拥塞控制时，仍留下会影响测量的选择。RFC 3148要求BTC方法说明窗口如何增长、拥塞窗口等于慢启动阈值时如何处理、使用何种丢包恢复算法、如何选择段大小、怎样执行重传定时器，以及如何设置和读取测量时钟。

这些不是外观选项。发送速率取决于路径返回的确认。丢包可能触发快速重传，也可能让发送方等到定时器到期。SACK恢复、NewReno、重传超时、发送缓冲区、接收窗口与最大段尺寸都可能改变一个流在给定区间内搬运的数据量。RFC 5681、RFC 6298、RFC 2018、RFC 6582和RFC 6675分别记录了其中不同机制。机制都存在，不代表各实现等效；这意味着测试所选的行为本身就是结果的一部分。

RFC 3148还把较窄的“Congestion Avoidance Capacity”与更完整的BTC区分开来。前者排除了触发重传超时和慢启动恢复的阶段，因此可以描述稳态拥塞避免，却也可能漏掉真实大文件传输中重要的恢复过程。文件并未宣称一种指标总是更好，而是要求名称和数字不能隐去测量包含或排除的行为。

留下解释差异的轨迹

一个速率数字无法说明两种方法为何不同。RFC 3148建议记录辅助指标，或保留足够数据供事后推导，例如段级轨迹。相关观测包括成组丢包、报文重排、重传超时、拥塞窗口变化、确认时钟是否保持、测试主机自身的丢包和排队、段大小，以及反向路径负载。

确认时钟是一个容易理解的例子。TCP经常在收到已送达数据的确认后再发新数据。如果这种节奏中断，超时和慢启动恢复会消耗时间，而稳态速率未必包含这段时间。因此，两种方法可能面对同样的丢包模式，却因恢复行为不同而给出不同速率。轨迹可以让差异变得可调查，但不会自动指认是哪台路由器、哪条队列或哪家运营方造成了它。

这一做法接续了RFC 2330的测量纪律：区分精确定义的指标与测量方法，并说明误差和不确定性。之后的RFC 5166讨论如何评价拥塞控制算法，RFC 6349则提供TCP吞吐测试框架。这些文件提供相邻背景，却没有把RFC 3148变成唯一的通用测试，也不能证明某家运营方部署了它。

RFC 3148还提出一个微妙的经济问题：拥塞动态可能并非线性，因此在某些条件下，提高路径链路速率反而可能降低TCP或BTC测量结果。它把这当作一种可能情形和研究问题，并非实测事件、升级网络的一般规律，也不证明增加带宽通常会伤害用户。真正的提醒是：数字变化时，应先保留测试方法与路径观测，再作商业判断。

测试本身也会占用网络

BTC依靠大流量传输测量，不是发几个被动探测包。测试会主动尝试填满瓶颈。RFC 3148指出，有些方法可能不用普通TCP报文，在网络运营者看来却像拒绝服务流量。因此它建议参与方协商测试时间、规模和频率。文件还提醒，测试流量可能被识别并受到区别处理，也可能有人注入相似报文来干扰测量。

操作影响不只在两个端点。测试方决定算法、时长、缓冲区和仪器；路径带来时延、丢包、重排和排队；运营者看到的是一个会消耗容量的高负载流。负责任的结果应写明足够条件以供解释和复测，并确认测试已获准在相应路径和时段执行。

一个结果能够说明什么

RFC 3148与RFC 3133的主题不同。RFC 3133定义Frame Relay单方向交付率，并指出丢失一个很小的确认帧可能触发大量数据重传，所以链路层比率很好看时，应用表现仍可能很差。这是交付计数机制。RFC 3148提出另一个问题：传输算法都合规，却能有不同表现时，怎样比较两个单流大数据传输速率？

答案是方法纪律：注明传输行为，保留辅助证据，确认测试主机没有先成为瓶颈，在可能时区分正向与反向路径，再按已说明的条件重复实验。此时结果支持的是一个有限命题：某个明确定义的方法，在某段时间内沿着这条被观测路径传输了多少唯一数据。

单独一个结果不能证明链路物理速率、多个并发流共享的总容量、所有TCP实现的速率、服务等级违约、应用完成时间或用户感受。没有轨迹和独立证据，它也不能定位原因。

RFC 3148的历史贡献不大，却经得起时间检验：它不让一个标签抹掉测量仪器内部的选择。它保留了醒目的数字，同时要求方法随数字一起交代。

本文的解释视角也参考了 Lu Heng 的第64篇笔记（最小初始规范与本地决策）和第20篇笔记（形式描述与可观察现实的区分）。它们是编辑分析框架，并非 RFC 3148 作者的主张。

来源

1. RFC 3148 — A Framework for Defining Empirical Bulk Transfer Capacity Metrics
2. RFC Editor 的 RFC 3148 记录
3. RFC 2330 — Framework for IP Performance Metrics
4. RFC 3133 — Terminology for Frame Relay Benchmarking
5. RFC 5166 — Metrics for the Evaluation of Congestion Control Algorithms
6. RFC 6349 — Framework for TCP Throughput Testing
7. RFC 5681 — TCP Congestion Control
8. RFC 6298 — Computing TCP's Retransmission Timer
9. RFC 2018 — TCP Selective Acknowledgment Options
10. RFC 6582 — The NewReno Modification to TCP's Fast Recovery Algorithm
11. RFC 6675 — A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment
12. Lu Heng，第64篇笔记 — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
13. Lu Heng，第20篇笔记 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile