Counting Round Trips in Connection Setup

On a path with 150 milliseconds of round-trip time, a request that requires four serial round trips before the server can begin producing a response spends 600 milliseconds on nothing. The bytes involved are trivial; the cost is entirely the waiting, and it is the sum of independent negotiations that each had to finish before the next could start. Reducing that count is the single largest lever available to a protocol designer working over long paths, larger than any tuning of congestion control or buffer size.

The count is not fixed. Some steps can be overlapped, some can be eliminated by remembering state from an earlier connection, and some are only visible when a new name or a new certificate is involved.

The baseline: name, transport, security, request

A cold request from a client that has never contacted the server involves four distinct exchanges.

Name resolution: the client must learn an address for the hostname. If the answer is not cached, the resolver queries a recursive server, which may in turn query authoritative servers. A typical cold lookup involving a root, a top-level domain, and an authoritative server is three or four round trips from the recursive resolver to the authority chain, plus one between the client and the recursive resolver. From the client’s perspective the visible cost is one round trip if the recursive resolver has the answer cached and several if it does not. The client can start this before it knows the address, so it is the first serial step.

Transport handshake: TCP connection establishment takes one round trip. The client sends a synchronise segment with its initial sequence number; the server replies with its own synchronise and an acknowledgement; the client acknowledges. The client can send data with that third packet, so a TCP handshake costs one round trip of delay before data can be in flight, not one and a half.

Security negotiation: TLS 1.3 takes one round trip for a full handshake. The client sends a ClientHello with a key share; the server responds with its own key share, certificate, and finished message; the client can then send application data. Earlier protocol versions took two round trips for a full handshake, and a session resumption could reduce that.

Request and response: one round trip, at minimum, for the request to reach the server and the first response byte to return.

The cold total is therefore four round trips, and at 150 ms that is 600 ms before the server has done any work. The same request on a warm connection with a cached address is one round trip, 150 ms. The gap between those two figures is the entire subject.

What a handshake round trip actually contains

It is worth being precise about why each exchange costs a full round trip rather than half of one. The client sends a message and must wait for the reply; during that wait it cannot proceed, because the reply contains information it needs. In the TCP case the client needs the server’s initial sequence number before it can send data that the server will acknowledge correctly, and it needs confirmation that the server is listening at all. In the TLS case the client needs the server’s key share before it can derive the traffic keys, and it needs the certificate to verify the server’s identity.

The waiting is unavoidable given the message contents, but the number of waits is a design choice. TLS 1.3 reduced the full handshake from two round trips to one by having the client guess the key agreement group and send its share in the first message, so the server can compute the shared secret immediately. If the guess is wrong the server sends a retry message and the handshake costs an extra round trip, which is the price of the optimisation. The design trade is explicit: a common case that is one round trip faster, in exchange for a rare case that is one round trip slower.

A second reduction is available when the client has connected before. A pre-shared key established in an earlier session lets the client send encrypted application data in its first message, so the handshake costs zero additional round trips from the client’s perspective. The server’s response arrives one round trip later, so the request-response exchange is still one round trip, but the security negotiation has been folded into it. This is what “zero round trip” means in practice: the negotiation did not disappear, it was moved into the same flight as the payload.

Overlapping the steps that do not depend on each other

The four steps are serial only if each one’s output is needed by the next. Name resolution produces an address that transport needs, so it must precede the transport handshake. Transport must be established before security can run over it, in the common case. Security must complete before the request can be sent, unless the protocol allows early data.

Two of those dependencies can be broken.

The address can be learned in parallel with other work. A client that already has an address for a hostname from a previous connection can open the transport connection immediately and refresh the address in the background. This is why a cached but stale address is often faster than a fresh lookup: the stale address is probably still correct, and if it is not, the connection attempt fails quickly and the client retries with a fresh lookup. The cost of being wrong is one failed connection attempt, which is cheaper than a serial lookup on every request.

Security can be overlapped with transport when the protocol supports it. TLS over TCP must wait for the TCP handshake, because the TLS records travel inside TCP segments. TLS over a transport that carries the handshake in the same flight, or a protocol that combines transport and security negotiation, can collapse the two into one round trip. The general principle is that the number of serial waits equals the number of dependency edges in the protocol’s message graph, and removing an edge requires either pre-computing the information or sending it speculatively.

The cost of a round trip on the wire

The reason round trips matter so much is that each one costs the full path latency, not the serialization time of the messages involved. A TLS ClientHello is a few hundred bytes and its serialization time on any modern link is microseconds, as the arithmetic in serialization delay and the cost of small packets shows. The round trip is 150 ms because the path is 15,000 kilometres long and light takes that long to cross it twice. The messages are essentially free; the waiting is not.

That gives a simple budget rule. On a path with round-trip time $R$, a protocol that needs $k$ serial round trips before the first payload byte has a floor of $kR$ plus the server’s own processing time. Nothing about bandwidth, congestion control, or buffer size changes that floor. A connection that needs four round trips has a floor of 600 ms at 150 ms $R$ regardless of whether the link is 10 Mbit/s or 100 Gbit/s.

The same rule explains why connection reuse is worth more than almost any other optimisation on long paths. A client that keeps a connection open and reuses it converts a four-round-trip cold request into a one-round-trip warm request. The saving is three round trips, and it recurs on every request that the connection serves. Each round trip is itself the sum of propagation, serialization, queueing, and processing across the path, and decomposing path latency separates those terms.

There is a countervailing cost. An idle connection consumes state on the server and on any middlebox that tracks it, and a middlebox may silently drop the state after a timeout that the endpoints do not know about. A client that reuses a connection the path has forgotten sends its request into a black hole and waits for a timeout, which is far worse than a fresh handshake. The design has to include a way to detect that case, and the failure mode is the reason keep-alive intervals are chosen conservatively rather than aggressively.

Where the round trips hide

Three places hide round trips that are easy to overlook.

Redirects. A request that receives a redirect to a different hostname restarts the whole sequence for the new name: a new lookup, possibly a new connection, a new security negotiation. A single redirect on a cold path can double the cost of the request. Redirect chains multiply it.

Certificate retrieval. A server that must fetch an intermediate certificate or check a revocation list during the handshake adds a round trip to something else’s server, and that round trip may be longer than the client’s. The fix is to send the full chain and to use a revocation mechanism that does not require a live check during the handshake.

Connection establishment to a back end. The server that terminates the client connection may itself need to open a connection to a database or an upstream service, and that handshake happens inside the client’s waiting period. From the client’s view it is indistinguishable from server processing time, which is why a latency measurement that ends at the front-end server understates the true path.

The general diagnostic is to count dependency edges rather than messages. Each edge is a wait, each wait is a round trip, and the only ways to remove one are to pre-compute the information, to send it speculatively, or to remember it from a previous exchange. Protocol versions differ mainly in which of those three they chose.