Cache Processing Steps

7.7 Cache Processing Steps

Modern commercial proxy caches are quite complicated. They are built to be very high-performance and to support advanced features of HTTP and other technologies. But, despite some subtle details, the basic workings of a web cache are mostly simple. A basic cache-processing sequence for an HTTP GET message consists of seven steps ( illustrated in Figure 7-11 ):

1.             ReceivingCache reads the arriving request message from the network.

2.             ParsingCache parses the message, extracting the URL and headers.

3.             LookupCache checks if a local copy is available and, if not, fetches a copy (and stores it locally).

4.             Freshness checkCache checks if cached copy is fresh enough and, if not, asks server for any updates.

5.             Response creationCache makes a response message with the new headers and cached body.

6.             SendingCache sends the response back to the client over the network.

7.             LoggingOptionally, cache creates a log file entry describing the transaction.

Figure 7-11. Processing a fresh cache hit

figs/http_0711.gif

7.7.1 Step 1: Receiving

In Step 1, the cache detects activity on a network connection and reads the incoming data. High-performance caches read data simultaneously from multiple incoming connections and begin processing the transaction before the entire message has arrived.

7.7.2 Step 2: Parsing

Next, the cache parses the request message into pieces and places the header parts in easy-to-manipulate data structures. This makes it easier for the caching software to process the header fields and fiddle with them. [10]

[10] The parser also is responsible for normalizing the parts of the header so that unimportant differences, like capitalization or alternate date formats, all are viewed equivalently. Also, because some request messages contain a full absolute URL and other request messages contain a relative URL and Host header, the parser typically hides these details (see Section 2.3.1 ).

7.7.3 Step 3: Lookup

In Step 3, the cache takes the URL and checks for a local copy. The local copy might be stored in memory, on a local disk, or even in another nearby computer. Professional-grade caches use fast algorithms to determine whether an object is available in the local cache. If the document is not available locally, it can be fetched from the origin server or a parent proxy, or return a failure, based on the situation and configuration.

The cached object contains the server response body and the original server response headers, so the correct server headers can be returned during a cache hit. The cached object also includes some metadata , used for bookkeeping how long the object has been sitting in the cache, how many times it was used, etc. [11]

[11] Sophisticated caches also keep a copy of the original client response headers that yielded the server response, for use in HTTP/1.1 content negotiation (see Chapter 17 ).

7.7.4 Step 4: Freshness Check

HTTP lets caches keep copies of server documents for a period of time. During this time, the document is considered "fresh" and the cache can serve the document without contacting the server. But once the cached copy has sat around for too long, past the document's freshness limit , the object is considered "stale," and the cache needs to revalidate with the server to check for any document changes before serving it. Complicating things further are any request headers that a client sends to a cache, which themselves can force the cache to either revalidate or avoid validation altogether.

HTTP has a set of very complicated rules for freshness checking, made worse by the large number of configuration options cache products support and by the need to interoperate with non-HTTP freshness standards. We'll devote most of the rest of this chapter to explaining freshness calculations.

7.7.5 Step 5: Response Creation

Because we want the cached response to look like it came from the origin server, the cache uses the cached server response headers as the starting point for the response headers. These base headers are then modified and augmented by the cache.

The cache is responsible for adapting the headers to match the client. For example, the server may return an HTTP/1.0 response (or even an HTTP/0.9 response), while the client expects an HTTP/1.1 response, in which case the cache must translate the headers accordingly . Caches also insert cache freshness information (Cache-Control, Age, and Expires headers) and often include a Via header to note that a proxy cache served the request.

Note that the cache should not adjust the Date header. The Date header represents the date of the object when it was originally generated at the origin server.

7.7.6 Step 6: Sending

Once the response headers are ready, the cache sends the response back to the client. Like all proxy servers, a proxy cache needs to manage the connection with the client. High-performance caches work hard to send the data efficiently , often avoiding copying the document content between the local storage and the network I/O buffers.

7.7.7 Step 7: Logging

Most caches keep log files and statistics about cache usage. After each cache transaction is complete, the cache updates statistics counting the number of cache hits and misses (and other relevant metrics) and inserts an entry into a log file showing the request type, URL, and what happened .

The most popular cache log formats are the Squid log format and the Netscape extended common log format, but many cache products allow you to create custom log files. We discuss log file formats in detail in Chapter 21 .

7.7.8 Cache Processing Flowchart

Figure 7-12 shows, in simplified form, how a cache processes a request to GET a URL. [12]

[12] The revalidation and fetching of a resource as outlined in Figure 7-12 can be done in one step with a conditional request (see Section 7.8.4 ).

Figure 7-12. Cache GET request flowchart

figs/http_0712.gif

 



HTTP. The Definitive Guide
HTTP: The Definitive Guide
ISBN: 1565925092
EAN: 2147483647
Year: 2001
Pages: 294

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net