客戶端瀏覽器的緩存問題排查

問題描述

最近對文件上傳功能進行了優化改版，上線以後有同事反饋出來，自從上線以後所上傳的圖片，均沒有設置瀏覽器端緩存，致使客戶端每次都要去請求服務器上的圖片資源，會致使頁面加載速度變慢，用戶體驗很差諸類問題。以前從未接觸過此類問題趕緊查閱了瀏覽器緩存的相關知識，並對問題進行了修復，現將一些所學進行整理概括。

HTTP的緩存機制

在Chrom瀏覽器中打開一張圖片，好比華爲新款P30手機，選擇一張圖片（https://res9.vmallres.com/shopdc/pic/e769ea22-d741-45fd-94e8-1b39deb19719.jpg），查看它的網絡請求信息。

第一次請求

 

第二次請求

 

強緩存

能夠理解爲無須驗證的緩存策略。對強緩存來講，響應頭中有兩個字段 Expires/Cache-Control 來代表規則。

Expires

Expires 指緩存過時的時間，超過了這個時間點就表明資源過時。有一個問題是因爲使用具體時間，若是時間表示出錯或者沒有轉換到正確的時區均可能形成緩存生命週期出錯。

Cache-Control

Cache-Control 能夠由多個字段組合而成，主要有如下幾個取值：

Cache-Control: max-age =? : 指定一個時間長度，在這個時間段內緩存是有效的，單位是s。例如設置 Cache-Control:max-age=31536000，也就是說緩存有效期爲（31536000 / 24 / 60 * 60）天。

Cache-Control: no-cache強制全部緩存了該響應的用戶，在使用已緩存的數據前，發送帶驗證器的請求到服務器。不是字面意思上的不緩存。

Cache-Control: no-store纔是真正的不緩存數據到本地

Cache-Control: public能夠被全部用戶緩存（多用戶共享），包括終端和CDN等中間代理服務器

Cache-Control: private只能被終端瀏覽器緩存（並且是私有緩存），不容許中繼緩存服務器進行緩存

協商緩存

緩存的資源到期了，並不意味着資源內容發生了改變，若是和服務器上的資源沒有差別，實際上沒有必要再次請求。客戶端和服務器端經過某種驗證機制驗證當前請求資源是否可使用緩存。

瀏覽器第一次請求數據以後會將數據和響應頭部的緩存標識存儲起來。再次請求時會帶上存儲的頭部字段，服務器端驗證是否可用。若是返回 304 Not Modified，表明資源沒有發生改變可使用緩存的數據，獲取新的過時時間。反之返回 200 就至關於從新請求了一遍資源並替換舊資源。

Last-Modified與If-Modified-Since

Last-modified: 服務器端資源的最後修改時間，響應頭部會帶上這個標識。第一次請求以後，瀏覽器記錄這個時間，再次請求時，請求頭部帶上 If-Modified-Since 即爲以前記錄下的時間。服務器端收到帶 If-Modified-Since 的請求後會去和資源的最後修改時間對比。若修改過就返回最新資源，狀態碼 200，若沒有修改過則返回 304。

ETag與If-None-Match

由服務器端上生成的一段 hash 字符串，第一次請求時響應頭帶上 ETag: abcd，以後的請求中帶上 If-None-Match: abcd，服務器檢查 ETag，返回 304 或 200。

 

緩存流程

用戶行爲與緩存的使用方式

 

參考資料：

https://zhuanlan.zhihu.com/p/29750583

http://www.javashuo.com/article/p-kqyakzsl-cu.html

http://www.cnblogs.com/shixiaomiao1122/p/7591556.html