摘要

  • RFC 9111 允许缓存把多次未命中合并为一次转发请求，但前提是返回的响应可以用于相关请求。
  • 每个等待者仍需独立判断目标、方法、Vary 字段、授权上下文和缓存控制条件。

设想一项明确属于假设的边缘网关场景。两个指向同一 URI 的 GET 几乎同时到达，一个是匿名请求，另一个带有 Authorization，并期待账户特定的表示。网关把前者选为领头请求，只向源站发起一次访问，然后把同一个 200 OK 分发给两者。源站负载下降了，但第二个请求应有的响应决策却被优化吞没。

RFC 9111 允许合并请求，是因为缓存未命中同时涌现时，单次转发可以降低源站和网络压力。可是，这项许可带有明确条件：返回响应必须获准用于相关请求。如果它不能用于部分或全部等待请求，缓存仍需分别转发这些请求，即使这样会增加延迟。

条件之所以重要，是因为 URI 看似相同并不足以决定复用。目标 URI 必须匹配；已存响应关联的方法必须允许复用；Vary 指定的请求字段必须匹配；no-cache 条件必须得到满足；响应还必须新鲜、获准以陈旧状态提供，或已经成功验证。合并改变的是上游访问次数，不会消除这些逐请求条件。

Vary 是判断的一部分。RFC 9110 说明，Vary 会列出可能影响表示选择的请求字段，从而扩展后续匹配所需的缓存键。RFC 9111 又规定这些字段如何比较，包括规范化处理和字段缺失的情况。包含 * 的 Vary 永远无法匹配。Vary 不是把所有请求变成一个请求，反而是区分它们的证据。

Authorization 把边界表现得更清楚。RFC 9111 规定，共享缓存不得把针对含 Authorization 请求的已存响应用于后续请求，除非响应带有允许这样做的 Cache-Control 指令，且缓存遵守该指令的要求。这并不意味着所有合并组都涉及认证，而是说明响应分发不能越过普通复用原本要遵守的控制。

因此，只统计“节省了多少次源站请求”非常危险。领头请求成功只能证明一次上游事务取得响应，不能证明每个跟随者都具有相同的选择字段、授权限制、新鲜度状态与复用权限。输入不一致时，单独转发代表正确性，而不是浪费。

运营方可以用一份“合并释放收据”兼顾容量与证据。这是本文提出的编辑性控制构造，不是 IETF 定义的协议对象。它把领头请求与每个等待者相连，记录返回响应和已存对象身份，规范化方法与目标，比较 Vary 字段，检查 Authorization 与 Cache-Control，并为每个等待者保存“释放响应”或“独立转发”的决定。

这样，权衡便清晰可查：合并只共享一次获取，响应交付仍是逐请求决定。平台可以衡量节省的上游工作，同时避免把不合格的分发误算成缓存命中。

来源