[譯]關于緩存的那些風流事兒

最近大家針對 preload 、 HTTP/2 push 和 ServiceWorker 的瀏覽器緩存實現展開了激烈的討論，而這也引起了很多人的疑惑。

鑒于此，我想講個故事來讓大家了解一個請求如何完成他的使命并找到匹配的緩存資源，

以下內容均基于 Chromium 的術語，不過其余瀏覽器的實現本質上沒有太大的差異。

Questy 的旅程

Questy 是一個請求。她是在渲染引擎內（也叫渲染器）誕生的。她渴望能在這個標簽頁關閉前找到一個讓她的“人生”再無遺憾的資源。

所以 Questy 展開了她追求幸福的旅程。 但是她會在哪里找到一個恰恰適合的資源呢？

此時離她最近的是……

內存緩存（Memory Cache）

內存緩存中包含了大量的資源。他包含了所有渲染引擎請求的資源。這些資源都是現有文檔的一部分。在文檔的生命周期中他們都會被儲存在此。這意味著，如果 Questy 尋找的資源已經被文檔中的其余部分加載了，那么他們會在此相遇。

確切來說，“短期內存緩存”這個名字可能會更適合。因為內容緩存僅在導航結束前保存這些資源，在某些情況下，時間甚至會更短。

事實上，很多種情況都會導致 Questy 尋找的資源已經被加載。

預加載器（preloader） 可能是最常發生的情況。如果 Questy 是由 HTML 解析器創造的 DOM節點所激發的，那么她很可能會發現，她所尋找的資源早已在 HTML 標記化階段加載完畢了。

顯示 preload 指令（ <link rel=preload> ）則是另一種較為可能發生的情況。該指令會讓瀏覽器預加載資源并存儲在內存緩存中。

除此之外，還有可能是因為所請求的資源與之前的 DOM 節點或者 CSS 規則所需要的資源相同。例如，一個頁面中可能會含有多個具有相同 src 屬性的 <img> 元素，但是他們會得到同一個資源。而實現這種機制的正是內存緩存。

然而，內存緩存不會輕易匹配我們的資源請求。當然了，為了使請求和資源相匹配，他們必須要有相同的 URL 。不過，這還不是全部。他們還必須要有相同的資源類型（這樣子一個腳本資源才不會被一個圖片請求所匹配），相同的 CORS 策略和一些其他特性。

規范并沒有十分地明確定義內存緩存所需要匹配的特性，所以不同的瀏覽器的實現可能會有一定的差異。

有一樣東西是內存緩存不關心的，那就是 HTTP 語義。無論資源的頭部是是否帶有 max-age=0 或者 no-cache 、 Cache-Control 標簽，內存緩存都不關心。因為在當前導航中，資源是可以重用的，所以 HTTP 語義并不重要。

唯一例外的是 no-store 指令。在某些特定的情況下瀏覽器會尊重他。（例如，當資源被單獨節點重用時）。

所以，Questy 走上前詢問內存緩存是否有匹配的資源。唉，然而并沒有。

Questy 并沒有放棄。她走過資源計時器和開發者工具的網絡注冊點。在那里，她注冊為尋找資源的請求（這意味著如果她能找到匹配的資源，則會出現在開發中工具和資源計時器中）。

完成了這些官方登記后，她繼續向前……

Service Worker 緩存

和內存緩存不一樣， Service Woker 喜歡不走尋常路。他的行為難以預測。因為他只遵循開發者告訴他的規則。

首先，Service Worker只有安裝后才會存在。而且因為他的邏輯是由開發者編寫的 JavaScript 而不是瀏覽器控制的，所以 Questy 完全不知道她能不能在這里找到那個他？那個資源長成什么的？他是被存儲在緩存里嗎？還是說他是由 Service Worker 的主人精心偽造的響應？

這些問題沒有人可以回答她。因為 Service Worker 自成一套，無論是資源的匹配方式還是響應的包裝方法，他們都能按照自己的的想法去完成。

Service Worker 擁有和緩存相關的 API ，這讓他可以儲存資源。和內存儲存不同的是這種存儲方式是持久的。即使該標簽頁被關閉甚至瀏覽器重啟，這些被存儲的資源都不會丟失。只有當開發者明確表示要移除他們的時候（使用 cache.delete(resource) ），他們才會被移除。另外一種情況就是當瀏覽器的存儲空間不足時，他會將整個 Service Worker 緩存還有其他源存儲如 indexedDB、localStorage 等都清除掉。也因此，Service Worker 能確保他的存儲和其他源存儲是同步的。

Service Worker 只負責特定的域，換言之，他最多只能管理一個 host。因此，Service Worker 只能控制來自特定域內的文檔的請求。

Questy 走向 Service Worker 詢問他有沒有合適的資源。可惜的是 Service Worker 從來沒有見過那個域的資源，所以他也找不到 Questy 尋找的請求了。于是，Service Worker 讓 Questy 繼續前行（通過 fetch() ），從而在網絡棧這片神奇的土地里繼續尋找她需要的資源。

