This is the first in a series of blog posts exploring the mechanics of content delivery.
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?
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
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/
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).
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/
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.
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?”
A Content Delivery Network (CDN) is a distributed network of servers designed to deliver digital content, such as web pages, streaming video, software downloads, and images, quickly and reliably to users. CDNs place caches closer to end users, reducing latency and helping content providers handle large volumes of traffic without overwhelming their origin infrastructure.
While content owners can host content on their own servers, large-scale demand can quickly overwhelm that infrastructure. CDNs distribute requests across thousands of caching servers worldwide, preventing servers from becoming overloaded and improving performance for users. This is especially important for high-traffic events such as live sports streams, major software releases, or viral content.
When you request content, DNS records typically direct your request to a CDN rather than directly to the content owner’s servers. The CDN uses routing algorithms to identify the cache node best positioned to serve your request, often selecting a server geographically or network-topologically close to you. This helps reduce delivery times and improves reliability.
Streaming video is typically delivered in small chunks or segments rather than as a single file. To support continuous playback, streaming infrastructure often relies on caching servers that combine web server and reverse proxy functionality. These servers maintain ongoing delivery of video segments, allowing players to continuously request and receive content as viewers watch.
CDNs now deliver the majority of internet traffic because they improve speed, reliability, and scalability. Without CDNs, services such as video streaming, online gaming, software downloads, and large websites would experience slower performance and more frequent outages during periods of heavy demand. CDNs help ensure content remains available even when millions of users access it simultaneously.
.png)