摘要

  • “简单尽力而为”不是没有控制，而是让基本通信不依赖逐流调度、准入合同、拥塞计价或所有自治网络同时升级的低状态公共层。
  • “按流大致公平”必须先回答什么算一条流、按包还是按字节、观察多久、在哪里执行；它不能自动证明用户公平、机构公平或业务结果公平。

先看未购买优先权的人

RFC 5290 对简单尽力而为的定义很克制：这类流量不依赖路由器、策略执行器或路径中间盒对不同流进行差异化处理，也不以准入控制为前提。它并没有声称现实网络很简单。运营商之间仍有结算，用户仍可能按流量付费，路径上仍有防火墙和复杂中间盒。被简化的是一项基本条件：数据包不必先携带一份被沿途每个参与者共同理解的高级服务合同，才有机会穿过网络。

这项“少要求”本身就是能力。它不强制所有路由器保留逐流状态，不强制跨域共享一个拥塞账本，也不要求应用启动前完成端到端资源预留。网络因此牺牲了一部分确定性，却换来跨自治边界部署的可能。独立运营者可以在不接受同一套经济制度的前提下，为同一普通业务提供连接。

RFC 5290 写于 2008 年，是一份 Informational 文档，不是互联网标准。它记录的是当时的观察和论证：简单尽力而为虽然不完美，却承载过文件、邮件、网页、音视频与语音，并让多数用户在拥塞时仍有机会取得一部分资源。今天不能把这些历史描述直接当作当前互联网的测量值。但它提出的证据问题仍然有效：一种服务的价值，有时正来自它没有要求共享核心替每一种用途预先作出精细判断。

优先服务增加了什么控制面

简单尽力而为无法在拥塞时保证带宽、时延、抖动、丢包率、快速启动或“资源不足便拒绝开始”的通话准入。QoS 并非多余。RFC 2475 的差分服务、RFC 2212 的保证服务，以及 RFC 3662 的低于尽力而为行为，都回答了不同问题。

但“增加一种服务”与“用它替代普通层”是两项决定。优先队列可以保护实时业务，也可以帮助基础设施获得收入；如果普通层没有受保护的最低份额，它也可能在拥塞时把缺乏支付能力的用户挤出。真正的控制边界不在 DSCP 或产品名称，而在竞争发生时普通层还剩多少可用容量。

因此需要把五个事实拆开：业务被分类、标记被沿途识别、调度器实际执行、容量在相关瓶颈存在、终端应用得到结果。第一项成功不推出第五项。单个域的队列配置也不证明跨域路径遵循同一规则。付费合同证明商业关系存在，不证明公共基线仍可用。

“快车道”还带来新的依赖。标记由谁写入？边界处是否重写？策略数据库版本是否一致？某个下游域不支持时如何回退？计费和拥塞信号怎样跨运营商结算？这些问题若没有闭环，所谓端到端高级服务可能只是若干局部绿色状态的拼接。

公平计数器没有告诉你“谁”

RFC 5290 赞成把粗略按流公平作为简单尽力而为的一项目标，但明确不把它称为唯一目标、最优分配或可保证的权利。当时的大致公平主要来自大量流量使用 TCP，且大量 TCP 连接遵守相近的拥塞控制。那是规模化合作，不是无处不在的强制执行。

即使每一条流的速率都被精确测出，“公平”仍缺少主体。一条流是一条 TCP 连接，还是同一对端点之间的全部连接？是一位订户、一个应用、一个家庭，还是一家企业？一个客户端开十条连接，另一个只开一条，调度器可以对连接完全平等，却让用户得到极不相等的资源。

度量单位同样会改变结论。按包公平与按字节公平不同；长 RTT 与短 RTT 的连接在相同丢包率下表现不同；经过两个拥塞点的流与只经过一个瓶颈的流承受不同代价；突发发送与平滑发送不能只看同一秒的平均值；单播、多播、可靠与不可靠传输也没有天然统一的比较方法。观察十分钟、十小时或整月，会得到不同的分配叙事。

所以“公平率 98%”不是一个自足事实。可审计记录至少要带上分组键、观察区间、包或字节口径、瓶颈位置、拥塞信号、传输响应和执行点。缺失这些字段时，公平只是把一项未公开的政策伪装成数学结果。

合作失效时，谁来执行

RFC 2914 说明端点响应拥塞的责任；RFC 2309 讨论队列管理和不响应流；更早的 RFC 896 记录拥塞崩溃为何迫使网关具备防御能力。这些材料并不支持“尽力而为就是无人管理”。它们说明共同层依赖合作，同时保留在合作失败时施加保护的空间。

至少应区分三种状态。第一种，大多数端点使用相似拥塞控制，网络以很少的核心状态获得粗略分配。第二种，路由器或中间盒识别并限制过度激进的流。第三种，基础设施通过逐流调度等机制主动执行更强的公平模型。第一种状态下观察到的平稳结果，不能写成第三种状态已经提供的保证。

流量洪峰会放大差别。DDoS 或突发热点可以让共享路径上的所有普通流量一起变差。运营者可能必须做聚合限速或检查；此时又出现一组权力问题：聚合键是谁定的，阈值为什么如此，误伤怎样识别，限制何时解除。防御可以合理，但仍需要收据。

部署计划也是协议的一部分

RFC 5290 把增量部署困难放在设计中心。需要路由器标记、两端策略执行、跨域结算和新商业关系共同成立的方案，不是一枚开关，而是一条依赖链。任一环节缺失，端到端承诺便退化成局部配置。

RFC 1958 所描述的互联网没有单一所有者和中央控制者。应用和端点通常比共享基础设施、互联协议与经济安排变化得快。也正因此，一种精度较低但能容忍局部协调的公共服务，可能比理论更优雅的统一机制更有生命力。

评估方案时不能只比较理想状态下的队列图。要比较完整的运行负担：哪些设备必须升级，哪些端点必须合作，谁负责结算，标记丢失时进入什么安全回退，未升级域出现时普通业务是否仍能继续。只有在普遍协同之后才可用的设计，其采用计划本身就是可用性风险。

这份 RFC 没有证明什么

它没有证明今天的网络仍保留足够普通容量，没有证明现代流量结构仍由同样的 TCP 行为主导，没有证明某家运营商执行了粗略公平，也没有证明付费优先必然伤害普通用户。它更没有把尽力而为变成送达承诺：包仍会延迟、丢失或乱序，连接仍可能失败。

RFC 5290 提供的是分析边界。允许进入共同层，是准入事实；调度器给予某类特定待遇，是执行事实；某位用户获得公平且有用的结果，是需要身份模型、比较对象和应用证据的判断。把三者压成一个绿色图标，就会让符号拥有超过任何实际组件的权力。

来源