How Web Caches Work: From Hits to Expiration Explained

1. Web Cache

When introducing web cache, we first need a simple understanding of caching.

1.1 Cache Explanation

Caching is usually based on key‑value pairs; the key is derived from a hash and stored in memory, acting as an index, while the value resides in memory or disk.

When a user request reaches the web server, the server hashes the URL and looks up the cache key. If it matches, the corresponding value (a pointer to the data location) is used to retrieve the cached result.

1.2 Working Principle

1.2.1 Cache Hit

① The client request first reaches the cache server, which listens on port 80. ② The cache server forwards the request to an agent process. ③ The process strips application, TCP, and IP headers to obtain the URL. ④ The URL is hashed and compared with cache keys; a match means a cache hit. ⑤ The corresponding data is retrieved from memory or disk. ⑥ A response is built and returned directly to the client.

1.2.2 Cache Miss

① The client request reaches the cache server. ② The request is passed to the agent process. ③ The process extracts the URL. ④ The URL hash does not match any cache key, resulting in a miss. ⑤ The agent acts as an HTTP client and requests the resource from the upstream server. ⑥ The upstream server returns the content, which the cache server stores (both in memory or disk) and then forwards to the client.

1.3 Extension

Browsers also maintain private caches. When a user requests a homepage, the browser may serve cached assets locally without contacting the proxy server, creating a multi‑level caching hierarchy.

2. Cache Invalidation

Caches have a TTL (time‑to‑live). Before TTL expires, the cached object can be used; after expiration, the client must request the resource from the next higher cache layer.

If a cached object is valid for 7 days but the backend updates it on day 2, the stale cache would return outdated data, so proper invalidation is required.

2.1 Cache Types

Absolute‑time caching (used in HTTP 1.0 with precise timestamps)

Conditional caching

Since version 1.1, caching has been extended with:

1. Relative expiration times 2. Fine‑grained cache‑control directives 3. Conditional caching

2.2 Based on Absolute Time

For example, a cache created at 9:00 AM on July 3 2016 with a TTL of 7 days expires at 9:00 AM on July 10 2016. Using absolute timestamps can cause problems across time zones.

2.3 Based on Conditional Caching

Validation based on the last‑modified time

When a client requests the same URL, it may send an If-Modified-Since header. If the server reports no changes (304), the client uses its local cache; otherwise, a 200 response with the new content is returned and the cache is updated.

Another method uses ETag tags:

Tag‑based conditional requests

Each resource gets a unique tag. The client sends If-None-Match with its cached tag; a matching tag yields a 304 response, otherwise a 200 response with the new resource.

3. HTTP Cache Working Modes

3.1 Based on Expiration Time

1. On first request, the cache server has no entry, so it fetches the resource from the backend, stores it with Cache‑Control headers, and returns it to the client.

2. On subsequent requests before expiration, the cache server serves the cached resource directly.

3. After TTL expires, the cache server revalidates with the backend, updates the cache and TTL, and serves the fresh content.

3.2 Based on Conditional Caching

1. On first request, the cache server stores the resource together with Last‑Modified information.

2. On later requests, the client sends If-Modified-Since. If unchanged, the server returns 304 and the client uses the cached copy.

3. If the resource has changed, the server returns 200 with the new data, which the cache updates and forwards to the client.

3.3 Combined HTTP Headers

Combining expiration and conditional validation mitigates each method’s drawbacks. The cache server records both ETag and Cache‑Control information on the first request.

1. Subsequent requests use the cached resource if still fresh.

2. When the cached entry expires, the client sends If-None-Match with the stored ETag. A 304 response updates the TTL; a 200 response provides the new content.

3.4 Multi‑Level Cache

Multi‑level caching follows the same principles across several cache layers, allowing deeper hierarchies to improve hit rates.

4. Summary

4.1 HTTP Validation Methods

1. Cache expiration time 2. Last‑Modified / If‑Modified‑Since (time‑based validation) 3. Etag / If‑None‑Match (tag‑based validation) Note: items 2 and 3 involve response headers (left) and request headers (right).

4.2 Common Cache‑Related Headers

Cache‑Control

Last‑Modified

/

If‑Modified‑Since

Etag

/

If‑None‑Match

Expires

(e.g., Cache‑Control: max-age=, s-maxage)

This article summarizes cache mechanisms, invalidation handling, and HTTP cache working modes, providing a concise reference for developers and operations engineers.