CDN (Content Delivery Network)

A CDN (content delivery network) is a geographically distributed network of edge servers. These servers cache copies of your content close to end users. Each request is answered from a nearby node instead of from your origin. Cloudflare's definition is the plain one: "a geographically distributed group of servers that caches content close to end users". A CDN is not a web host. In Cloudflare's words, a CDN "does not host content and can't replace the need for proper web hosting". AWS describes the origin as the server that "stores the original, definitive version of your objects". Fastly warns that everything in its cache "is ephemeral: it will expire, and may be evicted by the platform before it expires depending on how frequently it is used". A CDN adds reach and a place to answer from, close to the user. Every request it satisfies from a stored copy is a request your origin never sees.

Structurally, a CDN is a large managed reverse proxy in front of your origin. Cloudflare's own documentation defines a reverse proxy as "a network of servers that sits in front of web servers and either forwards requests to those web servers, or handles requests on behalf of the web servers". The formal definition is the IETF's. RFC 6707 lists "Content Distribution Network (CDN) / Content Delivery Network (CDN)" as a single term. That is why you also see the entry spelled content distribution network. RFC 6707 defines a CDN as "Network infrastructure in which the network elements cooperate at Layers 4 through 7 for more effective delivery of Content to User Agents". It adds: "Typically, a CDN consists of a Request Routing system, a Distribution system (that includes a set of Surrogates), a Logging system, and a CDN Control system." Those four systems are the right mental model. Routing decides where a request lands. The surrogates are the caches that answer it. Logging and control are what make the network operable. Caching is one part of four, not the whole thing.

The idea is not new. Writing in 2010, Akamai's engineers record that the company "first pioneered the concept of Content Delivery Networks (CDNs) ... more than a decade ago". They started by "caching static site content at the edge of the Internet, close to end users, in order to avoid middle mile bottlenecks as much as possible". Everything CDNs do today grew out of that one move.

How it works

You do not install a CDN. Instead, you delegate a hostname to it. You point the hostname at the provider, usually with a CNAME or by moving your nameservers. You also configure your origin as the backend. From then on, requests arrive at the provider's network first. This is the path each one takes.

1. Request routing picks a location. A routing step sends the user to a nearby point of presence rather than to your origin. Two mechanisms do this in practice. DNS-based request routing is catalogued in RFC 3568. In that scheme, "a specialized DNS server is inserted in the DNS resolution process" and returns "a different set of A, NS or CNAME records based on user defined policies, metrics, or a combination of both". With anycast, one IP address is announced from many locations. In RFC 3568's words, "the inter-network is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address". Applied to a CDN, that "typically routes incoming traffic to the nearest data center with the capacity to process the request efficiently". Nearest is a tendency, not a guarantee. The two mechanisms are combined as often as they are contrasted.
2. The edge server checks its cache. On a hit, it answers from its stored copy. The request goes no further. CloudFront: "If the content is already in the edge location with the lowest latency, CloudFront delivers it immediately."
3. A miss is fetched from the origin and stored on the way past. CloudFront documents the sequence. It "forwards the request to your origin server". Then, "as soon as the first byte arrives from the origin, CloudFront begins to forward the object to the user. CloudFront also adds the object to the cache for the next time someone requests it." Delivery to the user therefore starts before the object has finished arriving.
4. Middle tiers absorb most misses. Most networks place at least one cache between the edge and the origin. Examples are an origin shield or shield POP at Fastly, regional edge caches at CloudFront, and "parent" clusters in Akamai's tiered distribution. There, "when an edge cluster does not have a piece of requested content in cache, it retrieves that content from its parent cluster rather than the origin server". Only a request that misses every tier reaches you: "for objects not cached at either the POP or the regional edge cache location, CloudFront ... forwards the request to the origin server."

