CDNs, why a website "near you" exists

Field note. Game traffic doesn't go through CDNs, it's a direct TCP/UDP path. But your panel, mod downloads, and status page all do. Knowing the line is useful when something is slow.

You load a major website. It feels instant. The company that owns it might be on another continent. By all physics, this shouldn't be possible: light takes ~70ms to cross the Atlantic. So how do these sites feel so fast?

Because they aren't actually hosted on a single far-away server. They're served from a CDN (Content Delivery Network): a global fleet of servers, with copies of the site's content near every major city. When you load the site, you connect to whichever copy is nearest you.

This article explains CDNs: what they are, how they work, and why they shape the modern internet.

The basic idea

A CDN is a network of servers spread across many locations worldwide, each holding cached copies of content from many origin sites.

When a user requests content:

1. DNS or routing magic directs them to a nearby CDN server.
2. If the CDN server has the content cached, it serves it immediately.
3. If not, the CDN server fetches it from the origin (the actual source server), caches it, and serves it.

Subsequent users in the same region get the cached copy directly, at low latency.

The origin server might be in Virginia. The CDN servers are in 200+ cities worldwide. From your laptop in Berlin, you're talking to a Berlin-area CDN server. The 5000-mile journey to Virginia happened once, for the cache fill. Everything since has been local.

Why latency matters

The internet's speed is ultimately bounded by physics. Light in fiber travels at about 200,000 km/s (2/3 the speed of light in vacuum because of refraction).

Practical latencies:

• Same city: 1-5 ms.
• Same country (US, large): 20-50 ms.
• Continent crossing (US-Europe): 60-100 ms.
• Trans-Pacific: 100-150 ms.
• US to Asia: 150-250 ms.

A page load involves many round-trips: TCP handshake (1), TLS handshake (1 to 2), HTTP request (1), maybe more for additional resources. Each round-trip costs the latency of one round-trip.

At 200 ms latency (US to Australia), a single page can take 1.5 to 2 seconds just in network round-trips before any bytes flow. At 5 ms latency (local CDN), the same page loads in under 100 ms.

CDN: bring the content close, eliminate the round-trip cost.

What CDNs cache

Originally, CDNs cached static assets: images, stylesheets, JavaScript files. Things that don't change per-user and rarely change at all.

Modern CDNs cache more aggressively:

• HTML pages (with care, since they can be user-specific).
• API responses (with cache invalidation).
• Video segments (streaming).
• Dynamic content with short TTLs.

Some CDNs (Cloudflare, Fastly) run code at the edge: not just caching, but actually executing your application logic close to users. This is called "edge computing."

How users find the right CDN node

Several techniques:

Anycast routing. The CDN advertises the same IP from many locations. BGP routing automatically sends users to the closest one. We have a dedicated article on anycast in Series B.

GeoDNS. The CDN's DNS servers return different IPs to different users based on geographic detection. Less precise than anycast but works without BGP routing tricks.

HTTP redirect. Less common. A user requests cdn.example.com, gets back an HTTP 302 to eu-west.cdn.example.com. One extra round-trip, but precise.

Most modern CDNs use anycast as the primary mechanism, with GeoDNS as a fallback or for specific use cases.

Origin and edge

CDN architecture has two layers:

Edge servers (or "PoPs," points of presence). Distributed globally. Serve users.

Origin servers (your actual site, or a regional origin shield). Where the real content lives.

When an edge server doesn't have a cached copy, it fetches from origin. The path between edge and origin is sometimes optimized (private CDN backbone networks) or sometimes goes over the public internet.

For sites pushing a lot of dynamic content, origin shield (a regional caching layer between edges and origin) reduces origin load by deduplicating fetches.

Cache invalidation

Cache invalidation is famously hard. CDNs deal with it via:

TTL. Each cached object has a Time To Live. When it expires, the CDN re-fetches from origin. Conservative TTLs (a few minutes to an hour for HTML, longer for static assets) are common.

Purge API. When content changes, the site tells the CDN to drop the cache for specific URLs. Fast and surgical.

Cache keys. Different versions of the same URL can be cached separately, keyed by query parameters, headers, cookies, etc. Used for personalization without losing CDN benefits.

Stale-while-revalidate. Serve the stale cache while asynchronously fetching the fresh version. User sees content immediately; cache updates in the background.

Major CDN providers

Some prominent ones in 2026:

• Cloudflare. Largest by number of PoPs (300+ cities). General-purpose CDN, DDoS protection, edge compute.
• Akamai. The original CDN. Strong in enterprise and media.
• Fastly. Developer-friendly. Strong programmability.
• Amazon CloudFront. Integrated with AWS. Strong if you're already on AWS.
• Google Cloud CDN. Integrated with GCP. Strong YouTube heritage.
• Bunny.net. Independent, pricing-focused. Popular for small to mid sites.

