Caches & content delivery

Its job in the system

Caching reduces repeated work. A browser can reuse eligible responses locally, while shared services can serve cached content to many users. A content delivery network often combines distributed serving locations with caching and other functions. The result can be a shorter network trip and less load on an origin service.

How it works

HTTP defines rules for deciding whether a stored response is reusable and whether it is still fresh. A cache may need to validate a response with the server before reusing it. Different directives govern different cases, so “saved somewhere” does not mean “safe to reuse for everyone forever”. Personalised and shared content need appropriate handling.

A cache hit means a suitable stored response can be used. A miss means the requested response is unavailable or unsuitable in that cache, so it must be obtained elsewhere. The first visit and a later visit can consequently follow different paths. A small amount of validation traffic may also occur even when a full response body is not downloaded again.

What it connects to

Caching connects HTTP semantics with network geography and browser behaviour. A closer serving point may reduce round-trip delay, but actual experience also depends on congestion, processing, resource size, and the device. DNS and routing can help direct clients towards a serving location, using arrangements that vary by provider.

Different places, different designs

Not every response is cached, and not every cache is a content delivery network. Browsers, proxies, application systems, and provider infrastructure can store different things. DNS also has caching, but it stores naming information under different rules from HTTP response caches. The shared idea is controlled reuse, not one universal mechanism.