What the edge may store, and for how long, is decided by HTTP caching semantics. These are standardised in RFC 9111, which obsoletes RFC 7234. RFC 2616 is long dead. A CDN cache is a shared cache. RFC 9111 defines a shared cache as "a cache that stores responses for reuse by more than one user". So a CDN cache honours the shared-cache directives as well as the ordinary ones. Your origin's Cache-Control and Expires headers set whether an object may be stored and for how long. s-maxage "indicates that, for a shared cache, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field". That is how you give the CDN a long lifetime and browsers a short one. Where you send no headers at all, vendor defaults fill the gap, and they differ per provider. When a stored copy goes stale, the edge revalidates rather than blindly refetching. Fastly's cache "will automatically issue conditional requests to a backend when possible to update (revalidate) its stored copy". So an unchanged object costs a 304 instead of a transfer.

Why it matters for a CDN

RFC 6707's abstract states the payoff for cacheable content plainly: "reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery".

• Latency. Distance dominates the first fetch. Serving from a nearby edge "reduces the physical distance data must travel". This "minimizes latency and ensures that users experience faster page load speeds".
• Origin offload. The origin handles only what the caches cannot. Akamai reports that with tiered distribution, "even for customers with very large content footprints, we typically see offload percentages in the high 90's". That is a vendor figure for very large content libraries. It is not a number to assume for your own traffic mix. But it is where the cost saving comes from: bytes and requests the origin never serves.
• Robustness. Copies of an object exist in many places. So "a CDN can handle more traffic and withstand hardware failure better than many origin servers". A failed location is routed around.
• Security posture. The network stands in front of the origin. So it is what an attacker reaches first. Cloudflare notes a CDN "may improve security by providing DDoS mitigation, improvements to security certificates, and other optimizations". Cloudflare also notes that a reverse proxy "can be configured to decrypt all incoming requests and encrypt all outgoing responses, freeing up valuable resources on the origin server". Both are capabilities you configure, not automatic properties of being on a CDN.
• Programmability. The large networks are also compute platforms. They run edge functions in the request path. Cloudflare states that "with Cloudflare's network of 335+ geographically distributed edge locations, Cloudflare customers can have edge code running worldwide using Cloudflare Workers".
• Ubiquity. Being on a CDN is the default for large sites. Cloudflare asserts that "today the majority of web traffic is served through CDNs, including traffic from major sites like Facebook, Netflix, and Amazon". The claim is the vendor's own. The page cites no measurement behind it.

What CDNs do

The three networks below are all origin-pull. You upload nothing. The edge fetches from your origin on first request. Fastly says so directly, describing itself as "a reverse proxy to your origin server (also known as Origin Pull)". Fastly adds: "we do not provide services for uploading your content to our servers". What differs between them is routing, defaults and billing.

• Cloudflare. When a domain is active and a DNS record is set to proxied, "Cloudflare responds with an anycast IP address, instead of the origin IP address defined in your DNS table". That record's HTTP and HTTPS traffic then routes through the network. Caching is on by default, but it is keyed on file type. "Cloudflare only caches based on file extension and not by MIME type. The Cloudflare CDN does not cache HTML or JSON by default". So dynamic content needs a cache rule. Origin cache headers are respected. Where none are present, status-code defaults apply, currently 120 minutes for a 200. Simultaneous misses are collapsed within each data centre. There, a cache lock means "only the first request is forwarded to the origin to fetch the asset" and the rest are served the streamed response. See request coalescing.
• Fastly. Fastly runs its own DNS service. This service "automatically routes your traffic to the nearest Fastly POP (in terms of network proximity)". Its POPs are "strategically placed near the highest density Internet Exchange Points around the world". The readthrough (HTTP) cache is the only cache interface available to CDN services. It "works without any configuration or code required", filling on the first request at each POP. Shielding is opt-in per origin. Enable it, and "visitor requests from across the global network funnel through a single, designated shield POP". So "a request that is not satisfiable from cache will transit two POPs". Purging is not a setting but an action you invoke. It "allows cache entries to be expunged ahead of their normal expiry".
• Amazon CloudFront. Each request "is routed to the edge location that provides the lowest latency". A miss is pulled from the origin you configured. If your origin sends no cache headers, "each file stays in an edge location for 24 hours before it expires". That 24-hour figure is the no-headers default, not a ceiling. Regional edge caches sit "between your origin server and the POPs". They hold objects longer than an individual POP and reduce "the need for CloudFront to go back to your origin server". But AWS documents that dynamic requests and the proxy methods PUT, POST, PATCH, OPTIONS and DELETE skip the regional edge caches and go straight to the origin. Billing is per use: "CloudFront charges for data transfers out from its edge locations, along with HTTP or HTTPS requests". By contrast, transfer from an AWS origin into CloudFront "is always free".

