HTTP 캐싱 소개

This article is a light introduction to how HTTP servers and clients cache data to improve performance. Taking advantage of this lets clients perform well despite network overhead. This was all information I got to learn while implementing my own open source thumbnail server, Thumbrella.

HTTP caching is opt-in behavior for servers and clients, so even partial implementations can start seeing immediate benefits. The full caching specification gets fairly extensive, growing in complexity once proxies and failures are involved. Here are a couple resources describing the full details:

• MDN: HTTP Caching Guide, conceptual overview and diagrams of the flow
• RFC 9111, the actual spec for all the details and edge-case behaviors

Concepts

There are two concepts for caching HTTP requests. Most cachable content will have an expiration. Before expiring the contents are considered fresh, and can be reused immediately, with no additional checks.

After the cached content is expired it is no longer considered fresh. A followup request should be validated by the server. This allows the server to avoid transferring identical information when the client and server agree the existing cached contents are up to date.

HTTP Headers

Cache management is handled by various HTTP headers in each request and response. The initial response will return any combination of these. The client will return some of these back to the server, and follow the reported guidelines for the others.

Initial Response Header Followup Request Header Information Cache-Control 8 different directives (comma separated) that control caching behavior. ETag If-None-Match Server validates if cache data is current by returning status 304 Not Modified. Last-Modified If-Modified-Since Vary A list of request header names that modify the content, like `Accepts`. Expires A superseded way to define max-age, now defined by the Cache-Control.

One extra note on headers. Requests that provide an Authorization header are generally not expected to be cached. Or when cached, privately stored for whatever credentials were provided.

ETag and Last-Modified

Let’s start with the two conditional validation headers, since they are conceptually simplest.

These are two values the server can provide with any response. The ETag header represents an arbitrary hashing or opaque value generated by the server. The Last-Modified can be an HTTP-date timestamp representing when the content was last updated. Neither of these values needs to be based on the returned body. Servers generating dynamic content will generate these values based on the inputs.

When making a followup request the client can return these same values in different headers named If-None-Match (for the ETag value) and If-Modified-Since (for the Last-Modified value). When provided the server is allowed to return an empty response with the status 304 Not Modified. This allows the client to know its existing cached value for this request is still up to date, without transferring the content a second time.

Cache-Control

This header defines a combination of 8 different directives, separated by commas. These can be loosely organized into two categories.

Freshness

• max-age=<seconds> This is the most common directive for controlling client side freshness. This tells a browser it can reuse the contents within the given number of seconds. This is the only directive that has a value. There is also a s-maxage alternative that is ignored by browsers.
• immutable Means the contents are never expected to change. The cached results will can be reused for as long as the client wants to store them.
• no-cache The contents are cached, but never considered fresh. The client should always followup with one of the if headers to validate the contents are still valid. This is a slightly misleading name, but is defined to mean “never fresh”.

Behavior

• no-store Disable all caching. Used for sensitive responses like tokens and personal data.
• public Response can be stored in shared caches, even when Authorization headers are provided.
• private Only the end-user’s browser cache should store this, not proxies or intermediate results.
• must-revalidate This is a stricter no-cache that also means the cached values should not be used if the server cannot be reached to revalidate its contents.

Thumbrella

All this was crucial to learn and implement for my online thumbnailing server, Thumbrella. This implements intelligent caching is for all media requests, and a critical part of generating fast and interactive results.

Much of this had to be encapsulated for thumbnail clients because the API is built around handling bulk batch requests, returning multiple thumbnail results in a single request. (Some results potentially cached and some not cached). Thumbrella cleverly simplifies all this, although unnecessary to learn if using any of the high level client libraries through Javascript, Python, or Rust.

Self hosting Thumbrella is an easy way to provide thumbnails for your own media libraries, supporting over 100 formats.