# What Is 0-RTT (TLS 1.3 early data)? Definition and Examples

> 0-RTT is a TLS 1.3 and QUIC feature that lets a returning client send application data in its very first flight, using a key from a previous session.

Source: https://ssl.sh/glossary/0-rtt/
Last updated: 2026-11-10

0-RTT, called early data in the TLS 1.3 specification ([RFC 8446](https://www.rfc-editor.org/rfc/rfc8446), now [RFC 9846](https://www.rfc-editor.org/rfc/rfc9846)), works only on resumed connections. During an earlier session the server issued a [session ticket](https://ssl.sh/glossary/session-ticket/) that establishes a [PSK](https://ssl.sh/glossary/psk/); on the next connection the client sends its ClientHello and, in the same flight, application data encrypted with a key derived from that PSK, without waiting for the server's reply. QUIC offers the same mechanism.

## Why it matters
It removes a full round trip for repeat visitors, which is noticeable on high-latency mobile links. The cost is weaker guarantees for the early data. It is not protected against replay, so an attacker who captures it can send it to the server again, and it lacks [forward secrecy](https://ssl.sh/glossary/forward-secrecy/) with respect to the PSK. Servers should therefore accept 0-RTT only for requests that are safe to repeat, such as GET requests without side effects. RFC 8470 defines the `Early-Data: 1` request header and the 425 (Too Early) status code so that a backend can refuse early data it cannot handle safely.

## Example
nginx can accept early data and tell the backend about it:

```nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_early_data on;
proxy_set_header Early-Data $ssl_early_data;
```

The application should then answer 425 to any state-changing request that arrives with `Early-Data: 1`, and the client retries it after the handshake completes.

## Common misconceptions
- **0-RTT speeds up the first visit.** A first connection has no PSK, so it always needs a full handshake; only resumed connections can use 0-RTT.
- **0-RTT data is as secure as normal TLS 1.3 data.** Only the early data loses replay protection and forward secrecy; everything sent after the handshake completes has full TLS 1.3 protection.
- **Turning it on is a free performance win.** Without application-level replay handling it can duplicate payments, orders or other state-changing requests.

## Related terms

- [会话恢复](https://ssl.sh/zh/glossary/session-resumption/): 会话恢复是 TLS 的一种机制，客户端重连时复用先前会话的密钥材料，跳过完整的密钥交换和证书验证。
- [Session Ticket](https://ssl.sh/zh/glossary/session-ticket/): Session Ticket 是服务器交给客户端保管的加密会话状态，客户端下次连接时出示它即可恢复会话，服务器无需保存任何状态。
- [PSK](https://ssl.sh/zh/glossary/psk/): PSK（预共享密钥）是 TLS 双方在握手前就已共同持有的秘密，用于会话恢复，或在不使用证书的情况下完成身份认证。
- [TLS 1.3](https://ssl.sh/zh/glossary/tls-1-3/): TLS 1.3 是当前最新的传输层安全协议版本（2018 年的 RFC 8446，现行规范为 RFC 9846），完整握手只需一个往返，且只保留 AEAD 加密算法。
- [QUIC](https://ssl.sh/zh/glossary/quic/): QUIC 是基于 UDP、始终加密的传输协议，把 TLS 1.3 握手内置在传输层中，HTTP/3 就运行在它之上。
- [前向保密](https://ssl.sh/zh/glossary/forward-secrecy/): 前向保密是密钥交换的一种安全属性：即使服务器的长期私钥日后泄露，过去连接的会话密钥也不会因此暴露。