A content delivery network is a geographically distributed group of servers optimized to deliver static content to end users. This static content can be almost any sort of data, but CDNs are most commonly used to deliver web pages and their related files, streaming video and audio, and large software packages.
A CDN consists of multiple points of presence (PoPs) in various locations, each consisting of several edge servers that cache assets from your origin, or host server. When a user visits your website and requests static assets like images or JavaScript files, their requests are routed by the CDN to the nearest edge server, from which the content is served. If the edge server does not have the assets cached or the cached assets have expired, the CDN will fetch and cache the latest version from either another nearby CDN edge server or your origin servers. If the CDN edge does have a cache entry for your assets (which occurs the majority of the time if your website receives a moderate amount of traffic), it will return the cached copy to the end user.
When a user visits your website, they first receive a response from a DNS server containing the IP address of your host web server. Their browser then requests the web page content, which often consists of a variety of static files, such as HTML pages, CSS stylesheets, JavaScript code, and images.
Once you roll out a CDN and offload these static assets onto CDN servers, either by "pushing" them out manually or having the CDN "pull" the assets automatically (both mechanisms are covered in the next section, you then instruct your web server to rewrite links to static content such that these links now point to files hosted by the CDN. If you're using a CMS such as WordPress, this link rewriting can be implemented using a third-party plugin like CDN Enabler.
Many CDNs provide support for custom domains, allowing you to create a CNAME record under your domain pointing to a CDN endpoint. Once the CDN receives a user request at this endpoint (located at the edge, much closer to the user than your backend servers), it then routes the request to the Point of Presence (PoP) located closest to the user. This PoP often consists of one or more CDN edge servers collocated at an Internet Exchange Point (IxP), essentially a data center that Internet Service Providers (ISPs) use to interconnect their networks. The CDN's internal load balancer then routes the request to an edge server located at this PoP, which then serves the content to the user.
Caching mechanisms vary across CDN providers, but generally they work as follows:
X-Cache: MISS
. This initial request will be slower than future requests because after completing this request the asset will have been cached at the edge.X-Cache: HIT
.To learn more about how a specific CDN works and has been implemented, consult your CDN provider's documentation.
In the next section, we'll introduce the two popular types of CDNs: push and pull CDNs.
Most CDN providers offer two ways of caching your data: pull zones and push zones.
Pull Zones involve entering your origin server's address, and letting the CDN automatically fetch and cache all the static resources available on your site. Pull zones are commonly used to deliver frequently updated, small to medium sized web assets like HTML, CSS, and JavaScript files. After providing the CDN with your origin server's address, the next step is usually rewriting links to static assets such that they now point to the URL provided by the CDN. From that point onwards, the CDN will handle your users' incoming asset requests and serve content from its geographically distributed caches and your origin as appropriate.
To use a Push Zone, you upload your data to a designated bucket or storage location, which the CDN then pushes out to caches on its distributed fleet of edge servers. Push zones are typically used for larger, infrequently changing files, like archives, software packages, PDFs, video, and audio files.
source: digitalocean