快取詳解

阿新 • • 發佈：2019-01-07

前言

總括： 快取從來都是前端的一個痛點，很多前端搞不清楚快取到底是何物，從而給自己創造了一些麻煩，本文一如既往的用通俗易懂的文字和例項來講述快取，希望能讓您有所得。

天青色等煙雨，而我在等你。

正文

快取是一種儲存資源副本並在下次請求時直接使用該副本的技術。

說實話，我起始真的不知道怎麼去介紹快取，所以引用了上面相對官方的定義。我想幾乎每個開發者都碰到過快取的問題吧，甚至有很多情況下我們會說這個問題已經修復了,你清理下快取就好了。這篇文章我們就細細的來挖掘下快取的種種軼事。

��快取的種類

很多開發者習慣把cookie、webStorage以及IndexedDB儲存的資料也稱之為快取，理由是都是儲存在客戶端的資料，沒有什麼區別。其實這是不嚴謹的，cookie的存在更多的是為了讓服務端區別使用者，webStorage和IndexedDB則更多用在儲存具體的資料和在客戶端儲存大量結構化資料(檔案/blobs)上面。

實際上所謂的快取只有一種——它是請求資源的副本。試想一下，如果每一個資源我們客戶端都會儲存一份副本，這會怎麼樣？客戶端會炸掉，開發者會瘋掉！所以我們需要一份協議來處理快取，可以讓開發者控制快取的建立和刪除。誰呢？還能有誰，HTTP唄。HTTP協議裡定義了很多關於快取的請求和響應欄位，這也是接下來我們重點要逼逼叨的物件，研究下究竟是哪些欄位怎麼影響快取的。

納尼？你問我為什麼要快取？��

那就太容易說道了��，快取好處有很多：

緩解伺服器壓力(不用每次去請求資源)；
提升效能(開啟本地資源速度當然比請求回來再開啟要快得多)；
減少頻寬消耗(我相信你可以理解)；

��‍♀️那麼問題又來了，既然快取這麼好，如果我請求的伺服器中間有代理也快取了怎麼辦？代理伺服器快取了我的資源導致我沒法從源伺服器拿到最新的資源怎麼辦？HTTP當然也想到了這塊的訴求。接下來我們也會逐層剖析。

��快取在巨集觀上可以分成兩類：私有快取和共享快取。共享快取就是那些能被各級代理快取的快取(咋覺得有點繞)。私有快取就是使用者專享的，各級代理不能快取的快取。

��微觀上可以分下面三類：

1. 瀏覽器快取

我相信只要你經常使用某個瀏覽器��(Chrome,Firefox,IE等)，肯定知道這些瀏覽器在設定裡面都是有個清除快取功能，這個功能存在的作用就是刪除儲存在你本地磁碟上資源副本，也就是清除快取。

快取存在的意義就是當用戶點選back按鈕或是再次去訪問某個頁面的時候能夠更快的響應。尤其是在多頁應用的網站中，如果你在多個頁面使用了一張相同的圖片，那麼快取這張圖片就變得特別的有用。��

2. 代理伺服器快取

代理伺服器快取原理和瀏覽器端類似，但規模要大得多，因為是為成千上萬的使用者提供快取機制，大公司和大型的ISP提供商通常會將它們設立在防火牆上或是作為一個獨立的裝置來運營。(下文如果沒有特殊說明,所有提到的快取伺服器都是指代理伺服器。)

由於快取伺服器不是客戶端或是源伺服器的一部分，它們存在於網路中，請求路由必須經過它們才會生效，所以實際上你可以去手動設定瀏覽器的代理，或是通過一箇中間伺服器來進行轉發，這樣使用者自然就察覺不到代理伺服器的存在了。��

代理伺服器快取就是一個共享快取，不只為一個使用者服務，經常為大量使用者使用，因此在減少相應時間和頻寬使用方面很有效：因為同一個快取可能會被重用多次。

3. 閘道器快取

也被稱為代理快取或反向代理快取，閘道器也是一箇中間伺服器，閘道器快取一般是網站管理員自己部署，從讓網站擁有更好的效能。��

CDNS(網路內容分發商)分佈閘道器快取到整個（或部分）網際網路上，並出售快取服務給需要的網站，比如國內的七牛雲、又拍雲都有這種服務。

4. 資料庫快取

資料庫快取是指當我們的應用極其複雜，表自然也很繁雜，我們必須進行頻繁的進行資料庫查詢，這樣可能導致資料庫不堪重負，一個好的辦法就是將查詢後的資料放到記憶體中，下一次查詢直接從記憶體中取就好了。關於資料庫快取本篇不會展開。��

��瀏覽器的快取策略

快取的目標：

一個檢索請求的成功響應: 對於 GET請求，響應狀態碼為：200，則表示為成功。一個包含例如HTML文件，圖片，或者檔案的響應；
不變的重定向: 響應狀態碼：301；
可用快取響應：響應狀態碼：304，這個存在疑問，Chrome會快取304中的快取設定，Firefox；
錯誤響應: 響應狀態碼：404 的一個頁面；
不完全的響應: 響應狀態碼 206，只返回區域性的資訊；
除了 GET 請求外，如果匹配到作為一個已被定義的cache鍵名的響應；

以上，對於我們可以和應該快取的目標有個瞭解。��

瀏覽器對於快取的處理是根據第一次請求資源時返回的響應頭來確定的。

那麼瀏覽器怎麼確定一個資源該不該快取，如何去快取呢❓響應頭！響應頭！響應頭！重要的事情說三遍。✌️

我們看��：

Age:23146
Cache-Control:max-age=2592000
Date:Tue, 28 Nov 2017 12:26:41 GMT
ETag:W/"5a1cf09a-63c6"
Expires:Thu, 28 Dec 2017 05:27:45 GMT
Last-Modified:Tue, 28 Nov 2017 05:14:02 GMT
Vary:Accept-Encoding

1. 強快取階段

以上請求頭來自百度首頁某個CSS檔案的響應頭。我去除了一些和快取無關的欄位，只保留了以上部分。我們來分析下，Expires是HTTP/1.0中的定義快取的欄位，它規定了快取過期的一個絕對時間。Cache-Control:max-age=2592000是HTTP/1.1定義的關於快取的欄位，它規定了快取過期的一個相對時間。優先順序上當然是版本高的優先了，max-age > Expires。

這就是強快取階段，當瀏覽器再次試圖訪問這個CSS檔案，發現有這個檔案的快取，那麼就判斷根據上一次的響應判斷是否過期，如果沒過期，使用快取。載入檔案，OVER！✌️

Firefox瀏覽器表現為一個灰色的200狀態碼。

Chrome瀏覽器狀態碼錶現為:

200 (from disk cache)或是200 OK (from memory cache)

多說一點：關於快取是從磁碟中獲取還是從記憶體中獲取，查找了很多資料，得出了一個較為可信的結論：Chrome會根據本地記憶體的使用率來決定快取存放在哪，如果記憶體使用率很高，放在磁盤裡面，記憶體的使用率很高會暫時放在記憶體裡面。這就可以比較合理的解釋了為什麼同一個資源有時是from memory cache有時是from disk cache的問題了。

那麼當這個CSS檔案過期了怎麼辦?ETag和Last-Modified就該閃亮登場了。

先說Last-Modified，這個欄位是檔案最後一次修改的時間；

ETag呢？ETag是對檔案的一個標記，嗯，可以這麼說，具體生成方式HTTP並沒有給出一個明確的方式，所以理論上只要不會重複生成方式無所謂，比如對資源內容使用抗碰撞雜湊函式，使用最近修改的時間戳的雜湊值，甚至只是一個版本號。

2. 協商快取階段

利用這兩個欄位瀏覽器可以進入協商快取階段，當瀏覽器再次試圖訪問這個CSS檔案，發現快取過期，於是會在本次請求的請求頭裡攜帶If-Moified-Since和If-None-Match這兩個欄位，伺服器通過這兩個欄位來判斷資源是否有修改，如果有修改則返回狀態碼200和新的內容，如果沒有修改返回狀態碼304，瀏覽器收到200狀態碼，該咋處理就咋處理(相當於首次訪問這個檔案了)，發現返回304，於是知道了本地快取雖然過期但仍然可以用，於是載入本地快取。然後根據新的返回的響應頭來設定快取。(這一步有所差異，發現不同瀏覽器的處理是不同的，chrome會為304設定快取，firefox則不會)��

具體兩個欄位攜帶的內容如下(分別和上面的Last-Modified、ETag攜帶的值對應)：

If-Moified-Since: Tue, 28 Nov 2017 05:14:02 GMT
If-None-Match: W/"5a1cf09a-63c6"

到這協商快取結束。

3. 啟發式快取階段

我們把上面的響應頭改下：

Age:23146
Cache-Control: public
Date:Tue, 28 Nov 2017 12:26:41 GMT
Last-Modified:Tue, 28 Nov 2017 05:14:02 GMT
Vary:Accept-Encoding

