HTTP缓存的深入介绍：Cache-Control和Vary

简介-本文范围 (Introduction - scope of the article)

This series of articles deals with caching in the context of HTTP. When properly done, caching can increase the performance of your application by an order of magnitude. On the contrary, when overlooked or completely ignored, it can lead to some very unwanted side effects caused by misbehaving proxy servers that, in the absence of clear caching instructions, decide to cache anyway and serve stale resources.

本系列文章讨论了HTTP上下文中的缓存。 正确完成后，缓存可以将应用程序的性能提高一个数量级。 相反，如果忽略或完全忽略它，则可能导致代理服务器行为异常，从而导致某些非常有害的副作用，这些代理服务器在没有明确的缓存指令的情况下仍决定缓存并提供过时的资源。

In the first part of this series, we argued that caching is the most effective way to increase performance, when measured by the page load time. In this second part, it is time to shift our focus to the mechanisms at our disposal. To put it in another way: how does HTTP caching actually work?

在本系列的第一部分中，我们认为，以页面加载时间衡量，缓存是提高性能的最有效方法。 在第二部分中，是时候将我们的重点转移到我们掌握的机制上了。 换句话说：HTTP缓存实际上如何工作？

To answer this question, we decided to consider the case of an empty cache that starts progressively caching and serving resources. As it gradually receives incoming HTTP requests, our cache will start behaving accordingly. Serving the resource from the cache when a fresh copy is available, varying over multiple representations, making a conditional request... This way, we can introduce each concept progressively as we need it.

为了回答这个问题，我们决定考虑空缓存的情况，该缓存开始逐渐缓存和提供资源。 随着它逐渐接收传入的HTTP请求，我们的缓存将相应地开始工作。 当有可用的新副本时，从缓存中提供资源，以多种表示形式变化，发出条件请求...这样，我们可以根据需要逐步引入每个概念。

At first, our empty cache will have no choice but to forward requests to the origin server. This will allow us to understand how origin servers instruct our cache on what to do with the resource, such as if it is allowed to store it, and for how long. For this, we will examine each Cache-Control directive and clarify some of them that have been known to have conflicting meanings.

首先，我们的空缓存除了将请求转发到原始服务器外别无选择。 这将使我们了解原始服务器如何指示缓存如何处理资源，例如是否允许存储资源以及存储时间。 为此，我们将检查每个Cache-Control指令，并弄清其中一些已知的含义有冲突 。

Second, we will look at what happens when our cache receives a request for a resource it already knows. How does our cache decide if it can re-use a previously stored response? How does it map a given HTTP request to a particular resource? To answer these, we will learn about representation variations with the Vary header.

其次，我们将看看当缓存接收到对它已经知道的资源的请求时会发生什么。 我们的缓存如何决定是否可以重用先前存储的响应？ 如何将给定的HTTP请求映射到特定资源？ 为了回答这些问题，我们将了解Vary标头的表示形式变化。

This article is going to focus on knowledge that’s the most valuable from a web developer’s perspective. Therefore, conditional requests are only discussed briefly and will be the focus of another article.

从Web开发人员的角度出发，本文将重点介绍最有价值的知识。 因此，仅简要讨论条件请求，这将是另一篇文章的重点。

Without further ado, let us start with an overview of what we will be exploring.

事不宜迟，让我们首先概述我们将要探索的内容。

HTTP缓存决策树 (The HTTP caching decision tree)

Conceptually, a cache system always involve at least three participants. With HTTP, these participants are the client, the server, and the caching proxy.

从概念上讲，高速缓存系统始终包含至少三个参与者。 使用HTTP，这些参与者是客户端，服务器和缓存代理。

However, when learning about HTTP caching, we strongly encourage you not to think of the client as your typical web browser because these days, they all ship with their own HTTP caching layer. It makes it difficult to clearly separate the browser from the cache. For this reason, we invite you to think of the client as a headless command line program such as cURL or any application without an embedded HTTP cache.

但是，在学习HTTP缓存时，我们强烈建议您不要将客户端视为典型的Web浏览器，因为如今，它们都带有自己的HTTP缓存层。 这使得很难将浏览器与缓存区分开来。 因此，我们邀请您将客户端视为无头命令行程序，例如cURL或任何没有嵌入式HTTP缓存的应用程序。

All precautions aside, let us now deep dive into the subject by taking a look at the following picture: the HTTP caching decision tree.

