摘要

  • 假设一种新传输算法让一个长流的吞吐量提高 35%，这仍不是网络改善的证明；实验可能没有披露短流完成时间、队列尾延迟、有效吞吐、竞争流损失与路由变化后的振荡。
  • RFC 5166 要求比较一组相互牵制的指标；RFC 5033 区分“可安全试用”与“值得推荐”，并要求说明算法在哪里失效；RFC 2914 则解释了局部抢占如何演变为拥塞崩溃与竞相激进。

先不要看新算法的曲线，先看旧流发生了什么。它的速率下降了吗？一段语音是否在长队列后面等待？短连接是否要多经历一个往返时间？若答案没有出现在报告中，那么“提高 35%”可能是精确数字，却不是完整结果。

这里的 35% 是用于说明评估缺口的假设，并非任何具名协议、产品或网络的实测数据。问题不在数字真假，而在数字被赋予了多大的结论。

同一批字节可以有三种意义

RFC 5166发布于 2008 年 3 月，是 IRTF Transport Modeling Research Group 的 Informational 文档，由 Sally Floyd 担任编辑；它不是 Internet Standard。文档没有声称研究者、运营者或厂商已经同意唯一优化目标。它确认的是更窄的共识：新机制应在多项指标的取舍中接受评估，不能只优化一项。

吞吐量本身也要先确定观察者。对路由器，它可以是链路总利用率；对单个流，它可以是传输速率或任务完成时间；对用户，它可能是按下按钮后等了多久。goodput 更进一步，只统计最终完成有用交付的流量，排除重复、重传或在下游丢弃的工作。

这三个视角可能同时给出不同判断。链路满载不等于有效工作最大。平均流速不等于每个流的处境。少数长流取得高收益，也可能让大量短请求落入更差的尾部。因此，报告需要给出分布、时间尺度、流大小与需求构成，不能只给均值。

延迟和丢包也不能等发布前再补。平均延迟会抹掉对交互应用最关键的尾延迟。一个批量传输自身可能不在意单包等待，却会在 FIFO 队列中把同样的等待施加给其他流。丢包率若脱离突发模式、ECN 标记、重传与下游丢弃，也无法说明网络实际完成了多少有用工作。

控制器最危险的时刻可能是“正在变好”

稳态实验常常把最难的部分裁掉。竞争流突然进入、可用带宽变化、无线接入切换、链路间歇断开或路由更新，都会要求控制器重新判断。反应太慢，拥塞持续；反应过猛，一次短暂扰动便可能触发降速、空队列、再冲高的循环。

RFC 5166 因而把响应时间与振荡放在一起。更快响应不是无条件的善，更平滑也不能以长期承受拥塞为代价。需要观察收敛时间、超调、速率方差、队列长度以及恢复期间由谁承担损失。

这也解释了为何只比较实验最后一分钟不够。一个算法可能在最终平衡点表现优秀，却在到达平衡点前反复伤害共存流。迁移过程属于结果，而不是可删去的预热阶段。

公平先是权限问题，才是公式问题

应该在流之间、会话之间、用户之间还是组织之间分配容量？经过三条拥塞链路的流与只经过一条的流，是否应获得同样速率？Jain 指数、max-min、公平比例与其他方法各自保护不同对象。

RFC 5166 没有把其中一个公式宣布为通用裁判。这不是允许评估者跳过公平，而是要求其说明：选择了什么单位，接受了什么代价。如果新流的提升来自标准 TCP 流的下降，这两条曲线必须放在同一结论里。

RFC 2914由 Floyd 编辑，并明确建立在长期的集体研究之上。它将拥塞崩溃描述为：投入更多负载，网络完成的有用工作反而减少。它还警告传输协议与应用之间的“军备竞赛”——谁更激进谁先占便宜，直到共同退让机制失效。只奖励参赛新流的基准，可能把这种竞赛误判为创新。

可安全使用，不等于值得使用

RFC 5033是 Sally Floyd 与 Mark Allman 共同撰写的 Best Current Practice。它要求 IETF 在考虑替代拥塞算法时，获得对优缺点的完整科学研究，而不是一张胜出的性能图。

文档把 Experimental 提案分为两类：一类被认为足以在全球 best-effort 互联网中试验；另一类虽有前景，但应限制在仿真、测试床或受控环境中，因为尚未证明广泛使用安全。即使进入第一类，也不能自动写成“推荐”。机制可能不伤害公共网络，却在某些场景给自己的用户带来糟糕体验。

RFC 5033 要求比较标准 TCP、SCTP 与 DCCP 共存；测试无线等困难环境；改变带宽、RTT、反向流量、统计复用与队列管理；找出表现崩坏的区域；验证极端拥塞下的 full backoff；检查同算法之间的公平、恶意节点、突发事件与渐进部署。

“在哪里不好用”因此不是负面附录，而是发布对象的一部分。若机制只适合受控网络，还要问这个范围靠什么执行。只在摘要里写一句限制，未必能阻止实现被带入不相容的环境。

人物记录的正确边界

Floyd 的 ICIR 生平页面记录了她在 BART 实时计算机系统、UC Berkeley、LBNL 与 ICIR 的经历；项目档案列出 RED、ECN、DCCP、TFRC、HighSpeed TCP、流量模型与评估方法等工作。

这足以说明她为何适合作为本文的人物线索，却不足以制造“独自发明”的传记。RFC 5033 还有 Mark Allman；RED、ECN、DCCP 与 TFRC 各有完整的共同作者、评审、实现者与社群记录；RFC 5166 也写明获得 TMRG 成员的详细反馈。可核验的贡献，是她反复参与建立一种能看见共存成本和证据边界的研究纪律。

让运行结果有权推翻标题

部署档案至少应连起五件事：算法与实现版本；默认值与回退；拓扑、队列、RTT、反向负载和竞争流；goodput、完成时间、延迟与丢包的分布；变化、错误、滥用与恢复测试；以及 canary、停止条件、rollback 和未知项。

卢恒关于运行代码优先与现实而非倡议的文章，为 Sofia Ren 提供了后来的分析视角：技术主张必须始终能被可观察结果反驳。这是本文在 2026 年的编辑比较，不是对 Floyd、TMRG 或 IETF 私人意图的推断。

吞吐量当然重要，但它不能审判自己。只有当优势经受多项指标、外部成本可见、失效区域被命名，而且运行证据出现反例时仍能撤回，算法才获得扩大范围的理由。

来源