發現沒？瀏覽器用來確定快取過期時間的欄位一個都沒有！那該怎麼辦？有人可能會說下次請求直接進入協商快取階段，攜帶If-Moified-Since唄，不是的，瀏覽器還有個啟發式快取階段��

根據響應頭中2個時間欄位 Date 和 Last-Modified 之間的時間差值，取其值的10%作為快取時間週期。

這就是啟發式快取階段。這個階段很容讓人忽視，但實際上每時每刻都在發揮著作用。所以在今後的開發過程中如果遇到那種預設快取的坑，不要叫囂，不要生氣，瀏覽器只是在遵循啟發式快取協議而已。

我畫了下面這張圖，來解釋瀏覽器整個快取策略的過程：

��對於快取策略介紹到這，接下來再細細分析不同的HTTP首部欄位的內容，以及它們之間的關係。

��HTTP中和快取相關的首部欄位

HTTP報文是什麼呢？就是HTTP報文，這是一個概念，主要由以下兩部分構成：

首部(header)：包含了很多欄位，比如：cookie、快取、報文大小、報文格式等等）；
主體(body)：HTTP請求真正要傳輸的部分，比如：一個HTML文件，一個js檔案；

以上我們知道瀏覽器對於快取的處理過程，也簡單的提到了幾個相關的欄位。��接下來我們具體看下這幾個欄位：

1. 通用首部欄位

欄位名稱	說明
Cache-Control	控制快取具體的行為
Pragma	HTTP1.0時的遺留欄位，當值為”no-cache”時強制驗證快取
Date	建立報文的日期時間(啟發式快取階段會用到這個欄位)

2. 響應首部欄位

欄位名稱	說明
ETag	伺服器生成資源的唯一標識
Vary	代理伺服器快取的管理資訊
Age	資源在快取代理中存貯的時長(取決於max-age和s-maxage的大小)

3. 請求首部欄位

欄位名稱	說明
If-Match	條件請求，攜帶上一次請求中資源的ETag，伺服器根據這個欄位判斷檔案是否有新的修改
If-None-Match	和If-Match作用相反，伺服器根據這個欄位判斷檔案是否有新的修改
If-Modified-Since	比較資源前後兩次訪問最後的修改時間是否一致
If-Unmodified-Since	比較資源前後兩次訪問最後的修改時間是否一致

4. 實體首部欄位

欄位名稱	說明
Expires	告知客戶端資源快取失效的絕對時間
Last-Modified	資源最後一次修改的時間

��瀏覽器快取控制

HTTP/1.1一共規範了47種首部欄位，而和快取相關的就有以上12個之多。接下來的兩個小節會一個一個介紹給大家。��

1. Cache-Control

通過cache-control的指令可以控制告訴客戶端或是伺服器如何處理快取。這也是11個欄位中指令最多的一個，我們先來看看請求指令：

指令	引數	說明
no-cache	無	強制源伺服器再次驗證
no-store	無	不快取請求或是響應的任何內容
max-age=[秒]	快取時長，單位是秒	快取的時長，也是響應的最大的Age值
min-fresh=[秒]	必需	期望在指定時間內響應仍然有效
no-transform	無	代理不可更改媒體型別
only-if-cached	無	從快取獲取
cache-extension	-	新的指令標記(token)

響應指令：

