How CDN Works

The speed of light in fiber optic cables is approximately 200,000 kilometers per second. While incredibly fast, it represents an absolute physical limit. A round-trip packet from Sydney to a data center in London takes mathematically no less than 170 milliseconds. For a modern web application loading 100 images and scripts sequentially, this accumulates into a disastrous 17-second load time. Content Delivery Networks (CDNs) were engineered to defeat the speed of light by defeating distance itself.

---

Part 1: The Anatomy of a CDN

A CDN is not a single server; it is a globally distributed proxy network. Its architecture consists of two primary components:

1. The Origin Server

This is the single primary server location (e.g., an AWS EC2 instance in us-east-1) where your application's source code and master database reside. Before CDNs, every user on Earth had to connect directly to this single server, meaning it had to process the TLS handshake and TCP congestion window for every single connection globally.

2. Points of Presence (PoPs) & Edge Nodes

Mega-corporations like Cloudflare, Akamai, and Fastly lease physical rack space in hundreds of data centers scattered globally (Tokyo, Mumbai, Paris, Sao Paulo). These are known as Points of Presence (PoPs). Inside each PoP are highly optimized proxy servers called Edge Nodes.

When a user in Sydney types your URL into their browser, the network does not send them to London. Through complex DNS resolution and BGP Anycast routing, the network identifies that the user is in Australia and reroutes their TCP connection to the physical CDN data center located 5 miles away in Sydney.

Part 2: The Magic of Static Caching

The primary mandate of an Edge Node is to act as a massive reverse proxy cache.

When the Sydney user requests `hero-image.jpg`:

1. Cache Miss: The Edge Node checks its local SSDs. If the file isn't there, the Edge Node opens a blazing fast, long-lived multiplexed connection back to the London Origin server.
2. The Fetch: The Origin transmits the image to Sydney. The Edge node serves it to the user.
3. The Cache: Crucially, the Edge Node saves a copy of `hero-image.jpg` to its local disk.
4. Cache Hit: When the next 10,000 users in Sydney request that image, the Edge Node serves the file directly from its local disk in 5 milliseconds. The London Origin server experiences exactly zero load.

This process mathematically guarantees that bandwidth costs for the Origin server collapse to nearly zero, while globally distributed users experience instantaneous delivery.

Part 3: Dynamic Acceleration (Bypassing the Cache)

Files like `app.css` are static. But what about the `GET /api/user/profile` route? That data is unique per user; it cannot be cached on the Edge node. The request must travel all the way to the London Origin database.

Does a CDN help here? Yes, massively, through Dynamic Acceleration.

Connection Pooling & Keep-Alive

Establishing a secure HTTPS connection requires a TCP 3-way handshake and a TLS 1.3 cryptographic handshake. This requires 2-3 round trips. If a Sydney user connects directly to London, those round trips take 500ms before a single byte of HTTP data is even sent.

With a CDN, the user executes their TLS handshake with the Sydney Edge Node (taking 15ms). Meanwhile, the Sydney Edge Node maintains a persistent, permanently open "pool" of pre-warmed, highly optimized TCP/TLS tunnels directly back to the London Origin.

When the user requests their dynamic profile, the Sydney node simply forwards the HTTP payload down the pre-warmed tunnel. This bypasses the brutal latency tax of long-distance cryptographic handshakes.

Part 4: The 100 Tbit/s Shield (DDoS Mitigation)

CDNs are the only viable defense against modern Distributed Denial of Service (DDoS) attacks. If an attacker controls a botnet of 1 million infected IoT cameras generating 5 Terabits per second of garbage traffic, redirecting that traffic at a single AWS load balancer will obliterate it instantly.

Because a CDN operates via BGP Anycast, the botnet traffic does not concentrate on a single server. A bot in Moscow attacks the Moscow CDN PoP. A bot in Brazil attacks the Sao Paulo PoP. The attack is inherently distributed and fragmented across the CDN's massive global surface area.

Inside each PoP, hardware-accelerated traffic scrubbers (often built on eBPF/XDP inside the Linux kernel) inspect packets at line-rate. They analyze HTTP headers and TCP anomalies, instantly dropping the malicious packets while allowing legitimate human traffic to pass through unharmed. To the Origin server in London, it appears as just another quiet Tuesday.

Part 5: Edge Computing (The Next Frontier)

The latest evolution of CDNs is abandoning the concept of merely "proxying" entirely.

If the Edge node is a powerful Linux server sitting 5 miles from the user, why just cache images? Why not run the backend code itself right there?

Technologies like Cloudflare Workers and Fastly Compute@Edge utilize WebAssembly (Wasm) and Chrome V8 Isolates to execute JavaScript, Rust, or Go code directly on the PoP.

Instead of proxying an API request to London, the Sydney PoP executes the backend business logic and queries a globally distributed database (like DynamoDB Global Tables) in milliseconds. This represents the holy grail of low-latency architecture: moving the compute to the user, rather than moving the user to the compute.

Conclusion: The Global Superhighway

The modern internet is fundamentally reliant on CDNs. They have transformed the web from a fragile web of distant, easily-overwhelmed origin servers into a highly resilient, globally distributed super-organism. By caching static assets, accelerating dynamic routes, and maintaining an impenetrable shield against malicious botnets, the CDN ensures the internet remains fast and available for billions of users simultaneously.