前端緩存的一些認識

前言

本文主要內容爲我對前端緩存的一些見解，和一些服務器配置的運用。相信你們都有了解過雅虎的35條前端優化法則吧，前端緩存也是前端優化當中的必不可少的一部分，雅虎推薦爲"Add an Expires or a Cache-Control Header"，但是對這2個http header 咱們又知道多少呢。

#expires

HTTP 1.0 的header，nginx對expires有如下的一些配置：

expires    24h;
expires    modified +24h;
expires    @24h;
expires    0;
expires    -1;
#Thu, 01 Jan 1970 00:00:01 GMT
expires    epoch;
expires    $expires;
add_header Cache-Control private;複製代碼

當咱們對服務器資源設置expires時，就會告訴瀏覽器（或代理）這個資源咱們要多久到期,以下圖的響應頭

響應頭

)
這時瀏覽器就會在下次請求該資源時，首先會判斷是否在有效期內：是，就直接從本地緩存讀取；否，請求頭中攜帶if-modified-since，這個請求頭的值就是上次響應頭中的的last-modified，這時服務器會與當前資源的修改時間進行比較，看看last-modified是否在修改時間以前：是，響應304 not modified，瀏覽器就會從本地讀取，而不須要再次下載資源了；否，就說明服務器資源變動過，返回200，body中爲此資源內容，瀏覽器須要從新下載。這就是完整的緩存策略。

---

#cache-control

HTTP1.1 定義的規則
與expires相似，其對應關係爲

expires --- cache-control
last-modified --- etag
if-modified-since --- if-match複製代碼

功能相似，取值稍有不一樣

客戶端（或代理）請求指令

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>] //代表客戶端願意接收一個已通過期的資源。 可選的設置一個時間(單位秒)，表示響應不能超過的過期時間。
Cache-Control: min-fresh=<seconds> //表示客戶端但願在指定的時間內獲取最新的響應。
Cache-control: no-cache 
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached //代表若是緩存存在，只使用緩存，不管原始服務器數據是否有更新。複製代碼

服務器響應指令

Cache-control: must-revalidate //緩存必須在使用以前驗證舊資源的狀態，而且不可以使用過時資源。
Cache-control: no-cache //強制全部緩存了該響應的緩存用戶，在使用已存儲的緩存數據前，發送帶驗證器的請求到原始服務器
Cache-control: no-store
Cache-control: no-transform
Cache-control: public //代表響應能夠被任何對象（包括：發送請求的客戶端，代理服務器，等等）緩存。
Cache-control: private //代表響應只能被單個用戶緩存，不能做爲共享緩存（即代理服務器不能緩存它）。
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds> //設置緩存存儲的最大週期，超過這個時間緩存被認爲過時(單位秒)。
Cache-control: s-maxage=<seconds> //覆蓋max-age 或者 Expires 頭，可是僅適用於共享緩存(好比各個代理)，而且私有緩存中它被忽略。複製代碼

那麼no-cache 和 no-store 有什麼關係呢？

相同點：
客戶端每次請求都會與服務器創建鏈接
不一樣點：
no-cache,客戶端會緩存資源，再次請求時會與對原始服務器上的資源進行驗證，未更改->304，已更改->200；
no-store，客戶端不會緩存資源，每次請求都從新下載原始服務器資源，對應響應狀態碼 200