TLS Handshake (1.2 vs 1.3)

TechniqueNetworking and OSMidSeniorUpdated Nov 10, 2026

TLS 1.2 needs 2 round trips before app data flows. TLS 1.3 collapses that to 1 round trip (1-RTT) for new sessions and 0 round trips (0-RTT) for resumed ones using pre-shared keys (PSK).

When to Use TLS Handshake (1.2 vs 1.3)

Any HTTPS edge where latency matters. Forcing TLS 1.3 on your load balancer typically saves 50-100ms per new connection vs 1.2, more on high-RTT mobile links.

In Practice

Cloudflare and Fastly default to TLS 1.3 with 0-RTT optional. 0-RTT lets a returning client send a GET inside the first packet, but the server must treat 0-RTT data as replayable, so it is limited to idempotent reads.

How TLS Handshake (1.2 vs 1.3) Comes Up in Interviews

Scenario

TLS is terminating at the edge and you want returning clients to skip the full handshake on subsequent connections. What is the modern answer?

TLS 1.3 session tickets plus 0-RTT. The server issues a pre-shared key (PSK) ticket; on the next connection the client sends app data in the very first packet. Keepalive helps within a connection; this helps across connections.

0-RTT data is replayable, so only use it for idempotent requests (GETs). For mutations, force 1-RTT. Cloudflare publishes a good writeup on bounding the replay window with anti-replay caches.

Scenario

You type https://shop.example.com into a browser. DNS returns the server's IP address and the TCP three-way handshake completes. Before the browser can send GET /, the two sides verify the server's certificate and agree on encryption keys. What is that step?

The TLS handshake proves the server holds the certificate for shop.example.com and sets up the keys that encrypt everything after it. TLS 1.3 needs one round trip for a new connection. Keepalive reuses a connection that has already finished this step, and HTTP/2 multiplexing runs many requests over that connection afterward.

The full path, in order: DNS lookup (cached by the browser, the OS, or a resolver), TCP handshake (SYN, SYN-ACK, ACK), TLS handshake, then the HTTP request with its method, path, headers such as Host and Cookie, and an optional body. The server returns a status line, headers, and a body, and the browser parses the HTML and fetches the CSS, JavaScript, and images it references. Each of the first three steps costs at least one round trip, which is why connection reuse and servers close to the user cut page load time.