強制快取：
當瀏覽器去請求某個檔案的時候，服務端就在respone header裡面對該檔案做了快取配置。快取的時間、快取型別都由服務端控制
expires：失效時間（伺服器時間與客戶端時間有偏差時，就可能會導致快取失效，比如使用者隨意修改了本地時間）
http1.1新增cache-control
1.cache-control: max-age=***x，public
客戶端和**伺服器都可以快取該資源；
客戶端在***秒的有效期內，如果有請求該資源的需求的話就直接讀取快取,statu code:200 ，如果使用者做了重新整理操作，就向伺服器發起http請求
2.cache-control: max-age=***x，private
只讓客戶端可以快取該資源；**伺服器不快取
客戶端在***秒內直接讀取快取,statu code:200
3.cache-control: max-age=***x，immutable
客戶端在***秒的有效期內，如果有請求該資源的需求的話就直接讀取快取,statu code:200 ，即使使用者做了重新整理操作，也不向伺服器發起http請求
4.cache-control: no-cache
跳過設定強快取，但是不妨礙設定協商快取；一般如果你做了強快取，只有在強快取失效了才走協商快取的，設定了no-cache就不會走強快取了，每次請求都回詢問服務端。
5.cache-control: no-store
不快取，這個會讓客戶端、伺服器都不快取，也就沒有所謂的強快取、協商快取了。
expires和cache-control可以在服務端配置為同時啟用，同時啟用的時候cache-control優先順序更高
協商快取
強快取就是給資源設定個過期時間，客戶端每次請求資源時都會看是否過期；只有在過期後才會去詢問伺服器，此時可用協商快取
response header（request header）
etag（if-none-match）：檔案hash值
last-modified（if-modified-since）：檔案的修改時間，精確到秒
發請求–>看資源是否過期–>過期–>請求伺服器–>伺服器對比資源是否真的過期–>沒過期–>返回304狀態碼–>客戶端用快取的老資源
發請求–>看資源是否過期–>過期–>請求伺服器–>伺服器對比資源是否真的過期–>過期–>返回200狀態碼–>客戶端如第一次接收該資源一樣，記下它的cache-control中的max-age、etag、last-modified等。
為什麼要有etag？（http1.1新增）
（1）一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get；
（2）某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了n次)，if-modified-since能檢查到的粒度是秒級的，這種修改無法判斷(或者說unix記錄mtime只能精確到秒)；
（3）某些伺服器不能精確的得到檔案的最後修改時間。
last-modified 和 etag同樣可以同時配置，伺服器會優先驗證etag，一致的情況下，才會繼續比對last-modified，最後才決定是否返回304。
強快取與協商快取
協商快取 優先順序區別 瀏覽器快取包含兩種方式 強快取與協商快取 在第一次請求資源時，伺服器返回所請求資源與有效時間,瀏覽器將其快取在本地，在第二次請求該資源時，瀏覽器判斷該資源是否在有效期中，如果在有效期就直接呼叫該資源，不向服務端發起請求。expires expires是http1.0的規範，它...
強快取 協商快取
強快取 客戶端第一次向伺服器請求資源時，伺服器返回某個資源的同時，新增某些頭部資訊，告訴客戶端將資源儲存在本地，並在未來的某個時點之前再次請求這個資源時，直接從本地獲取就可以了。字段控制 瀏覽器再次請求這個資源時，會先從快取中找到這個資源，然後獲取expires時間與當前的請求時間比較，如果expi...
強快取和協商快取
對於一次已經有快取存在的請求來說 即之前已經發過針對這個資源的請求，在本地已經有快取 如果發起請求，那麼 首先會去找到快取資源的響應頭中的expires 過期時間 和cache control 控制快取的失效性 來判斷當前是否直接使用快取，如果當前時間還在expires之前，即快取仍未失效的情況下，...