CDN and Anycast Explained: How They Cut Latency

Quick answer: a CDN (content delivery network) is a group of servers in many locations that store copies of content so that you fetch it from a place near you instead of from one distant origin server. Anycast is a routing method where many servers in different places share the same IP address and the network delivers your packets to a nearby one. Both exist to attack the largest part of latency that you cannot buy your way out of: distance. A CDN can turn a 180 ms round trip to a far-away origin into a 10 to 30 ms round trip to a server in your region, as long as the content can be served from the nearby copy.

What problem does a CDN solve?

Every web request needs several round trips before the first byte of content arrives: a connection setup, an encryption handshake, and the request itself. Each round trip is limited by the distance to the server, because light in optical fibre travels at about 200,000 km/s, which works out to roughly 1 ms of round-trip time for every 100 km of fibre path (see undersea cables and the speed of light). If a website's only server is in one city, visitors on another continent pay that distance on every round trip, and no amount of extra bandwidth changes it.

A CDN fixes this by moving the server toward the user. Instead of one origin, the content is available from dozens or hundreds of locations. The user connects to the nearest one, which finishes the handshakes and often answers the request itself. The origin is contacted only when the nearby server does not already have what was asked for.

How does a CDN work step by step?

The vocabulary first. The origin is the server that holds the authoritative content, such as your own web server or cloud storage. An edge server (or cache) is a CDN server near users. A point of presence (PoP) is a CDN site, a room of such servers in a data centre or internet exchange in a particular city. Here is what happens on a typical request:

1. Steering. Your device looks up the site's hostname (see DNS explained). The answer, or the routing behind it, points you to a nearby PoP. The two main steering methods are described below.
2. Connection. Your device opens a TCP and TLS connection to the edge server. Because the edge server is close, these handshakes cost only a few milliseconds each (see TLS and the HTTPS handshake).
3. Cache lookup. The edge server checks whether it holds a fresh copy of the requested object. If yes, this is a cache hit and it responds immediately.
4. Cache miss. If not, the edge fetches the object from the origin (or from another CDN layer, often called a shield or mid-tier cache), stores a copy according to the caching rules, and returns it to you. The next nearby visitor gets a hit.

How long a copy stays valid is controlled by the origin through HTTP headers such as Cache-Control: max-age=3600, which tells caches the object may be reused for 3,600 seconds. After that the edge must revalidate or fetch again. This lifetime is often called the TTL (time to live).

What content can a CDN cache?

Static files cache well: images, fonts, stylesheets, JavaScript, downloads, software updates and video segments. Streaming video relies heavily on this, since the same segments are watched by many people. Dynamic content, such as a logged-in account page or a search result built for one user, usually cannot be reused for others. Many CDNs still carry it, because a nearby edge that holds a persistent, warm connection to the origin can shorten the path even when the response is not cached. This is sometimes called dynamic acceleration, and the gain is smaller and varies by provider and route.

Content type	Cacheable at the edge?	Typical benefit
Images, CSS, JS, fonts	Yes, with long TTLs	Large: every visitor gets a nearby copy
Video segments, software downloads	Yes	Large: lower latency and less origin load
Public HTML pages	Often, with short TTLs	Moderate to large
API responses identical for all users	Sometimes	Moderate
Personalised pages, account data	Usually no	Small: faster connection setup only
Live game or voice traffic	No	None from caching

What is anycast?

Normally an IP address belongs to one place. That is unicast: one address, one destination. With anycast, the same IP address is announced from many places at once. Each location tells the rest of the internet, using the Border Gateway Protocol (BGP, the system networks use to exchange routes; see routing, BGP and peering), that it can reach that address. Every router on the internet then picks the best route it knows according to its own rules, which usually means the one crossing the fewest or cheapest networks. In effect, your packets reach whichever announcing location is "closest" in routing terms.

You can see why this is attractive. Nothing needs to change on the user's device. There is one address to type or hard-code, yet the traffic is spread over many sites. If one site goes offline and stops announcing the address, routers converge on the next best site within seconds to minutes, so users are redirected without any change on their side. Spreading traffic also helps absorb attack floods, because each site only receives the share routed to it.

Anycast is used by many of the internet's core services. The DNS root servers are operated as anycast groups with hundreds of instances. Well-known public DNS resolvers such as 8.8.8.8 and 1.1.1.1 are also anycast addresses, so they answer from a nearby location wherever you are. Many CDN providers use anycast for some or all of their edge addresses.

Anycast vs DNS-based steering

There are two common ways to send a user to a nearby CDN site. A third, hybrid style combines them.

Method	How it works	Strengths	Weak points
DNS-based	The CDN's DNS servers return different IP addresses depending on where the question seems to come from	Fine control; can account for load and health	Decision is based on the resolver's location (or a hint of the client subnet), which may not match the user's; answers are cached for the DNS TTL, so changes take time
Anycast	One IP address announced from many sites; routing picks the site	Works with the user's real network position; fast failover; no per-user DNS decision	Routing cost is not distance, so some users land at a far site; less direct load control
Hybrid	DNS returns anycast addresses, sometimes different ones by region	Combines coarse DNS control with routing flexibility	More complex to operate

One practical consequence for DNS-based steering: if you use a distant public DNS resolver, a CDN may think you are where the resolver is, and send you to a CDN site near it instead of near you. This is one reason a poorly chosen resolver can slow some sites even though the resolver itself is quick.

