题干与适用场景
这道 HTTP 与安全基础题适合后端、平台、SRE 和基础设施岗位。场景是 TLS 1.3 0-RTT 请求到达网关：早期数据降低握手等待，却可能被重放。回答要把 425 的语义、业务幂等和逐跳策略连起来。
面试官考察点
- 是否理解 0-RTT 的性能收益与重放风险。
- 能否准确解释 425、429、503 和 408 的边界。
- 是否会用幂等键、去重账本和状态查询保护副作用。
- 能否让网关、源站和多实例对早期数据采用一致策略。
回答前需要澄清的问题
先确认请求是否真的包含早期数据证据、方法会不会产生副作用、网关是否保留 Early-Data，以及客户端是否支持在完整握手后重试。再问是否存在幂等键、唯一约束、去重记录和跨实例共享状态。GET 也可能触发业务副作用，不能只按方法名判断安全性。
30 秒回答框架
TLS 1.3 0-RTT 允许客户端在握手完成前发送早期数据，但这些数据可能被重放。若请求尚未证明可安全处理，服务端返回 425 Too Early，要求客户端完成握手后重试；重试不得再次使用早期数据。可重放、幂等且有去重保护的操作才考虑接受。网关和源站必须一致识别 Early-Data: 1，并监控重试放大。
分步骤深入解答
- 说明风险。 0-RTT 早期数据仍受加密保护，但攻击者可能复制并重放有效请求。风险核心是重复副作用，不是机密性被直接暴露。
- 说明 425。 当请求在早期数据阶段不宜处理时返回 425。服务端不应无证据地滥发 425；响应本身默认不可缓存。
- 判定可接受操作。 读操作也要检查真实副作用；支付、发货、配额变更等写操作默认等待完整握手。若接受早期数据，必须有幂等键、唯一约束或去重账本。
- 定义重试。 发送早期数据的客户端收到 425 后，在完整握手完成后重试，重试不能再放入早期数据。服务端应限制重试次数和总期限。
- 保持逐跳一致。 中间层可添加或转发
Early-Data: 1。网关、负载均衡器和源站必须使用相同信任边界；否则一个实例等待，另一个实例可能先执行副作用。 - 控制放大。 过载时 425 与握手重试会放大流量。限制早期数据大小和并发，监控 425 比例、重试率、重复业务键和握手延迟。
高质量示范回答
我会先把 Early-Data: 1 当作重放风险信号，而不是把 0-RTT 当作普通已确认请求：
POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123如果支付操作尚未证明可重放，我返回 425 Too Early，并让客户端完成 TLS 握手后用同一个幂等键重试；重试不能再次使用早期数据。若操作确实可重放，我仍会用唯一约束或去重账本防止重复执行。425 不表示限流（429）、整体暂时不可用（503）或客户端超时（408）。网关与源站统一策略，记录请求 ID、早期数据标记、重试次数和重复键，避免重试把过载放大。
常见错误
- 说“0-RTT 未加密” → TLS 仍提供加密 → 风险是请求可重放。
- 收到 425 后原样再次发 0-RTT → 风险仍在 → 完整握手后再重试。
- 看到 POST 就永远返回 425 → 某些写入有可靠去重 → 按副作用和证据判断。
- 把 425 当作 429 → 425 处理早期数据，429 表示速率限制 → 分开退避和告警。
- 只在网关判断，源站没有相同策略 → 多实例可能执行不一致 → 统一信任边界和状态。
追问及应对
425 与 503 如何区分？
425 针对早期数据阶段的重放风险；503 针对服务暂时无法处理请求。只有请求带有早期数据证据且策略要求等待握手时才选 425。
为什么不能只允许 GET？
HTTP 方法名不保证业务无副作用。某些 GET 会触发计数、预取或状态变更，仍需按实际副作用和去重能力评估。
网关如何传递早期数据信息？
受信任中间层可添加或转发 Early-Data: 1，但必须防止不可信客户端伪造信号，并让源站知道该标记的来源和策略。
如何验证不会重复扣款？
用同一幂等键执行唯一插入或去重账本，记录最终状态；重试前先查询，事后对账支付流水与业务订单。