指令	引數	說明
public	無	任意一方都能快取該資源(客戶端、代理伺服器等)
private	可省略	只能特定使用者快取該資源
no-cache	可省略	快取前必須先確認其有效性
no-store	無	不快取請求或響應的任何內容
no-transform	無	代理不可更改媒體型別
must-revalidate	無	可快取但必須再向源伺服器進確認
proxy-revalidate	無	要求中間快取伺服器對快取的響應有效性再進行確認
max-age=[秒]	快取時長，單位是秒	快取的時長，也是響應的最大的Age值
s-maxage=[秒]	必需	公共快取伺服器響應的最大Age值
cache-extension	-	新指令標記(token

請注意no-cache指令很多人誤以為是不快取，這是不準確的，no-cache的意思是可以快取，但每次用應該去想伺服器驗證快取是否可用。no-store才是不快取內容。另外部分指令也可以組合使用，比如：

Cache-Control: max-age=100, must-revalidate, public

上面指令的意思是快取的有效時間為100秒，之後訪問需要向源伺服器傳送請求驗證，此快取可被代理伺服器和客戶端快取。

2. Pragma

這是HTTP/1.0裡面的一個欄位，但優先順序很高，測試發現，Chrome和Firefox中Pragma的優先順序高於Cache-Control和Expires，為了向下相容，這個欄位依然發揮著它的作用。��一般可能我們會這麼用：

<meta http-equiv="Pragma" content="no-cache">

Pragma屬於通用首部欄位，在客戶端上使用時，常規要求我們往html上加上上面這段meta元標籤（而且可能還得做些hack放到body後面去。

事實上這種禁用快取的形式用處很有限：

僅有IE才能識別這段meta標籤含義，其它主流瀏覽器僅能識別Cache-Control: no-store的meta標籤(見出處)
在IE中識別到該meta標籤含義，並不一定會在請求欄位加上Pragma，但的確會讓當前頁面每次都發新請求(僅限頁面，頁面上的資源則不受影響)。——淺談瀏覽器http的快取機制

讀者可以自行拷貝後面模擬服務端決策的程式碼進行測試。

服務端響應新增'Pragma': 'no-cache'，瀏覽器表現行為和強制重新整理類似。

3. Expires

這又是一個HTTP/1.0的欄位，上面也說過了定義的是快取到期的絕對時間。

同樣，我們也可以在html檔案裡直接使用:

<meta http-equiv="expires" content="Thu, 30 Nov 2017 11:17:26 GMT">

如果設定的是已經過去的時間會怎樣呢？YES！！！則重新整理頁面會重新發送請求。

Pragma禁用快取，如果又給Expires定義一個還未到期的時間，那麼Pragma欄位的優先順序會更高。��

��Expires有一個很大的弊端，就是它返回的是伺服器的時間，但判斷的時候用的卻是客戶端的時間，這就導致Expires很被動，因為使用者有可能改變客戶端的時間，導致快取時間判斷出錯，這也是引入Cache-Control:max-age指令的原因之一。

4. Last-Midified

接下來這幾個欄位都是校驗欄位，或者說是在協商快取階段發揮作用的欄位。第一個就是Last-modified，這個欄位不光協商快取起作用，在啟發式快取階段同樣起到至關重要的作用。

在瀏覽器第一次請求某一個URL時，伺服器端的返回狀態碼會是200，響應的實體內容是客戶端請求的資源，同時有一個Last-Modified的屬性標記此檔案在伺服器端最後被修改的時間。like this:

Last-Modified : Fri , 12 May 2006 18:53:33 GMT

If-Modified-Since

當瀏覽器第二次請求這個URL的時候，根據HTTP協議規定，瀏覽器會把第一次Last-Modified的值儲存在If-Modified-Since裡面傳送給服務端來驗證資源有沒有修改。like this:

If-Modified-Since : Fri , 12 May 2006 18:53:33 GMT

服務端通過If-Modified-Since欄位來判斷在這兩次訪問期間資源有沒有被修改過，從而決定是否返回完整的資源。如果有修改正常返回資源，狀態碼200，如果沒有修改只返回響應頭，狀態碼304，告知瀏覽器資源的本地快取還可用。

用途：

驗證本地快取是否可用

If-Unmodified-Since

這個欄位字面意思和If-Modified-Since相反，但處理方式並不是相反的。如果檔案在兩次訪問期間沒有被修改則返回200和資源，如果檔案修改了則返回狀態碼412(預處理錯誤)。

用途：

與含有 If-Range訊息頭的範圍請求搭配使用，實現斷點續傳的功能，即如果資源沒修改繼續下載，如果資源修改了，續傳的意義就沒有了。
POST、PUT請求中，優化併發控制，即當多使用者編輯用一份文件的時候，如果伺服器的資源已經被修改，那麼在對其作出編輯會被拒絕提交。

��Last-Modified有幾個缺點：沒法準確的判斷資源是否真的修改了，比如某個檔案在1秒內頻繁更改了多次，根據Last-Modified的時間(單位是秒)是判斷不出來的，再比如，某個資源只是修改了，但實際內容並沒有發生變化，Last-Modified也無法判斷出來，因此在HTTP/1.1中還推出了ETag這個欄位��

5. ETag

伺服器可以通過某種自定的演算法對資源生成一個唯一的標識(比如md5標識)，然後在瀏覽器第一次請求某一個URL時把這個標識放到響應頭傳到客戶端。伺服器端的返回狀態會是200。

ETag: abc-123456

ETag的值有可能包含一個 W/ 字首，來提示應該採用弱比較演算法（這個是畫蛇添足，因為 If-None-Match 用且僅用這一演算法）。��

If-None-Match

If-None-Match和If-Modified-Since同時存在的時候If-None-Match優先順序更高。

當瀏覽器第二次請求這個URL的時候，根據HTTP協議規定，瀏覽器回把第一次ETag的值儲存在If-None-Match裡面傳送給服務端來驗證資源有沒有修改。like this:

If-None-Match: abc-123456

Get請求中，當且僅當伺服器上沒有任何資源的ETag屬性值與這個首部中列出的相匹配的時候，伺服器端會才返回所請求的資源，響應碼為200。如果沒有資源的ETag值相匹配，那麼返回304狀態碼。

POST、PUT等請求改變檔案的請求，如果沒有資源的ETag值相匹配，那麼返回412狀態碼。

If-Match

在請求方法為 GET) 和 HEAD的情況下，伺服器僅在請求的資源滿足此首部列出的 ETag之一時才會返回資源。而對於 PUT或其他非安全方法來說，只有在滿足條件的情況下才可以將資源上傳。

