摘要

  • draft-ietf-httpapi-ratelimit-headers-11 允许服务端用 pk 表达某次请求对应的配额分区；分区可以按用户、应用、方法、资源或其组合生成，并不等同于经过认证的身份。
  • 自动化必须分别保留策略、分区、当前额度、客户端节奏、后续准入、授权、执行和结果。分区相同只支持“可能从同一额度池扣减”这一窄结论。

网关连续三天返回同一个分区键。风控系统于是把它登记成“用户指纹”：同键请求被认为来自同一个人，不同键请求则被认为属于不同主体。随后，共享企业凭据把数百名员工合并到一个分区；同一个员工访问两个资源时又被拆成两个分区。

键值始终稳定。身份判断始终错误。

2026 年 5 月 23 日，IETF HTTPAPI 工作组发布了 RateLimit header fields for HTTP 第 11 版。它是一个仍在推进的 Internet-Draft，拟进入 Standards Track，并将于 2026 年 11 月 24 日到期。它不是 RFC，也不是任何产品已经部署、互通或普及的证据。本文只讨论草案明示的语义边界。

分区解决的是计量范围，不是主体是谁

草案把配额分区定义为服务端容量的一种划分。服务可以按用户、应用、HTTP 方法、资源，或者这些维度的组合来划分。pk 是一个字节序列，用来告诉客户端当前请求落入哪个分区。

这项信息很有用。如果服务公开生成规则，客户端可以推断未来请求是否可能消耗同一份配额，从而避免把一个资源的剩余量误用于另一个资源。代理某些情况下也能据此管理不同消费者的工作队列。

但“同一记账范围”不是“同一自然人”。一个企业令牌可以让多人共享分区；一个用户可以因为方法或资源不同而进入多个分区；网关规则改变后，键值也可能改变。即使键值中含有识别信息，草案仍提醒服务端注意冒用风险，并避免泄露敏感数据。

因此，pk 最多证明：返回该字段的服务表示，按当时规则，这个请求与该键指向的配额分区关联。它不证明谁完成了认证、不证明谁拥有资源，也不证明分区方式公平。

策略不是当前状态

RateLimit-Policy 描述一项命名策略。必需的 q 表示分配额度；可选的 qu 表示单位，w 表示时间窗口，pk 表示分区。草案初始定义三类单位：请求数、内容字节数和并发请求数。

RateLimit 描述当前服务限制。r 是该策略下当前可用的额度，t 是有效窗口。把两类字段都压缩成一个“剩余请求数”，会同时丢失策略名称、单位、分区与观察时间。

更重要的是，一次请求可以受多项策略影响。日额度和小时额度可以同时存在，服务端可以只返回最接近耗尽的那一项。没有出现在响应里的策略，并不因此停止生效。

一个可审计的记录至少应包含：服务来源、响应时间、策略名、单位、分区、q、w、r、t、HTTP 状态和触发请求的关键属性。这个元组是服务端当时所陈述状态的证据，不是未来准入函数的完整副本。

正数不是授予，零也不是封禁

草案明确要求，客户端不得把正的 r 当作后续请求必然获得服务的保证。安全章节进一步指出，可用额度只是帮助客户端避免被限流的提示，不是已授予的请求，也不是服务等级协议。

在下一次请求抵达前，服务负载可能变化，防护策略可能收紧，另一项配额可能先触顶，或者请求根本未通过授权和应用校验。限流字段没有覆盖这些判断。

反过来，r=0 也不强制拒绝。草案不要求字段值与响应状态码固定对应。服务端可以在零额度时仍处理某次请求，也可以在正额度时拒绝另一次请求。

这不是语义模糊，而是权力归属清楚：字段提供协作信息，服务端保留执行策略和准入请求的权力。客户端可以把任务标为“符合最近一次已知提示”，不能提前标为“已经获准”。

时间窗不是补额时刻

t 用相对秒数表示有效窗口，避免客户端与服务端必须校准绝对时钟，也降低所有客户端在同一时间戳醒来的惊群风险。

它描述的是在这段时间内不要使用超过 r 的额度，而不是倒计时结束后恢复多少。草案禁止客户端假定窗口结束会完全补额。服务端可以因滑动窗口、资源饱和或自适应控制，在后续响应中任意调整 r 和 t。

安全的控制器在 t 到期时废止旧观察，而不是把本地令牌桶补满。它加入抖动，以小规模探测获取新响应，再在本地速率、并发、成本和依赖容量上限内逐步调整。

Retry-After 可以给出再次尝试的建议时间，草案建议它不要早于有效窗口结束。但“可以再次尝试”仍不等于“届时必然有席位”。重试建议、窗口约束、额度恢复和实际准入必须分别记录。

授权被明确留在边界之外

草案直接说明，RateLimit 字段不用于授权或其他访问控制。一个请求可以尚有额度却没有权限；也可以权限有效但配额耗尽。401 或 403 是否消耗额度，也由实现决定。

如果系统把分区键当身份，再把正额度当授权，就会连续跨越两道没有证据支持的边界。攻击者可能利用共享分区污染他人配额，也可能诱使系统把一个可预测键当作主体证明。

正确的链条应保留认证主体、授权决定、配额分区、限流观察、请求准入和应用结果。它们可以关联，但不得相互替代。

中间节点改变计数，却不能冒充最终裁决者

代理和网关可能转发、重试或施加自己的限制。外部中间节点不应把源服务的策略改得更宽松；在理解单位并确实执行自身规则时，它可以表达更严格的限制。

即便如此，返回字段并执行策略的服务仍是最终负责方，并且始终可以决定是否处理请求。中间节点通常应继续转发它认为可能失败的请求，而不是把推测升级为源服务的裁决。

透明重试还会制造计数差异：客户端只发起一次，代理可能向服务端尝试两次，于是服务端消耗两份额度。这个差值不能自动证明任何一方作弊。它要求检查请求标识、尝试序号、代理动作和服务响应的完整链路。

过大的许可感同样危险

草案提醒，较大的 r 与很短的 t 组合，可能诱使简单算法按 r/t 形成高峰，远超策略 q/w 所暗示的平均速率。协作信号反而可能触发资源耗尽。

异常大的值可能来自配置错误、恶意中间节点或真实但短暂的容量变化。客户端无需先判断动机，才能执行安全策略。它应该保留自己的最大速率、并发、内存、成本与下游压力阈值，并通过渐进爬升和熔断器控制执行。

远端数字可以帮助本地策略选择动作，但不能取消本地责任。把执行器直接连到一个并未授予容量的整数，是把安全权交给一次观察。

问题类型不是定罪书

第 11 版草案定义了配额超限、临时配额超限和检测到异常使用等问题类型。它们可以携带违反的策略名称，帮助机器采取不同的降速或暂停动作。

然而，“检测到异常使用”只是响应服务的分类。它不独立证明恶意意图、操作者身份或检测结论正确。它足以支持可逆动作，例如减速、暂停批次、转入人工复核；不足以单独支持永久封禁或公开归责。

RFC 9457 提供问题详情容器，RFC 6585 定义 429，RFC 9110 提供通用 HTTP 语义，RFC 9651 提供结构化字段语法。格式越精确，越有利于忠实保存陈述；它不会扩大陈述者的权限。

来源与限制

冻结证据包括第 11 版草案及 Datatracker 状态、历史与引用，HTTPAPI 工作组页面与隐私草案，RFC 9110、9651、6585、9457、9205，以及 IANA 字段和问题类型注册表。这些材料证明提议中的协议语义和边界，不证明任何部署、厂商行为、事故、性能、采用率或互操作结果。

来源