Does anycast ever make latency worse?

Sometimes, yes. Anycast picks by routing preference, and routing preference is influenced by business arrangements, not only geography. A user of one provider might reach a site in the same city, while a user of another provider in the same street might have their traffic carried to a site hundreds or thousands of kilometres away because of how those networks are connected. Operators try to minimise this by adding sites, peering directly with many networks and adjusting how routes are announced.

A second concern is stability. If routing changes in the middle of a long TCP connection, later packets can arrive at a different anycast site that knows nothing about that connection, and the connection resets. In practice this is rare and well managed for short web requests, and modern providers design for it. Connection-oriented services that last minutes or hours need extra care, and protocols such as QUIC, which can survive some changes (see HTTP/1, 2, 3 and QUIC), help.

What does a good CDN result look like?

When a site is delivered well by a CDN, the round trip you measure to it tracks your access network and distance to the nearest PoP, not the distance to the origin. Typical outcomes on healthy wired or fibre connections in well-served regions are roughly 5 to 30 ms. On Wi-Fi, mobile or satellite links the access part is higher (see Wi-Fi, Ethernet, fibre, mobile and satellite latency). In regions with fewer PoPs or fewer local networks exchanging traffic, the nearest site may be one or more countries away, and values of 50 to 150 ms are normal.

Two measurements are worth keeping apart. Network latency to the edge shows how close the CDN is. Time to first byte (TTFB, see TTFB and web performance) additionally includes whether the edge had the object cached. A site can have an excellent edge round trip and still a slow TTFB because every request misses the cache and goes to a slow origin.

How GlobeLatency treats CDN and anycast destinations

Many destinations in the free latency test are served by large CDN or anycast networks. The test sends real HTTPS requests from your browser and times each one from the start of the request until the response headers arrive, so you are measuring the path to whichever edge answered you, including DNS, TCP and TLS when a new connection is needed. Each request uses a cache-busting query string and no-store caching, which prevents your browser's own HTTP cache from answering. Be aware that some CDNs treat a different query string as a different object, so a small asset may be fetched from further back than a normal user request would be; the figure can therefore be a little higher than a real visitor sees on a popular, cached URL.

On the live map, a pin for an anycast or CDN destination is placed where the hostname resolved from the lookup, which is the edge near the resolver, not the company's headquarters. That is expected: the pin shows where your traffic is likely to be served, and a very low reading on such a pin tells you that the edge is close to you. To compare how a CDN performs for a site you operate across regions, see CDN performance testing.

Worked examples

Example 1: Origin only vs CDN

A shop's origin server is in Frankfurt. A visitor in Singapore sees about 170 ms RTT to Frankfurt (roughly 10,300 km great-circle distance, so a real fibre path of 12,000 to 14,000 km and a physical minimum of about 120 to 140 ms, plus equipment). Loading a product image over a fresh HTTPS connection costs about one RTT for TCP, one for TLS 1.3 and one for the request: 3 × 170 = 510 ms before the first byte arrives. With a CDN PoP in Singapore at 8 ms RTT, a cache hit costs 3 × 8 = 24 ms. The saving is about 486 ms for each new connection, and the image itself downloads faster too, since shorter round trips let TCP speed up sooner.

Example 2: A cache miss

The first visitor from Singapore asks for a new image that the Singapore edge has never seen. The edge opens a connection to Frankfurt, which takes 170 ms for TCP plus 170 ms for TLS if it has no reusable connection, plus 170 ms for the request, and then relays the file. That first visitor may wait longer than they would have without a CDN. The second visitor, a few seconds later, gets a hit. Mid-tier shield caches and persistent origin connections exist to soften this first-miss penalty.

Example 3: Anycast landing far away

A user's ISP has no direct connection to a CDN's local PoP and hands traffic to a transit provider that delivers it to a PoP 2,500 km away. The result is a 45 ms RTT instead of an expected 8 ms, though another user on a different ISP in the same city reaches the local PoP at 7 ms. The CDN is working as designed, but the network path of the first user's ISP decides the outcome. See talking to your ISP for how to raise a routing question with evidence.

Common mistakes and myths

• "A CDN makes my origin faster." It does not change the origin; it avoids using it. A slow origin still hurts on every cache miss.
• "Anycast always picks the geographically nearest server." It picks the best route by network rules, which usually but not always means nearby.
• "A low ping to a big brand means that company's servers are next door." It means an edge or anycast node is next door. The origin could be on another continent.
• Setting TTLs to zero or sending no-store on everything. This turns the CDN into a pass-through proxy and removes most of the benefit.
• Ignoring query strings and cookies. If the cache key includes a unique query value or a varying cookie, every request is a miss.
• Testing from one place only. A CDN may be excellent in one region and poor in another. Measure from where your users are.
• Believing a CDN will fix a bad last mile. A congested home Wi-Fi or mobile link adds delay that no edge server can remove.

What to do next

If you run a site, first check your cache behaviour: look at response headers such as Cache-Control and, where your provider adds one, a cache status header, and compare a hit against a miss. Then read CDN performance testing and latency for websites and APIs to measure from several regions. If you are a user, use the free latency test to see which CDN-hosted destinations answer quickly from your connection, and compare against other destinations in the same results. To understand where servers physically live, continue with data centres, cloud regions and the edge, and for the background on why the internet picks the paths it does, read how the internet works.