Watch out for

• It is not a substitute for the origin. Cached copies expire and can be evicted early. So an origin that stays down eventually becomes a site that is down, whatever your hit ratio looks like. Serving stale content buys time, not immunity.
• Caching offloads. Routing accelerates. Do not confuse the two. Personalised responses cannot be cached wholesale: "dynamic content on a web page that is customized for each user cannot be entirely cached by the edge platform and must be fetched from the origin". Those requests get no offload, but that is not the same as no benefit. The same Akamai paper reports large-file and application speedups "due solely to path and protocol optimizations rather than edge caching". These speedups come from pooled persistent connections, tuned transport and better paths between edge and origin.
• Your headers decide freshness, not the CDN. A lifetime that is too long serves stale content until it expires. Only a purge publishes a change immediately, "so that changes to the source content can be reflected at the edge immediately". A lifetime that is too short turns the edge into a proxy that revalidates constantly and offloads little.
• TLS terminates at the edge. To cache or rewrite anything, the CDN must see plaintext. So it holds a certificate and key for your hostname, and it can read your traffic. Keyless options exist, but they are narrow. Cloudflare's Keyless SSL "allows security-conscious clients to upload their own custom certificates and benefit from Cloudflare, but without exposing their TLS private keys". It is an Enterprise-only paid add-on that does not support TLS 1.3. Provider trust is a design decision, not a checkbox.
• You pay per request as well as per byte. CloudFront bills "data transfers out from its edge locations, along with HTTP or HTTPS requests". Pricing "varies by usage type, geographical region, and feature selection". Traffic that cannot be cached still pays those egress and request fees. It still lands on your origin. So a low hit ratio means paying for the same work twice. Model your own mix. The saving is not automatic.
• Nearest is best-effort. Routing decides with imperfect information. RFC 3568 notes of anycast that "routing protocols are not load sensitive". So "the closest server may not be the one with the least network latency". Of DNS-based routing, RFC 3568 notes that it "is based only on knowledge of the client DNS server, as client addresses are not relayed within DNS requests". This "limits the ability of the Request-Routing system to determine a client's proximity to the surrogate". Expect a tail of users served from a location you would not have chosen.

Best practice

• Keep the origin authoritative and healthy. It "stores the original, definitive version of your objects". Everything at the edge is a disposable copy of it.
• Send explicit cache headers from the origin instead of relying on vendor defaults. Use s-maxage when the shared cache should hold an object longer than the browser does. Defaults are not comparable across providers: no HTML or JSON on Cloudflare, 24 hours on CloudFront when headers are absent, status-code TTLs elsewhere.
• Put a tier between the edge and the origin. On Fastly, enable shielding. It "reduces the volume of requests from Fastly to your origin servers" and improves cache hit ratio. On CloudFront, the regional edge caches do it for you, so that "all of the POPs in a region share a local cache, eliminating multiple requests to origin servers".
• Track the cache hit ratio, "the ratio of inbound requests that are able to be satisfied from cache". Track it per content type rather than as one site-wide average. A single number hides the paths that are still reaching your origin.
• On deploy, publish changes deliberately. Purge the affected objects, or change their URLs so the new version is a new cache entry (cache busting). Waiting for a lifetime to expire is not a release process.