题干与适用场景
移动客户端经常切网和重连，团队希望利用 QUIC 0-RTT 在握手完成前发送应用数据。服务既有读取接口，也有扣款、创建订单和刷新令牌等有副作用的操作。
回答要说明 0-RTT 的安全边界，而不是只说“它更快”。重点是重放、负载均衡、多区域部署和客户端回退。
面试官考察点
协议事实
候选人应知道 0-RTT 数据缺少完整的重放保护，服务器不能把它当作已经完成认证的 1-RTT 请求。
请求分类
强回答会按副作用、幂等性、时效性和授权状态分类，而不是按 HTTP 方法名称机械放行。
分布式防护
需要讨论票据、重放窗口、跨节点共享状态、负载均衡和拒绝后的重试语义。
可验证性
要能提出攻击回放测试、指标、日志脱敏和逐步启用策略，证明安全性而非依赖配置截图。
回答前需要澄清的问题
- 哪些接口只读，哪些接口会写入账务或订单状态？
- 0-RTT 票据的有效期、签发范围和绑定身份是什么？
- 服务是否跨区域、跨版本部署，节点能否共享重放状态？
- 客户端收到 0-RTT rejected 后，是否会自动以 1-RTT 重试？
- 请求是否包含一次性 nonce、幂等键或业务版本号？
- 合规或审计是否要求证明同一请求未被重复执行？
30 秒回答框架
“我先把 0-RTT 视为未完成握手的数据面，只允许无副作用或明确幂等的读取请求。写请求默认等待 1-RTT；若业务确实需要提前发送，就使用短时票据、请求 nonce、共享重放检测和幂等业务键。服务器拒绝 0-RTT 时，客户端用同一请求在 1-RTT 重试，并用 request_id 去重。发布前做回放攻击测试，按接口逐步开启。”
分步骤深入解答
第一步：建立请求分类
把接口分为只读、幂等写、非幂等写和安全敏感操作。只读查询通常可候选；创建订单、扣款、发奖和令牌轮换默认禁止 0-RTT。即使 PUT 语义幂等，也要检查序列组合是否产生副作用。
第二步：定义票据与范围
票据绑定服务、协议版本、客户端身份范围和过期时间。不要让一个环境签发的票据跨租户或跨区域无限复用。密钥轮换后旧票据应快速失效，服务端记录拒绝原因。
第三步：设计重放防护
对允许的 0-RTT 请求要求 nonce 或幂等键，并在短窗口内做去重。多节点部署可使用区域级共享存储、带 TTL 的键集合，或把请求限制到能保证一致性的路由。防护状态不可阻塞主握手路径。
第四步：处理拒绝与重试
服务端可拒绝 0-RTT；客户端必须等待握手完成后以 1-RTT 重试，不能把早期请求和重试当两次业务操作。响应携带 requestid、attempt 和 replaysafe 标记，方便下游去重。
第五步：保护负载均衡与缓存
边缘层只把重放安全的请求转发到支持 0-RTT 的后端。缓存键不能包含会变化的票据，私有响应不得被共享缓存。跨区域路由切换时，优先降级到 1-RTT，避免重放状态不一致。
第六步：验证与渐进发布
在测试环境录制并重复发送同一 0-RTT 包，覆盖不同节点、区域、票据过期和版本升级。先对只读接口小流量启用，再观察拒绝率、重复拦截率、业务副作用告警和握手延迟，最后决定是否扩大范围。
高质量示范回答
“我不会把 0-RTT 当成通用加速开关。服务端先维护接口清单：无副作用读取可启用；幂等写只有在业务键和 nonce 能保证重复执行结果一致时才考虑；扣款、创建订单、发放权益和刷新令牌一律等 1-RTT。
票据绑定租户、服务版本和有效期，密钥轮换让旧票据尽快失效。允许的请求带 requestid 与幂等键，边缘和后端在短 TTL 共享集合中检测重放；无法共享状态的跨区切换直接拒绝 0-RTT。拒绝后客户端等待握手完成，以同一 requestid 在 1-RTT 重试，服务端按 revision 或幂等键只保留一次业务效果。
我会用回放包、并发重放、节点切换、票据过期和版本混跑做攻击测试，并监控 0-RTT 接受率、拒绝率、重放拦截率、重复业务告警、票据年龄和 p95 首字节延迟。发布采用只读接口到低风险写接口的分阶段开关。”
常见错误
- 看到 GET 就无条件放行 → 查询也可能触发计费或日志副作用 → 按业务效果分类并审查组合操作。
- 把 0-RTT 当成已认证请求 → 重放者可重复提交早期数据 → 等待 1-RTT 或建立明确的重放防护。
- 只在单机内存去重 → 负载均衡后另一节点再次执行 → 使用共享短 TTL 状态或限制路由并降级。
- 拒绝后重新生成业务键 → 1-RTT 重试变成新操作 → 复用 request_id 与幂等键。
- 票据长期有效 → 密钥和权限变化后风险持续 → 绑定范围、缩短 TTL 并轮换密钥。
- 只测延迟不测攻击 → 上线后才发现副作用重复 → 录制、回放并验证业务效果只发生一次。
- 把缓存和票据混为一谈 → 私有响应被错误共享 → 缓存键、授权和 0-RTT 状态分层设计。
追问及应对
追问一：幂等操作就一定能用 0-RTT 吗？
不一定。多步组合可能把多个幂等动作组成非幂等序列，还要考虑权限、库存、配额和外部通知等副作用。必须以业务效果验证。
追问二：服务端如何知道请求是否被重放？
可用短 TTL 的 nonce 或 request_id 集合、票据使用窗口和跨节点共享状态。检测失败时宁可拒绝 0-RTT，改走 1-RTT。
追问三：0-RTT 被拒绝后会丢数据吗？
应用协议应定义回退。客户端保留请求，完成握手后以 1-RTT 重试；服务端通过幂等键保证早期尝试若已生效也不会重复。
追问四：为什么跨区部署更难？
重放状态、票据密钥和版本可能不同。共享状态成本高时，应按区域绑定票据，切换区域立即拒绝早期数据。
追问五：如何逐步关闭 0-RTT？
先停止签发新票据，再让旧票据自然过期或主动拒绝，观察拒绝率与回退成功率。保留 1-RTT 路径和告警，避免客户端无声失败。
来源一：RFC 9001
RFC 9001 说明 0-RTT 缺少重放保护，应用数据必须由应用协议定义可接受的使用方式，不能默认承载有副作用的操作。
来源二：RFC 9308
RFC 9308 说明重放可能让服务端多次处理同一数据，并建议限制为无持久效果或幂等操作，同时分析组合操作的风险。
来源三：Algoroq 网络面试指南
公开网络面试指南把 QUIC、0-RTT、低延迟与重放风险放在同一追问链中，为本题的面试场景提供依据。