Express delivery to your Internet customers
In today's highly competitive e-business world, companies must deliver Web content faster than their competitors to attract and retain Internet customers. According to a study that Jupiter Research Center conducted in 2000, 7 percent of customers will abandon a Web page if the download time is less than 7 seconds, 30 percent will move on if the download time is 8 to 11 seconds, and 70 percent will leave the Web page if the download time is 12 seconds or longer.
To avoid losing customers because of slow download times and to improve customers’ Web surfing experience, many companies deploy load balancers to equalize the load among multiple Web servers in one site or across two or more sites. (For more information about load balancers, see "Web Server Load Balancers," April 2000.) Some companies place reverse proxy servers in front of Web servers to cache Web pages that external customers frequently access, and many companies use cache servers in their intranets to cache Web pages that their internal users frequently access. (For more information about Web caching, see "Surfing Web-Caching Technology, Part 1," September 1999, and "Surfing Web-Caching Technology, Part 2," October 1999.) Load balancers efficiently select the least-busy Web server among several mirrored servers to speed Web content retrieval. However, a load balancer doesn’t minimize the number of hops that content must make to reach a requesting user; the average number of hops between a browser or browser's cache server and a Web site is 17. So, many hops can degrade a company’s Internet-content delivery performance, even if the company’s Web site quickly retrieves the content and the customer has a fast Internet link. Even with a cache server, the hit ratio will be only about 40 percent. The other 60 percent of requests must travel to the originating Web server over the Internet.
To provide better quality and faster Web service, content providers want to put their content as close as possible to the customers who want it. Over the past 2 years, this concept has evolved into a new Web architecture and Internet service called Content Delivery Network or Content Distribution Network (CDN). The Internet Engineering Task Force (IETF) calls this new architecture a Content Network (CN).
A CDN is a smart, application-layer network that a CDN service provider builds on the Internet to guarantee high-performance content delivery. Organizations such as content providers and Web-hosting services can subscribe to CDN services—many organizations are already taking advantage of CDN’s benefits. The High Tech Resource Consulting Group, a market research firm, estimates that the CDN market will grow to $2.3 billion by 2002.
CDN Architecture and Services
A CDN replicates a Web server’s content from the origin server (CDN terminology for the originating Web server) to the CDN's surrogates (i.e., content or cache servers) at various Points of Presence (POPs) near customers. A CDN POP often has multiple surrogates and uses a load balancer to spread the load among them.
When a customer requests content, the CDN directs the user's request to the nearest POP, whose load balancer forwards the request to the least-loaded surrogate. This surrogate retrieves the content from its cache and delivers the content through the load balancer to the customer. Figure 1 shows CDN architecture and the three major CDN functions: accounting, content distribution, and request routing.
Accounting
As Figure 1 shows, accounting takes place on the surrogate level. Each surrogate logs content usage, such as the speed (in megabits per second) with which the surrogate delivers content and the number of hits that particular content (i.e., a specific page or object) receives, and reports the usage information to a central accounting system. The CDN uses the gathered accounting information to charge subscribers, produce statistics for subscribers, and analyze the workload of surrogates and POPs.
Content Distribution
A CDN can use two methods to distribute content from an origin server to surrogates: the Internet or satellite broadcast. Using the Internet to replicate content is the simple and natural choice. Distribution occurs when a company changes content on its origin Web server or when the CDN adds a new surrogate to the network. Because only one distribution takes place from the origin server to each surrogate per content change, the bandwidth consumption and workload for content distribution is almost nothing when compared with the number of content accesses and fetches each surrogate performs for requesting customers. Many CDN service providers, such as Akamai Technologies, Digital Island, and Mirror Image Internet, use the Internet for content distribution.
If a company’s origin server is far away from surrogate locations or slow links exist between the origin server and the surrogates, content distribution performance for rich content such as realtime streaming multimedia will be unpredictable. For such content, satellite broadcasting provides a high-performance transmission path from the origin server to remote surrogate locations. However, satellite broadcasting is an expensive solution. Using a satellite channel can cost hundreds of thousands of dollars per month. Despite this cost, several CDN service providers, such as Cidera and Loral CyberStar, use satellite broadcasting.
A CDN uses either the push or pull method to maintain up-to-date replicated content on its surrogates. In the push method, a content distribution controller monitors content on the origin server. When a change occurs, the controller copies and synchronizes the change from the origin server to remote surrogates. Consequently, the surrogates always contain up-to-date content. Several CDN service providers, such as Mirror Image Internet, use the content push method.
A content distribution controller can be a hardware appliance (e.g., F5 Networks' GLOBAL-SITE Controller) or a software package (e.g., Inktomi's Content Delivery Suite) that can run on a dedicated server or on the origin server. With either the hardware or software content-distribution solution, you can specify which files, pages, objects, and applications on the origin server you want the controller to replicate, to which surrogates, and under what conditions. A content distribution controller can publish content to popular Web server software-based servers, such as Apache, Microsoft IIS, and Netscape Enterprise Server. However, controllers often require that surrogates run the associated surrogate product from the controller’s vendor. For example, F5 Networks' GLOBAL-SITE Controller works with F5 Networks' EDGE-FX Cache, and Inktomi's Content Delivery Suite works with Inktomi's Traffic Server. Some vendors have been working together to improve CDN product interoperability. In April 2001, F5 Networks and Inktomi announced a strategic alliance to integrate their CDN products.
Previous
Register