用途：

For GET和 HEAD 方法，搭配 Range首部使用，可以用來保證新請求的範圍與之前請求的範圍是對同一份資源的請求。如果 ETag 無法匹配，那麼需要返回 416（範圍請求無法滿足) 響應。
對於其他方法來說，尤其是 PUT, If-Match 首部可以用來避免更新丟失問題。它可以用來檢測使用者想要上傳的不會覆蓋獲取原始資源之後做出的更新。如果請求的條件不滿足，那麼需要返回412(預處理錯誤) 響應。

當然和Last-Modified相比，ETag也有自己的缺點，比如由於需要對資源進行生成標識，效能方面就勢必有所犧牲。��

關於強校驗和弱校驗：

ETag 1	ETag 2	Strong Comparison	Weak Comparison
W/”1”	W/”1”	no match	match
W/”1”	W/”2”	no match	no match
W/”1”	“1”	no match	match
“1”	“1”	match	match

��服務端快取控制

當Expires和Cache-Control:max-age=xxx同時存在的時候取決於快取伺服器應用的HTTP版本。應用HTTP/1.1版本的伺服器會優先處理max-age，忽略Expires，而應用HTTP/1.0版本的快取伺服器則會優先處理Expires而忽略max-age。接下來看下和快取伺服器相關的兩個欄位。

6. Vary

Vary用來做什麼的呢？試想這麼一個場景：在某個網頁中網站提供給移動端的內容是不同的，怎麼讓快取伺服器區分移動端和PC端呢？不知道你是否注意，瀏覽器在每次請求都會攜帶UA欄位來表明來源，所以我們可以利用User-Agent欄位來區分不同的客戶端，用法如下：

Vary: User-Agent

再比如，源伺服器啟用了gzip壓縮，但使用者使用了比較舊的瀏覽器，不支援壓縮，快取伺服器如何返回？就可以這麼設定：

Vary: Accept-Encoding

當然，也可以這麼用：

Vary: User-Agent, Accept-Encoding

這意味著快取伺服器會以User-Agent和 Accept-Encoding兩個請求首部欄位來區分快取版本。根據請求頭裡的這兩個欄位來決定返回給客戶端什麼內容。

7. Age

這個欄位說的是資源在快取伺服器存在的時長，前面也說了Cache-Control: max-age=[秒]就是Age的最大值。

這個欄位存在的意義是什麼呢？用來區分請求的資源來自源伺服器還是快取伺服器的快取的。

��但得結合另一個欄位來進行判斷，就是Date，Date是報文建立的時間。

Date

如果按F5頻繁刷新發現響應裡的Date沒有改變，就說明命中了快取伺服器的快取以下面的一個響應為��：

Accept-Ranges: bytes
Age: 1016859
Cache-Control: max-age=2592000
Content-Length: 14119
Content-Type: image/png
Date: Fri, 01 Dec 2017 12:27:25 GMT
ETag: "5912bfd0-3727"
Expires: Tue, 19 Dec 2017 17:59:46 GMT
Last-Modified: Wed, 10 May 2017 07:22:56 GMT
Ohc-Response-Time: 1 0 0 0 0 0
Server: bfe/1.0.8.13-sslpool-patch

如上圖來自百度首頁某個圖片的響應欄位。我們可以看到Age=1016859，說明這個資源已經在快取伺服器存在了1016859秒。如果檔案被修改或替換，Age會重新由0開始累計。

