The problem: one server, many viewers, long distances
Imagine all of a video service’s files stored on a single server in one city. Every viewer, wherever they are, would send requests to that machine. Two difficulties follow.
First, distance. Data travels quickly but not instantly, and each request and reply crosses many network hops. Setting up a connection, fetching a manifest and downloading the first segments all involve round trips, so a longer path means a slower start. Distance also tends to mean more places where congestion can occur.
Second, load. A single server has a limited capacity. If a popular title is watched by very many people simultaneously, the server and its connection can be overwhelmed, causing slowdowns for everyone.
A content delivery network, usually abbreviated CDN, is the standard answer to both.
What a CDN is
A CDN is a network of servers placed in many locations, which store copies of content and serve it to nearby viewers. The original source of the files is called the origin. The distributed servers closer to viewers are often called edge servers, or points of presence when grouped at a site.
The CDN is not a different kind of internet. It uses ordinary web technology. When a player asks for a video segment, the request is directed to a suitable edge server instead of the origin, typically through DNS or routing arrangements that pick one by proximity and current conditions.
How caching works
The central mechanism is caching, which means keeping a copy of a file so it need not be fetched again.
- A viewer’s player requests a segment, and the request reaches a nearby edge server.
- If the edge server already holds that segment, it is a cache hit, and the server sends it straight back.
- If not, it is a cache miss: the edge server fetches the segment from the origin (or from another layer of the CDN), sends it to the viewer and usually keeps a copy.
- The next viewer nearby asking for the same segment gets a hit.
Video suits this model well because streamed video is already cut into small, standard files, as explained in HLS and DASH. Many viewers request identical segments, so each copy can be reused many times. Files that do not change are easy to cache, whereas live streams generate fresh segments continuously, so caches must pick them up quickly and only briefly.
Many CDNs add intermediate tiers. If a nearby edge server misses, it may ask a larger regional cache before bothering the origin, which reduces the number of requests reaching the origin and so protects it.
Each cached copy is kept according to rules about how long it stays valid and when it can be discarded. Rarely watched files tend to be pushed out to make room for popular ones, which is one reason obscure titles sometimes start more slowly than popular ones.
What a CDN does for video
- Shorter paths. With content served from nearby, each round trip is shorter, which can help startup time and the speed at which segments arrive. The wider subject of waiting is covered in buffering causes.
- More capacity. Spreading demand across many servers lets a service handle a large number of simultaneous viewers, such as for a major live event.
- Resilience. If one server or route has trouble, traffic can often be sent elsewhere.
- Origin protection. Because most requests are answered from caches, the origin sees only a fraction of the total traffic.
- Cost patterns. Delivering data is a large part of the expense of streaming at scale. CDN pricing and the amount of data served strongly shape what a service spends, a topic examined in streaming costs.
Where the CDN sits among other parts
A CDN does not create, compress or package video. It only delivers files that have already been prepared by the streaming pipeline. The encoding ladder determines how many files exist; the more versions there are, the more distinct objects the caches must hold. Encrypted content can be cached too, since the files stay scrambled until the player gets a licence, as outlined in DRM protection.
For viewers on mobile networks, the CDN handles the internet side of the journey but not the last leg across the radio network. Improvements in the mobile network, such as 5G networks, address that final part separately.
Different kinds of CDN
Several arrangements exist. Some companies provide CDN services to many customers. Some very large services build their own, placing servers inside internet providers’ networks to be as close to households as possible. Many organisations use more than one CDN and switch among them depending on performance, cost or reliability. This is known as multi-CDN, and it adds complexity in exchange for flexibility. Which approach is sensible depends on audience size, geography and budget, and there is no universal best choice.
Limits and misunderstandings
- A CDN cannot fix a poor connection at the viewer’s end. It shortens the path from the server but cannot speed up an overloaded home wi-fi network.
- Cache misses are real. The first request for a new or rarely watched file may be slower. Large services sometimes push anticipated content to caches in advance.
- Live video is harder to cache. Segments are new and short-lived, and a low-latency design puts extra demands on how quickly the network must pass them on, an issue discussed under stream latency.
- Not everything is cacheable. Personalised or constantly changing responses, such as account information, usually go back to origin systems.
- Location accuracy has limits. Choosing the closest server depends on routing and measurement, and the selection is not always ideal.
Who needs to think about it
A creator posting to a large platform rarely needs to consider the CDN at all, because the platform handles it. Someone running their own site with embedded video, as in video embedding, may choose a hosting service that includes a CDN so that viewers in different regions get consistent performance. For anything beyond a small audience, serving video from one ordinary web server is usually the weaker option.