A CDN (content delivery network) is a geographically distributed network of servers that stores copies of web content and delivers them to users from the location nearest to them, instead of from a single origin server. In content delivery on the Internet, a CDN sits between the origin and the audience as a large, shared reverse proxy and cache.
The purpose is threefold: lower latency, less load on the origin and better resilience against traffic peaks and attacks. Modern CDNs also terminate TLS, filter malicious requests and run code at the edge, but caching close to the user remains the core function.
How a CDN routes and serves a request
A CDN works by steering each user to a nearby Point of Presence and answering from cache whenever possible. The website’s hostname is pointed at the CDN, usually through a DNS CNAME record or by delegating the domain to the CDN’s name servers.
The CDN then selects a location by one of two methods. DNS-based routing returns the address of a nearby PoP based on the location of the resolver, while anycast routing announces the same IP address from every PoP and lets BGP deliver packets to the topologically closest one. Many providers combine both.
At the PoP, the edge server checks its edge cache. On a cache hit, it answers immediately; on a cache miss, it fetches the object from an upstream tier or the origin, returns it to the user and stores it for later requests, as long as the caching rules allow it.
The table below lists the main building blocks of a CDN.
| Component | Role | Effect on delivery |
|---|---|---|
| Point of Presence | A data center site hosting edge servers in a metro area | Shortens the network distance to users |
| Edge cache | Storage of objects on edge servers | Serves repeat requests without contacting the origin |
| Origin shield | A designated mid-tier cache in front of the origin | Collapses many edge misses into one origin request |
| Request routing | DNS or anycast steering to a PoP | Chooses a nearby, healthy location |
| Origin | The customer’s server or storage holding the original content | Remains the source of truth for all objects |
Why proximity reduces latency
Proximity matters because light in optical fiber travels at about 200,000 km per second, roughly two thirds of its speed in a vacuum, which adds about 1 ms of round-trip time per 100 km of fiber path. Real routes are longer than straight lines, so actual delays are higher.
Each new HTTPS connection needs several round trips before the first byte arrives: one for the TCP handshake, one for a TLS 1.3 handshake and one for the request itself. With HTTP/3 over QUIC, the transport and TLS handshakes are combined, which saves one round trip. Round-trip time multiplies through every handshake, so moving the server closer pays off several times over.
| Scenario | Round-trip time | Round trips over TCP and TLS 1.3 | Network time before first byte |
|---|---|---|---|
| Distant origin | 250 ms | 3 | About 750 ms |
| Regional origin | 40 ms | 3 | About 120 ms |
| Nearby CDN edge | 10 ms | 3 | About 30 ms |
The figures cover network round trips only and exclude server processing time. They show why a cache hit at a nearby edge can be an order of magnitude faster than a request served from another continent.
Caching rules and the cache hit ratio
A CDN caches only what the HTTP caching headers and the CDN configuration permit. The origin controls behavior mainly through Cache-Control directives, and the CDN builds a cache key, usually from the host, path and selected query parameters, to decide which requests share a stored copy.
| Directive | Meaning for the CDN | Typical use |
|---|---|---|
| max-age | How long a response stays fresh, in seconds | Versioned static assets, often one year |
| s-maxage | Freshness for shared caches only, overriding max-age | Longer edge caching than browser caching |
| no-store | Do not store the response at all | Personal or sensitive pages |
| private | Only the browser may store the response | Logged-in account views |
| stale-while-revalidate | Serve a stale copy while fetching a fresh one | News pages and listings that change often |
The key performance metric is the cache hit ratio, the share of requests answered from cache. At a 95% hit ratio, 10 million daily requests generate only 500,000 origin requests, a twentyfold reduction. Providers also report the byte hit ratio, which can differ widely because a few large files may dominate traffic volume.
When content changes before its lifetime ends, operators purge it by URL, tag or prefix. For static files, a more robust practice is file name versioning, such as a hash in the file name, which makes purges unnecessary.
Security and edge functions
Because all traffic passes through it, a CDN is also a natural security perimeter. Its aggregate capacity, usually measured in terabits per second across all PoPs, can absorb volumetric DDoS attacks that would overwhelm a single origin.
- TLS termination at the edge shortens handshakes for users, but it means the CDN can see decrypted traffic, which is a deliberate trust decision.
- A web application firewall and bot management filter malicious requests before they reach the origin.
- Origin protection works only if the origin accepts traffic solely from the CDN; an exposed origin IP address lets attackers bypass every edge control.
- Edge computing runs small programs at PoPs for redirects, header changes, personalization or authentication checks.
When a CDN helps and common mistakes
A CDN helps most when the audience is geographically spread and content is reusable across users. Its benefit is smaller for a local audience close to the origin or for responses that are unique to each user.
| Symptom | Likely cause | Fix |
|---|---|---|
| Low hit ratio | Cache key includes tracking parameters or cookies | Normalize the cache key and ignore irrelevant parameters |
| Users see outdated content | Long lifetimes without versioning or purge | Version file names and purge on deployment |
| One user sees another’s data | Personalized responses cached as public | Mark them private or no-store and vary the cache key |
| Origin overloaded after purge | Every PoP refetches at once | Use an origin shield and request collapsing |
The most serious mistake is caching personalized content as public, because it leaks private data at scale. Caching rules should be reviewed whenever an application adds login, cart or account features.
The short version
A CDN is like a chain of local warehouses for a website. Instead of shipping every order from one central factory, the company keeps popular items in warehouses near its customers, so deliveries arrive faster and the factory is not overwhelmed.
When you open a page, your request goes to the nearest warehouse. If the item is in stock, you get it immediately; if not, the warehouse fetches it once from the factory and keeps a copy for the next customer. The result is faster pages and a website that copes with crowds.
Where it makes a difference
An online course platform hosts its site and video files on servers in one European data center. Learners in Southeast Asia report pages that take more than 4 seconds to load and videos that stall, and the origin servers struggle each time a popular course launches.
The team places the platform behind a CDN, gives static files and video segments one-year lifetimes with versioned file names, caches course pages for 60 seconds with stale-while-revalidate and marks account pages private. An origin shield in Europe sits in front of the servers, and the origin firewall accepts only CDN traffic.
After the change, the cache hit ratio settles at about 93%, origin traffic falls by more than 90%, and page load times for Asian learners drop to under 1.5 seconds. The next course launch causes no origin slowdown at all.