Web caching

A Web cache is an HTTP device that automatically saves copies of common documents. When the Web request arrives in the cache, if there is a cached copy locally, the document can be extracted from the local storage device instead of the original server.

1. Why cache

  • Redundant data transmission

When many clients visit a popular raw server page, the server will transfer the same document multiple times, each time to one client, and some of the same bytes will be sent over and over again across the network. These redundant data transfers can eat up expensive network bandwidth. By caching, we can keep a copy of the response from the first server, and subsequent requests can be handled by cached copies

  • The bandwidth bottleneck

Caching can also alleviate network bottlenecks. Many networks provide more bandwidth for local network clients than for remote servers. The client accesses the server at the slowest network speed on the path. If the client gets a copy from a cache on a fast LAN, the cache can improve performance — especially if large files are to be transferred

  • The instant congestion

Caching is very important when the loop is broken and congested. Sudden events (such as breaking news, mass E-mail announcements, or a celebrity event) are when many people access a Web document at about the same time, causing instant congestion. The resulting excessive traffic spikes can cause catastrophic crashes to the network and web servers

  • From the time delay

Even if bandwidth is not a problem, distance may be called a problem. Each network router adds to the delay of Internet traffic, and even if there are not many routers between clients and servers, the speed of light itself adds to the delay. Putting the cache in a nearby machine room can cut the distance a file travels from thousands of miles to tens of meters

2. Cache hits and misses

But the cache can’t hold a copy of every document in the world, so there are two cases:

  • Some requests that reach the cache can be serviced with an existing copy, which is called a cache hit

  • Other requests that reach the cache may be forwarded to the original server because no copy is available, which is called a cache miss

3. Freshness testing rules

HTTP keeps a copy of a server document for a period of time through caching. During this time, the document is considered fresh and the cache can serve it up without contacting the server. We call this a strong cache hit, and the browser returns a 200 status code.

However, if the cached copy stays too long and exceeds the document’s freshness limit, the document is considered expired.

Before serving the document again, the cache is re-validated with the server to see if the document has changed. We call this negotiated caching

  • On validation hit: If the server object has Not been modified, the server sends a small HTTP 304 Not Modeified response to the client

  • Revalidation missed: If the server object is different from the cached copy, the server sends a plain HTTP 200 OK response to the client 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 removes its copy

4. Strong cache principle

HTTP lets the original server append an expiration date to each document through special HttpCache-Control and Expries headers that specify how long the content can be considered fresh.

Browser for the second time send requests to the same resource, the expiration time and compares the current time, if prior to the expiration date, the cache hit, expired, if the cache file cache must check with the server, asked whether the document is overdue, if have been modified, to obtain a copy of the fresh (with a new expiration date)

4.1 Strong cache header
  • Cache-Control: max-age:

The max-age value defines the maximum lifetime of the document — the maximum legal lifetime (in seconds) from the time the document is first generated until it is no longer fresh and unusable

  • Expires:

Specify an absolute expiration date. If the expiration date has passed, the document is no longer fresh, but since we can change the client’s time, we can change the cache hit result. Therefore, cache-control is preferred

The cache-control directives:

  • no-cacheandno-store:

No-cache indicates that the response returned must be checked with the server to see if it has changed before the response can be used to satisfy subsequent requests for agreed urls. So if a suitable validation token (ETag) exists,no-cache initiates a round-trip communication to validate the cached response, but if the resource has not changed, the download can be avoided

No-store means that the browser and all intermediate caches are directly prohibited from storing any version of the returned response, for example, a response containing personal privacy data or banking data. Each time a user requests the asset, the request is sent to the server and the complete response is downloaded

  • publicwithprivate:

If public appears before the response header, the response can be cached even if it has HTTP validation associated with it, and even if the response status code code is not normally cached. In most cases,public is not necessary because explicit cache information (such as max-age) already indicates that the response is cacheable

By contrast, browsers can cache private responses. However, these responses are usually only cached for a single user, so they are not allowed to be cached by any intermediate caches. For example, the user’s browser can cache HTML web pages containing the user’s private information, but the CDN cannot cache them

  • max-age:

The directive specifies the maximum amount of time from the time of the request that the retrieved response is allowed to be reused. For example, max-age=60 indicates that the response can be cached and reused for the next 60 seconds

  • must-revalidate:

