What is a CDN?

A CDN is a global infrastructure of proxy servers installed in PoPs (Points of Presence) over geographical locations. The aim is to produce a network that increases the availability and performance of websites or web-based applications.

For a full explanation, please visit the following wiki page: https://en.wikipedia.org/wiki/Content_delivery_network

For the purpose of this document it is important to understand where the CDN sits in the OSI 7-layer model and the technical terms that explain the flow of information as well as understanding which components are required to use a CDN.

‍

‍

Diagram 2 shows all 7 layers and their relationship to specific protocols used within our network and application industry. CDN’s strictly use and work with the HTTP protocol. When considering the use of a CDN for a website/application, it is imperative that the CDN is considered during the design and planning phase. This
will ensure a number of factors:

• Less time modifying the website/application once the CDN is in play.
• Make use of CDN features instead of relying on complex website/application configurations.
• CDN configuration can be completed in parallel to the website/application and no longer need be an additional piece of work.
• UAT without the CDN in play is not a real end user experience.
• Any issues between the website/application and CDN can be resolved during the website/application development phases.

Setting up configurations on a CDN can be just as complex as the website or application itself and this will only get more complex if the CDN is not reviewed early enough in the process.

To point a website or application to a CDN requires a simple DNS CNAME (explained later in the Configuration section of this document) change and a domain setup on the CDN that understands where the Origin Server (hosting server) of the website/application is located.

Diagram 3 shows the flow of information from the browser through to the hosting server when a CDN is in play. There are four main interactions that always need to be considered:

InteractionTypeBest Practice/RecommendationsURQ – User RequestRequestEnd User Request to CDN

• URL Rewrites
• URL Redirects
• Force HTTPS
• Cookie

SRQ – Server RequestRequestCDN Request to the Origin

• HTTP and/or HTTPS
• Host Header
• Encoding
• Cookie

ORP – Origin ResponseResponseOrigin Response to the CDN

• Cache-Control
• Decoding
• Chunking
• Content-Type
• Set-Cookie
• Expires
• Date

SRP – Server ResponseResponseCDN Response to the End User

• Cache-Control
• Decoding
• Set-Cookie
• Expires
• Date

When designing a website/application, best practice would recommend that all customisation should be handled by the website/application itself. While this is preferential there can be some hurdles/options to consider:

• Customisation on the website/application may be handled or interpreted differently by a CDN than a hosting server (Apache, NGINX, ISS etc.).
• If customisation is not handled by the website/application a CDN may enforce default settings.
• There are options available within CDN configurations that are not available on hosting servers or that are much easier to configure and manage.

The key elements from Diagram 3 are the four interactions of flow and functionality when a CDN is in play. Designing, planning and customising a website/application with these interactions will not only lead to a much more refined but also a more efficient and effective application by allowing objects and processes to be run at the correct times and in parallel and not in series. These points lead to a faster loading website/application. We can start to consider how we can manipulate information to our advantage at each interaction (this can be found later in the document Configuration section).