摘要

  • RFC 9808 让下游 CDN 向上游 CDN 通告受足迹约束的“不应超过”容量，并指明与之配套的利用率遥测。规范明确说，这些信息只供委派决策参考，不构成保证、承诺或容量预留。
  • 可审计的决定必须保留整条证据链：所有同时适用的软硬上限、足迹与 TTL、遥测来源和指标、时间粒度、均值或分位数、延迟、跨下游汇总、上游路由规则，以及后续的请求准入、实际交付与另行约定的商业责任。

一张容量表里可以同时有六类格子：出口速率、每秒请求、存储字节、存储对象、会话数和缓存字节。最醒目的格子往往是出口速率，因为它最像人们口中的“带宽”。但如果会话数已经逼近上限，剩余带宽并不能自动变成可服务的新请求。若存储对象达到边界，空闲的缓存字节也未必有用。

这正是 RFC 9808 要求逻辑与（AND）的原因：上游 CDN 必须同时考虑所有适用限制，不能挑一个最宽松、最容易展示的数字作为“可用容量”。本文的例子只是解释规范，不代表任何真实 CDN 已发送过该对象、保留过容量或完成过一次交付。

RFC 9808 于 2025 年 7 月作为标准跟踪文件发布，它扩展了 RFC 8008 的足迹与能力通告接口，新增 FCI.CapacityLimits 和 FCI.Telemetry 两类对象。RFC Editor 资料页与 IETF Datatracker记录了 Andrew Ryan、Ben Rosenblum 和 Nir B. Sopher 三位作者及文件历程；IANA CDNI 参数登记表则保存跨实现共用的对象名、遥测来源类型和容量限制类型。

统一词汇解决的是协调成本。两家独立运营的网络如果只交换一句“还有容量”，双方仍不知道单位、地理范围、测量窗口、来源、更新速度和失效时间。结构化对象把这些条件放到机器能读取的位置，也让上游能说明为何减少或停止委派。它建立了一套共同语法，却没有替任何一方做商业或运行决定。

规范对权力边界写得很直白：容量信息是建议性的，不是保证、承诺或预留。下游通告的 maximum-hard 表示在相应范围内可供使用的最大容量；它并不证明其中某一部分已专门锁定给这个上游，更不保证稍后到达的具体请求一定获准。一个字段的签名、语法和时效都正确，也不能凭空生成独占库存。

RFC 6707所描述的 CDNI 关系说明了原因。内容服务提供者可以与权威 CDN 有一份安排，权威或上游 CDN 又可以同下游 CDN 安排部分流量交付。协议传递的是技术协作信息；价格、优先级、排他性、违约条件和赔偿仍在技术规范之外。把容量通告当作 SLA，等于用一个系统的证据替代另一个系统的合同。

RFC 7336把请求路由保留为本地决定。RFC 9808 改善了决定所需的输入，但没有把路由权交给下游。上游仍要结合自身需求预测、故障代价、安全余量、其他下游和遥测延迟，决定是否委派、何时委派以及委派多少。有效对象不是“请把容量灌满”的命令。

每条限制都必须有 maximum-hard。可选的 maximum-soft 必须低于硬上限，用来提示上游在撞到外沿之前先减量；若省略，软上限等于硬上限。两者之间的距离不是装饰性缓冲，而是控制回路的风险预算。测量晚两分钟、决策每分钟执行一次、流量又可能在十秒内突增时，贴着硬上限运行会把“当前尚未超过”变成一份过期结论。

软硬距离不能脱离指标和业务后果设定。会话建立、对象写入和出口流量具有不同惯性；拒绝一个可重试请求与打断长会话的代价也不同。一个固定百分比虽然方便，却会隐藏这些差异。更可靠的做法是记录测量滞后、控制周期、峰值变化速度和容错路径，再据此决定余量。

范围同样不可省略。容量限制继承所在 FCI 通告的足迹。RFC 8008允许地址、ASN、国家和其他已登记类型作为足迹，多个条件还可能累积收窄候选范围。因此“一万请求每秒”并不是完整事实；它必须连同适用地址、地区或条件交集一起读取。超出足迹的请求不能借用这个数字获得资格。