Age訊息頭的值通常接近於0。表示此訊息物件剛剛從原始伺服器獲取不久；其他的值則是表示代理伺服器當前的系統時間與此應答訊息中的通用訊息頭 Date的值之差。

上面這個結論歸結為一個等式就是：

靜態資源Age + 靜態資源Date = 原服務端Date

��使用者操作行為對快取的影響

搜尋了很久有沒有關於這方面的權威總結，最後竟然在百度百科找到了也是很驚訝，我自己加了一條使用者強制重新整理操作瀏覽器的反應。強制重新整理，window下是Ctrl+F5,mac下就是command+shift+R操作了。:relieved:

操作	說明
開啟新視窗	如果指定cache-control的值為private、no-cache、must-revalidate,那麼開啟新視窗訪問時都會重新訪問伺服器。而如果指定了max-age值,那麼在此值內的時間裡就不會重新訪問伺服器,例如：Cache-control: max-age=5 表示當訪問此網頁後的5秒內不會去再次訪問伺服器.
在位址列回車	如果值為private或must-revalidate,則只有第一次訪問時會訪問伺服器,以後就不再訪問。如果值為no-cache,那麼每次都會訪問。如果值為max-age,則在過期之前不會重複訪問。
按後退按扭	如果值為private、must-revalidate、max-age,則不會重訪問,而如果為no-cache,則每次都重複訪問.
按重新整理按扭	無論為何值,都會重複訪問.（可能返回狀態碼：200、304，這個不同瀏覽器處理是不一樣的，FireFox正常，Chrome則會啟用快取(200 from cache)）
按強制重新整理按鈕	當做首次進入重新請求(返回狀態碼200)

:wink:如果想在瀏覽器點選“重新整理”按鈕的時候不讓瀏覽器去發新的驗證請求呢？辦法找到一個，知乎上面一個回答，在頁面載入完畢後通過指令碼動態地新增資源：

$(window).load(function() {
    var bg='http://img.infinitynewtab.com/wallpaper/100.jpg';
    setTimeout(function() {
        $('#bgOut').css('background-image', 'url('+bg+')');
    },0);
});

來自知乎

��HTML5的快取

這部分準備的說應該叫離線儲存。現在比較普遍用的是Appcache，但Appcache已經從web標準移除了，在可預見的未來裡，ServiceWorker可能會是一個比較適合的解決方案。

1. Appcache

這是HTML5的一個新特性，通過離線儲存達到使用者在沒有網路連線的情況下也能訪問頁面的功能。離線狀態下即使使用者點選重新整理都能正常載入文件。

使用方法如下，在HTML檔案中引入appcache檔案:

<!DOCTYPE html>
<html manifest="manifest.appcache">
<head>
  <meta charset="UTF-8">
  <title>***</title>
</head>
<body>
  <div id="root"></div>
</body>
</html>

��web 應用中的 manifest 特性可以指定為快取清單檔案的相對路徑或一個絕對 URL(絕對 URL 必須與應用同源)。快取清單檔案可以使用任意副檔名，但傳輸它的 MIME 型別必須為 text/cache-manifest。

注意：在 Apache 伺服器上，若要設定適用於清單(.appcache)檔案的 MIME 型別，可以向根目錄或應用的同級目錄下的一個 .htaccess 檔案中增加 AddType text/cache-manifest .appcache 。

CACHE MANIFEST
# 註釋：需要快取的檔案，無論線上與否，均從快取裡讀取
# v1 2017-11-30
# This is another comment
/static/logo.png

# 註釋：不快取的檔案，始終從網路獲取
NETWORK:
example.js

# 註釋：獲取不到資源時的備選路徑，如index.html訪問失敗，則返回404頁面
FALLBACK:
index.html 404.html

上面就是一個完整的快取清單檔案的示例。

注意：主頁一定會被快取起來的，因為AppCache主要是用來做離線應用的，如果主頁不快取就無法離線查看了，因此把index.html新增到NETWORK中是不起效果的。

實際上這個特性已經web標準中刪除，但現在為止還有很多瀏覽器支援它，所以這裡提一下。

你可以用最新的Firefox(版本 57.0.1)測試下，控制檯會有這麼一行字��：

程式快取 API（AppCache）已不贊成使用，幾天後將被移除。需離線支援請嘗試使用 Service Worker。

最新Chrome(版本 62.0.3202.94)倒是沒有這個警告。��

AppCache之所以不受待見我想了下面幾個原因：

