Streaming & CDNs
Video is the majority of internet traffic, and it is delivered over plain HTTP. The trick is how the video is packaged and where it is served from.
Chunked video and adaptive bitrate
A video is not sent as one giant file. It is cut into short chunks (a few seconds each), and every chunk is encoded at several quality levels - low, medium, high. A small manifest lists the chunks and the available qualities.
This is what makes adaptive bitrate (ABR) streaming work, as used by DASH (Dynamic Adaptive Streaming over HTTP). The player watches its own buffer and measured throughput and, chunk by chunk, requests the highest quality it thinks it can sustain. If the network slows, the next chunk is fetched at a lower quality instead of stalling; if it speeds up, quality climbs back. The server does nothing clever - it just serves whichever chunk the client asks for.
The client, not the server, decides what to fetch next and at what quality. The player has the best view of its own buffer level and screen size, so putting the decision there keeps playback smooth without the server tracking every viewer.
Worked example: a bitrate ladder in numbers
A typical ABR ladder for 6-second chunks might look like this:
| Rendition | Bitrate | Chunk size (6s) |
|---|---|---|
| 240p | 0.4 Mbps | 0.3 MB |
| 480p | 1.2 Mbps | 0.9 MB |
| 720p | 2.5 Mbps | 1.9 MB |
| 1080p | 5.0 Mbps | 3.75 MB |
Suppose the player is happily pulling 1080p chunks and measured throughput drops to 3 Mbps for one interval - a common blip on a shared home Wi-Fi network. A 5 Mbps chunk over a 3 Mbps link takes 5/3 = 1.67x its 6-second runtime to download, so the player falls a bit further behind every chunk. A sensible ABR algorithm reacts before the buffer empties: it drops to the 2.5 Mbps rendition, whose 6-second chunk now downloads in 2.5/3 * 6 = 5 s - comfortably inside the 6-second playback window - and the buffer stops draining.
Chasing throughput too aggressively causes visible quality oscillation: bouncing between 1080p and 480p every few chunks is more jarring than staying at a steady 720p. Real players smooth their throughput estimate (e.g. a harmonic mean over several chunks, not the instantaneous last sample) and add hysteresis before switching up, precisely to avoid this "ABR flapping" that early streaming deployments got complaints about.
CDNs: content at the edge
Serving every chunk from one origin server would be slow for distant users and would overload that server. A content delivery network (CDN) solves both by caching copies of the content on servers spread across the world, close to users. A request is steered to a nearby CDN node, which serves the chunk from its cache (fetching from the origin only on a miss).
The payoff: lower latency (the bytes travel a shorter distance), less load on the origin, and resilience to demand spikes. This "push content to the edge" idea returns in more depth in the later "At scale" module.