Must-revalidate tells the cache that it cannot provide stale copies of the object without first revalidating them with the original server, and that the cache can still provide fresh copies at will. If the original server is unavailable during the cache’s must-revalidate freshness check, the cache must return a 504 error

Optimal cache-control policy:

5. Negotiation cache principle

Just because the cache is out of date doesn’t mean it’s actually different from the document that is currently active on the original server, it just means it’s time to check, which is called negotiated caching, meaning that the cache needs to ask the original server if anything has changed

  • If the revalidation display changes, the cache takes a new copy of the document, stores it in place of the old document, and sends the document to the client.

  • If the revalidation has not changed, the cache simply gets a new header, including a new expiration date, updates the header in the cache, and updates the header in the cache

5.1 Re-verification by conditional method

HTTP’s conditional approach is efficient for revalidation. HTTP allows the cache to send a conditional GET to the original server. The requesting server will only send back the object body if the document is different from the existing copy in the cache, the two headers most useful for caching validation

  • If-Modified-Since: <date>:

If the document has been modified since the specified date, the requested method is executed. Can be used with last-modfied server response headers and only fetch content if it has been modified to be different from the cached version

  • If-None-Match:<tags>:

Instead of matching documents with the most recently modified date, the server can provide special tags (ETags) that act like serial numbers. If the cached label is different from the one in the server document, the if-none-match header executes the requested method

If – Modified – Since: 5.2 / last-modified

The specific process is as follows:

  1. The first time a client makes a request to the server, the server appends a last-modified date to the supplied document

  2. When the resource time is requested again and the strong cache is not hit, the validation is performed with an if-modifed-since header with the date the cached copy was last Modified: if-modified-since:

  3. If the content has been modified, the server sends back the new document, returning the 200 status code and the last modification date

  4. If the content has Not been Modified, a 304 Not Modified response is returned

5.3 the If – None – Match/ETag

In some cases revalidation using the last modified date alone is not sufficient

  • Some documents may be periodically rewritten (for example, from a background process), but often contain the same amount of data, although the content does not change, but the modification date may change

  • Some documents may have been modified, but the changes are not significant. You don’t need to reload all of the caches around the world (like filling in comments)

  • Some servers cannot accurately determine the last modification date of their pages

  • One-second change dates may not be sufficient for servers that provide documents that change in milliseconds (for example, live monitors)

HTTP therefore allows users to compare version identifiers called entity tags (ETags). Entity tags are arbitrary tags (referencing strings) attached to documents, and the random tokens that the server generates and returns are usually hash values or other fingerprints of file contents. The client doesn’t need to know how the fingerprint was generated, just send it to the server on the next request. If the fingerprints are still the same, the resource hasn’t changed and you can skip the download.

In the above example, the client automatically provides the ETag token in the “if-none-match” HTTP request header. The server verifies the token against the current resource. If it has Not changed, the server returns a 304 Not Modified response telling the browser that the response in the cache has Not changed and can be extended for another 120 seconds. Note that you don’t have to download the response again, which saves time and bandwidth.

Update and discard responses

All HTTP requests made by the browser are first routed to the browser cache to verify that a valid response can be cached for the request. If there is a matching response, the response is read from the cache, thus avoiding network latency and traffic charges associated with transmission

But what if we respond to an update or deprecate cache, for example we have a CSS stylesheet cache that is 24 hours old, but we need to update it immediately, how do we notify all visitors of an outdated copy of the CSS cache to update its cache? You can’t do this without changing the url of the resource.

So, to achieve client-side caching and fast updates, you can change the url of a resource whenever its content changes, forcing users to download a new response. Typically, this can be done by embedding the fingerprint or version number of the file in the file name

  • HTML is marked no-cache, which means that the browser always revalidates the document every time it is requested and gets the latest version when the content changes. In addition, fingerprints are embedded in HTML tags, CSS and javascript, and if the contents of these files change, the HTML of the page will also change, and a new copy of the HTML response will be downloaded

  • Allow browsers and intermediate caches (such as CDN) to cache the CSS, and set the CSS to expire after 1 year. Because the fingerprint of the file is embedded in the file name, the URL will change when the CSS is updated

  • JavaScript is also set to expire after 1 year, but marked private, perhaps because it contains some personal user data that the CDN should not cache.

  • Images are cached without versions or unique fingerprints and set to expire after a day

The resources

  • HTTP cache

  • Browser cache knowledge summary and application

  • HTTP explosion focus – caching