而一旦進入網絡棧，最容易找到資源的地方就是……

HTTP 緩存

HTTP 緩存（有時候也被他的朋友成為“磁盤緩存”）和 Questy 之前遇到過的緩存不太一樣。

一方面，他們的存儲是持久的，而且能被不同的會話甚至不同的網站重用。如果一個資源被一個網站下載了，他也可以被其他網站重用，

而另一方面，HTTP 緩存遵循 HTTP 語義（名字早已暗示了一切）。他樂于提供他認為覺得是“新鮮”的資源（基于由響應的緩存頭聲明的生命周期）、校驗那些需要 重新驗證 的資源、并拒絕存儲那些它不應該存儲的資源。

既然他是一個持久性的緩存，他也需要移除資源。但和 Service Worker 不一樣的事，他會在覺得他需要空間來存儲更重要或者會被更多人需要的資源時，逐個移除那些舊資源。

HTTP 緩存擁有一個基于內存的組件。他負責為請求匹配資源。可是一旦資源匹配成功，它需要從磁盤中獲取資源內容，這是一個較為昂貴的操作。

上文我們提到 HTTP 緩存遵循 HTTP 語義。這基本是正確的。除了一個例外情況，HTTP 緩存會存儲一些資源一段時間。瀏覽器能夠為下次導航預取資源。我們可以通過顯示的指令（ <link rel=prefetch> ）或者依靠瀏覽器內部機制完成。這些被預取的資源會被保存下來直到下次導航，盡管它們可能是不允許緩存的。所以當預取資源到達 HTTP 緩存時，它會被緩存（并且不需要校驗就會被提供）大概五分鐘。

盡管 HTTP 緩存看起來十分的嚴厲，但 Questy 還是鼓起勇氣上前詢問有沒有匹配的資源。然而答案依舊是沒有。

她還是得繼續隨著網絡往前走。這段旅程時可怕而且未知的，然而 Questy 知道無論如何她都要找到她需要的資源。所以她只能繼續。這時候她找到了一個對應的 HTTP/2 會話。并且準備通過網絡繼續前行，這時候她忽然看到了……

推送“緩存”

推送緩存（其實他更應該被描述為“待認領的推送流存儲器”，不過那實在是太拗口了）是存儲 HTTP/2 推送資源的地方。它們是 HTTP/2 會話的一部分，這有幾個特殊的含義。

這個容器并不是持久的。當會話結束后，未被認領的資源（例如，從來沒有被請求匹配到的）就會被移除。如果資源是由不同的 HTTP/2 會話獲取的，他們 并不會匹配 。除此之外，推送緩存只會存儲資源一段時間（在基于 Chromium 的瀏覽器里，這個時長約為五分鐘）。

推送緩存根據請求的 URL 和請求頭匹配相應，但他不遵循嚴格的 HTTP 語義。

規范里也沒有明確定義推送緩存，所以再各個瀏覽器、系統或者 HTTP/2 客戶端間的實現可能會不一樣。

盡管信心不大，Questy 還是上前詢問是否有匹配的請求。令人驚訝的是，他真的有！！Questy 喜出望外的認領了這個資源（這也意味著它將這個 HTTP/2 流從待認領容器中移除）。現在她可以回去渲染這個資源了。

在他們回程的路上，他們走過了 HTTP 緩存，并且話費了一些時間去復制了一份資源以備日后使用。

離開網絡棧后，他們回到 Service Worker 的轄區，而 Service Worker 也將一份資源的拷貝存儲到自己的緩存中才讓他們回到渲染器里。

最終，一旦它們會到渲染器，內存緩存就會保存一份資源的引用（而不是拷貝）。這樣子在稍后如果在同一個導航會話中需要這份資源，他就可以將相同的資源分配給他。

于是，它們就幸福快活的住在了一起，直到文檔被移除，然后他們都被垃圾回收了。

不過那是另外一天的故事了。

要點

所以，從 Questy 旅程中我們能學習到什么呢？

• 不同的請求可以從不同的瀏覽器緩存中匹配的資源。
• 請求匹配資源的緩存的不同會影響這個請求是否會被開發者工具和資源計時器所展示。
• 推送資源不會被持續存儲除非他們被請求所認領。
• 不能存儲的預加載資源在下一個導航時不會存在。這是預加載（preload)和預取（prefetch）間的最大區別。
• 因為還有很多地方規范沒有明確定義，所以不同的瀏覽器實現會有差異。我們需要彌補這些差異。

總而言之，如果你使用預加載，HTTP/2 推送， Service Worker 又或者其他高級技術來加速你的網站，你可能會注意到內部緩存的實現情況。了解這些內部緩存和他們的運作方式能讓你更好的解決問題并且減少不必要的麻煩。

 

 

 

來自：http://www.w3ctech.com/topic/1990