Transport-layer request routing. As I mentioned, DNS request routing uses the IP address of a user's local DNS server as a factor in selecting a surrogate for the user. If the user's DNS server isn’t close to the user, the DNS server address can introduce misleading information in the DNS request-routing system’s surrogate selection. Transport-layer request routing solves this problem.
After the DNS request-routing system chooses a surrogate for a user's initial connection and directs the user to the surrogate, a transport-layer request-routing system examines the first packet of the user request to determine whether the chosen surrogate is optimal for the user. Each POP includes a transport-layer request-routing system that vendors usually implement in the load balancer. Based on the information in the first packet, including the IP address, port number, transport-layer protocol, and user policy and performance metrics, the transport-layer request-routing system determines whether it needs to select a more suitable surrogate POP for the user request.
Figure 3 illustrates triangulation, a common implementation of transport-layer request routing. After a user receives a VIP for a surrogate in the CDN’s POP1, the user sends a content request to the surrogate. POP1's transport-layer request-routing system uses the information in the user’s first packet to determine that POP2 can better fulfill the user's request (e.g., POP2 might provide the user better ftp download capabilities). POP1 then forwards the request to POP2's transport-layer request-routing system. POP2 recognizes that the arriving request is from POP1's transport-layer request-routing system. After POP2 fetches the requested content, POP2's transport-layer request-routing system changes the source IP address in the content packet’s IP header to POP1's VIP address and sends the packet to the user. When the user receives the packet, the user thinks the packet is from POP1. The user continues sending requests to POP1 until the session finishes. Triangulation redirection works well because upstream traffic from users is light compared with downstream traffic from a POP. Using triangulation to provide a more efficient downstream path for user requests improves content-delivery performance.
Application-layer request routing. An application-layer request-routing system conducts a deeper inspection of the user request by checking the application information beyond the transport layer in the received packet. This examination lets the application-layer request-routing system determine the best surrogate for a user request based on information at the individual-object level. For example, when a user requests a news page that contains news items, graphics, and advertisements, the application-layer request-routing system can redirect the user to retrieve each object from the best surrogate. Three major methods for implementing application-layer request-routing systems exist: header inspection, HTTP and Real Time Streaming Protocol (RTSP) redirection, and content modification.
In the header of a session request, HTTP, RTSP, and Secure Sockets Layer (SSL) applications provide useful information, such as a URL, cookie, session identifier, site specification, or language specification. For example, an SSL session requires a persistent connection between a user and the surrogate running the SSL application. By inspecting the user information in the user’s cookie or the surrogate information in the SSL session identifier, an application-layer request-routing system can direct the user’s requests to the same surrogate for the entire session.
Alternatively, an application-layer request-routing system can use HTTP and RTSP redirection to redirect a user’s GET request to another surrogate. If a user requests information from a surrogate that’s overloaded or down, the application-layer request-routing system responds to the user’s GET request with a 301 (moved temporarily) or 302 (moved permanently) code message that includes the IP address of the surrogate with which the user was communicating. The user’s browser can then initiate a new session.
The third method, content modification, lets a content provider control request-routing decisions. When the content provider subscribes to a CDN service, the content provider rewrites URLs on the origin server. For example, an HTML Web page often contains plaintext as well as embedded objects such as graphics and images. The Web page uses embedded HTML directives in the form of URLs to reference the embedded objects. Usually, the embedded URLs point to the embedded objects on the same origin server that contains the Web page. However, to take advantage of a CDN service, the content provider can change the embedded URLs to CDN URLs so that the CDN service can deliver bandwidth-sensitive objects such as graphics, images, and streaming multimedia.
As Figure 4 shows, when a user requests a Web page, the request goes to the origin server first. The origin server returns to the user the HTML Web page with the embedded CDN URLs. The user then retrieves the embedded objects from the CDN. The user must resolve the domain name in a CDN URL so that the CDN can use DNS request routing to select an optimal POP and surrogate to fulfill the user request. The CDN then uses transport- and application-layer request routing to redirect the user’s request to the best POP or surrogate.
