In the first post of this multi-part series, we dug into how content delivery works. In this second post, we look at the many different ways content delivery networks can be architected.
Content Delivery Networks (CDNs) are among the most important yet least understood components of the internet. Every video stream, software download, website, and online service relies on CDNs to deliver content quickly and reliably to users around the world. While they all serve the same purpose, not all CDNs are built the same way. From private global networks and cloud-hosted platforms to real-time streaming specialists and peer-to-peer architectures, different CDN models offer unique advantages and tradeoffs. Understanding these approaches is essential for anyone involved in delivering digital content at scale.
Content Delivery Networks (CDNs) are a crucial piece of internet infrastructure. The core technology, the reverse proxy cache, is used across the entire internet. But, as we talked about in that first post, these are just specially-purposed web servers, although many CDNs also have a lot of secret sauce in their custom DNS or anycast implementations for traffic routing. And, anyone delivering any kind of content, whether it’s a website, a software download, or a streaming video, is using a web server (sure, there are some special cases, like using Real Time Media Protocol, that require specialty servers). When it comes down to it, CDNs are really just farms of web servers set up to handle incoming HTTP requests and respond with the content that is requested. The CDN itself uses special control plane software that allows them to spread out across their cache infrastructure. Without that, all the requests would go back to the source of the content, the origin, which, in the event of a lot of requests, would make that server unavailable.
That means that anyone operating a web server is, in essence, operating a cache. That’s why this piece of technology is so fundamental to the internet. Without web servers, the web wouldn’t be possible. Without commercial CDN operators and their big farms of web servers, the web, at scale, wouldn’t be possible. But not all CDNs are architected the same. In fact, you could say that there are four basic types:
First, what’s a leased wavelength? Without getting into the science of it all, wavelength defines a characteristic of a wave, in this instance light. These wavelengths of light, for the purpose of delivering data, are all contained in fiber optic cables. In telecommunications equipment, the wavelength is controlled by a modulator. So, for CDNs that chose this kind of architecture, they not only have to pay for wavelength subscription (from a trunk provider like Lumen), but they have to buy, operate, and maintain their own fiber optic modulators. In addition to that, they must purchase the other core CDN infrastructure, like servers, routers, and load balancers, and build out data centers (otherwise called a Point of Presence, or PoP) in key geographic areas.
The benefits of this network are increased security and more consistent performance. In short, it’s private. The CDN provider that builds and operates this network, such as Limelight Networks (now Edgio), owns the network. It is only their traffic running through the capacity. The performance can be much more consistent than a private network which is routed because, again, the provider owns the network. The traffic is not bouncing from one network to another. It is delivered entirely through the private network. And because the network is a physical, private network the CDN can optimize it for consistency and reliability.
The drawbacks are, obviously, cost. This is a very expensive network and every time new capacity is needed, more capital must be spent.
The non-wavelength version of the closed physical network CDN has many of the same characteristics. But, in this case, the delivery of traffic may run over many other networks on its journey through the internet. The magic of this kind of network is that special algorithms determine the best possible path to the ideal cache for serving a specific request.
There are many benefits to this kind of approach for content delivery. First is that it’s much less capital intensive. While it still requires physical infrastructure, such as servers, routers, and load balancers in geographically distributed PoPs, there is no requirement for wavelength subscription or equipment, like modulators or multiplexers. Second is that capacity of the entire network is no longer dependent on the amount of capacity from a provider. Because this CDN delivers traffic often through the internet (which is really through a bunch of other unmanaged networks), capacity isn’t limited to what the CDN operator provisions. Of course, it’s dependent upon the capacity in those other unmanaged networks, but with the magic of those algorithms, low capacity or constrained networks can be avoided in the delivery path.
The drawback to this kind of network is that there can really only be one: Akamai. They hold a lot of patents which define the routing of traffic through optimal network paths.
A cloud-hosted CDN, such as something built on top of AWS or Google, is like a virtualized private network CDN, similar in architecture to leased wavelength as the content is delivered only on the rails of the cloud provider.
You can probably guess that this is a much cheaper alternative to building out physical infrastructure (although that may be a little simplistic as cloud providers, like AWS, can charge significantly for compute and data egress). But there’s an immediate drawback as well–this CDN relies on another provider’s infrastructure. So, they don’t have the same opportunities to optimize the physical network as do the closed-network CDN providers. What’s more, those cloud provider rails are delivering other traffic as well which can sometimes make traffic delivery through these options less secure than on a closed physical network. In addition, the cloud-based CDNs can only declare their geographic regions which are supported by the cloud providers. This makes them inherently limited to serve traffic for large-scale events.
With the advent of real-time streaming have come a new crop of CDNs that specialize in delivering specific kinds of traffic using non-standard delivery methods. Because CDN caches are really web servers, they deliver HTTP-based traffic (that can either be traditional HTTP2 traffic overTCP, or even HTTP3 traffic running over QUIC). But there are other protocols, like WebRTC and RTMP, which are far better at delivering a real-time streaming experience which might be needed for live sports betting. The issue, though, is scale. These protocols require specialized software that is not part of a normal web server. What’s more, they often cannot support as many sessions as a standard web server can which requires more servers to scale to meet demand.
The benefit of these networks is that they are purpose-built. So for content owners with specific use cases that necessitate alternate protocols, like WebRTC, these speciality CDN providers have very optimized delivery networks. The downside, of course, is scale. Many of these speciality providers are smaller operators without the capital to purchase and host lots of servers. While they may have some physical infrastructure, they often supplement with virtual instances giving them greater geographic reach but limiting their ability to truly optimize delivery. It’s important to note, though, that these scaling issues are being addressed. Some of the real-time streaming providers that are operating WebRTC farms are getting much better at maximizing the number of sessions a single server can support. So while these CDNs might not be scalable to millions of concurrent users, they can support hundreds of thousands. Future protocols, like Media-over-QUIC (or MOQ), provide the same kind of real-time streaming as WebRTC but don’t require specialty servers (as they are HTTP-based).
Peer-to-Peer (P2P) networks are a very unique, distributed architecture. While traditional CDNs rely on physical infrastructure (whether that is purchased by the CDN operator or made available by a cloud provider), P2P CDNs do not. They rely on a user base installing their software to act as distribution nodes.
What truly makes P2P delivery different, though, is how content is routed. In a P2P network, there is a centralized broker service to which all the nodes in the network subscribe. When a node requests content, the broker finds the nearest node to the requester that has the content. When that node has been identified, the broker hands off the connection to the node so that a dedicated connection is made between the two nodes. Unlike a traditional CDN where a centralized network is managing all incoming requests and load balancing them across caching pools, P2P are all about one-to-one connections.
While there are some advantages to this, such as a very low cost architecture and scaling economics which are much cheaper than buying and hosting servers, there are also significant disadvantages to this. The first is security. Because there is no network operator in control of the computers serving the content, there is no way the content owner can be assured that their content remains secure. The second is performance. There is no way to guarantee the performance of a single user’s internet connection. As such, a streaming operator using a P2P network can’t be assured that any single user will have a positive user experience.
There have been some interesting hybrid approaches to content delivery using traditional CDN infrastructure “assisted” by P2P. So, when it makes more sense to deliver from a local user’s node, rather than going back up to the CDN caches, the network can choose to shift delivery to P2P. This is especially relevant in sparsely populated areas where Tier 2 or Tier 3 ISPs may be located a significant distance from an upstream CDN provider who is peered with the Tier 1 ISP providing those ISPs with their capacity.
There are some common elements of any type of network-based CDN:
While there are many different network approaches for delivering content, there is no one right way. That’s probably the reason that most content operators utilize a few different CDNs simultaneously. This allows them to switch between the CDNs, selecting the network which offers the best performance in a given region. In these “multi-CDN” architectures, the CDNs can be a combination of types all of which provide the streaming operator the geographical, performative, and economic advantages of multiple types of CDNs.
But more ways to deliver content are on the horizon. These could include 5G-based CDNs, which are “sliced” private segments within a larger mobile operator’s network, broadcast networks, such as ATSC 3, and even overlay networks which, utilizing something like the SVTA’s Open Caching specifications, connects the caches of many CDNs together into a single “capacity footprint”.
While all CDNs are designed to deliver content efficiently, they can be built using different architectures. The most common types are closed physical networks using leased wavelengths, closed physical networks that route traffic across multiple networks, cloud-hosted CDNs, specialty CDNs optimized for real-time streaming, and peer-to-peer (P2P) networks. Each approach offers different tradeoffs in performance, scalability, cost, and control.
Private physical CDN networks give operators greater control over performance, reliability, and security because content travels entirely over infrastructure they own or lease. This reduces dependence on third-party networks and allows providers to optimize traffic flows. The tradeoff is cost, as building and maintaining dedicated fiber, servers, routers, and data centers requires significant capital investment.
Cloud-based CDNs rely on infrastructure provided by cloud platforms such as AWS or Google Cloud rather than owning physical networks and data centers. This can reduce upfront infrastructure costs and simplify deployment. However, cloud-based CDNs are dependent on the cloud provider’s geographic footprint, network performance, and pricing models, which can limit optimization opportunities compared to privately operated networks.
Traditional CDNs primarily deliver HTTP-based traffic such as web pages, video segments, and software downloads. Real-time streaming CDNs often support protocols like WebRTC and RTMP that are designed for ultra-low-latency applications such as sports betting, interactive broadcasts, and live communications. These specialized protocols require different server software and infrastructure, making real-time CDNs highly optimized for specific use cases but often more challenging to scale.
Many content providers adopt a multi-CDN strategy to improve reliability, performance, and geographic coverage. By using several CDN providers simultaneously, they can dynamically route traffic to the network that delivers the best performance for a specific region or audience. This approach reduces dependence on any single provider and helps ensure content remains available even if one CDN experiences congestion or outages.
.png)