Video is by far the heaviest type of content travelling across the internet. Serving it from a single server works for a few people at a time; with a larger audience the server's outbound bandwidth saturates, the distance from viewers increases response times and costs rise fast. CDNs (Content Delivery Networks) solve the problem by replicating content on geographically distributed servers close to users. With adaptive streaming, which is based on ordinary HTTP files, a general-purpose CDN is perfectly suited to video, provided it is configured sensibly.
How delivery works
The typical chain has three tiers:
- origin: the server or storage where manifests and segments live;
- intermediate tiers: CDN nodes that collect requests from several edge nodes;
- edge nodes: the servers close to viewers, which respond directly.
When a viewer requests a segment, the edge node checks whether it has it in cache. If so, it delivers it immediately (cache hit). If not (cache miss), it asks the upper tier or the origin, delivers it and keeps it for subsequent requests.
Why adaptive streaming suits caching
With HLS and DASH, all viewers watching the same content at the same quality request the same files. The first viewer in an area «warms» the cache, and those who follow are served by the nearby node. The more the audience concentrates on the same content, the higher the cache hit ratio, and the lower the load and costs at the origin.
Manifests and segments: different cache rules
This is the most important aspect of the configuration.
| File type | Video on demand | Live |
|---|---|---|
| segments | long cache, they never change | long cache, they don't change once created |
| manifests | long or medium cache | very short cache, they change constantly |
In a live stream the playlist is updated every time a segment is added. If the CDN keeps it too long, viewers receive an old version, the player finds no new segments and the stream stalls or falls behind. As a rule, the cache lifetime of a live manifest should be shorter than the duration of one segment.
The rules are communicated with the HTTP Cache-Control header. For example, for segments:
Cache-Control: public, max-age=31536000, immutable
and for a live manifest a value of a few seconds or less.
Origin shield
If hundreds of edge nodes simultaneously request the same segment not yet cached, the origin receives hundreds of identical requests. An origin shield is a designated intermediate tier through which all requests to the origin pass: only it contacts the origin, while the other nodes ask it. It drastically reduces load, especially at the start of a live stream followed by many people.
Common configuration mistakes
- URL parameters that break the cache. If every request carries a user identifier in the query string and the CDN treats it as part of the cache key, every viewer generates a cache miss. The cache key should be configured to ignore irrelevant parameters.
- Compression applied to segments. Video segments are already compressed; applying gzip or similar wastes resources. Compression only makes sense for text manifests.
- CORS not configured. Browser players download manifests and segments through JavaScript requests; without correct CORS headers, the video will not start if it is hosted on a different domain from the page.
- Byte-range requests not supported. For progressive download and some formats, the server and CDN must handle
Rangerequests.
Protecting content on the CDN
For restricted content, signed URLs or expiring tokens are used: the address contains a signature the CDN checks before responding. A shared link stops working after a short time. Verification should happen at the edge node, so that caching keeps working.
Measuring
Useful indicators to keep an eye on are:
- cache hit ratio, ideally high for popular content;
- time to first byte for segments, which affects start-up and quality switches;
- 4xx and 5xx errors, a sign of misconfiguration or a struggling origin;
- origin bandwidth, which should be a small fraction of what is served to users.
Multiple CDNs
Large services often use several CDNs at once, choosing for each viewer the one performing best in their area or switching to another if problems arise. To do this, content must be reachable in the same way from all of them, and the player or a routing service must decide which to use.
In short
- A CDN brings content closer to viewers and offloads the origin.
- Adaptive streaming suits caching because everyone requests the same files.
- Segments can stay cached for a long time; live manifests very briefly.
- An origin shield prevents floods of requests to the origin.
- Configure cache keys, CORS and signed URLs carefully.
