Resuming a previous relationship
If the client previously connected successfully, the server can supply information supporting future resumption, commonly through a TLS 1.3 resumption ticket. The client can derive a pre-shared-key identity from that ticket and try a resumed handshake. Server policy, ticket validity, key rotation and the selected cryptographic parameters determine whether resumption is accepted. A ticket is not an everlasting credential or proof that a client can skip authenticating the service it reaches.
For accepted TLS 1.3 resumption, the client may send 0-RTT early data with its first flight rather than waiting for the new handshake to finish. This can matter on high-latency links. But early data is not protected against replay in the same sense as ordinary handshake-completed application data. A captured early-data flight can potentially be replayed under conditions the server and deployment must explicitly defend against.
The replay issue is about execution, not whether an attacker can read the encrypted payload. The encryption can be strong while a duplicated request still causes a duplicate purchase or transfer. TLS 1.3 also does not give 0-RTT data the same forward-secrecy properties as later traffic in the connection. Servers may reject early data, in which case the client needs a defined fallback and must not blindly issue harmful operations twice.
A payment request is the wrong first experiment
Suppose POST /charges creates a charge each time it executes and has no business idempotency contract. Sending it as 0-RTT exposes a replay-sensitive mutation earlier in the connection. Even a correctly implemented TLS stack does not know what that mutation means. The safer answer is to refuse early data for this endpoint. Later, the platform can design deduplicated payment identifiers, authenticated state transitions and an explicit application policy for request replay, but that does not make indiscriminate early data a sensible default.
You may hear that GET methods are safe. HTTP defines safe methods, but real services sometimes hide side effects behind GET routes. A GET endpoint that issues a password reset, changes inventory or triggers a job should not be treated as replay-safe just because of its verb. Even ordinary GET requests can have privacy, rate-limiting and cache implications. The deployment's replay-safety policy must reflect actual handler behavior and authentication context.
Anti-replay mechanisms can reduce risk, but distributed deployment complicates them. Imagine a ticket accepted by edge A and replayed through edge B. An edge-local replay cache does not automatically protect the whole acceptance domain. Bounded ticket age, shared replay tracking or server partitioning can help, each with availability and consistency costs. TLS 1.3 explicitly warns that preventing all replay requires more than treating the early-data flag as harmless.
Diagnose setup latency without overclaiming
I would instrument DNS resolution, TCP establishment, TLS negotiation, ALPN selection, ticket acceptance, and time to first response byte separately. If most calls reuse long-lived connections, handshake savings may barely change normal API latency. If radio networks repeatedly interrupt connections, reducing setup costs may help much more. But opening unnecessary connections to measure handshake speed could itself worsen CPU, certificate operations and port use.
On a 150 ms RTT path, a simplistic comparison suggests one fewer TLS round trip can save roughly 150 ms on a cold connection. It does not guarantee that observed end-to-end time falls by exactly that amount. Servers process handshakes, TCP setup may overlap other work, the client might use QUIC rather than TCP, and connection reuse might remove setup from most requests entirely. Measure the actual population of new versus resumed sessions.
My design would enable TLS 1.3, prefer connection reuse, ensure session-ticket rotation and key protection, and consider early data only for explicitly reviewed replay-tolerant operations. I would log early-data acceptance and rejection and exercise fallback under edge rotation. For payment mutations, the latency budget should be improved through endpoint placement, fewer round trips in the application workflow, and safe request contracts rather than through removing a security boundary.
At interview depth, remember the actual decision: TLS 1.3's shorter handshake is usually good. TLS 1.3 0-RTT is a separate application-security choice. That distinction leads into the next lesson about HTTP/2 and HTTP/3, where removing one kind of transport blocking can improve some request patterns but cannot remove every source of delay.