一旦使用了manifest後，沒辦法清空這些快取，只能更新快取，或者得使用者自己去清空瀏覽器的快取；
假如更新的資源中有一個資源更新失敗了，那麼所有的資源就會全部更新失敗，將用回上一版本的快取；
主頁會被強制快取(使用了manifest的頁面)，並且無法清除；
appache檔案可能會無法被及時更新，因為各大瀏覽器對於appcache檔案的處理方式不同；
以上幾個弊端一旦出問題，會讓使用者抓狂更會讓開發者抓狂！

2. Service Worker

Service worker還是一個實驗性的功能，線上環境不推薦使用。��這裡大概介紹一下。

Service worker本質上充當Web應用程式與瀏覽器之間的代理伺服器。

��首先講個小故事：

我們都知道瀏覽器的js引擎處理js是單執行緒的，它就好像一個大Boss高高在上，同一個時間它只做一個事情(就是那麼傲嬌)，基於這個弊端，W3C(HR)給大Boss招聘了一個祕書(web worker)，大Boss可以把瑣碎的事情交給祕書web worker去做，做完了發個微信(postMessage)通知大Boss，大Boss通過onmessage來獲取祕書web worker做的事情的結果。傍晚時分，下班時間到！大Boss回家哄兒子了，祕書也出去約會去了，沒人加班了！這怎麼行！W3C(HR)又提出了招個程式��的想法的想法，OK，Service Worker應聘成功！於是，程式��就堅持在工作崗位上了，從此開啟沒完沒了的加班之路。總的來說這隻猿的工作是這樣的：

後臺資料同步
響應來自其它源的資源請求
集中接收計算成本高的資料更新，比如地理位置和陀螺儀資訊，這樣多個頁面就可以利用同一組資料
在客戶端進行CoffeeScript，LESS，CJS/AMD等模組編譯和依賴管理（用於開發目的）
後臺服務鉤子
自定義模板用於特定URL模式
效能增強，比如預取使用者可能需要的資源

注意：Service workers之所以優於以前同類嘗試（如上面提到的AppCache)），是因為它們無法支援當操作出錯時終止操作。Service workers可以更細緻地控制每一件事情。如何控制的呢？

Service workers利用了ES6中比較重要的特性Promise，並且在攔截請求的時候使用的是新的fetch API，之所以使用fetch就是因為fetch返回的是Promise物件。可以說Service workers重要組成部分就是三塊：事件、Promise和Fetch請求。OK，talk is cheap，show you the code。��

首先我們看下app.js檔案：告訴瀏覽器註冊某個JavaScript檔案為service worker，檢查service worker API是否可用，如果可用就註冊service worker：

//使用 ServiceWorkerContainer.register()方法首次註冊service worker。
if (navigator.serviceWorker) {
    navigator.serviceWorker.register('./sw.js', {scope: './'})
        .then(function (registration) {
            console.log(registration);
        })
        .catch(function (e) {
            console.error(e);
        });
} else {
    console.log('該瀏覽器不支援Service Worker');
}

再來看看具體作為service worker的檔案sw.js，例子如下：

const CACHE_VERSION = 'v1'; // 快取檔案的版本
const CACHE_FILES = [ // 需要快取的檔案
    './test.js',
    './app.js',
    'https://code.jquery.com/jquery-3.0.0.min.js'
];

self.addEventListener('install', function (event) { // 監聽worker的install事件
    event.waitUntil( // 延遲install事件直到快取初始化完成
        caches.open(CACHE_VERSION)
        .then(function (cache) {
            console.log('快取開啟');
            return cache.addAll(CACHE_FILES);
        })
    );
});

self.addEventListener('activate', function(event) {// 監聽worker的activate事件
    event.waitUntil(// 延遲activate事件直到
        caches.keys().then(function(keys) {
            return Promise.all(keys.map(function(key, i){
                if(key !== CACHE_VERSION){
                    return caches.delete(keys[i]); // 清除舊版本快取
                }
            }))
        })
    )
});

self.addEventListener('fetch', function(event) { // 擷取頁面的資源請求
    event.respondWith(
        caches.match(event.request).then(function(res) { // 判斷快取是否命中
            if (res) { // 返回快取中的資源
                return res;
            }
            _request(event); // 執行請求備份操作
        })
    )
});

function _request(event) {
    var url = event.request.clone();
    return fetch(url).then(function(res) {// 使用fetch請求線上資源
        // 錯誤判斷
        if (!res || res.status !== 200 || res.type !== 'basic') {
            return res;
        }

        var response = res.clone(); // 建立了一個響應物件的克隆,儲藏在一個單獨的變數中

        caches.open(CACHE_VERSION).then(function(cache) {// 快取從線上獲取的資源
            cache.put(event.request, response);
        });
        return res;
    })
}

