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 webcaching meshes. This document gives guidelines and outlines strategies for building a functional webcaching system with co-operating web caches.
The architecture of a webcaching mesh is highly depending 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 webcaching is discussed and examples of policies for international webcaching agreements are given. The impact of webcaching as a routing issue is discussed.
First several basic requirements for hardware used on web caching servers, giving general advice and pointers to several hardware suppliers.
Second we will look into several criteria for chosing 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. The main part of the paper is focused on how to build and join a ISP-wide webcaching mesh, providing examples and listing alternative approaches to the architecture of a mesh.
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 next definitions are used in the HTTP/1.1 specification [HTTP/1.1] :
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.
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 ordisk 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 gives a nonhierarchical arrangement of large national and international caching proxies.
Web caching servers may co-operate in a mesh where they share load and distribute requests. A webcaching server in a mesh may pass a unfulfilled request on to another webcaching 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.
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 grow 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 will grow also 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.
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. We will avoid using the word "correct" and use the specific term "semantic transparency". A cache is "semantically transparent" to indicate if a Web client cannot tell that it exists, except for the speed at which documents are delivered [Mogul].
Caching, introduction for libraries Jon Knight and Martin Hamilton
Quick Introduction to WWW Caching, Martin Hamilton