Solutions in Azure : Azure CDN for Maximum Bandwidth & Reduced Latency – Part I
Under the Current Ecosystem of Microsoft Cloud; Azure CDN has been widely recognized as CDaaS (Content Delivery as a Service), with its growing network of POP locations it can be used for offloading content to a globally distributed network of servers. As its prime functionality it caches static content at strategically placed locations to help distributing Content with low latency and higher data transfer that ensures faster throughput to your end users.
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.
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.
Author Credits: This article was written by Utkarsh Pandey, Azure Solution Architect at 8KMiles Software Services and originally published here