摘要

  • RFC 8085 要求应用对发往同一目的地的全部 UDP 流量实施拥塞控制；流量由多少 socket、进程或 worker 产生，并不会把责任切碎。
  • 只有在容量确有保留、边界确可约束的受限环境中，非自适应发送才可能有理由存在；它不应默认开启，更不能泄漏到未预留的 Internet 路径。

路径不认识你的进程树

应用可以迅速建立一个 UDP socket，把它交给一个 worker，再让另一个容器使用另一个源端口。服务内部看到的是几个独立单元；网络路径看到的却是争夺同一有限容量的一串数据报。操作系统没有建立连接，并不意味着发送速率的后果也被隔离。

RFC 8085 以这个事实为起点。UDP 是没有内建拥塞控制的尽力而为报文传输。应用可以按本机链路速率发送，即使端到端路径远远承载不了。差额会变成排队、丢包、延迟，以及从其他流量那里挤走的有效工作。

这份 BCP 指出两个理由：防止“负荷越高、有效工作反而越少”的拥塞崩溃；并让共享路径容量的流量获得一定程度的公平。这两个目标不随 socket 数量、容器数或面板上的服务名称改变。

责任单位是流量聚合

Lars Eggert、Gorry Fairhurst 和 Greg Shepherd 在 RFC 8085 中留下了一条很难被绕开的表述：如果应用不使用已有拥塞控制的传输协议，它应控制发往一个目的主机的 UDP 数据报速率；更重要的是，不论这些流量怎样产生，都应对发往该目的地的全部 UDP 流量进行控制。拆分 worker 或打开更多 socket，不会拆分义务。

RFC 并没有规定唯一的聚合键。对不同设计而言，目的地址、一组路径、隧道或另一项能反映真实争用的技术单位都可能合适。它也没有承诺每次丢包只有一个原因。它要求的是控制边界的诚实性：聚合方式应对准设计实际造成的竞争，而不是对准最方便分配配额的组织结构。

socket 清单只能证明进程存在，不能证明合计发送速率、反馈来源、RTT 估计、丢包后的反应，或同级进程是否共享速率策略。按 worker 限速可能正确，却仍然不够。自动扩容时，每一个 worker 都未越过自己的上限，而同一个目的地所受的总压力可以突然翻倍。

因此，有用的运行凭据应把扩容事件、目的地或路径分组、反馈来源、节奏规则和观测到的聚合放在同一记录中。这不是要求一套统一仪表盘，而是为了分清有意的共享控制与架构无意中放大的发送量。

本地选择不等于共有安全可选

RFC 8085 并未禁止 UDP。它建议大多数应用考虑已有拥塞控制的 IETF 传输协议，因为把这些机制正确地重做一遍很困难。TCP、SCTP 和 DCCP 都是文中列举的选择，其他传输也可以采用恰当方法。决定权仍在写代码和运行系统的人手中。

这与 Heng Lu 的“最小初始规范”相符：共同层需要的是共享路径的安全性，而不是由中央指定一套实现。团队可以本地决定传输协议、反馈机制、发送节奏或隧道配置；但不能把一个没有边界的本地偏好，包装成别的网络应承担的队列。

Internet 路径的延迟、容量、拥塞、重排、报文大小和丢包率各不相同，同一路径也会随时间变化。RFC 因而要求保守探测并适应反馈。文档发布本身不会替任何人做到这一点；只有运行中的代码与操作它的人才会做到。“无连接”是传输层属性，不是发送率和邻近流量延迟之间因果关系的消失。

例外必须自带证据

RFC 8085 允许一个有限情形：大批量传输可以在受限环境中依赖预留路径容量，而不采用自适应拥塞控制。当同一负责方控制容量与流量边界时，这可能是合理的。

但这不是一张空白许可。无控制或非自适应模式不应成为默认值，应由用户显式启用，且运营者应验证容量确实已保留。一旦这种流量跑到未预留的 Internet 路径上，它会损害并发流量，并可能促成拥塞崩溃。

关键并不只是配置里写着“已预留”，而是预留、边界和活跃发送者之间真实存在的关系。出口改变、路由泄漏或新实例绕过限速，都可能让标签还在而前提消失。例外记录需要说明覆盖的域、容量决定及负责人、包含的流量类别、有效期，以及离开该边界时恢复自适应控制的开关。

断路器不是方向盘

RFC 8084 把网络传输断路器描述为严重过载时的最后防线。正常控制已经失效时，它可以限制一个流或聚合，防止错误无限持续。这正是它的重要性。

但断路器不是日常拥塞控制。消防警报不能管理一栋楼每日的人流；断路器可以在危险已经出现后停下或压低流量，却不能代替危险出现前持续的适应、测量和公平行为。

RFC Editor 的记录显示，RFC 8085 是 2017 年 3 月发布的 IETF BCP，作者为 Eggert、Fairhurst 和 Shepherd；它废止了 RFC 5405，后来由 RFC 8899 在数据报传输的分组层路径 MTU 发现方面更新。Eggert 的公开 IETF 资料证明其技术贡献与服务经历，不证明他对其他人的部署、运营者或路径拥有命令权。

证据的限度

这些来源不证明任何 UDP 协议的当前部署量、某供应商的内部限速设计，或所有系统都适用的一种聚合方法。它们也不说明每次丢包都是拥塞、每个 UDP 用法都不安全，或断路器触发就表示公平。本文提出的记录要求是从 RFC 8085 的责任边界作出的编辑推论，不是对某起事故的叙述。

来源