HTTP The Definitive Guide (Caching)

Caching

• Caches reduce redundant data transfers, saving you money in network charges.
• Caches reduce network bottlenecks. Pages load faster without more bandwidth.
• Caches reduce demand on origin servers. Servers reply faster and avoid overload.
• Caches reduce distance delays, because pages load slower from farther away.

Redundant Data Transfers
Bandwidth Bottlenecks

Flash Crowds

Distance Delays

 

Hits and Misses

     HTTP gives us a few tools to revalidate cached objects, but the most popular is the

If-Modified-Since header. When added to a GET request, this header tells the server
to send the object only if it has been modified since the time the copy was cached.
Here is what happens when a GET If-Modified-Since request arrives at the server in
three circumstances—when the server content is not modified, when the server content
has been changed, and when the object on the server is deleted

Revalidate hit

     If the server object isn’t modified, the server sends the client a small HTTP 304

Not Modified response.

Revalidate miss
    If the server object is different from the cached copy, the server sends the client a
normal HTTP 200 OK response, with the full content.

Object deleted
     If the server object has been deleted, the server sends back a 404 Not Found
response, and the cache deletes its copy.

Hit Rate
    A hit rate of 40% is decent for a modest web cache today

Byte Hit Rate
    The byte hit rate represents the fraction of all bytes transferred that were served from
cache.
    Document hit rate and byte hit rate are both useful gauges of cache performance.
Document hit rate describes how many web transactions are kept off the outgoing
network. Because transactions have a fixed time component that can often be large
(setting up a TCP connection to a server, for example), improving the document hit
rate will optimize for overall latency (delay) reduction. Byte hit rate describes how
many bytes are kept off the Internet. Improving the byte hit rate will optimize for
bandwidth savings.

Distinguishing Hits and Misses
Cache Topologies

Private Caches
Public Proxy Caches

Proxy Cache Hierarchies

Cache Meshes, Content Routing, and Peering

Cache Processing Steps

1. Receiving—Cache reads the arriving request message from the network.
2. Parsing—Cache parses the message, extracting the URL and headers.
3. Lookup—Cache checks if a local copy is available and, if not, fetches a copy (and stores it locally).
4. Freshness check—Cache checks if cached copy is fresh enough and, if not, asks server for any updates.
5. Response creation—Cache makes a response message with the new headers and cached body.
6. Sending—Cache sends the response back to the client over the network.
7. Logging—Optionally, cache creates a log file entry describing the transaction.

Cache Processing Flowchart

Keeping Copies Fresh
Document Expiration
    HTTP lets an origin server attach an “expiration date” to each document, using special
HTTP Cache-Control and Expires headers

Expiration Dates and Ages

    The Expires and Cache-Control: max-age headers do basically the same thing, but the

newer Cache-Control header is preferred, because it uses a relative time instead of an

absolute date. Absolute dates depend on computer clocks being set correctly.

Server Revalidation
 The HTTP protocol requires a correctly behaving cache to return one of the following:
• A cached copy that is “fresh enough”
• A cached copy that has been revalidated with the server to ensure it’s still fresh
• An error message, if the origin server to revalidate with is down*
• A cached copy, with an attached warning that it might be incorrect

Revalidation with Conditional Methods
    HTTP’s conditional methods make revalidation efficient. HTTP allows a cache to
send a “conditional GET” to the origin server, asking the server to send back an
object body only if the document is different from the copy currently in the cache.

Other conditional headers include If-Unmodified-Since (useful for partial document transfers, when you

need to ensure the document is unchanged before you fetch another piece of it), If-Range (to support caching of incomplete documents), and If-Match (useful for concurrency control when dealing with web servers).

If-Modified-Since: <cached last-modified date>

Note that some web servers don’t implement If-Modified-Since as a true date comparison. Instead, they do a string match between the IMS date and the last-modified date.

If-None-Match: Entity Tag Revalidation

Weak and Strong Validators
Some operations cannot be performed using weak validators (such as conditional partial-range fetches), so servers identify validators that are weak with a “W/” prefix:

• ETag: W/"v2.6"
• If-None-Match: W/"v2.6"

When to Use Entity Tags and Last-Modified Dates

• HTTP/1.1 clients must use an entity tag validator if a server sends back an entity tag. If the server sends back only a Last-Modified value, the client can use If-Modified-Since validation. If both an entity tag and a last-modified date are available, the client should use both revalidation schemes, allowing both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
• HTTP/1.1 origin servers should send an entity tag validator unless it is not feasible to generate one, and it may be a weak entity tag instead of a strong entity tag, if there are benefits to weak validators. Also, it’s preferred to also send a last-modified value.
• If an HTTP/1.1 cache or server receives a request with both If-Modified-Since and entity tag conditional headers, it must not return a 304 Not Modified response unless doing so is consistent with all of the conditional header fields in the request.

