How a CDN works

The physics first: a user 150 ms from the origin pays that RTT for the TCP handshake, once or twice more for TLS, and then again for every slow-start round of the response — so a 100 kB asset costs 4–6 round trips, close to a second, before bandwidth even matters (Bandwidth vs Latency). An edge 10 ms away shrinks each of those round trips by 15×. A CDN is a fleet of points of presence that terminate the user’s connection nearby and serve from cache when they can. See CDNs: The Networking View.

Getting the user to a nearby edge is done one of two ways. DNS steering: the CDN’s authoritative servers answer assets.example.com with an edge IP chosen by the *resolver’s* location (improved by EDNS Client Subnet, which passes part of the client’s address), using short TTLs so decisions can change. It is precise and controllable but only as good as the resolver’s location — a user on a distant public resolver without ECS is sent to the wrong continent — and the low TTL costs extra lookups (Following One Lookup Through Every Cache). Anycast: every PoP announces the *same* IP prefix over BGP and the internet’s routing delivers each packet to the topologically nearest PoP (Internet Routing: Autonomous Systems and BGP). No DNS games and instant failover, but "nearest by BGP" is not always nearest by latency, and a route change can shift a live TCP connection to a PoP that has no state for it — rare in practice, and one reason QUIC’s connection IDs help.

The cache is keyed on URL (plus whatever Vary names) and governed by the origin’s headers: Cache-Control: public, max-age / s-maxage, stale-while-revalidate, stale-if-error; private, no-store or a Set-Cookie keep a response out. Hit ratio is the metric, and it is destroyed by unkeyed variety: Vary: Cookie or Vary: User-Agent, query strings in random order, per-user URLs. Content-hashed filenames with a year-long TTL plus a short TTL on the HTML that references them is the standard pattern; purging is the escape hatch and it is eventually consistent across PoPs.

For uncacheable responses the CDN is still a fast front door. The TCP and TLS handshakes happen against the 10 ms edge instead of the 150 ms origin; the edge holds warm, pooled, already-slow-started connections to the origin, so the user’s request rides an established path; the edge speaks HTTP/3 and Brotli to the user while the origin speaks HTTP/1.1; the CDN’s private backbone often beats the public internet between edge and origin; a shield or tiered cache collapses thousands of edge misses into one origin request; and DDoS traffic is absorbed at the edge. The trade-off is that the CDN is now an L7 proxy with everything that implies (Forward and Reverse Proxies): it has its own timeouts and error codes, the origin sees CDN IPs, and it is a single vendor whose outage takes every customer down at once.