CDN

Reading time: 9 minute Word count: 1815

Network CDN DNS HTTP HTTPS Cache

What is hard to understand about a CDN is not “it can cache files.” It is that it moves user access points, cache layers, and origin protection out to the network edge. As a result, the first-packet time for the same URL may differ a lot across regions, the origin may be healthy while some users still see old content, and when image or video traffic rises, the first thing to saturate is often not the CPU but the cross-region bandwidth and origin fetch path.

CDN is often described as “static asset acceleration” or “edge-node caching,” which leaves only a vague impression: place the file a bit closer. But what made CDN durable is not only cache hit rate. It is that it takes part of public-access responsibility away from the origin. When we talk about websites, installers, image and video delivery, or large-scale API access today, many systems are no longer asking just “should I cache it?” They are asking “who should the user reach first, which requests should end at the edge, and which requests must still go back to origin?”

The core of a CDN is not copying files to more machines.
It is moving access, caching, and part of traffic control to edge nodes closer to the user,
without changing the semantic meaning of the resource.

Why It Exists

If every user accessed a single origin directly, the system would quickly hit three practical problems:

The user is far from the origin, so round-trip time is high
The same hot content keeps crossing regions, which drives up bandwidth cost and origin pressure
A sudden spike or a malicious spike hits the origin first

In the early Internet, when the scale was smaller, these problems could still be handled with more web servers, reverse proxies, and bigger uplinks. But once the audience spreads across regions, carriers, and even continents, the bottleneck is no longer only the origin’s processing capacity. It is the long public path between the user and the origin.

CDN was initially most suitable for high-frequency read-only content:

Images, scripts, and stylesheets
Software installers and update packages
Video segments and large file downloads
Many cacheable page and API responses

The common property is simple: many users repeatedly request the same or similar data, and going back to origin every time is both slow and expensive.

What It Was Built for, and Under What Background

CDN is not a single standard protocol, and it is not something that can be defined fully with one HTTP header. It is more like an entire deployment system built on DNS, HTTP, HTTPS, cache control, and global node scheduling.

Its default reality has always been clear:

Users are spread out, and path quality varies widely
The origin cannot be deployed close to every user
The same resource will be requested many times
Public access must consider performance, availability, and security together

So the center of CDN design is not “invent a new resource protocol.” It is “keep high-frequency access at the edge as much as possible, without breaking the original URL and HTTP semantics.”

A Typical End-to-End Path

When a browser requests https://static.example.com/app.js, a typical CDN path looks like this:

The client uses DNS or business scheduling to get a suitable entry point
The client and a CDN edge node establish a TCP/TLS or QUIC connection
The edge node checks whether the object already exists locally and can be returned immediately
If it hits, it returns it directly; if not, it fetches from upstream cache or origin
If the origin response is cacheable, the edge stores a copy and returns it to the client
Later users from the same area or similar paths are more likely to hit at the edge first

In short:

Client
  -> DNS / Scheduling: static.example.com ?

Client
  -> CDN Edge: GET /app.js

CDN Edge
  -> cache lookup
  -> hit: return object
  -> miss: fetch from upper tier / origin

Origin
  -> CDN Edge: 200 OK + Cache-Control + Body

CDN Edge
  -> Client: 200 OK + Body

The URL does not change, and the HTTP semantics do not change, but the access object has changed:

The user thinks they are contacting the site
In reality the first hop often lands at a CDN edge
The origin only takes requests when the cache misses, the content is not cacheable, or dynamic handling is required

Why It Is Designed That Way

Why let the user connect to the edge first instead of connecting to origin and forwarding afterward?

Because latency and bandwidth cost happen first on the path from the user to the first hop. Only by moving the entry point forward can TLS handshake cost, first-packet response cost, retransmission recovery, and large-transfer cost be absorbed close to the user.

If the user crosses an ocean to reach the origin first and only then decides whether to cache, that is basically just putting a cache next to origin. The user’s most expensive path has not been shortened at all.

Why CDN is always tied to DNS, Anycast, or scheduling systems

The edge node must get the user into the network first, not wait until the request reaches origin to decide. To do that, the system usually has to make the “which edge region should this user reach?” choice before the request is even sent.

Common approaches include:

Use DNS to return a more suitable entry address
Use Anycast so the same address can be routed to different nodes in different regions
Use a higher-level scheduler to split traffic by geography, carrier, load, and health

That is why CDN cannot be viewed as just a “cache server cluster.” Without entry scheduling up front, even many edge nodes might not be hit correctly.

Why it looks like caching, but actually takes on access-layer responsibilities

Modern CDNs do much more than store files:

TLS termination
HTTP/2 and HTTP/3 entry
Connection reuse and compression
Basic rate limiting, WAF, and bot protection
Header rewriting and origin policy control

These abilities show that a CDN is no longer just “disks placed closer to users.” It is more like an access layer deployed on the public boundary, with caching being one of its earliest and most central capabilities.

Why not every request should be cached

Caching reduces origin traffic, but only when the response semantics allow reuse. Requests with user state, strong consistency requirements, or obvious personalization are easy to break if they are forced into edge caching.

That is one of CDN’s most important boundaries:

It is well suited for high-frequency, reusable content with tolerance for short inconsistency
It does not automatically solve dynamic state consistency for business logic

Many stable systems do not “cache the whole site.” They distinguish carefully between:

Objects that can be cached for a long time
Objects that need short caching or conditional caching
Requests that must be passed through to origin

Things That Look Awkward but Are Actually Important

The same URL may hit different nodes in different places

That is not an anomaly. It is normal CDN behavior. Once the entry point is moved forward, the same domain in different regions, through different carriers, or at different times may land on different edge nodes first.

The benefit is proximity. The cost is that behavior is no longer naturally globally consistent:

One region may already have the new content while another still serves old cache
A node health check may fail and users will be switched elsewhere
Debugging must ask not only “does this URL have a problem?” but also “which layer and which node did the user actually hit?”

Refresh and invalidation are never globally instantaneous

A CDN can easily make people assume that once the origin file changes, the entire edge becomes consistent immediately. Reality is usually different.

The reasons are simple:

There are many edge nodes, so invalidation has to propagate
A local node may still have existing connections and in-flight old objects
Expiration and eviction timings across cache layers are not necessarily identical

So CDN, like DNS, often depends on an “acceptable inconsistency window.” It is not a strong-consistency system. It is a distributed caching and access system optimized for performance and scale.

High hit rate does not automatically mean the whole system is fast

Edge hit rate is important, but it is not the only metric. A CDN that looks healthy in terms of hit rate can still slow users down in the following ways:

First DNS scheduling is unstable
Edge TLS handshake or HTTP/3 entry configuration is poor
Origin fetches are slow, so misses jitter heavily
Hot content changes too often, so the benefit of hits is eaten by misses

If you only think of CDN as a “cache hit rate system,” you will miss the access, handshake, origin, and node-scheduling costs that matter just as much.

Having a CDN does not mean the origin can be designed carelessly

CDN can absorb a lot of repeated traffic, but not all of it. Misses, origin validation, dynamic requests, warm-up, and failover all still hit the origin.

If the origin does not stand up well in these areas, the CDN will only delay the problem, not remove it:

Confusing cache-control headers
Unstable origin APIs
No clear separation between static and dynamic resources
Inconsistent domain, certificate, or origin-Host policy

What You Should Really Think About It Today

When implementing, integrating, or debugging CDN, the most important thing to start with is not a vendor feature table, but these judgments:

First, locate which layer the problem sits in: is DNS scheduling not sending users to a good entry point, or is the edge missing the cache, or is the origin fetch too slow, or is the origin returning non-cacheable or wrong content?

Second, check whether the cache semantics are clear. If Cache-Control, ETag, expiration policy, refresh policy, and origin Host are all muddy, the more edge nodes you have, the harder the behavior is to reason about.

Third, separate “acceleration” from “takeover.” After a domain has been pointed to the CDN, TLS, connections, headers, real client address, logs, and security policy may already be happening at the edge. You can no longer debug it as if the client were talking to origin directly.

Fourth, ask whether the business is really suitable for the edge to take on more responsibilities. Static assets, software delivery, video distribution, and front-door API gateways are usually good candidates. Highly personalized, strongly consistent, or transaction-heavy requests need much more careful boundary design.

CDN