时间则决定这份事实还能用多久。通告通常从 HTTP Cache-Control 等传输机制继承 TTL；若传输没有 TTL，双方须在带外约定寿命。RFC 9808 期待容量上限是相对稳定的合理峰值，而当前利用率变化得更快。上限仍在有效期内，只能说明信封未过期，不能说明信封内的余量还在。

FCI.Telemetry 正是为这个差异而设。它通告面向特定上下游委派关系的近实时、聚合后的下游利用率来源。来源标识在一次通告内必须唯一；若仍指同一来源，跨通告应保持稳定。指标名也有同样要求。容量限制引用来源和指标，使上游比较的是指定计量口径，而不是另一个系统里恰好同名的计数器。

三个可选属性会改变数字的解释。time-granularity 表示数据覆盖的时间间隔；data-percentile 表示分位数，缺省时表示该区间均值；latency 表示观测落后现实多久。五分钟窗口的第 95 分位、延迟两分钟，与一分钟窗口的均值、延迟十秒，可能都准确，却不能支持同一种委派速度。只显示一个“当前值”的仪表盘会把这些差异全部抹掉。

通用遥测来源没有把访问配置统一写死，而是将具体格式留给双方带外安排。这种克制很重要：共同层规定来源身份和比较语义，不假装所有运营者都使用相同传输、凭据或安全边界。它是最小初始规范，而不是中央遥测平台。

当流量经过多个 CDN 继续委派时，汇总规则成为另一道控制。若上游被要求报告总使用量，它必须把下游使用量聚合进来；否则，被再次委派的流量会从上游视野消失。只看本节点直接服务的负载，可能让控制器在整条链已接近上限时仍报告余量。账本必须沿委派图闭合。

规范保留了内嵌 current 值供简单场景使用，但不建议把快速变化的利用率频繁塞进可缓存的容量通告。把稳定信封与高频状态分成两个对象，可以让各自采用合适的更新节奏，也迫使运营者面对失败问题：来源取不到、指标换名、延迟扩大或粒度改变时，控制器究竟减额、暂停还是回落到另行约定的静态值？

答案应写在上游的可执行策略里，而不是默认复用最后一个有利数字。高后果流量可以在遥测失效时停止新增委派；可重试流量可以按折减后的容量继续；已有会话可能需要另一套保护。RFC 9808 提供做出这些选择所需的结构，并不替运营者选择。

即便委派决定完美，服务仍未被证明。下游还要在实时队列、内容状态和本地政策下接纳具体请求，可能还要通过 RFC 8006涉及的机制获得内容或元数据，然后才能交付字节、维持会话并产生性能记录。用户看到的时延、完成度和质量属于更后的证据层。

RFC 8007定义了另一套触发与状态接口，也提醒我们：命令被接受、处理完成与效果被观察是不同状态。容量流程同样应该分开记录“已通告、已测量、已委派、已准入、已交付、已体验”。把它们压成一个绿色图标，会让故障发生时没人知道绿色究竟证明了什么。

可靠审计应从原始 FCI 文档、取得时间、足迹和 TTL 开始，保存完整限制集合、软硬值、来源与指标标识、遥测时间戳、粒度、均值或分位、声明延迟以及总使用量如何聚合。随后再记录请求路由器版本、安全余量、预测、委派量与理由。只有后续记录才加入下游准入、实际交付、质量和决定商业责任的合同条款。

Heng Lu 的《最小初始规范》解释了这种分层的价值：共同语法尽可能薄，承担后果的一方保留未来决定。《现实层》阻止符号性的容量陈述被升级成技术状态、行动或结果。《运行代码优先》则把问题落到程序和现场：真实控制器是否取得、老化、比较并执行了对象，交付系统随后到底做了什么？

RFC 9808 的价值不在于创造容量，而在于让网络更诚实地讨论容量。成熟治理会坚持七个动词各自有凭据：通告、测量、委派、准入、交付、体验、补救。新对象只负责前两个。

来源