How Does Content Delivery Work?

Content delivery is like the plumbing of the internet. Whenever you click on a link for a new webpage, or to watch a video on YouTube, or to download a new game to your phone, the digital bits are delivered through the mechanism of content delivery. But how does that work? What components are needed and what actually happens?

TL;DR

• Every website, video stream, and software download relies on content delivery infrastructure built on web servers, reverse proxies, and internet protocols like TCP and UDP.
• Content Delivery Networks (CDNs) emerged to solve internet scaling challenges by distributing content across geographically dispersed caching servers.
• CDNs route users to nearby caches, reducing latency, improving performance, and preventing origin servers from being overwhelmed by demand.
• Today, CDNs deliver the majority of internet traffic and are essential for streaming video, online gaming, software distribution, and large-scale web applications.
• Despite their critical role and massive market size, the CDN industry remains concentrated among a relatively small number of providers, raising questions about the future of content delivery infrastructure.

Understanding Protocols

While we won’t go into incredible detail here, there are two primary means by which to deliver traffic through the internet: TCP and UDP. The first, Transmission Control Protocol, is how most requests for content on the internet are served, like HTTP. The second, Universal Datagram Protocol, is not as common. While it provides a number of performance improvements and advantages to TCP, it also doesn’t use standard ports. For example, HTTP uses ports 80 and port 443 (the first for normal, the second for secured) while UDP doesn’t. This can result in network operators such as internal corporate networks from blocking those requests.

https://www.wowza.com/blog/udp-vs-tcp

The Backbone of Content Delivery: Web Server + Reverse Proxy

So what happens when someone clicks on a link on a webpage, or presses the “play” button on a video? Those actions result in a request being sent (again, usually through HTTP which rides on TCP) from the user’s device to the source of that content (well, the source as it is defined by the owner and represented in DNS records). In many cases, that is a reverse proxy which is a specialized server for spreading requests out to farms of web servers, content origins, or more. There are many reverse proxy servers available today, including NGINX, Varnish, and Squid, as well as some specialized servers, like Wowza, specific to streaming media.

‍

The web server, though, is what responds to the request (again, it doesn’t matter if the request is made through HTTP, over TCP, or HTTP3, over QUIC, a UDP-based protocol) and sends whatever is being requested back to the device.

‍

For streaming media, the setup is a little different. The web server and reverse proxy are often combined into a single server: a cache. Often this is through NGINX or Varnish, two of the most well-known caching systems. Why is streaming media different from, say, a web page or a web application? It’s because the server needs to maintain a persistent connection to continually deliver the small “chunks” or “segments” of video. Individual HTTP requests, for each chunk, are sent through that connection.

https://bunny.net/academy/http/what-are-reverse-proxies/

A Network Specific for Delivering Content?

What people who were architecting the internet in the early 90s realized was that scale was an issue. See, if too many requests for too much data hit a web server, it can become unresponsive (if you didn’t already know, it’s called “tipping over”, and it’s the basis behind DDoS attacks). So a then small company coming out of MIT called Akamai solved this problem by creating a unique, distributed network composed of many caches (those reverse proxies plus web server) that were basically just large boxes of very responsive disks and memory (minimal compute needed). Throwing in some very unique algorithms to route around internet congestion, Akamai gave birth to the world’s first Content Delivery Network (CDN). While it initially focused on small objects, like images on websites, it eventually grew to deliver all kinds of content like streaming media and game downloads. Of course, they were only the first and an entirely new industry sprang up with a new host of companies offering one thing: a really big, distributed network of servers dedicated solely to delivering content over the internet. If you weren’t aware, when you watch any streaming video, like from Disney, it’s being delivered not by Disney’s network infrastructure but one of a few CDNs (Netflix is a little different as they’ve built out their own CDN; guess that’s what you can do when you have a lot of money and a mammoth audience).

How Does A CDN Work?

A CDN works by handling requests on behalf of their clients. For example, when you click on the play button, the link might be something like cdn.disney.com or cache.disney.com. This DNS entry is a CNAME record that points to the CDN provider’s network where they will route the request, using their unique software, to one of their caching nodes nearest to the user making the request. By spreading requests out across a wide footprint of caches, CDNs essentially “load balance” large scale internet traffic, like for a live sporting match, to ensure that none of the infrastructure tips over.

‍

CDNs operate, essentially, by terminating the traffic as close to the end-user as possible, often at the ISP. So the ISP’s subscriber makes a request for some internet content (that’s in the last mile), the ISP sends that request up through their network (that’s the middle mile), and, hopefully, right to a CDN cache that is peered with them in one of the teleport facilities that houses an internet peering fabric. The ISP then routes the return traffic back through their network and down to the subscriber. For chunked streaming video, like HLS and DASH, this can happen millions of times for a single video. CDNs measure themselves, ultimately, on cache efficiency: the ratio of objects that are returned from that initial cache to objects that are not found in cache and must be retrieved from the origin (or other “parent caches” further upstream).

‍

Many content owners utilize multiple CDNs, switching between them in real-time using programming in the player and data about CDN performance (such as time-to-first byte), in order to deliver content on the CDN that is best for their needs.

https://www.cloudflare.com/learning/cdn/what-is-a-cdn/

Why Does Using A CDN Matter To You?

Simply put: without CDNs, watching streaming video, whether on Netflix or YouTube, would be a much different experience. CDN operators have spent hundreds of millions building their own private networks to deliver content on behalf of content owners, whether that’s a live sports provider like the NFL, a streaming video operator like Netflix, or even a game studio like Riot Games. If those content owners didn’t have CDN operators, they would need to build their own networks or take the chance that their content wouldn’t be available when their own, limited infrastructure tipped over because of demand. Many people don’t even know this and just assume the internet is one big network when, in fact, it’s a huge collection of individual networks owned by lots of different companies and organizations. And CDNs are a critical piece of the infrastructure that enables the internet to work the way you are used to: fast and responsively. Consider this: in 2023, 73% of all internet traffic was delivered through CDNs.

There’s More Than One Way to Skin A Cat

As you can probably imagine, CDNs make a lot of money. In 2023, it was estimated to be about $27.5BN. By 2033? It’s projected to be around $127BN. But there really isn’t one way to build or run a CDN which probably accounts for the fact that there are over hundreds of CDNs worldwide. Some focus on website performance, some on streaming video, some on real-time low-latency live events. And we will dig into it in the next blog in this series. Until then, though, maybe ask yourself this simple question:

‍

“Why should just a handful of companies control that much revenue?”