Who needs them?
You can easily become bogged down in the day-to-day aspects of an IIS administrator's job—such as installing the most recent security hotfixes—and overlook more interesting tasks such as tuning Web site performance, ensuring scalability, and optimizing bandwidth utilization. For the good of your Web site and your sanity, take a few minutes away from NTBugtraq to learn how Content Delivery Networks (CDNs) can improve your site's performance while reducing your costs.
What's a CDN?
A CDN is a set of multiple, coordinated HTTP proxy servers—called CDN cache nodes—distributed throughout the Internet. Proxy servers, such as Microsoft Internet Security and Acceleration (ISA) Server 2000, sit between a Web server and the public Internet and cache frequently accessed pages and images. As Figure 1, page 2, shows, a proxy server receives an incoming request exactly as though the proxy server were a Web server. The proxy server then impersonates a Web browser to request the page from the actual Web server. After the Web server returns the page, the proxy server forwards a copy to the end user and stores a copy on its local hard disk. The next time a user requests that page, the proxy server can serve it directly from its hard disk, saving a request to the Web server.
A CDN distributes Web site content throughout the Internet to cache nodes at the ISPs that provide access to the end users who visit your site. The cache nodes serve the Web pages faster than your Web server can because the pages don't have to cross the congested Internet backbone. Figure 2, page 2, shows a small CDN consisting of two cache nodes at two ISPs. However, CDN providers can have thousands of nodes distributed throughout the Internet.
To determine the ideal locations for its cache nodes, a CDN provider must understand where users connect to the Internet and how traffic travels between ISPs. After identifying locations, the CDN provider must make arrangements with ISPs to plug its cache nodes into their networks. Although most ISPs offer rack space for hosting Web servers, CDN providers need to get their cache nodes as close to the network as possible—preferably directly connected to the ISP's main routers. CDN providers might pay an ISP to plug a cache node into the ISP's network, or they might convince the ISP that having a cache node on the ISP's network will improve performance for the ISP's customers and reduce the ISP's upstream bandwidth requirements.
Contracting with a CDN provider to move your Web site's content closer to your end users has several positive effects. First, it improves the performance of your Web site for users because their requests don't have to incur the delay of crossing the Internet. Second, a CDN takes the load off your Web server, so you don't need as many servers or processors to meet your users' demands. Finally, it reduces the bandwidth your Web server generates, which saves you money because you can purchase less bandwidth from your ISP or hosting service provider. The CDN provider charges you for the bandwidth you use, but this cost is typically lower than the alternative.
Of course, using a CDN presents some technical challenges. If you manage one IIS server, making a change to your Web site is as simple as editing a file. Changes are more complicated when your content is distributed around the Internet. At a minimum, CDN cache nodes respect the content expiration setting you configure on the HTTP Headers tab of the Web site's Properties dialog box (just as browsers do). Some CDN providers also offer a proprietary UI for removing content from cache nodes.
CDN Origins
CDNs were originally designed to compensate for Internet performance problems. From 1996 to 1998, Internet use was growing too quickly for most ISPs to keep up with. Internet backbones and peering points, in particular, were becoming performance bottlenecks. (Peering points are locations on the Internet at which ISPs freely exchange traffic with one another.) The performance of a Web site for a given user is tied to the number of hops between the two points—the more hops across the backbone the traffic had to make, the slower the site performed for the user when the Internet backbone was slow. E-commerce sites lost money because performance was so bad that customers left the sites without ordering.
Given that the backbone was a significant cause of poor performance, the idea of placing a Web site in multiple places on the Internet made sense. The promise of performance improvement made CDNs a clear value proposition.
Then, in 2000, everything changed. When the dot-coms went bust, the number of e-commerce sites dwindled. As the growth of the Internet slowed, ISPs had a chance to catch up with the performance demands placed on the backbone. Now that backbone and Web site performance has improved, who still needs a CDN?
Scalability and Bandwidth
Perhaps you do, but you probably don't need a CDN to reduce Internet latency. Today, CDNs are most useful to those who have a different performance-related need—Web site scalability. It makes sense that you can reach a larger audience if you serve content from 100 different devices on the Internet than from one Web server. CDNs let a Web site scale to accommodate many times more users than would otherwise be possible, and they do so with the cost-efficiency of a shared infrastructure.
Previous
Register