Controlling Cachability

In decreasing order of priority, the server can:

• Attach a Cache-Control: no-store header to the response.

• Attach a Cache-Control: no-cache header to the response.

• Attach a Cache-Control: must-revalidate header to the response.

• Attach a Cache-Control: max-age header to the response.

• Attach an Expires date header to the response.

• Attach no expiration information, letting the cache determine its own heuristic

expiration date.

No-Cache and No-Store Response Headers

    Cache-Control: no-store

    Cache-Control: no-cache

    Pragma: no-cache

• A response that is marked "no-store" forbids a cache from making a copy of the response. A cache would typically forward a no-store response to the client, and then delete the object, as would a non-caching proxy server.
• A response that is marked "no-cache" can actually be stored in the local cache storage. It just cannot be served from the cache to the client without first revalidating the freshness with the origin server. A better name for this header might be "do-notserve-from-cache-without-revalidation."
• The Pragma: no-cache header is included in HTTP/1.1 for backward compatibility with HTTP/1.0+. HTTP 1.1 applications should use Cache-Control: no-cache, except when dealing with HTTP 1.0 applications, which understand only Pragma: no-cache.

Max-Age Response Headers

The Cache-Control: max-age header indicates the number of seconds since it came from the server for which a document can be considered fresh. There is also an smaxage header (note the absence of a hyphen in “maxage”) that acts like max-age but applies only to shared (public) caches:

• Cache-Control: max-age=3600
• Cache-Control: s-maxage=3600

Servers can request that caches either not cache a document or refresh on every access by setting the maximum aging to zero:

• Cache-Control: max-age=0
• Cache-Control: s-maxage=0

Expires Response Headers
    Some servers also send back an Expires: 0 response header to try to make documents always expire, but this syntax is illegal and can cause problems with some software. You should try to support this construct as input, but shouldn’t generate it.

Must-Revalidate Response Headers
    Cache-Control: must-revalidate

    If the origin server is unavailable when a cache attempts a must-revalidate freshness check, the cache must return a 504 Gateway Timeout error.

Heuristic Expiration

Any algorithm may be used, but if the resulting maximum age is greater than 24 hours, a Heuristic Expiration Warning (Warning 13) header should be added to the response headers. As far as we know, few browsers make this warning information available to users.

LM-Factor algorithm

• If a cached document was last changed in the distant past, it may be a stable document and less likely to change suddenly, so it is safer to keep it in the cache longer.
• If the cached document was modified just recently, it probably changes frequently, so we should cache it only a short while before revalidating with the server.

 
    $time_since_modify = max(0, $server_Date - $server_Last_Modified);
    $server_freshness_limit = int($time_since_modify * $lm_factor);

Client Freshness Constraints

Controlling HTML Caching Through HTTP-EQUIV
<HTML>
<HEAD>
<TITLE>My Document</TITLE>
<META HTTP-EQUIV="Cache-control" CONTENT="no-cache">
</HEAD>
...
    In general, <META HTTP-EQUIV> tags are a poor way of controlling document cachability. The only sure-fire way to communicate cache-control requests for documents is through HTTP headers sent by a properly configured server.

Detailed Algorithms

• Age and Freshness Lifetime
• $is_fresh_enough = ($age < $freshness_lifetime);
• Age Computation
• The age includes the time the response has floated around in the routers and gateways of the Internet, the time stored in intermediate caches, and the time the response has been resident in your cache.  $age = $age_when_document_arrived_at_our_cache + $how_long_copy_has_been_in_our_cache;
• Apparent age is based on the Date header 
• $apparent_age = max(0, $time_got_response - $Date_header_value);
• Hop-by-hop age calculations
• $corrected_apparent_age = max($apparent_age, $Age_header_value);
• Compensating for network delays
• $apparent_age = max(0, $time_got_response - $Date_header_value);
• $corrected_apparent_age = max($apparent_age, $Age_header_value);
• $response_delay_estimate = ($time_got_response - $time_issued_request);
• $age_when_document_arrived_at_our_cache =$corrected_apparent_age + $response_delay_estimate;

Complete Age-Calculation Algorithm

Complete Server-Freshness Algorithm

Caches and Advertising
The Advertiser’s Dilemma
The Publisher’s Response
Today, advertisers use all sorts of “cache-busting” techniques to ensure that caches don’t steal their hit stream. They slap no-cache headers on their content. They serve advertisements through CGI gateways. They rewrite advertisement URLs on each access.

Log Migration

Hit Metering and Usage Limiting