清除一個Service Worker也很簡單：

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js', {scope: './'}).then(function(registration) {
    // registration worked
    console.log('Registration succeeded.');
    registration.unregister().then(function(boolean) {
      // if boolean = true, unregister is successful
    });
  }).catch(function(error) {
    // registration failed
    console.log('Registration failed with ' + error);
  });
};

相對AppCache來說，Service Worker的API增多了不少，用法也更復雜了些，但看得出Service Worker才是未來，對於web app來說，更是如虎添翼。現在支援Service Worker的瀏覽器除了Chrome和Firefox，最近新添一個生力軍——Safari也支援Service Worker了。期待它在未來大放異彩吧。��

��模擬實現服務端決策

如下，使用node原生程式碼簡單的模擬下伺服器傳送響應的過程，包括對於協商快取的處理過程：

var http = require('http');
var fs = require('fs');
var url = require('url');

process.env.TZ = 'Europe/London';

let tag = '123456';

http.createServer( function (request, response) {  

   var pathname = url.parse(request.url).pathname;

    console.log("Request for " + pathname + " received.");
    const fileMap = {
       'js': 'application/javascript; charset=utf-8',
       'html': 'text/html',
       'png': 'image/png',
       'jpg': 'image/jpeg',
       'gif': 'image/gif',
       'ico': 'image/*',
       'appcache': 'text/cache-manifest'
    }
    fs.readFile(pathname.substr(1), function (err, data) {
        if (request.headers['if-none-match'] === tag) {
            response.writeHead(304, {
                'Content-Type': fileMap[pathname.substr(1).split('.')[1]],
                'Expires': new Date(Date.now() + 30000),
                'Cache-Control': 'max-age=10, public',
                'ETag': tag,
                'Last-Modified': new Date(Date.now() - 30000),
                'Vary': 'User-Agent'
            });
       } else {             
            response.writeHead(200, {
                'Content-Type': fileMap[pathname.substr(1).split('.')[1]],
                'Cache-Control': 'max-age=10, public',
                'Expires': new Date(Date.now() + 30000),
                'ETag': tag,
                'Last-Modified': new Date(Date.now() - 30000),
                'Vary': 'User-Agent'
            });
            response.write(fs.readFileSync(pathname.substr(1)));        
        }
        response.end();
    });   
}).listen(8081);

如上程式碼。如果你沒使用過node，拷貝下程式碼存為file.js，安裝node，命令列輸入node file.js，可以在同目錄下建立index.html檔案，在html檔案中引用一些圖片，CSS等檔案，瀏覽器輸入localhost:8081/index.html進行模擬。��

��關於快取的一些問答

1. 問題：請求被快取，導致新程式碼未生效

解決方案:

服務端響應新增Cache-Control:no-cache,must-revalidate指令；
修改請求頭If-modified-since:0或If-none-match；

2. 問題：服務端快取導致原生代碼未更新

解決方案：

合理設定Cache-Control:s-maxage指令；
設定Cache-Control:private指令，防止代理伺服器快取資源；
CDN快取可以使用管理員設定的快取重新整理介面進行重新整理；

3. 問題： Cache-Control: max-age=0 和 no-cache有什麼不同

回答：

max-age=0和no-cache應該是從語氣上不同。max-age=0是告訴客戶端資源的快取到期應該向伺服器驗證快取的有效性。而no-cache則告訴客戶端使用快取前必須向伺服器驗證快取的有效性。

後記

參考文件：

快取詳解

前言

正文

��快取的種類

1. 瀏覽器快取

2. 代理伺服器快取

3. 閘道器快取

4. 資料庫快取

��瀏覽器的快取策略

1. 強快取階段

2. 協商快取階段

3. 啟發式快取階段

��HTTP中和快取相關的首部欄位

1. 通用首部欄位

2. 響應首部欄位

3. 請求首部欄位

4. 實體首部欄位

��瀏覽器快取控制

1. Cache-Control

2. Pragma

3. Expires

4. Last-Midified

If-Modified-Since

If-Unmodified-Since

5. ETag

If-None-Match

If-Match

��服務端快取控制

6. Vary

7. Age

Date

��使用者操作行為對快取的影響

��HTML5的快取

1. Appcache

2. Service Worker

��模擬實現服務端決策

��關於快取的一些問答

後記

相關推薦