Why the TLS Handshake Cost Three Round Trips and How to Lose Two

The first request paid for DNS, the TCP connect and a full TLS 1.2 negotiation before a single byte of the response arrived, and the round trips were the…

Share
Why the TLS Handshake Cost Three Round Trips and How to Lose Two. Abstract deep dive illustration in orange and dark grey on debugly.dev

The slow behaved. The cost of the round trips behaved. The chain between them is where working as designed stopped meaning working.

Here is the shape of the connection setup cost, and the one property that makes it dominate: the round trips are serial, so the total is the sum, and the sum is proportional to the distance, and the distance is the speed of light, which no amount of bandwidth fixes.

This applies to any HTTPS site, and the mechanism is the protocol's handshake, which is the same regardless of the server.

Where the round trips go

The browser needs the address, and the address is the DNS, and the DNS is the lookup, and the lookup is the round trip, and the round trip is the first. The browser then connects, and the connect is the TCP handshake, and the handshake is the SYN and the SYN-ACK and the ACK, and the exchange is the second round trip. The browser then negotiates the encryption, and the negotiation is the TLS handshake, and the TLS 1.2 handshake is two round trips, and the two are the third and the fourth, and the four are the total, and the total is the wait before the first byte.

The four round trips are the setup, and the setup is the cost, and the cost is the latency, and the latency is the distance times the count, and the count is the four, and the four is the protocol, and the protocol is the fix's target, and the target is the reduction, and the reduction is the fewer trips, and the fewer is the faster, and the faster is the user's experience.

The bandwidth does not help, because the round trips are the latency, and the latency is the propagation, and the propagation is the speed of light, and the speed of light is the limit, and the limit is the reason the reduction is the count rather than the size, and the count is the handshake's structure, and the structure is the protocol's version.

Why TLS 1.3 is the big win

TLS 1.3 removed a round trip from the full handshake, and the removed is the one, and the one is the twenty five percent, and the twenty five percent is the saving, and the saving is the latency, and the latency is the fix. TLS 1.3 also added session resumption with zero round trips, and the zero is the returning visitor's cost, and the cost is the cached session, and the cached is the resumption, and the resumption is the fix, and the fix is the configuration, and the configuration is the version.

The version is the cheapest fix in this list, because it is a setting, and the setting is the server's, and the server's is the one change, and the one change is the round trip, and the round trip is the latency, and the latency is the user's wait, and the wait is the fix's value.

This is the same shape as the TCP retransmission that became the p99, and the common root is the property, not the platform.

The fix, in order

Enable TLS 1.3. The handshake drops a round trip, and the resumption drops to zero, and the zero is the returning visitor's cost, and the cost is the saving, and the saving is the fix, and the fix is the setting, and the setting is the server's configuration, and the configuration is the one change with the largest effect.

Preconnect to the origins you will need. The browser starts the DNS and the TCP and the TLS early, and the early is the overlap, and the overlap is the hidden cost, and the hidden is the saving, and the saving is the fix, and the fix is the link tag, and the tag is the hint, and the hint is the one line in the head, and the line is the parallel setup.

Reduce the number of origins. The origins are the separate connections, and the separate are the separate handshakes, and the handshakes are the round trips, and the round trips are the latency, and the latency is the sum, and the sum is the fix's target, and the target is the consolidation, and the consolidation is the fewer origins, and the fewer is the saving.

Use HTTP/2 or HTTP/3. The multiplexing is the one connection, and the one connection is the one handshake, and the handshake is the cost paid once, and the once is the saving, and the saving is the fix, and the fix is the version, and the version is the server's, and the server's is the configuration. HTTP/3 also removes the TCP handshake by running over UDP, which is another round trip saved.

Cache the session and the DNS. The session ticket is the resumption, and the resumption is the zero round trips, and the DNS cache is the skipped lookup, and the skipped is the saving, and the saving is the fix, and the fix is the TTL, and the TTL is the configuration, and the configuration is the discipline.

If it happens again

The first request to an HTTPS origin pays for DNS, the TCP connect and the TLS handshake in serial, so the latency is the sum of the round trips and bandwidth does not reduce it. Enable TLS 1.3, preconnect to the origins you need, consolidate origins, use HTTP/2 or HTTP/3, and cache the session and the DNS.

The page took three hundred milliseconds before the first byte and the response was four kilobytes, so the transfer was not the problem, the setup was. The lesson I keep is the property, not the incident.


Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud