Getting started with Cloud CDN
Getting started with Cloud CDN
21 August 2020
Even before we dive into CDN, let’s understand the issue behind this solution – Latency. Latency can be defined as the total round-trip time taken for a data packet to travel from source to destination and back to source again. One of the main issues causing latency within a network is the distance between the client and the server. And this latency can be annoying at times. CDN (Content Delivery Networks) is a significant step in reducing latency. To minimize the latency, CDN stores cached versions of server’s content in multiple geographic locations known as Points of Presence (PoPs). These PoPs are responsible for delivering content to clients in its proximity.
Overview of Cloud CDN
With an 100+ PoPs, Google CDN uses Google’s global edge networks to deliver contents for users in proximity. Google CDN works with an HTTP(S) load balancing to deliver content to users. The HTTP(S) load balancer provides a frontend IP address and ports to receive requests and backends to respond to the requests.
Cloud CDN content can be obtained from various types of backends such as GCS buckets, instance groups, Zonal NEGs, etc.
Working of Cloud CDN
A user request arrives at Google’s Front End (GFE), located at the edge of Google’s network in proximity to the user, when requested content from a HTTP(S) load balancer. This GFE uses Cloud CDN, if the load balancer’s URL map routes traffic to a backend that has Cloud CDN configured. If the request demands any content for the first time, the GFE understands that the request cannot be fulfilled from the cache, and hence this phenomenon is called cache miss. When a cache miss occurs, GFE attempts to fetch the content from a nearby cache, otherwise it forwards the request to the HTTP(S) load balancer. The backend, which is the server, finally receives the request from the load balancer. Responses can be stored in Cloud CDN cache only if a specific criteria is met. If the server’s response meets this criteria, Cloud CDN stores it in the Cloud CDN cache. One can even invalidate the cache content by removing an item from the cache. An item remains in cache untils it is expired (controlled through HTTP headers) or expelled to accommodate new content.
On the other hand, if the GFE finds the cached response within the Cloud CDN, it sends the cached response to the user. This phenomenon is known as cache hit. During cache hit, GFE searches contents using cache key, thus considerably reducing the round trip time (RTT).
Features
- Invalidation: Some of the important features of Cloud CDN includes the invalidation mechanisms, where the user can remove any item from the cache according to their convenience.
- Origins: Another important aspect of Cloud CDN is its origins to deliver content ranging from GCS buckets, instance groups, zonal NEGs, and many more.
- Signed URLs: This feature of Cloud CDN delivers responses from distributed caches, even when the request needs to be authorized.
Today most of the traffic is served by CDNs, and these numbers are rapidly increasing with increase in years. CDN’s are not for everyone, especially if you are running a strictly localized website, where vast numbers of users are in proximity to the hosting server. In this case, CDNs are of very little benefit. Still, a vast number of sectors still use CDN including online gaming, media & entertainment, etc.