Web Caching

Web Caching

A Web cache - also called a proxy server - is a network entity that satisfies HTTP requests on the behalf of an origin Web server. The Web cache has its own disk storage and keeps copies of recently requested objects in this storage. As shown in Figure 1, a user's browser can be configured so that all of the user's HTTP requests are first directed to the Web cache. Once a browser is configured, each browser request for an object is first directed to the Web cache. As an instance, assume a browser is requesting the object http://www.someschool.edu/campus.gif. Here is what happens:

I. The browser establishes a TCP connection to the Web cache and sends an HTTP request for the object to the Web cache.

Clients requesting objects through a Web cache

2, The Web cache checks to see if it has a copy of the object stored locally. If it does, the Web cache returns the object within an HTTP response message to the client browser.

3. If the Web cache does not have the object, the Web cache opens a TCP connection to the origin server, that is, to www.someschool.edu. The Web cache then sends an HTTP quest for the object into the cache-to-server TCP connection. After receiving this request, the origin server sends the object within an HTTP response to the Web cache.

4. When the Web cache receives the object, it stores a copy in its local storage and sends a copy, within an HTTP response message, to the client browser (over the existing TCP connection between the client browser and the Web cache).

Note that a cache is both a server and a client at the same time. When it receives requests from and sends responses to a browser, it is a server. When it sends requests to and receives responses from an origin server, it is a client.

Normally a Web cache is purchased and installed by an ISP. For instance, a university might install a cache on its campus network and configure all of the campus browsers to point to the cache. Or a major residential ISP (such as AOL) might install one or more caches in its network and preconfigure its shipped browsers to point to the installed caches.

Web caching has seen deployment in the Internet for two reasons. First, a Web cache can considerably decrease the response time for a client request, especially if the bottleneck bandwidth between the client and the origin server is much less than the bottleneck bandwidth between the client and the cache. If there is a high-speed connection between the client and the cache, as there frequently is, and if the cache has the requested object, then the cache will be able to deliver the object rapidly to the client. Second, as we will soon demonstrate with an example, Web caches can considerably decrease traffic on an institution's access link to the Internet. By decreasing traffic, the institution (for instance, a company or a university) does not have to upgrade bandwidth as rapidly, thus reducing costs. Moreover, Web caches can considerably decrease Web traffic in the Internet as a whole, thus improving performance for all applications.

Bottleneck between an institutional network and the Internet

To gain a deeper understanding of the benefits of caches, let's look at an example in the context of Figure 2. This figure shows two networks - the institutional network and the rest of the public Internet. The institutional network is a high-speed LAN. A router in the institutional network and a router in the Internet are connected by a 15 Mbps link. The origin servers are attached to the Internet but are located all over the globe. Assume that the average object size is 1 Mbits and that the average request rate from the institution's browsers to the origin servers is 15 requests per second. Assume that the HTTP request messages are insignificantly small and therefore create no traffic in the networks or in the access link (from institutional router to Internet router). Also assume that the amount of time it takes from when the router on the Internet side of the access link in Figure 2 forwards an HTTP request (within an IP datagram) until it receives the response (normally within many IP datagrams) is two seconds on average. Informally, we refer to this last delay as the "Internet delay".

The total response time - that is, the time from the browser's request of an object until its receipt of the object - is the sum of the LAN delay, the access delay (that is, the delay between the two routers), and the Internet delay. Let's now do a rough calculation to estimate this delay. The traffic intensity on the LAN (see "Queuing Delay and Packet Loss") is

(15 requests/sec) * (1 Mbits/request) / (100 Mbps) = 0.15

whereas the traffic intensity on the access link (from the Internet router to institution router)  is

(15 requests/sec) * (1 Mbits/request) / (15 Mbps) = 1

A traffic intensity of 0.1 5 on a LAN normally results in, at most, tens of milliseconds of delay; hence, we can ignore the LAN delay. However, as discussed in "Queuing Delay and Packet Loss", as the traffic intensity approaches 1 (as is the case of the access link in Figure 2), the delay on a link becomes very large and grows without bound. Hence, the avenge response time to satisfy requests is going to be on the order of minutes, if not more, which is unacceptable for the institution's users, Clearly something must be done.

One possible solution is to increase the access rate from 15 Mbps to, say, 100 Mbps. This will lower the traffic intensity on the access link to 0.15, which translates to negligible delays between the two routers. In this case, the total response time will roughly be two seconds, that is, the Internet delay. But this solution also means that the institution must upgrade its access link from 15 Mbps to 100 Mbps, a costly proposition.

Now look at the substitute solution of not upgrading the access link but instead installing a Web cache in the institutional network. This solution is demonstrated in Figure 3. Hit rates - the fraction of requests that are satisfied by a cache - normally range from 0.2 to 0.7 in practice. For descriptive purposes, lets assume that the cache provides a hit rate of 0.4 for this institution. Because the clients and the cache are connected to the same high-speed LAN, 40 percent of the requests will be satisfied almost at once, say, within 10 milliseconds, by the cache. However, the remaining 60 percent of the requests still need to be satisfied by the origin servers. But with only 60 percent of the requested objects passing through the access link, the traffic intensity on the access link is decreased from 1.0 to 0.6. Normally, a traffic intensity less than 0.8 corresponds to a small delay, say, tens of milliseconds, on a 15 Mbps link. This delay is insignificant compared with the two-second Internet delay. Given these considerations, average delay therefore is

0.4 * (0.01 seconds) + 0.6 * (2.01 seconds)

which is just slightly greater than 1.2 seconds. Hence, this second solution provides an even lower response time than the first solution, and it doesn't require the institution to upgrade its link to the Internet. The institution does, of course, have to purchase and install a Web cache. But this cost is low - many caches use public-domain software that runs on inexpensive PCs.

Adding a cache to the Institutional network


web cache, proxy server, network entity, router, internet delay

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.