關(guān)于Web緩存的那些風(fēng)流事兒
最近大家針對preload、HTTP/2 push和ServiceWorker的瀏覽器緩存實(shí)現(xiàn)展開了激烈的討論，而這也引起了很多人的疑惑。
鑒于此，我想講個故事來讓大家了解一個請求如何完成他的使命并找到匹配的緩存資源，以下內(nèi)容均基于 Chromium 的術(shù)語，不過其余瀏覽器的實(shí)現(xiàn)本質(zhì)上沒有太大的差異。
Questy 的旅程
Questy 是一個請求。她是在渲染引擎內(nèi)(也叫渲染器)誕生的。她渴望能在這個標(biāo)簽頁關(guān)閉前找到一個讓她的“人生”再無遺憾的資源。
所以 Questy 展開了她追求幸福的旅程。 但是她會在哪里找到一個恰恰適合的資源呢?
此時離她最近的是……
內(nèi)存緩存(Memory Cache)
內(nèi)存緩存中包含了大量的資源。他包含了所有渲染引擎請求的資源。這些資源都是現(xiàn)有文檔的一部分。在文檔的生命周期中他們都會被儲存在此。這意味著，如果 Questy 尋找的資源已經(jīng)被文檔中的其余部分加載了，那么他們會在此相遇。
確切來說，“短期內(nèi)存緩存”這個名字可能會更適合。因?yàn)閮?nèi)容緩存僅在導(dǎo)航結(jié)束前保存這些資源，在某些情況下，時間甚至?xí)獭?/p>
事實(shí)上，很多種情況都會導(dǎo)致 Questy 尋找的資源已經(jīng)被加載。
預(yù)加載器(preloader)可能是最常發(fā)生的情況。如果 Questy 是由 HTML 解析器創(chuàng)造的 DOM節(jié)點(diǎn)所激發(fā)的，那么她很可能會發(fā)現(xiàn)，她所尋找的資源早已在 HTML 標(biāo)記化階段加載完畢了。
顯示 preload 指令()則是另一種較為可能發(fā)生的情況。該指令會讓瀏覽器預(yù)加載資源并存儲在內(nèi)存緩存中。
除此之外，還有可能是因?yàn)樗埱蟮馁Y源與之前的 DOM 節(jié)點(diǎn)或者 CSS 規(guī)則所需要的資源相同。例如，一個頁面中可能會含有多個具有相同 src 屬性的<img>元素，但是他們會得到同一個資源。而實(shí)現(xiàn)這種機(jī)制的正是內(nèi)存緩存。
然而，內(nèi)存緩存不會輕易匹配我們的資源請求。當(dāng)然了，為了使請求和資源相匹配，他們必須要有相同的 URL 。不過，這還不是全部。他們還必須要有相同的資源類型(這樣子一個腳本資源才不會被一個圖片請求所匹配)，相同的 CORS 策略和一些其他特性。
- 規(guī)范并沒有十分地明確定義內(nèi)存緩存所需要匹配的特性，所以不同的瀏覽器的實(shí)現(xiàn)可能會有一定的差異。
有一樣?xùn)|西是內(nèi)存緩存不關(guān)心的，那就是 HTTP 語義。無論資源的頭部是是否帶有 max-age=0 或者 no-cache 、Cache-Control標(biāo)簽，內(nèi)存緩存都不關(guān)心。因?yàn)樵诋?dāng)前導(dǎo)航中，資源是可以重用的，所以 HTTP 語義并不重要。
唯一例外的是no-store指令。在某些特定的情況下瀏覽器會尊重他。(例如，當(dāng)資源被單獨(dú)節(jié)點(diǎn)重用時)。
所以，Questy 走上前詢問內(nèi)存緩存是否有匹配的資源。唉，然而并沒有。
Questy 并沒有放棄。她走過資源計(jì)時器和開發(fā)者工具的網(wǎng)絡(luò)注冊點(diǎn)。在那里，她注冊為尋找資源的請求(這意味著如果她能找到匹配的資源，則會出現(xiàn)在開發(fā)中工具和資源計(jì)時器中)。
完成了這些官方登記后，她繼續(xù)向前……
Service Worker 緩存
和內(nèi)存緩存不一樣，Service Woker喜歡不走尋常路。他的行為難以預(yù)測。因?yàn)樗蛔裱_發(fā)者告訴他的規(guī)則。
首先，Service Worker只有安裝后才會存在。而且因?yàn)樗倪壿嬍怯砷_發(fā)者編寫的 JavaScript 而不是瀏覽器控制的，所以 Questy 完全不知道她能不能在這里找到那個他?那個資源長成什么的?他是被存儲在緩存里嗎?還是說他是由 Service Worker 的主人精心偽造的響應(yīng)?
這些問題沒有人可以回答她。因?yàn)?Service Worker 自成一套，無論是資源的匹配方式還是響應(yīng)的包裝方法，他們都能按照自己的的想法去完成。
Service Worker 擁有和緩存相關(guān)的 API ，這讓他可以儲存資源。和內(nèi)存儲存不同的是這種存儲方式是持久的。即使該標(biāo)簽頁被關(guān)閉甚至瀏覽器重啟，這些被存儲的資源都不會丟失。只有當(dāng)開發(fā)者明確表示要移除他們的時候(使用 cache.delete(resource))，他們才會被移除。另外一種情況就是當(dāng)瀏覽器的存儲空間不足時，他會將整個 Service Worker 緩存還有其他源存儲如 indexedDB、localStorage 等都清除掉。也因此，Service Worker 能確保他的存儲和其他源存儲是同步的。
Service Worker 只負(fù)責(zé)特定的域，換言之，他最多只能管理一個 host。因此，Service Worker 只能控制來自特定域內(nèi)的文檔的請求。
Questy 走向 Service Worker 詢問他有沒有合適的資源。可惜的是 Service Worker 從來沒有見過那個域的資源，所以他也找不到 Questy 尋找的請求了。于是，Service Worker 讓 Questy 繼續(xù)前行(通過 fetch())，從而在網(wǎng)絡(luò)棧這片神奇的土地里繼續(xù)尋找她需要的資源。
而一旦進(jìn)入網(wǎng)絡(luò)棧，最容易找到資源的地方就是……
HTTP 緩存
HTTP 緩存(有時候也被他的朋友成為“磁盤緩存”)和 Questy 之前遇到過的緩存不太一樣。
一方面，他們的存儲是持久的，而且能被不同的會話甚至不同的網(wǎng)站重用。如果一個資源被一個網(wǎng)站下載了，他也可以被其他網(wǎng)站重用，
而另一方面，HTTP 緩存遵循 HTTP 語義(名字早已暗示了一切)。他樂于提供他認(rèn)為覺得是“新鮮”的資源(基于由響應(yīng)的緩存頭聲明的生命周期)、校驗(yàn)?zāi)切┬枰匦买?yàn)證的資源、并拒絕存儲那些它不應(yīng)該存儲的資源。
既然他是一個持久性的緩存，他也需要移除資源。但和 Service Worker 不一樣的事，他會在覺得他需要空間來存儲更重要或者會被更多人需要的資源時，逐個移除那些舊資源。
HTTP 緩存擁有一個基于內(nèi)存的組件。他負(fù)責(zé)為請求匹配資源。可是一旦資源匹配成功，它需要從磁盤中獲取資源內(nèi)容，這是一個較為昂貴的操作。
上文我們提到 HTTP 緩存遵循 HTTP 語義。這基本是正確的。除了一個例外情況，HTTP 緩存會存儲一些資源一段時間。瀏覽器能夠?yàn)橄麓螌?dǎo)航預(yù)取資源。我們可以通過顯示的指令()或者依靠瀏覽器內(nèi)部機(jī)制完成。這些被預(yù)取的資源會被保存下來直到下次導(dǎo)航，盡管它們可能是不允許緩存的。所以當(dāng)預(yù)取資源到達(dá) HTTP 緩存時，它會被緩存(并且不需要校驗(yàn)就會被提供)大概五分鐘。
盡管 HTTP 緩存看起來十分的嚴(yán)厲，但 Questy 還是鼓起勇氣上前詢問有沒有匹配的資源。然而答案依舊是沒有。
她還是得繼續(xù)隨著網(wǎng)絡(luò)往前走。這段旅程時可怕而且未知的，然而 Questy 知道無論如何她都要找到她需要的資源。所以她只能繼續(xù)。這時候她找到了一個對應(yīng)的 HTTP/2 會話。并且準(zhǔn)備通過網(wǎng)絡(luò)繼續(xù)前行，這時候她忽然看到了……
推送“緩存”
推送緩存(其實(shí)他更應(yīng)該被描述為“待認(rèn)領(lǐng)的推送流存儲器”，不過那實(shí)在是太拗口了)是存儲 HTTP/2 推送資源的地方。它們是 HTTP/2 會話的一部分，這有幾個特殊的含義。
這個容器并不是持久的。當(dāng)會話結(jié)束后，未被認(rèn)領(lǐng)的資源(例如，從來沒有被請求匹配到的)就會被移除。如果資源是由不同的 HTTP/2 會話獲取的，他們并不會匹配。除此之外，推送緩存只會存儲資源一段時間(在基于 Chromium 的瀏覽器里，這個時長約為五分鐘)。
推送緩存根據(jù)請求的 URL 和請求頭匹配相應(yīng)，但他不遵循嚴(yán)格的 HTTP 語義。
- 規(guī)范里也沒有明確定義推送緩存，所以再各個瀏覽器、系統(tǒng)或者 HTTP/2 客戶端間的實(shí)現(xiàn)可能會不一樣。
盡管信心不大，Questy 還是上前詢問是否有匹配的請求。令人驚訝的是，他真的有!!Questy 喜出望外的認(rèn)領(lǐng)了這個資源(這也意味著它將這個 HTTP/2 流從待認(rèn)領(lǐng)容器中移除)。現(xiàn)在她可以回去渲染這個資源了。
在他們回程的路上，他們走過了 HTTP 緩存，并且話費(fèi)了一些時間去復(fù)制了一份資源以備日后使用。
離開網(wǎng)絡(luò)棧后，他們回到 Service Worker 的轄區(qū)，而 Service Worker 也將一份資源的拷貝存儲到自己的緩存中才讓他們回到渲染器里。
最終，一旦它們會到渲染器，內(nèi)存緩存就會保存一份資源的引用(而不是拷貝)。這樣子在稍后如果在同一個導(dǎo)航會話中需要這份資源，他就可以將相同的資源分配給他。
于是，它們就幸福快活的住在了一起，直到文檔被移除，然后他們都被垃圾回收了。
不過那是另外一天的故事了。
要點(diǎn)
所以，從 Questy 旅程中我們能學(xué)習(xí)到什么呢?
- 不同的請求可以從不同的瀏覽器緩存中匹配的資源。
- 請求匹配資源的緩存的不同會影響這個請求是否會被開發(fā)者工具和資源計(jì)時器所展示。
- 推送資源不會被持續(xù)存儲除非他們被請求所認(rèn)領(lǐng)。
- 不能存儲的預(yù)加載資源在下一個導(dǎo)航時不會存在。這是預(yù)加載(preload)和預(yù)取(prefetch)間的最大區(qū)別。
- 因?yàn)檫€有很多地方規(guī)范沒有明確定義，所以不同的瀏覽器實(shí)現(xiàn)會有差異。我們需要彌補(bǔ)這些差異。
總而言之，如果你使用預(yù)加載，HTTP/2 推送， Service Worker 又或者其他高級技術(shù)來加速你的網(wǎng)站，你可能會注意到內(nèi)部緩存的實(shí)現(xiàn)情況。了解這些內(nèi)部緩存和他們的運(yùn)作方式能讓你更好的解決問題并且減少不必要的麻煩。
