一、強緩存
當瀏覽器請求某個資源時，服務端會在response header中對此資源做緩存配置，緩存的時間和類型都由服務端配置。
response header的cache-control，常見的設置有max-age,public,immutable.private,no-cache,no-store
如下圖cache-controle的設置，其中：
max-age表示緩存的時間是315360000秒（10年）；
public表示可被客戶端或者代理服務（nginx）器緩存（與其對應的是private，只可以被客戶端緩存）；
immutable表示資源在設定的時間內(nèi)永遠不變，即使刷新瀏覽器也不會重新請求該資源（相反如果沒此屬性，當用戶刷新頁面時，會重新發(fā)送請求，獲取該資源，這就是額外的請求消耗了）
1、cache-control: max-age=xxxx，public
客戶端和代理服務器都可以緩存該資源；
客戶端在xxx秒的有效期內(nèi)，如果有請求該資源的需求的話就直接讀取緩存,statu code:200 ，如果用戶做了刷新操作，就向服務器發(fā)起http請求
2、cache-control: max-age=xxxx，private
只讓客戶端可以緩存該資源；代理服務器不緩存
客戶端在xxx秒內(nèi)直接讀取緩存,statu code:200
3、cache-control: max-age=xxxx，immutable
客戶端在xxx秒的有效期內(nèi)，如果有請求該資源的需求的話就直接讀取緩存,statu code:200 ，即使用戶做了刷新操作，也不向服務器發(fā)起http請求
4、cache-control: no-cache
跳過設置強緩存，但是不妨礙設置協(xié)商緩存；一般如果你做了強緩存，只有在強緩存失效了才走協(xié)商緩存的，設置了no-cache就不會走強緩存了，每次請求都回詢問服務端。
5、cache-control: no-store
不緩存，這個會讓客戶端、服務器都不緩存，也就沒有所謂的強緩存、協(xié)商緩存了。
二、協(xié)商緩存
某天客戶端發(fā)現(xiàn)資源過期，需要重新請求服務器，這時請求的過程就可以設置協(xié)商緩存。
協(xié)商緩存的設置：
response header :
etag:5c20abbd-e2e8(文件的唯一標識，就是文件的hash)
last-modified:Mon, 24 Dec 2018 09:49:49 GMT(文件的最近更新時間，精確到秒)
流程：
注意：response header中的etag、last-modified在客戶端重新向服務端發(fā)起請求時，會在request header中換個key名：
response header(request header)：
etag(if-none-matched)
last-modified(if-modified-since)
為什么要有etag？
你可能會覺得使用last-modified已經(jīng)足以讓瀏覽器知道本地的緩存副本是否足夠新，為什么還需要etag呢？HTTP1.1中etag的出現(xiàn)（也就是說，etag是新增的，為了解決之前只有If-Modified的缺點）主要是為了解決幾個last-modified比較難解決的問題：
1、一些文件也許會周期性的更改，但是他的內(nèi)容并不改變(僅僅改變的修改時間)，這個時候我們并不希望客戶端認為這個文件被修改了，而重新get；
2、某些文件修改非常頻繁，比如在秒以下的時間內(nèi)進行修改，(比方說1s內(nèi)修改了N次)，if-modified-since能檢查到的粒度是秒級的，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒)；
3、某些服務器不能精確的得到文件的最后修改時間。
