Why does the TLS handshake take so many round trips before any data is sent?

A fresh TLS connection takes three round trips before the first byte of a page arrives: one to open the transport connection, one for the handshake, and one for the request and response. The handshake itself is one round trip in modern TLS, not because key exchange is slow, but because its messages do three separate jobs: agree a secret, prove who is answering, and confirm that nothing in the handshake was altered.

Put the cost in one line. Let $r$ be the round trip time and $p$ the server's working time after the request arrives. The delay before the first byte is $t = n r + p$, where $n$ is the number of round trips before the request can be answered. The term that hurts is the product $n r$: a server can often produce a page in tens of milliseconds, while one crossing between continents is $150$ ms or more.

The messages look numerous because each one has a different job. The client's first flight carries supported versions, cipher suites, and a key share for the group it guesses the server will accept. The server's reply carries its own key share and the chosen version and cipher. From those two shares both sides compute the same secret, and everything after the server's reply is encrypted. The server then sends its certificate chain, a signature over the transcript so far, and a finished value. The client validates the chain, checks the signature, and sends its own finished value before the request.

The natural mistake is to treat the whole handshake as one key exchange with extra packaging. If that were true, the certificate and signature would be redundant. A certificate is a public document, so presenting it proves only that the sender has a copy of it. The signature is what proves possession of the matching private key, and it is computed over every byte of the handshake so far, including the client's fresh key share. An attacker replaying a recorded certificate and signature into a new conversation would be signing a different transcript, and the check would fail. The finished messages then cover the whole transcript with the derived keys, so any alteration anywhere in the handshake shows up at the end.

Several messages do not mean several round trips. The server can put its key share, certificate, signature and finished value into one flight, and the client's first flight is one crossing in the other direction. The handshake costs one round trip because the client guesses the key agreement group in its first message rather than negotiating it. Older designs asked which group to use, waited for the answer, then sent a share, which added exactly one round trip. The guess is right almost always, and a wrong guess costs a retry rather than a redesign.

Resumption removes the identity exchange but not the crossing. After a successful handshake the server can give the client a ticket, an encrypted record of the secret to use next time. On a later visit the client sends the ticket in its first message, both sides derive keys from the remembered secret, and the certificate, signature and chain validation disappear. The handshake still costs one round trip, but with much less work. Early data removes the crossing itself: a resuming client attaches application data to its first message, encrypted under the remembered secret, before hearing anything from the server in this conversation. The page can then start coming back in one round trip instead of two.

The cost of early data is exact. The client has not yet seen a value chosen by the server for this conversation, so the first message has no freshness. An attacker who records it can send the same bytes again later, and the server cannot tell the difference. That makes early data safe for a request whose repetition is harmless, which is most page reads, and unsafe for anything that changes state or moves money. The zero round trip figure also assumes a ticket is already held; without resumption the full handshake is still one round trip. And the one round trip handshake figure assumes modern TLS with the key share guess; an older handshake that negotiates the group first pays two.