簡介-本文范圍 (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 this case, the origin server sends a normal 200 OK response, as it would if the cache was empty and had forwarded the request. To put it another way, cache misses caused by empty cache and failed validation yield exactly the same HTTP response.

最后，最后可能的結果是資源更改時。 在這種情況下，原始服務器將發送正常的200 OK響應，就像緩存為空并轉發了請求一樣。 換句話說，由空緩存和驗證失敗導致的緩存未命中會產生完全相同的HTTP響應。

To best visualize these four paths, it is helpful to picture them in a timeline, as illustrated below.

為了最好地可視化這四個路徑，在時間線上顯示它們很有幫助，如下所示。

At first, the cache is empty. The flow of requests starts with a cache miss (empty cache outcome). On its way back, the cache would read caching instructions and store the response. All subsequent requests for this particular resource would yield to cache hits, until the resource becomes stale and needs to be revalidated.

首先，緩存為空。 請求流以緩存未命中(空緩存結果)開始。 在返回的過程中，緩存將讀取緩存指令并存儲響應。 對該資源的所有后續請求都將產生緩存命中，直到該資源變得陳舊并需要重新驗證為止。

Upon a first revalidation, it is possible that the resource has not changed, hence, a 304 Not Modified would be sent.

首次重新驗證后，資源可能沒有更改，因此將發送304未修改。

Then, the resource eventually gets updated by a client, typically with a PUT or a PATCH request. When the next conditional request arrives, the origin server detects that the resource has changed and replies a 200 OK with updated ETag and Last-Modified headers.

然后，客戶端最終通常使用PUT或PATCH請求來更新資源。 當下一個條件請求到達時，原始服務器檢測到資源已更改，并使用更新的ETag和Last-Modified標頭答復200 OK。

Knowing about cache hits and cache misses along with the 4 possible paths that every cacheable request could take, should give you a good overview of how caching works.

了解緩存命中和緩存未命中以及每個可緩存請求可能采用的4條可能的路徑后，應該可以很好地了解緩存的工作方式。

Though overviews can only get you so far. In the following section, we will give a detailed explanation of how origin servers communicate caching instructions.

盡管概述僅能帶您到此為止。 在以下部分中，我們將詳細說明原始服務器如何通信緩存指令。

原始服務器如何通信緩存指令 (How origin servers communicate caching instructions)

Origin servers communicate their caching instructions to downstream caching proxies by adding a Cache-Control header to their response. This header is an HTTP/1.1 addition and replaces the deprecated Pragma header, that was never a standard one. Cache-control header values are called directives. The specification defines a lot of them, with various uses and browser-support. These directives are primarily used by developers to communicate caching instructions. However, when present in an HTTP request, clients can also influence the caching decision. Let us now take the time to describe the most useful directives.

原始服務器通過向其響應添加Cache-Control標頭，將其緩存指令傳達給下游緩存代理。 此標頭是對HTTP / 1.1的添加，它取代了不推薦使用的Pragma標頭，該標頭從來都不是標準標頭。 緩存控制標頭值稱為指令。 規范定義了很多，具有各種用途和瀏覽器支持 。 這些指令主要由開發人員用來傳達緩存指令。 但是，當存在于HTTP請求中時，客戶端也會影響緩存決策。 現在讓我們花時間描述最有用的指令。

最大年齡 (max-age)

The first important Cache-Control directive to know about is the max-age directive, which allows a server to specify the lifetime of a representation. It is expressed in seconds. For instance, if a cache sees a response containing the header Cache-Control: max-age=3600, it is allowed to store and serve the same response for all subsequent requests for this resource for the next 3600 seconds. During these 3600 seconds, the resource will be considered fresh and cache hits will occur. Past this delay, the resource will become stale and validation will take over.

要了解的第一個重要的Cache-Control指令是max-age指令，它允許服務器指定表示的生存期。 以秒為單位。 例如，如果緩存看到包含標頭Cache-Control：max-age = 3600的響應，則在接下來的3600秒內，它可以為該資源的所有后續請求存儲并提供相同的響應。 在這3600秒內，該資源將被認為是最新資源，并且將發生緩存命中。 超過此延遲，資源將過時，驗證將接管。

無存儲，無緩存，必須重新驗證 (no-store, no-cache, must-revalidate)

Unlike max-age, the no-store, no-cache and must-revalidate directives are about instructing caches to not cache a resource. However, they differ in subtle ways. no-store is pretty self-explanatory, and in fact, it does even a little more than the name suggests. When present, a HTTP/1.1 compliant cache must not attempt to store anything, and must also take actions to delete any copy it might have, either in memory, or stored on disk.The no-cache directive, on the other hand, is arguably much less self-explanatory. This directive actually means to never use a local copy without first validating with the origin server. By doing so, it prevents all possibility of a cache hit, even with fresh resources.To put it another way, the no-cache directive says that caches must revalidate their representations with the origin server. But then comes another directive, awkwardly named… must-revalidate.If this starts to get confusing for you, rest assured, you are not alone. If what one wants is not to cache, it has to use no-store instead of no-cache. And if what one wants is to always revalidate, it has to use no-cache instead of must-revalidate. Confusing, indeed. As for the must-revalidate directive, it is used to forbid a cache to serve a stale resource. If a resource is fresh, must-revalidate perfectly allows a cache to serve it without forcing any revalidation, unlike with no-store and no-cache. That’s why this header should always be used with a max-age directive, to indicate a desire to cache a resource for some time and when it’s become stale, enforce a revalidation. When it comes to these last three directives, we find the choice of words to describe each of them particularly confusing: no-store and no-cache are expressed negatively whereas must-revalidate is expressed positively. Their differences would probably be more obvious if they were to be expressed in the same fashion. Therefore, it is helpful to think about each of them expressed in terms of what is not allowed:

與max-age不同，no-store，no-cache和must-revalidate指令與指示緩存不緩存資源有關。 但是，它們在微妙的方式上有所不同。 No-store是非常不言自明的，實際上，它甚至比名稱所暗示的還要多。 如果存在，則符合HTTP / 1.1的高速緩存不得嘗試存儲任何內容，并且還必須采取措施刪除其可能具有的任何副本(無論是在內存中還是存儲在磁盤上)。可以說不那么自省了。 該指令實際上意味著在未先與原始服務器進行驗證的情況下，切勿使用本地副本。 這樣，它可以防止所有可能發生的高速緩存命中，即使是使用新鮮資源也可以。換句話說，no-cache指令表示高速緩存必須使用源服務器重新驗證其表示。 但是隨后出現了另一個指令，笨拙地命名為…必須重新驗證。如果這開始讓您感到困惑，請放心，您并不孤單。 如果要不要緩存，則必須使用無存儲而不是無緩存。 而且，如果要始終重新驗證，則必須使用無緩存而不是必須重新驗證。 確實令人困惑。 至于must-revalidate指令，它用于禁止緩存提供過時的資源。 如果資源是新鮮的，則與無存儲和無緩存不同，必須重新驗證完全允許緩存提供服務而無需強制進行任何重新驗證。 這就是為什么此標頭應始終與max-age指令一起使用的原因，以表示希望在一段時間內緩存資源，并且在資源過時時，請強制進行重新驗證。 當涉及到最后三個指令時，我們發現描述每個指令的單詞選擇特別令人困惑：否定和否定緩存表示為否定，而必須重新驗證則表示肯定。 如果以相同的方式表達它們的差異可能會更加明顯。 因此，考慮用不允許的方式來表達它們是有益的：

• no-store: never store anything

  無商店：從不存儲任何東西

• no-cache: never cache hit

  無緩存：永不緩存命中

• must-revalidate: never serve stale

  必須重新驗證：永不陳舊

Technically, these directives can appear in the same Cache-Control header. It is not uncommon to see them combined as a comma-separated list of values. A lot of popular websites still seem to behave very conservatively, sending back HTML pages with the following header:

從技術上講，這些指令可以出現在相同的Cache-Control標頭中。 將它們組合為逗號分隔的值列表并不罕見。 許多受歡迎的網站似乎仍然非常保守，將帶有以下標頭HTML頁面發送回：

Cache-Control: no-cache, no-store, max-age=0, must-revalidateWhen you stumble upon this, the intention behind it is usually pretty clear: the web development team wants to ensure that the resource never gets served stale to anyone. However, such cache-buster lines are probably not necessary anymore. Past work done in 2017 already showed that browsers are really rather compliant with the specification in respect to Cache-Control response directives. Therefore, unless you’re planning on setting up a caching stack with decades old software, you should be fine using just the directives you need. The most popular combinations will be analyzed in another article.

緩存控制：無緩存，無存儲，max-age = 0，必須重新驗證當您偶然發現時，其背后的意圖通常非常清楚：Web開發團隊希望確保資源永遠不會過時地提供給任何人。 但是，這樣的緩存破壞線可能不再需要了。 2017年完成的工作已經表明，瀏覽器在緩存控制響應指令方面確實相當符合規范。 因此，除非打算使用數十年的軟件來建立緩存堆棧，否則只使用所需的指令就可以了。 最受歡迎的組合將在另一篇文章中進行分析。

公共，私人 (public, private)

The last important directives we haven’t discussed yet are a little bit different, as they control which types of caches are allowed to cache the resources. These are the public and private directives, private being the default one if unspecified.

我們尚未討論的最后一個重要指令有些不同，因為它們控制允許哪些類型的緩存來緩存資源。 這些是public和private指令，如果未指定，則private是默認指令。

Private caches are the ones that are supposed to be used by a single user. Typically, this is the web browser’s cache. CDN and reverse-proxies on the contrary, handle requests coming from multiple users.

專用緩存是應該由單個用戶使用的緩存。 通常，這是Web瀏覽器的緩存。 相反，CDN和反向代理處理來自多個用戶的請求。

Why do we need to distinguish these two types of caches ? The answer is straightforward: security, as illustrated by the following example.

為什么我們需要區分這兩種類型的緩存？ 答案很簡單：安全性，如以下示例所示。

Many web applications expose convenience endpoints that rely on information coming from elsewhere than the URL. If two users access their profile by requesting /users/me, at ?https://api.example/com, and their actual user id is hidden within a Authorization: Bearer 4Ja23?42…. ? token, the cache won’t be able to tell these are in fact two very different resources.

許多Web應用程序公開了便捷端點，這些端點依賴于URL之外的其他信息。 如果兩個用戶通過在https：//api.example/com上請求/ users / me來訪問其個人資料，并且其實際用戶ID隱藏在Authorization：Bearer4Ja23?42…中。 令牌，緩存將無法分辨出它們實際上是兩個截然不同的資源。

Indeed, when constructing their cache key, caches do not inspect HTTP headers unless specifically instructed to do so, as we shall see in the next section.

確實，在構造其緩存鍵時，除非特別指示，否則緩存不會檢查HTTP標頭，這將在下一部分中看到。

最大s (s-maxage)

The s-maxage directive is like the max-age directive, except that it only applies to public caches, which are also referred to as shared caches (hence the s- prefix). If both directives are present, s-maxage will take precedence over max-age on public caches and be ignored on private ones.

s-maxage偽指令與max-age偽指令類似，不同之處在于它僅適用于公共緩存，也稱為共享緩存(因此為s-前綴)。 如果同時存在這兩個指令，則在公共緩存中s-maxage將優先于max-age，而在專用緩存中將被忽略。

When using this directive, the general rule is to always ensure that s-maxage value is below max-age’s. The reasoning behind this rule is that the closer you are to the origin, the more suitable it is to check frequently what the latest representation is.

使用此指令時，一般規則是始終確保s-maxage值低于max-age的值。 該規則背后的原因是，您離原點越近，經常檢查最新的表示形式越合適。

Imagine you were to cache for one day in the proxy, and one hour in browsers.

假設您要在代理中緩存一天，在瀏覽器中緩存一個小時。

Every time a browser would ask a resource to upstream servers, we could know in advance that the proxy will not contact the origin server for at least a day. Therefore, why not put the same TTL directly in the browsers ? As a conclusion, it is a best practice to always leave out a longer TTL in max-age than in s-maxage.

每次瀏覽器會問一個資源上游的服務器，我們可以事先知道代理不會接觸至少一天的原始服務器。 因此，為什么不將相同的TTL直接放在瀏覽器中？ 結論是，最佳做法是始終在max-age中保留比s-maxage中更長的TTL。

stale-while-revalidate and stale-if-errorThese two directives are not technically part of the original specification but are part of an extension which were first described more than 10 years ago. Although their browser support is limited, some popular CDNs have been supported them for more than 5 years!

stale-while-revalidate和stale-if-error這兩個指令從技術上講不是原始規范的一部分，而是擴展的一部分，它們在10多年前就已首次描述。 盡管它們對瀏覽器的支持是有限的， 但已經為它們提供了一些流行的CDN超過5年了！

Though stale-while-revalidate is pretty useful. As the name implies, it allows a cache to “[...] immediately return a stale response while it revalidates it in the background, thereby hiding latency (both in the network and on the server) from clients”.

盡管過時的重新驗證非常有用。 顧名思義，它允許緩存“在后臺重新驗證過時的響應后立即返回陳舊的響應，從而對客戶端隱藏了網絡和服務器上的延遲”。

This caching extension proves really helpful for things like images, where reducing latency is critical for the user experience, and where having a stale version for a few seconds is often better than a painfully downloading image.

事實證明，這種緩存擴展確實對諸如圖像之類的東西很有幫助，其中減少延遲對于用戶體驗至關重要，而擁有陳舊版本幾秒鐘通常比痛苦地下載圖像更好。

As for stale-if-error, it allows a cache to serve a stale version if the origin server returns a 5xx status code. This gives developers a chance to fix potential issues during a grace period where clients are shielded from irritating error pages.

至于過時錯誤，如果原始服務器返回5xx狀態代碼，則它允許緩存提供過時版本。 這為開發人員提供了在寬限期內解決潛在問題的機會，在寬限期內，客戶端可以避免惱人的錯誤頁面。

Consider the case of a meteo third-party script. If the meteo server happens to be unreachable for a few minutes, it’s probably best to display a slightly outdated forecast during this lapse of time, than it is to see a portion of the page be blank (or a whole blank page if the code does not handle third-party scripts loading failures.

考慮一個meteo第三方腳本的情況。 如果meteo服務器在幾分鐘內碰巧無法訪問，則最好在這段時間內顯示稍微過時的預測，而不是看到頁面的一部分為空白(如果代碼確實為空白，則整個頁面為空白)無法處理第三方腳本加載失敗。

我們還不知道 (What we don’t know yet)

After examining these Cache-Control directives, we now understand how applications that are distributed on the web, tend to leverage HTTP caching mechanisms in multiple ways, depending on what they need.

在研究了這些Cache-Control指令之后，我們現在了解了在Web上分發的應用程序如何根據所需的需求以多種方式利用HTTP緩存機制。

Though what we don’t yet understand is what ?cache softwares actually do with the response they receive. They will most likely have to store it somewhere in order to retrieve it later. That’s the core idea of any caching system after all.

盡管我們還不了解緩存軟件實際上是如何處理收到的響應的。 他們很可能必須將其存儲在某個地方以便以后檢索。 畢竟，這是所有緩存系統的核心思想。

Under normal circumstances, this certainly looks like what we would call an implementation detail. It should be merely enough to know that resources are indeed stored some way. Yet in this case, learning just a little more is actually critical.

在正常情況下，這肯定看起來像我們所謂的實現細節。 僅知道資源確實以某種方式存儲就足夠了。 然而，在這種情況下，多學一點實際上是至關重要的。

Neglecting the mechanisms that govern how caching softwares map objects from the HTTP responses space to their storage space can have really unexpected consequences, such as serving a brotli encoded Chinese document, to a user who does not understand Chinese, using a browser unable to decode brotli ˉ\_(ツ)_/ˉ

忽略用于控制緩存軟件如何將對象從HTTP響應空間映射到其存儲空間的機制，可能會產生意想不到的后果，例如使用無法解碼brotli的瀏覽器向不懂中文的用戶提供brotli編碼的中文文檔。 ˉ\ _(ツ)_ /ˉ

緩存如何存儲和檢索資源 (How caches store and retrieve resources)

Albeit unlikely to happen, since most browsers can decode brotli - and since most people know how to 說中文 - ?the previous situation can still easily occur. To understand why this is the case, one must consider how caches store their representations.

盡管這種情況不太可能發生，但是由于大多數瀏覽器都可以解碼brotli，而且由于大多數人都知道怎么說中文，因此以前的情況仍然很容易發生。 要理解為什么會這樣，必須考慮緩存如何存儲其表示。

By virtue of what they try to achieve, most caching softwares ought to be able to quickly retrieve simple text documents. To do so, a very simple yet powerful strategy is to use a key-value store. This strategy fits well in-memory representations. Therefore, the question one must answer when designing is the following: how to construct a cache key from an HTTP response?

依靠他們試圖實現的目標，大多數緩存軟件應該能夠快速檢索簡單的文本文檔。 為此，一種非常簡單但功能強大的策略是使用鍵值存儲。 此策略非常適合內存中的表示形式。 因此，設計時必須回答的問題如下：如何從HTTP響應構造緩存鍵？

What we are looking for here is a way to uniquely identify a resource. Conveniently, this is exactly why URIs - Uniform Resource Identifiers - were invented in the first place!

我們在這里尋找的是一種唯一標識 資源的方法。 方便地，這正是URI的原因-統一資源 標識符-首先被發明！

But URIs don’t tell the whole truth about resources. They never describe them entirely, if only for the fact that resources change over time.

但是URI并不能說明資源的全部真相。 他們永遠不會完全描述它們，即使僅僅是因為資源隨時間變化而已。

Websites get rebranded, new content gets published and users update their profile. Granted, ?not for the same reasons or at the same frequency, though all resources will eventually change. In fact, the entire Conditional request specification is based on this sole observation: nothing is permanent except change.

網站更名，發布新內容，用戶更新個人資料。 當然，雖然所有資源最終都會改變，但并非出于相同的原因或頻率。 實際上，整個條件請求規范都基于這個唯一的觀察結果： 除了 change 之外，沒有什么是永久的 。

Philosophical quotes aside, there is, however, another time-independent reason why resources change. Indeed, any moment, resources may be available in multiple representations. This is why we have Content-Negociation.

除了哲學上的引用外，還有另一個與時間無關的原因來改變資源。 確實，任何時候，資源都可能有多種表示形式。 這就是為什么我們要進行內容協商。

The HTTP request headers Accept, Accept-Language, Accept-Encoding, Accept-Charset (and a few other headers who are not strictly speaking part of content negotiation) add another dimension on which representations can differ. As such, the problem of finding a good cache key becomes more complicated. Since all these representations share the same URI, caches must have a way to distinguish them in order to serve the right representation at each client, honoring content negotiation.

HTTP請求標頭Accept，Accept-Language， Accept-Encoding，Accept-Charset(以及其他一些嚴格不是內容協商的標頭)添加了另一個維度，表示方式可能會有所不同。 這樣，尋找良好的高速緩存密鑰的問題變得更加復雜。 由于所有這些表示形式共享相同的URI，因此緩存必須具有區分它們的方式，以便在每個客戶端上提供正確的表示形式，從而尊重內容協商。

And since only origin servers know what different representations are available, it is again the origin server’s responsibility to indicate to a cache based on which headers it will generate a different representation. To do so, the origin servers must add a Vary header containing the value of the request headers that cause different representations to be generated.

而且，由于只有原始服務器知道可用的不同表示形式，因此原始服務器還要負責根據緩存將生成不同表示形式的標頭向緩存進行指示。 為此，原始服務器必須添加一個Vary 標頭，其中包含導致生成不同表示形式的請求標頭的值。

When caches see a response coming from an origin server with, for instance, the header Vary: Accept-Language, it will examine the value of the Accept-Language header, ?such as fr-FR, and use this value to construct a more specific cache-key, perhaps like https://example.net/home.html_fr-FR.

當緩存看到來自源服務器的響應(例如帶有標頭Vary ： Accept-Language)時，它將檢查 Accept-Language頭，如FR-FR，并使用該值來構建一個更具體的緩存鍵，或許象https://example.net/home.html_ FR-FR。

The actual implementation strategy is of little importance to us. Altering the cache key might not even be the best way to do it. It somehow has to use the value of the header to differentiate representations.

實際的實施策略對我們而言并不重要。 更改緩存鍵甚至可能不是最佳方法。 它必須以某種方式使用價值 標頭的名稱以區分表示形式。

The Vary header can actually point at more than one header, when resources are available in multiple representations. Selecting a cache key when multiple headers are involved is not really much more complicated than with only one header. The real problem when varying over multiple dimensions is the combinatorial explosion.

當資源有多種表示形式時，Vary標頭實際上可以指向多個標頭。 當涉及多個標頭時，選擇一個緩存鍵并沒有比僅包含一個標頭復雜得多。 當在多個維度上變化時，真正的問題是組合爆炸 。

Unfortunately, there are no ways around this. If you are to cache and serve your resources in multiple representations, you have to pay the cost of a large storage. If you decide to lower your vary cardinality, some of your users will receive cache hits for responses that won’t match their requests.

不幸的是，這沒有辦法。 如果要以多種表示形式緩存和服務資源，則必須支付大容量存儲的費用。 如果您決定降低不同的基數，則您的某些用戶將收到緩存命中結果，因為這些結果與他們的請求不匹配。

On the other hand, if you vary properly on everything, and do not have enough storage space, chances are your users won’t be seeing cache hits anytime soon.

另一方面，如果您在所有方面都做得適當，并且沒有足夠的存儲空間，則您的用戶很可能很快就不會看到緩存命中。

Now, it is important to know that this is only a problem if you decide to use a public cache, for which two different requests coming from two different users are running the same code, at the proxy level. If you decide to leverage the browser’s cache only, then you can skip the Vary header altogether and serve resources in as many representations as you want. This is because each browser’s cache will only cache representations matching the user’s preferences. This is good news!

現在，重要的是要知道，這僅是一個問題，如果您決定使用公共緩存，在代理級別，來自兩個不同用戶的兩個不同請求正在運行同一代碼的公共緩存。 如果您決定僅利用瀏覽器的緩存，則可以完全跳過Vary標頭，并根據需要以任意數量的表示形式提供資源。 這是因為每個瀏覽器的緩存將僅緩存與用戶首選項匹配的表示形式。 這是個好消息！

But let’s not get ahead of ourselves just yet. As we said, caches use the value of the header as its input to generate a more specific cache key. But what is to say that all these values are well formatted ? Absolutely nothing! This is the rather inconvenient consequence of RFC father’s robustness principle. HTTP servers are indeed very liberal in what they accept.

但是，讓我們暫時不要超越自己。 如前所述，緩存使用標頭的值作為其輸入來生成更具體的緩存鍵。 但是，所有這些值的格式正確又是什么呢？ 絕對沒有！ 這是RFC 父親的魯棒性原則的不便之處。 HTTP服務器在接受方面確實非常自由 。

However there is hope.

但是有希望。

Considering the case of an origin server that can only produce a representation in two different languages, caches must be able to regroup incoming Accept-Content values such as fr, fr-FR, fr_FR.. into something such as FR. Otherwise, just like before with the combinatorial explosion, the number of representations will explode, but in this case, for a misguided reason.

考慮到原始服務器只能生成兩種不同語言的表示形式，緩存必須能夠將傳入的Accept-Content值(例如fr，fr-FR，fr_FR ..)重新組合為諸如FR之類的內容。 否則，就像之前的組合爆炸一樣，表示的數量也會爆炸，但是在這種情況下，原因是錯誤的。

The process by which all these representations are regrouped is called normalization and is often done at the cache. Many caches offer configuration utilities or their own languages to deal with these situations. Sometimes, the functions are even already written, or snippets can easily be found on the Internet. The following pictures illustrates the process for the infamous User-Agent header.

重新組織所有這些表示的過程稱為規范化 ，通常在緩存中完成。 許多緩存提供配置實用程序或它們自己的語言來處理這些情況。 有時，這些功能甚至已經編寫完畢，或者可以在Internet上輕松找到摘要。 下圖說明了臭名昭著的User-Agent標頭的過程。

Fastly, a popular CDN, sampled 100 000 requests and found that the Accept-Encoding header was expressed in 44 different ways ! As for the User-Agent header, they found a shy of… 8000 different ones! Without normalization, chances are that the cache will never see any hit.

很快，一個流行的CDN 對 100 000個請求進行了采樣 ，發現Accept-Encoding標頭以44種不同的方式表示！ 至于User-Agent標頭，他們發現了…8000個不同的標頭！ 如果不進行標準化，則很有可能緩存將永遠不會看到任何命中。

This wraps up the section about representation variation. At this point, we know how to instruct caches to store our resources, and have learned to leverage the Vary header to prevent accidents from happening when using public caches. We have now covered enough of the specification to be able to cache resources effectively.

這總結了關于表示變化的部分。 至此，我們知道了如何指示緩存來存儲資源，并且學會了利用Vary標頭來防止使用公共緩存時發生事故。 現在，我們已經涵蓋了足夠多的規范，以能夠有效地緩存資源。

常見的誤解 (Common misconceptions)

By now, you should have a thorough understanding of how HTTP caching works. Freshness control, resource’s representations and cache hits are no longer mysterious concepts to you. And if you start to feel empowered by all this knowledge, we have some good news for you: we’ve covered a large portion of the specification, and you now know pretty much all that’s necessary to be up and running.

到目前為止，您應該對HTTP緩存的工作方式有一個全面的了解。 對您而言，新鮮度控制，資源表示和緩存命中不再是神秘的概念。 而且，如果您開始感到受所有這些知識的啟發，那么我們將為您帶來一些好消息：我們已經涵蓋了大部分規范，現在您幾乎知道了啟動和運行所需要的一切。

But make no mistake. Caching is a complex topic.

但是請不要誤會。 緩存是一個復雜的話題。

Experience has shown us that, unless you’re dealing with it on a day-to-day basis, what may be crystal clear today will quickly turn into something rather blurry after a few weeks. ?Therefore, we decided to conclude this second article by dispelling two common misconceptions that are all too easy to make.

經驗告訴我們，除非您每天進行處理，否則幾周后，今天可能很清楚的事情很快就會變得很模糊。 因此，我們決定通過消除兩個太容易造成的常見誤解來結束第二篇文章。

新鮮度控制和驗證 (Freshness-control and validation)

This might seem obvious after reading the previous sections but it is worth repeating many times. Freshness control and validation (which we have slightly discussed in the beginning) are two very distinct mechanisms that serve two very different purposes, and involve HTTP requests between different pieces.

在閱讀了前面的部分之后，這似乎很明顯，但是值得重復多次。 新鮮度控制和驗證( 我們在開始時已經稍作討論了 )是兩種截然不同的機制，它們服務于兩種截然不同的目的，并且涉及不同部分之間的HTTP請求。

• Freshness control always happen in a cache and is solely based on time

  新鮮度控制始終在緩存中進行，并且僅基于時間

• Validations always happen in the origin server and are based both on time and on identifiers (ETags)

  驗證始終在原始服務器中進行，并且基于時間和標識符(ETag)

This is something we find important to remind ourselves. It means that once the cache has received temporal instructions, it can - and best believe it will - serve resources without ever contacting the origin server until the timer expires.

我們發現這很重要，需要提醒自己。 這意味著一旦高速緩存接收到時間指令，它就可以-最好地相信它會-在無需等待計時器到期之前就不聯系源服務器的情況下服務資源。

For instance, if your web application’s HTML file reaches a browser and the HTTP response happens to include the header Cache-Control: max-age=86400 the browser will happily serve the same version of your app for a day. In this case, the browser would serve it for one day without any possible action from you or anyone, except the user, if one ever decided to flush his browser’s cache.

例如，如果您的Web應用程序HTML文件到達瀏覽器，并且HTTP響應恰好包含標頭Cache-Control：max-age = 86400，則該瀏覽器將在一天之內愉快地為您的應用提供相同版本。 在這種情況下，如果一個瀏覽器決定刷新其瀏覽器的緩存，則該瀏覽器將在一天之內運行，而您或除用戶之外的任何人都不會采取任何行動。

If you’re thinking everyone can make mistakes, and one day is not so bad, well, brace yourself: the maximum max-age value is… 31536000 seconds! That is to say, one year. This is the reason why HTML files are very dangerous to cache like this, and should generally be declared with Cache-Control: no-cache.

如果您認為每個人都可能犯錯，并且一天還不錯，那么請做好準備：最大年齡上限是……31536000秒！ 也就是說， 一年。 這就是為什么HTML文件這樣非常危險地緩存的原因，通常應使用Cache-Control：no-cache來聲明。

新鮮度和最新表現 (Freshness and most recent representation)

Another misconception is to believe that cache hits and freshness have anything to do with having the last available version of a resource. This is what we all try to achieve, but one can never truly know if the resource it has been served from a cache is indeed the most up-to-date version. In fact, this holds true even in the absence of cache. It has to do with the nature of distributed applications: other people’s actions can change the things we are interacting with at any time.

另一個誤解是認為緩存命中率和新鮮度與擁有資源的最后可用版本有關。 這是我們所有人都試圖實現的目標，但是人們永遠無法真正知道從緩存提供的資源是否確實是最新版本。 實際上，即使沒有緩存，這也適用。 它與分布式應用程序的性質有關：其他人的行為可以隨時更改我們正在與之交互的事物。

When querying the state of the application, the ETag header must always be used to always let the server know what our current understanding of the application’s state is. And if it does not match the server’s, 409 Conflict are expected to be received on the client side.

查詢應用程序的狀態時，必須始終使用ETag標頭以始終讓服務器知道我們對應用程序狀態的當前了解。 并且，如果與服務器不匹配，則可能會在客戶端收到409沖突。

結論 (Conclusion)

Along this article, we have described how caching actually works. Now would be a good time to spin up a local dev server and fiddle around with these two core headers: Cache-Control and Vary to see them in action.

在本文中，我們描述了緩存實際上是如何工作的。 現在將是啟動本地開發服務器并在這兩個核心標頭中忙忙碌碌的好時機：Cache-Control和Vary以查看它們的運行情況。

We started by giving an overview of how caching works, illustrating the four possible paths that a request can take : the happy path (cache hit) and the 3 possible ways to have a cache miss : empty cache, failed revalidation and successful revalidation. This overview alone gives the possibility to understand how complex caching topologies can fit together.

我們首先概述了緩存的工作方式，說明了請求可以采用的四種可能路徑：快樂路徑(緩存命中)和三種可能的緩存缺失方式：空緩存，失敗的重新驗證和成功的重新驗證。 僅此概述就可以了解復雜的緩存拓撲如何組合在一起。

Then, we went deeper and looked at all the most useful Cache-Control headers, and clarified some subtle differences that are all easily missed.

然后，我們更深入地研究了所有最有用的Cache-Control標頭，并弄清了一些容易被忽略的細微差別。

We also looked at the Vary header and the fundamental difference between resources and representations, to avoid serving the wrong representation to the right client.

我們還研究了Vary標頭以及資源和表示形式之間的根本區別，以避免為正確的客戶提供錯誤的表示形式 。

Finally, we took some time to review it all through the angle of common misconceptions you might encounter, and hopefully helped you to avoid them.

最后，我們花了一些時間從您可能會遇到的常見誤解的角度來回顧所有問題，并希望能幫助您避免這些誤解。

In the next article, we’ll apply all of this knowledge to set up a local lab environment in which we will set an innocent node.js app on fire with a load-testing tool, right before rescuing it with the help of a popular caching software.

在下一篇文章中，我們將運用所有這些知識來設置本地實驗室環境，在該環境中，我們將使用負載測試工具來啟動一個無辜的node.js應用程序，然后在流行的幫助下對其進行搶救緩存軟件。

Stay tuned!

敬請關注！

更進一步： (To go further:)

The official specification about the material we covered (and other things)https://tools.ietf.org/html/rfc7234#section-5.3

關于我們涵蓋的材料(及其他內容)的官方規范https://tools.ietf.org/html/rfc7234#section-5.3

Google Web’s Fundamentalhttps://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#defining-optimal-cache-control-policy

Google Web的基礎https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#defining-optimal-cache-control-policy

About the Cache-Control header:https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Cache-Control

關于Cache-Control標頭： https : //developer.mozilla.org/fr/docs/Web/HTTP/Headers/Cache-Control

About the Vary Header:https://www.smashingmagazine.com/2017/11/understanding-vary-header/https://www.fastly.com/blog/best-practices-using-vary-headerhttps://www.fastly.com/blog/getting-most-out-vary-fastlyhttps://www.fastly.com/blog/understanding-vary-header-browser

關于Vary標頭： https: //www.smashingmagazine.com/2017/11/understanding-vary-header/ https://www.fastly.com/blog/best-practices-using-vary-header https：// www.fastly.com/blog/getting-most-out-vary-fastly https://www.fastly.com/blog/understanding-vary-header-browser

翻譯自: https://www.freecodecamp.org/news/an-in-depth-introduction-to-http-caching-cache-control-vary/