Some major sites run their own CDN-like infrastructure: Netflix's Open Connect, Apple's CDN, Facebook's. These aren't sold to others; they're internal infrastructure.

CDNs and HTTPS

CDNs terminate HTTPS connections at the edge. This means:

• The TLS handshake happens between user and edge server.
• The edge server holds the site's certificate.
• The edge fetches content from origin (sometimes over its own HTTPS to origin, sometimes plain HTTP within a private network).

This works because the site delegates trust to the CDN. The CDN has a copy of the cert and key, or uses a different cert that browsers will accept.

For sites concerned about CDN access to their data, more recent options:

• Encrypted SNI / Encrypted Client Hello. Already covered in the HTTPS article.
• End-to-end encryption for application-layer concerns (e.g., a chat app encrypts messages so the CDN sees ciphertext only).

For most sites, trusting the CDN with HTTPS termination is fine.

CDNs and DDoS protection

CDNs naturally absorb DDoS attacks. Reasons:

• They have far more bandwidth than typical attackers.
• They have many PoPs, distributing the load.
• They can identify and drop attack patterns at the edge before they reach origin.

This is why "Cloudflare-protected" is a common badge. The CDN's anti-DDoS is part of the service.

For game servers specifically, traditional HTTP CDNs don't help much (games don't use HTTP). But specialized "TCP / UDP CDNs" (Cloudflare Spectrum, others) work for raw TCP/UDP traffic too.

CDNs and the centralization concern

A real concern: the modern internet relies heavily on a few CDN providers. Cloudflare alone handles ~20% of all websites in some sampling. A Cloudflare outage takes a noticeable slice of the internet down with it.

This isn't necessarily bad (the alternative is many smaller providers with less expertise), but it's a centralization tradeoff. The "internet as a network of independent networks" has, in some practical sense, become "the internet through a few CDNs."

For the average site operator, using a major CDN is a clear win. For internet architecture overall, the concentration is something to watch.

When you don't need a CDN

CDNs aren't universally beneficial. Skip them when:

• Your audience is geographically concentrated (one city).
• Your content is heavily user-specific (low cache hit rate).
• You're optimizing for write-heavy workloads where caching doesn't help.
• The CDN's cost exceeds the latency benefit (rare for paid CDNs; common for free ones with limits).
• You need strict control over data location (compliance reasons).

For most public-facing sites, CDN is the right default.

CDNs and game hosting

Most game traffic doesn't benefit from CDN caching in the traditional sense. Game state is dynamic and player-specific.

Where CDNs help games:

• Patch distribution. When a game releases a 20 GB update, CDN dramatically cuts download times worldwide.
• Asset delivery. Voice packs, texture packs, maps for download.
• Launcher updates. Steam, Epic, Battle.net.
• API calls. Account systems, matchmaking, leaderboards.

Where CDNs don't help directly:

• Real-time game traffic. Position updates from a Minecraft server can't be cached; they need to flow live.

For real-time traffic, the analog is anycast and regional servers. Many large games run servers in multiple regions; players are matched to a regional server close to them. The "CDN logic" is built into the matchmaking, not into a separate CDN product.

A simple mental model

A CDN is a global cache. Cache near the user, fetch from origin when needed. Latency drops; origin load drops; bandwidth bills drop (CDN providers buy bandwidth wholesale).

Modern websites are 80% CDN and 20% origin compute by traffic share. The internet feels fast because of this.

For users: the CDN is invisible. You get fast pages.

For site operators: the CDN is a service to evaluate and integrate.

For internet infrastructure: CDNs are now critical components, and their consolidation is one of the major changes the internet has undergone in the past 15 years.

The end of Series A

We've come a long way. Series A started with two computers on one wire. We covered:

1. Networks.
2. The internet as networks of networks.
3. IP addresses.
4. Ports.
5. TCP vs UDP.
6. Packets.
7. Routers.
8. DNS basics.
9. DNS hierarchy.
10. DNS record types.
11. IPv4 scarcity.
12. IPv6.
13. NAT.
14. HTTPS and TLS.
15. CDNs.

Together, these cover the foundations of how the modern internet works. From here, Series B (Networking for the curious admin) digs into the higher-level system: BGP, ASNs, peering, anycast, the operational concerns that hosting companies and ISPs deal with daily.

If you got this far: you now know more about how the internet works than 99% of people who use it daily. The next time something feels broken on the network, you have a real mental model to diagnose with.