How a CDN puts your content next door

A site is hosted in Virginia. You open it from Beijing, and the images arrive from a machine in Tianjin. That is not a mirror site; it is a CDN — a content delivery network.

What it does sounds simple: move content close to users ahead of time. What makes it complicated is deciding close to whom, figuring out where the user is, and handling the case where the guess was wrong.

Image: Derrick Coetzee, CC0, via Wikimedia Commons.

Three jobs: cache, steer, fetch

Everything a CDN does decomposes into three actions:

Action	What it does	The hard question
Cache	store content on edge nodes	for how long, and when to invalidate
Steer	send users to the nearest node	how do you know what is nearest
Fetch	go to the origin on a miss	does that fallback crush the origin

Of the three, only the first saves time and money; the other two are safety nets. A good CDN is one with a high hit ratio and a fallback that holds when it misses.

Cache hit ratio is the only metric that matters

Hit ratio = requests answered at the edge / total requests. Its power is badly underrated:

• 90% hit ratio → 10 of every 100 requests reach the origin;
• 99% hit ratio → only 1 of every 100 does.

Nine percentage points sounds small. It is a tenfold difference in origin traffic — and origin traffic costs money, because it consumes origin bandwidth and carries latency.

A low hit ratio usually comes down to a few causes:

1. Too fine a cache key. The default key includes the full query string, and many sites hang tracking parameters off URLs (?utm_source=...&gclid=...). One image gets stored dozens of times, each copy hit once. The fix is configuring which parameters to ignore.
2. Too short a TTL. Sixty seconds means a fetch every minute. Static assets can use content-hashed filenames and a one-year immutable TTL instead.
3. Cookies or Vary fragmenting it. Many CDNs skip caching when a request carries Cookie, and Vary: User-Agent is a disaster — one cache entry per browser version.
4. Wrong headers from the origin. Cache-Control: private or no-store makes the CDN give up entirely.

Conversely, purging has to be ready before you need it. Content-hashed filenames make it unnecessary at release time; a config.json mistakenly marked long-lived will have you staring at stale config for half an hour after a deploy.

Image: Preston Keres / USDA, public domain, via Wikimedia Commons.

The edge is not just a cache

A modern edge node does far more than cache. Typical roles:

• TLS termination: handshakes complete at the edge, the origin sees plaintext or one long-lived connection. Certificates are managed centrally, and OCSP stapling happens at the edge;
• Protocol upgrades: HTTP/3 and Brotli need both ends to cooperate, and an edge can adopt them faster than an origin;
• WAF and bot management: keeping attack traffic away from the origin is the most underrated part of a CDN — it is also the first layer of DDoS defence;
• Image transcoding: generate WebP or AVIF thumbnails at the edge based on the Accept header or URL parameters, storing only originals at the origin;
• Edge functions: small pieces of code at the node for rewrites, A/B tests and auth.

Once you count all of that, “CDN” is a poor name. It is really the proxy layer closest to the user.

How “nearest” gets computed

Two dominant mechanisms, often used together:

DNS steering. The authoritative nameserver returns different IPs depending on where the recursive resolver sits. Simple and effective, with one built-in flaw: a resolver like 8.8.8.8 can be half a world away from the actual user, so steering by resolver location points at the wrong place. Hence EDNS Client Subnet — the resolver includes a prefix of the user’s network in the query so the authoritative server can answer more accurately.

Anycast. The same IP is announced from many nodes at once, and BGP decides which path traffic takes. To the user it is always the same address; where it actually lands is decided by routing tables. It is naturally resilient to DDoS (traffic is spread out) and to failure (a dead node just loses the route).

Image: Fabienne Serriere, CC BY-SA 3.0, via Wikimedia Commons.

Why everyone fights to get into an exchange

Nodes are useless without paths. The internet is not a uniform mesh, and links between networks come in two kinds:

• transit: pay another network to carry your traffic, billed by bandwidth;
• peering: two networks exchange each other’s traffic for free.

The overwhelming majority of CDN traffic is downstream to users — it sends far more than it receives. That traffic profile is commercially advantaged: carriers are happy to peer for free, because the content users want is already inside the CDN.

The physical place where peering is negotiated is the internet exchange (IX) — AMS-IX in Amsterdam, DE-CIX in Frankfurt, and so on. How many exchanges a CDN has ports in directly determines how much of the world it can cover for free. Getting into exchanges is not technical fastidiousness; it is the cost structure.

My take

The most common mistake a personal site makes with a CDN is fixating on “speed”. For a small site, two other things are worth more:

1. Hiding the origin IP. An exposed origin gets scanned, then crawled and attacked without end;
2. Free HTTPS and absorption capacity. Automatic certificate renewal and hundreds of Gbps of DDoS protection in front of you — costing out what it would take to build that yourself is not worth the effort.

As for the actual “local acceleration”: if your server already sits in the country your users are in, the gain is far smaller than the marketing suggests. Work out what you are buying before you buy it.