Cloudflare

Cloudflare's smarter TLS handshake cuts latency by over 150 milliseconds

Cloudflare's decision to replace static origin TLS guesses with per-origin measurement is a smart, practical win.

3 min readInfoQ
Cloudflare's smarter TLS handshake cuts latency by over 150 milliseconds

The quietest infrastructure wins are the ones you never notice. Cloudflare just proved that with a change so elegant it sounds obvious in hindsight: stop guessing which TLS key exchange your origin server supports, and measure it instead. For years, the company sent a static X25519 guess at the start of every origin handshake. When that guess missed, the server had to bounce back with a HelloRetryRequest, adding a full round trip and, in the worst cases, over 150 milliseconds to p90 latency. After switching to per-origin measurement, retries on scanned origins collapsed from 52% to 3.7%. That is not an incremental tweak. That is a structural rethink of how we assume the internet should behave.

The practical lesson here is one we have been circling for a while, and it connects directly to Cloudflare's Data Innovation Frees 100 TB, Boosts DNS Performance. In both cases, the win comes from questioning a default rather than adding a new feature. The DNS cache redesign made better use of memory by changing how entries were represented, not by throwing more hardware at the problem. This TLS work follows the same logic: the protocol was not broken, but the assumption baked into it was. Static defaults are comfortable. They are also, increasingly, a tax we pay in milliseconds. When you think about how many handshakes happen per second across Cloudflare's network, shaving a round trip off even a fraction of them is not a micro-optimization. It is the difference between a user feeling like the page loaded instantly and watching a spinner spin.

The post-quantum angle is where this gets genuinely interesting, and a little sobering. On scanned origins, the share of post-quantum connections completing in a single round trip jumped from 0% to 99.2%. That is a stunning number, but it comes with a caveat that should ground our enthusiasm: only 12.8% of origins actually support post-quantum key exchange in the first place. So we have built a fast lane, but most of the road is still unpaved. That is not a reason to dismiss the achievement. It is a reminder that the frontier of performance is often ahead of the frontier of adoption. For teams running their own origins, this should be a nudge to check whether you have even enabled post-quantum support, because the tools are there and the speed is real, but only if you opt in.

What we would tell a reader asking for advice is straightforward: do not wait for the protocol to force your hand. The same mindset that led Cloudflare to measure instead of guess is available to you. Look at your own handshake paths, your own cache representations, your own default settings. Ask where you are guessing. Then measure. Cloudflare also recently shared how it rebuilt its blog on EmDash, its own CMS, Cloudflare's Blog Finds Performance Gains with EmDash, Its New CMS, which is another example of dogfooding your own assumptions until they bend to your will. The specific numbers here will fade, but the principle will not: the cheapest performance you will ever find is hiding in the assumptions you stopped questioning. Go find one.

From InfoQ

Cloudflare has replaced its static X25519 guess for origin TLS handshakes with per-origin measurement. HelloRetryRequests on scanned origins fell from roughly 52% to 3.7%, removing over 150 ms from p90 latency. Post-quantum connections completing in one round trip rose from 0% to 99.2%, though only 12.8% of origins support it.

Read the original at InfoQ