摘要

  • Retry-After 表示用户代理应等待多久再发出后续请求，并不保证恢复时间。
  • 该值可以是绝对 HTTP 日期，也可以是秒数，因此时钟和解析过程属于证据链。
  • 503 或 429 只描述已经观察到的响应，不能证明未来容量或所有依赖项的状态。
  • 运营方需要重试准入收据，把指令、最新健康证据与实际后续结果连接起来。

设想一个恢复控制器收到带有 Retry-After: 120 的 503 Service Unavailable。它暂停所有请求，把两分钟后的节点标成绿色，并安排整条队列在同一秒释放。尚无任何新请求成功，事故却已被标记为恢复。两分钟后，源站依然受限，上游依赖仍不可用，同步重试浪潮反而延长了过载。

标头是有效的，恢复结论却是凭空添加的。

RFC 9110 对 Retry-After 的定义很窄：它表示用户代理在发出后续请求前应等待多久。服务器可在 503 中建议适当的重试时间；在重定向响应中，该字段也可提示用户代理在跟随 Location 地址前应等待多久。这两种用法都没有把指定时刻变成服务健康预测。

标头有两种形式。HTTP 日期指定一个时间点；delay-seconds 指定从收到响应起计算的非负秒数。前者依赖时钟，后者依赖实际接收时间，以及中间件、队列和本地计时器如何处理经过时间。只保存换算后的截止时刻，会丢掉原始指令。

状态码本身也有边界。RFC 9110 将 503 描述为过载或计划维护造成的暂时无法处理。服务器可以建议重试时刻，但规范没有保证限制会在那一刻解除，也没有要求每台过载服务器都必须返回 503。恢复可能更早、更晚、局部发生、因地区或访问上下文而异，也可能被另一依赖阻塞。

RFC 6585 定义了 429 Too Many Requests。响应可以带 Retry-After，但用户识别方式和请求计数方式由服务器决定。令牌、账户、地址、路由、租户或边缘节点可能采用不同限制。脱离该作用域的计时器不能证明下一次请求会被准入。

发出响应的组件同样重要。它可能是源站、网关、反向代理、CDN 或 API 管理器。观察结果只证明该组件在这次交换中发出了这条指令，不能自动证明每一层都共享相同状态。

重试准入收据应保存触发请求与响应、观察点、状态码、原始值、日期或延时形式、接收时间、换算后的最早重试时间、时钟来源及中间件引入的响应年龄，并在不保存秘密的前提下绑定账户、令牌、路由或租户作用域。

随后，收据记录退避算法、随机抖动、重试预算、并发上限、取消状态与实际发送时间。准入前再加入与请求相关的最新健康检查、可用容量、依赖状态、授权上下文与决策组件。最后记录后续响应、表示内容或交易结果。

这样，仪表盘可以区分“已到可再次尝试的时刻”“健康检查通过”“请求获准”和“交易完成”。这些事件可以并列显示，但前一项不能自动生成后一项。

来源

RFC 9110 — HTTP Semantics；RFC 6585 — Additional HTTP Status Codes。