In contrast to CDNs that use the push method, CDNs that use the content pull method don't have a dedicated content distribution controller to push the changed content to surrogates. When a CDN’s request-routing system directs a customer's request to a specific surrogate, the surrogate retrieves the locally cached content and passes it to the user. If the content isn’t cached locally on the surrogate, the surrogate fetches the requested content from the origin Web server.
Surrogates that use the pull method work like ordinary cache servers. The surrogates update cached content by checking for content changes on the origin server, and they purge cached content that users haven’t requested in a long time. Most CDN product manufacturers offer a cache server-based surrogate in their product lines (e.g., CacheFlow's Edge Accelerator and Server Accelerator, Network Appliance's NetCache, F5 Networks’ EDGE-FX Cache, Inktomi's Traffic Server). Most CDN service providers use the content pull method.
Although the pull method doesn’t provide as high a content hit ratio as the push method does, the hit ratio can still approach 100 percent, and a pull-method CDN will be much faster than a typical cache system. If a surrogate’s average hit ratio is 99 percent and we assume that content delivery time is 0.1 second for a hit and 8 seconds for a miss, then the average content delivery time for a CDN surrogate is 0.179 seconds. If the average hit ratio on a typical non-CDN cache server is 40 percent and we assume the same content delivery times that we assume for the CDN surrogate, then the average content delivery time for a non-CDN cache server is 4.84 seconds. Therefore, a pull-method CDN delivers content about 27 times as fast as a typical cache system.
Request Routing
Another important CDN service is request routing (aka content redirection and content routing), which directs users’ requests to an appropriate surrogate. A CDN request-routing system selects a surrogate according to various criteria, such as proximity of the surrogate network to the user, surrogate load, and content availability. The IETF recently studied CDNs’ request-routing techniques and concluded that CDNs use three primary request-routing mechanisms: DNS, transport-layer, and application-layer request routing. (To read the IETF report, click here.) CDNs can implement a combination of all three types.
DNS request routing. When a client requests content from a Web site, the client first needs to resolve the content server’s IP address through DNS. A local DNS server answers the client's query by returning an A record for the site. This A record contains the IP addresses for one or more selected surrogates. If the client receives more than one IP address, the client chooses a surrogate in a round-robin fashion. If a CDN uses a load balancer in the POP, the IP address in the A record is a virtual IP (VIP) address. CDNs often use smart servers, which have more capabilities than a BIND or Microsoft DNS server and direct users’ requests to the most appropriate surrogate.
Suppose example.com, a CDN subscriber, has delegated the subdomain www.example.com from its authoritative DNS server to the CDN's smart DNS server so that the smart DNS server can control surrogate selection for www.example.com. Figure 2 illustrates the following steps in smart DNS request routing:
- A user needs to access www.example.com. The user’s local DNS server looks up the IP address of www.example.com.
- If the local DNS server doesn't have a cached address for www.example.com, the server asks example.com’s authoritative DNS server for the IP address of www.example.com. The authoritative DNS server replies to the local DNS server with the Name Server (NS) record of www.example.com. This record provides the name of the CDN’s request-routing DNS server for www.example.com.
- The local DNS server sends the name-resolution request to the CDN request-routing DNS server.
- The request-routing DNS server instructs the load balancer in each CDN POP to determine the network proximity from the POP to the user's local DNS server. The request-routing DNS server uses this information to determine which POP is most appropriate for the user. (You should always disallow recursive resolution on an authoritative server to prevent the server from resolving IP addresses for the local DNS server. If you don’t, CDN load balancers will measure the POP’s proximity to the authoritative DNS server rather than to the local DNS server.)
- The load balancer in each POP probes the local DNS server to measure the load balancer’s network proximity to the user’s local DNS server. The request-routing DNS server can also perform this measurement task if it’s in a POP. This measurement task typically requires that the POP’s load balancer and the POP’s request-routing DNS server be from the same vendor.
-
Load balancers report the results of the network-proximity measurement to the request-routing DNS server. The load balancers also report their POP workload and surrogate availability status.
- The request-routing DNS server uses the metrics it receives from the load balancers to determine the best POP surrogate for the user and sends the VIP address of the chosen surrogate to the user's local DNS server. To prevent the local DNS server from caching the address for long, the VIP address’s Time to Live (TTL) value is usually very short. If the local DNS server caches the address for too long, availability problems might arise if the POP surrogate becomes unavailable.
- The local DNS server passes the VIP address to the user.
- The user requests content from the chosen POP surrogate.
