Content Delivery Networks: A Primer

Content Delivery Networks (CDNs) cache your content around the globe to reduce latency and improve performance for end users. It is a very powerful tool and can be leveraged by any web site. Historically, CDN providers have been very expensive and were not practical for most people. Now things have changed and there are many CDN providers that cater to cloud customers who want pay-as-you-go service.

Check out CloudFront, Rackspace Cloud Files, MaxCDN, SoftLayer CloudLayer, and more.

How a CDN works

CDN providers place servers strategically around the globe so that content can be served quickly to all users. These are usually referred to as Edge Servers or Edge Locations. When a user makes an HTTP request, a domain name is resolved to one or more IP address(es) that belong to the CDN.

The key here is returning IP addresses that are close to the requesting user. There are various methods to determine the user's location and which Edge Servers to return:

  • Use Anycast for the CDN's name servers to determine the closest Edge Location.
  • GeoIP lookup of the requesting DNS server. This goes on the premise that a user's configured DNS servers are close to the user. This is typical when using your ISP's provided name servers.
  • Use Anycast for the CDN IP addresses which means that packets should be routed to the closest receiver. (CacheFly, MaxCDN)
  • Experimental - DNS requests carry the originating user's subnet -- this can be used to help determine a physical location. See draft-vandergaast-edns-client-subnet-00
DNS is heavily utilized for determining a user's location. If you were to configure your computer to use a DNS server in another continent, the CDN would most likely provide you with Edge Servers that are probably very far away.

An example

This site is currently using Amazon's CloudFront to serve all content, which works great because everything is static (aside from the comments, which are loaded dynamically from Disqus).

CloudFront seems to use a GeoIP lookup of the requesting DNS server and/or Anycast for their authoriative name servers.

By running the following command the name www.chrismoos.com will be resolved to CloudFront's network:

$ dig @8.8.8.8 www.chrismoos.com
;; ANSWER SECTION:
www.chrismoos.com.  300  IN  CNAME   d38g1j01afvwut.cloudfront.net.
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.145
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.44
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.166
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.1
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.89
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.197
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.134
d38g1j01afvwut.cloudfront.net. 60 IN A   205.251.203.254

The record www.chrismoos.com is a CNAME that points to d38g1j01afvwut.cloudfront.net., which is provided by CloudFront and is a unique domain for my CloudFront distribution.

This CNAME is then resolved into multiple IP addresses.

Looking at the first A record with the IP 205.251.203.145 shows that it is a server in Los Angeles (lax) which is physically close to me (I am in Phoenix, Arizona).

server-205-251-203-145.lax3.r.cloudfront.net.

Spoofing your location

Making a query to a DNS server in Germany for www.chrismoos.com gives different results:

$ dig @87.118.100.175 www.chrismoos.com
;; ANSWER SECTION:
www.chrismoos.com.  174  IN  CNAME   d38g1j01afvwut.cloudfront.net.
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.184
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.188
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.227
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.42
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.52
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.126
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.160
d38g1j01afvwut.cloudfront.net. 60 IN A   216.137.59.168

The IP address 216.137.59.184 resolves to:

server-216-137-59-184.ams1.r.cloudfront.net.

The above shows that the server is in Amsterdam, which is physically close to the DNS server we sent the request to (in Germany).

Serving content fast

Telling the user the closest server is only half the battle. Now these geographically distributed Edge Servers need to actually provide content -- and deliver it fast.

In the next part I will discuss the importance of HTTP caching when using a CDN and how to balance performance and freshness of your content.

Written on December 5, 2012