0-RTT 早期数据和会话恢复

🌐 0-RTT early data and session resumption

QUIC 支持 0-RTT 提前数据，允许之前已与服务器建立连接的客户端在发送握手完成前的第一个数据包时发送应用数据。这可以在重新连接时消除一次完整的往返延迟。

🌐 QUIC supports 0-RTT early data, allowing a client that has previously connected to a server to send application data with its very first packet, without waiting for the handshake to complete. This can eliminate a full round-trip of latency on reconnection.

先前连接的两个状态使这成为可能：

🌐 Two pieces of state from a prior connection make this possible:

• 通过 session.onsessionticket 回调接收的 会话票证，使 TLS 会话恢复和 0-RTT 加密成为可能。在后续与同一服务器的连接中，将其作为 sessionOptions.sessionTicket 选项传递。
• 通过 session.onnewtoken 回调收到的 地址验证令牌 允许客户端跳过服务器的地址验证步骤（避免重试往返）。将其作为 sessionOptions.token 选项传递。

如果服务器接受会话票证，在握手完成之前发送的任何数据都是 0-RTT 早期数据。在服务器端，stream.early 对于携带早期数据的流是 true。服务器可以拒绝 0-RTT 尝试（例如，如果自票证发出以来其配置已更改）。当这种情况发生时，在 0-RTT 阶段打开的所有流都会被销毁，并且客户端的 session.onearlyrejected 回调会触发。连接会回退到正常的 1-RTT 握手，应用可以重新打开流。

🌐 If the server accepts the session ticket, any data sent before the handshake completes is 0-RTT early data. On the server side, stream.early is true for streams carrying early data. The server can reject the 0-RTT attempt (for example, if its configuration has changed since the ticket was issued). When this happens, all streams opened during the 0-RTT phase are destroyed and the client's session.onearlyrejected callback fires. The connection falls back to a normal 1-RTT handshake and the application can reopen streams.

早期数据的安全性低于握手完成后发送的数据——它可能会被攻击者重放。应用应谨慎处理 0-RTT 数据，并在早期数据阶段避免执行非幂等操作。

🌐 Early data is less secure than data sent after the handshake completes — it can potentially be replayed by an attacker. Applications should treat 0-RTT data with appropriate caution and avoid performing non-idempotent operations during the early data phase.