除了所有预防措施，现在让我们通过查看以下图片深入探讨该主题：HTTP缓存决策树。

This picture illustrates all the possible paths a request can take every time a client asks for a resource to an origin server behind a caching system. A careful examination of this illustration reveals that there are only four possible outcomes.

此图说明了每次客户端向缓存系统后面的原始服务器请求资源时，请求可以采用的所有可能路径。 仔细检查该图可以发现只有四个可能的结果。

Clearly separating these outcomes in our minds is actually very convenient, seeing as each important caching concept (cache instructions, representation matching, conditional requests and resource aging) maps to each one of them.

在我们的脑海中清楚地区分这些结果实际上非常方便，因为每个重要的缓存概念(缓存指令，表示匹配，条件请求和资源老化)都映射到它们中的每一个。

Let us describe succinctly each one by introducing two important terms relating to the HTTP caching terminology: cache hits and cache misses.

让我们通过介绍与HTTP缓存术语有关的两个重要术语来简要地描述每个：缓存命中和缓存未命中。

命中率 (Hits and misses)

The first possible outcome is when the cache finds a matching resource, and is allowed to serve it, which, in the caching world, are indeed two distinct things. This outcome is what we commonly call a cache hit, and is the reason why we use caches in the first place.

第一个可能的结果是，当高速缓存找到匹配的资源并被允许为其提供服务时，在缓存世界中，这确实是两个截然不同的事情。 这个结果就是我们通常所说的缓存命中，也是我们首先使用缓存的原因。

When a cache hit happens, it completely offloads the origin server and the latency is dramatically reduced. In fact, when the cache hit happens in the browser’s HTTP cache latency is null and the requested resource is instantly available.

当发生缓存命中时，它将完全减轻原始服务器的负担，并大大减少了延迟。 实际上，当缓存命中发生在浏览器的HTTP缓存中时，等待时间为null，并且所请求的资源立即可用。

Unfortunately, cache hits account only one of the four possible outcomes. The rest of them fall into the second category, also known as cache misses, which can happen for only three reasons.

不幸的是，缓存命中仅占四个可能结果之一。 它们的其余部分属于第二类，也称为缓存未命中，仅出于三个原因才可能发生。

The first reason a cache miss typically happens is simply when the cache does not find any matching resource in its storage. This is usually a sign that the resource has never been requested before, or has been evicted from the cache to free up some space. In such cases, the proxy has no choice but to forward the request to the origin server, fully download the response and look for caching instructions in the response headers.

高速缓存未命中通常发生的第一个原因仅仅是当高速缓存在其存储中找不到任何匹配的资源时。 这通常表明该资源以前从未被请求过，或者已从高速缓存中逐出以释放一些空间。 在这种情况下，代理别无选择，只能将请求转发到原始服务器，完全下载响应并在响应头中查找缓存指令。

The second reason a cache miss can happen is actually just as detrimental, where the cache detects a matching representation, one that it could potentially use. However, the resource is not considered to be fresh anymore - we will see how exactly in the cache-control section of this article - but is said to be stale.

高速缓存未命中可能发生的第二个原因实际上同样有害，因为高速缓存检测到匹配表示，它可能会使用该表示。 但是，该资源不再被认为是新鲜的 -我们将在本文的缓存控制部分中看到它的精确程度-但据说已经过时了。

In such case, the cache sends a special kind of request, called a conditional request to the origin server. Conditional requests allow caches to retrieve resources only if they are different from the one they have in their local storage. Since only the origin server ever has the most recent representation of a given resource, conditional requests always have to go through the whole caching proxy chain up to the origin server.

在这种情况下，缓存将一种特殊的请求(称为条件请求)发送到原始服务器。 条件请求仅允许高速缓存与本地存储中的资源不同时才检索资源。 由于只有原始服务器具有给定资源的最新表示，因此条件请求始终必须经过整个缓存代理链，直到原始服务器。

These special requests have only two possible outcomes. If the resource has not changed, the cache is instructed to use its local copy by receiving a 304 Not Modified response along with updated headers and an empty body. This outcome, the third one on our list, is called a successful validation.

这些特殊要求只有两个可能的结果。 如果资源未更改，则通过接收304 Not Modified响应以及更新的头和空主体来指示缓存使用其本地副本。 此结果是我们列表中的第三个结果，称为成功验证。

Finally, the last possible outcome is when the resource has changed. In th