摘要

  • QUIC 握手完成是本地、依赖观察端点视角的状态，两个端点不会必然同时完成。
  • 在客户端，HANDSHAKE_DONE 或符合条件的 1-RTT ACK 可以支持确认；确认之后必须丢弃 Handshake 密钥。
  • 在宣布服务就绪前，必须把握手证据与 0-RTT 决策及应用结果结合起来。

问题往往从一个绿色仪表盘开始。收到 HANDSHAKE_DONE 后，系统把状态改成就绪，观察者便容易把这个信号理解为请求可以安全执行。但服务器可能已经拒绝了早期数据。此时客户端必须重置所有相关流，也必须重置绑定在这些流上的应用状态。绿色信号本身没有错，错误在于把它解释成了比规范更宽的结论。

RFC 9001 对握手完成的定义是本地的。只有当本地 TLS 栈已经发送 Finished 消息并验证对端的 Finished 消息时，握手才算在该端完成。这一条件不会在两个端点同时成立。因此，记录和告警必须保留观察者是谁，而不能把一个端点的进展写成双方同时到达的共同时刻。

确认规则还取决于端点角色。服务器一侧，握手完成时握手即被确认，并且服务器必须在握手完成后尽快发送 HANDSHAKE_DONE。客户端一侧，收到 HANDSHAKE_DONE 即表示确认；客户端也可以根据覆盖其使用 1-RTT 密钥发送的某个数据包的 ACK 来推断确认。RFC 9000 规定只有服务器可以发送 HANDSHAKE_DONE。客户端从该帧得知服务器收到了并处理了客户端的 Handshake 数据包，但这仍然是连接状态信号，不是应用层响应。

确认的直接后果是密码密钥生命周期发生变化。确认成立后，端点必须丢弃 Handshake 密钥，Handshake 密码阶段由此退役。这一转换没有说明应用协议是否完成了自己的协商，没有说明请求是否进入应用代码，也没有说明后端依赖、授权服务或持久化存储是否正常。

Initial 密钥的丢弃是另一件事。客户端第一次发送 Handshake 数据包时丢弃 Initial 密钥；服务器第一次成功处理 Handshake 数据包时丢弃 Initial 密钥。这里的证据和时机都不同。Initial 密钥不再需要，并不等于握手已经确认；将 Initial 密钥与 Handshake 密钥的丢弃合并成一个事件，会让连接记录失去关键边界。

0-RTT 也必须单独记录。服务器在 EncryptedExtensions 中包含 early_data 扩展时接受 0-RTT，省略该扩展时拒绝 0-RTT。拒绝后，服务器不得处理 0-RTT 数据包，客户端必须重置所有流，包括与这些流绑定的应用状态。之后出现 HANDSHAKE_DONE，也不能把已经拒绝的早期数据变成已接受的工作。

重放安全属于应用协议的责任。RFC 9001 说明，0-RTT 中的应用数据可能因重放而被处理多次。客户端只有在应用明确要求时才应使用 0-RTT 应用数据，而应用协议必须定义可接受的使用方式。握手完成或确认都不能追溯性地证明早期工作具备重放安全性、已经精确执行一次，或已经提交成功。

符合条件的 1-RTT ACK 同样有明确边界。它覆盖客户端发送的最低 1-RTT 包号时，只能建立 RFC 9001 定义的确认条件；它不能证明应用已经消费数据、数据已经持久化、授权已经通过，或业务请求已经完成。最准确的说法是：确认是密码状态收据，而不是应用成功收据。