Azure CDN particularly offers a global solution to the developers for delivering high-bandwidth content by caching the content at physical nodes across the world. Now requests for these contents has to travel shorter distance reducing the number of hops in between. With CDN in place you can be ensured that Static files such as (images, JS, CSS, videos etc.) and website assets are sent from servers closest to your website visitors. For content heavy websites like e- commerce this latency savings could be of significant performance factor.
In essence, Azure CDN puts your content in many places at once, providing superior coverage to your users. For example, when someone in London accesses your US-hosted website, it is done through an Azure UK PoP. This is much quicker than having the visitor's requests, and your responses, travel the full width of the Atlantic and back.
There are two players (Verizon & Akamai) to provide us those edge locations for Azure CDN. Both providers have distinct ways of building their CDN infrastructures. Verizon on one hand has been quite happy disclosing their location on the contrary Azure CDN from Akamai POP locations are not individually disclosed. To get the updated list of locations keep checking Azure CDN POP Locations.
How Azure CDN Works
Today, over half of all internet traffic is already being served by CDNs. Those numbers are rapidly trending upward with every passing year, and azure has been significant contributor there.
As with most of the azure services, Azure CDNs are not magic and actually work in a pretty simple and straightforward manner. Let’s just go through the actual case-
- A user (XYZ) requests a file (also called an asset) using a URL with a special domain name, such as
.azureedge.net. DNS routes the request to the best performing Point-of-Presence (POP) location. Usually this is the POP that is geographically closest to the user. - If the edge servers in the POP do not have the file in their cache, the edge server requests the file from the origin. The origin can be an Azure Web App, Azure Cloud Service, Azure Storage account, or any publicly accessible web server.
- The origin returns the file to the edge server, including optional HTTP headers describing the file's Time-to-Live (TTL).
- The edge server caches the file and returns the file to the original requestor (Alice). The file will remain cached on the edge server until the TTL expires. If the origin didn't specify a TTL, the default TTL is 7 days.
- Additional users (ex. ABC) may then request the same file using that same URL, and may also be directed to that same POP.
- If the TTL for the file hasn't expired, the edge server returns the file from the cache. This results in a faster, more responsive user experience.
Reasons for using a CDN
- To understand the reasons behind why Azure CDN is so widely used, we first have to recognize the issue they're designed to solve (LATENCY). It's the annoying delay that occurs from the moment you request to load a web page to the moment its content actually appears onscreen, especially applications where many “internet trips” are required to load content. There are quite a few factors which contribute to this, many being specific to a given web page. In all cases however, the delay duration is impacted by the physical distance between you and that website's hosting server. Azure CDN's mission is to virtually shorten that physical distance, the goal being to improve site rendering speed and performance.
- Another obvious reason for using the Azure CDN is throughput. If you look at a typical webpage, about 20% of it is HTML which was dynamically rendered based on the user’s request. The other 80% goes to static files like images, CSS, JavaScript and so forth. Your server has to read those static files from disk and write them on the response stream, both actions which take away some of the resources available on your virtual machine. By moving static content to the Azure CDN, your virtual machine will have more capacity available for generating dynamic content.
When a request for an object is first made to the CDN, the object is retrieved directly from the Blob service or from the cloud service. When a request is made using the CDN syntax, the request is redirected to the CDN endpoint closest to the location from which the request was made to provide access to the object. If the object is not found at that endpoint, then it is retrieved from the service and cached at the endpoint, where a time-to-live (TTL) setting is maintained for the cached object.
Related Articles : Solutions In Azure: Azure CDN
