1 Introduction
[DESIRE] [DESIRE Web cache] [Web cache Architecture]
Contents
Drawing on the experiences in the EC 4th Framework Project DESIRE, funded by the European Union, this document identifies some of the pitfalls and possibilities of building Web caching meshes. This document gives guidelines and outlines strategies for building a functional Web caching system with cooperating Web caches.
The architecture of a Web caching mesh is highly dependent on the network topology and the cost factors of the network.
The emphasis is on building Internet Service Provider (ISP) wide caching systems, but architectural considerations for inter-network agreements on Web caching is discussed and examples of policies for international Web caching agreements are given. The impact of Web caching as a routing issue is discussed.
We look into several criteria for choosing Web caching server software and discuss why Squid has been chosen as the primary server software. Then the importance of Web browser (client) configuration is discussed. Criteria for location of Web caching servers and the importance of network topology and traffic flow are discussed. Several basic requirements for hardware used on Web caching servers are included, giving general advice and pointers to several hardware suppliers. The main part of the paper is focused on how to build and join an ISP-wide Web caching mesh, providing examples and listing alternative approaches to the architecture of a mesh.
1.1 Terminology
In this document a number of terms are used to refer to the roles played by participants in, and objects of, the HTTP communication. The following definitions are used in the HTTP/1.1 specification [HTTP/1.1] :
- client
- An application program that establishes connections for the purpose of sending requests. These are often browsers, editors, spiders (Web traversing robots), or other end user tools.
- server
- An application program that accepts connections in order to service requests by sending back responses.
- origin server
- The server on which a given resource resides or is to be created.
- proxy
- An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them, with possible translation, on to other servers. A proxy must interpret and, if necessary, rewrite a request message before forwarding it. Proxies are often used as client-side portals through network firewalls and as helper applications for handling requests via protocols not implemented by the user agent.
- cache
- A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server while it is acting as a tunnel.
- caching mesh
- a set of cooperating caching servers
- local Web cache server
- caching server running on the same LAN as a client
- first level Web cache server
- the Web cache server an end user client connect to
- upper level Web cache server
- seen from the clients view, all caches participating in the caching mesh that are not the clients first level cache are upper level caches
- top-level Web cache server
- one or more servers in a hierarchical caching mesh, normally few requests are made to other caching servers from the top level, serves first level Web cache servers
- neighbor/sibling Web cache server
- caching server participating in caching mesh, sends/receives requests to other cache servers
- parent Web cache server
- neighbor/sibling caching server through which misses are resolved
1.2 Introduction to Web caching
The introduction of World Wide Web has changed the view of the user community to the network in respect to accessibility and user friendliness. With the Web the user is able to look for and retrieve all kind of information from the network without having any knowledge of the network. From the user point of view it does not matter if the information he is looking for, e.g. a video clip with sound effects, is on a computer in the next room or on the other side of the world. This leads to an enormous growth of traffic on the local, national and international network backbone. Because the use of the Web is growing exponentially it is to be expected that the WWW traffic on the national and international networks also will grow exponential with raising latency. Nevertheless the user expects a high quality of service with modest response times.
The quality of service and the response times can be improved by decreasing the network load. One way to achieve this is to install a Web caching service. Caching effectively migrates copies of popular documents from Web servers closer to the Web clients. In general, Web client users see shorter delays when requesting a URL, network managers see less traffic and Web servers see lower request rates. An origin Web server might not only see lower requests rates but primarily will experience a lower server load because files will be fetched with an If-Modified-Since GET HTTP request. Web clients request documents from Web servers, either directly or through a Web cache server or proxy. A Web cache server has the same functionality as a Web server, when seen from the client and the same functionality as a client when seen from a Web server. The primary function of a Web cache server is to store Web documents close to the user, to avoid pulling the same document several times over the same connection, reduce download time and create less load on remote servers.
There is a certain urgency which may be deduced from network usage graphs, which show HTTP traffic increasing with a faster exponential growth rate than total Internet traffic. In 1995 the HTTP traffic has become a significant proportion of the total, and so Web growth is pushing network upgrades, causing performance degradation, and itself being slowed by network limitations [Berners-Lee].
However, the use of caches introduces two main problems: how do we ensure that the caches return the correct values, and how do we obtain the best possible performance. In general, there may be a trade-off between how correct the returned values are, and how effectively the caches perform.
Caching is used in two forms in the Web. The first is a local cache, which is built into a Web browser. A Web client with caching stores not only the documents currently displayed in browser windows, but also documents requested in the past. This local cache is also used for (temporary) storage of the history. There are two forms of client caches: persistent and nonpersistent. A persistent client cache retains its documents between invocations of the Web browser; Netscape uses a persistent cache. A nonpersistent client cache (used in Mosaic) deallocates any memory or disk used for caching when the user quits the browser. Per-client caches may maintain consistency of cached files with server copies by issuing an optional If-Modified-Since GET to the HTTP server or proxy server.
The second form of caching is in the network used by the Web (i.e., the caching proxy mentioned earlier). The cache is located on a machine on the path from multiple clients to multiple servers. Normally a caching proxy is not on a machine that runs a Web client or an HTTP server. The caching proxy caches URLs generated by multiple clients. It is possible to use caching proxies hierarchically, so that caching proxies cache URLs from other caching proxies. In this case the caches can be identified as first level caches, second level caches, and so on. A hierarchical arrangement is only one possible configuration; Smith [Smith96] gives a nonhierarchical arrangement of large national and international caching proxies.
Web caching servers may cooperate in a mesh where they share load and distribute requests. A Webcaching server in a mesh may pass a unfulfilled request on to another Web caching server.
The simplest mesh is two servers strung after another, if a request is not answered on the first cache server, it is passed on to the second and then on to the Web server. Another way is to build a network of servers that have different relations to one another, this may be done by the help of the Internet Cache Protocol, ICP [ICP-draft]. ICP passes messages among Web cache servers.
1.3 Recommended reading
- Quick Introduction to WWW Caching, Martin Hamilton
- DESIRE survey on caching, Henny Bekker, Ingrid Melve, Ton Verschuren
- DESIRE project, requirements and recommendations for Web caching
- WWW Cache Briefing, Alan J. Flavell
- What is Web caching, why use it, how to start
- A Hierarchival Internet Object Cache, Peter Danzig
- Harvest cache and the basic ideas for cache cooperation
- A Caching Relay for WWW, Steven Glassman
- One of the first papers on Web caching, an introduction to the topic
- Caching Proxies: Limitations and Potentials, Marc Abrams, Charles R. Standridge, Ghaleb Abdulla, Stephen Williams, Edward A. Fox
- Potential of Web caching
- The Harvest Object Cache in New Zealand, Donald Neal
- Includes overview of the Internet Cache Protocol
- UK Advisory Committee on Networking report on Web Caching, Andrew Cormack
- State of the art on Web caching
- Evolution of the NLANR Cache Hierarchy: Global Configuration Challenges, Duane Wessels and k claffy
- Discussion of cache meshes and configuration
- Caching, introduction for libraries, Jon Knight and Martin Hamilton
- Laymans introduction to Web caching
- Woj's links to caching info, the Polish W3CACHE
- Recommended Reading, NLANR
1.4 Requested background
In this document we assume that you have a working knowledge of Web caching and the primary target group is system administrators that are running a Web cache server or planning to start one. Executives are referred to the executive summary.
Examples are provided using the Squid software. Documentation on Squid is available from the Web site and is not included in this document.
Ingrid Melve, Henny Bekker