RFC 3448：接收反馈不是发送许可

摘要

TCP 的窗口会在拥塞反应中明显起落。文件传输能够承受这种锯齿，语音与流媒体却更在意短时间内的稳定。2003 年 1 月发布的 RFC 3448 因此提出 TFRC：在尽量保持与 TCP 竞争相容的同时，用基于速率的控制减少吞吐波动。

“TCP 友好”并非承诺每个瞬间都一样公平。规范把“合理公平”表述为：在相同条件下，发送速率通常处于一个 TCP 流速率的两倍范围之内。这是近似目标，不是容量预约、队列份额契约，更不是用户体验保证。

TFRC 也不是完整传输协议。它不定义可靠性，也不规定唯一报文格式；可以由 RTP、应用层控制或端点拥塞管理承载。其纯文本、RFC Editor 记录、Datatracker 页面、历史、引用、后续引用与勘误检索证明规范如何形成，不证明任何特定网络已经部署或成功。

接收端看到序号、到达时间、丢失和 ECN 标记，却不把每一个丢包都独立计罪。发生在约一个 RTT 内的多次丢失被归为一个丢失事件，因为 TCP 通常会针对同一拥塞窗口中的一组损失作一次主要降速反应。

于是，五个相邻丢包可能只构成一个事件；分散在多个往返时间中的五个丢包则可能构成五个事件。接收端对事件间隔加权，再取其平均值的倒数，得到丢失事件率 p。当前无损间隔异常长时，历史折扣还可以降低旧事件的影响。

这一数字并非原始事实的完整复制，而是面向控制的摘要。它刻意丢掉同一事件里的包数，不指出哪台路由器或哪个队列负责，也不能单独区分拥塞、无线误码、重排或其他原因。RFC 3168 允许 ECN 标记在不丢包时表达拥塞，但标记仍不是应用已收到数据的证明。

接收端同时测量 X_recv，并回送时间信息。它汇报的是过去一段时间“实际看见多少到达”，而不是宣告未来一定有同样带宽。

发送端利用回显时间估计 RTT，再按 RFC 2915 的背景方程，把包大小、RTT、丢失事件率和重传超时项组合为 X_calc。这个数描述一个模型化 TCP Reno 流在相似条件下可能获得的速率。

但 X_calc 不是输出指令。拥塞避免阶段还要受 2 × X_recv 限制，并保留与最大退避间隔相关的小速率下限。方程防止接收端单方面夸大许可；近期到达速率又防止模型在现实到达量很低时过度乐观。

第三层约束是时间。发送速率通常每个 RTT 不得增长超过一倍，数据包应被定时发送，而不是把一个周期的额度瞬间倾倒为突发。接收端即使给出有效反馈，也只贡献一个坐标；发送行为仍由发送端的模型、上限与节奏共同决定。

如果反馈迟迟不来，无反馈定时器会到期。发送端随后降低允许速率，常见做法是把缓存的 X_recv 减半，再根据新状态重算并重新启动定时器。初始化阶段没有 RTT 或反馈时，也有直接减半路径。

这里最重要的不是“减半”这个数字，而是对不确定性的处理。反馈可能在反向路径丢失，正向路径可能失效，接收端可能停止，发送端也可能只是闲置。规范没有伪装成知道原因；它只规定在证据缺失时采取更保守的动作。

这也揭示接收端的权力边界。恶意或故障接收端可以少报损失、夸大到达率，因而影响发送端。发送端自己的方程、增速限制和无反馈退让能够约束这种影响，却不能把未经独立验证的报告变成真相。

RFC 2914 把拥塞控制放在互联网稳定责任中；RFC 2581 与 RFC 3390 提供当时 TCP 拥塞控制和初始窗口背景；RFC 3550 则提供 RTP 语境。

后来，RFC 4342 把 TFRC 放入 DCCP CCID 3，RFC 4828 处理小包变体，RFC 5348 最终取代 RFC 3448。这些变化说明机制持续校正，不证明普遍部署或某个产品结果。

从证据链看，p 不是物理原因，X_recv 不是容量，X_calc 不是许可，发送速率不是转发，转发不是解码成功，平滑曲线也不是媒体质量。一个数字越方便，越需要阻止它跨层冒充下一层的事实。

Heng Lu 的现实层次框架要求把原始到达、事件聚合、反馈报文、发送端计算、节奏决定、网络结果和应用体验分别记账。运行代码优先解释了发送端为何不能只相信一份符号化报告；最小初始规范则提醒我们，TFRC 只解决拥塞控制，不冒充可靠传输或应用契约。这是后来的编辑分析，不是对 RFC 作者动机的代言。

RFC 3448 留下的历史教训，是把观测权与行动责任拆开。接收端可以说自己看见了什么；发送端仍要证明自己为何这样发送。昨天的到达记录，永远不是对明天链路容量的所有权。