協商快取
禁用快取
指的是瀏覽器第一次請求資源時，瀏覽器快取在本地，並設定時間，如果在這個時間內再次請求，便會讀取快取的資源。對應策略為expires 和 cache-control，cache-control的優先順序高於expires。強制快取不會請求伺服器。
expires
我們用pragma來禁用快取，自然也需要有個東西來啟用快取和定義快取時間，expires就是做這件事的首部字段。
expires的值對應乙個gmt（格林尼治時間），比如「mon, 22 jul 2002 11:12:01 gmt」來告訴瀏覽器資源快取過期時間，如果還沒過該時間點則不發請求。
cache-control
cache-control也是乙個通用首部字段，這意味著它能分別在請求報文和響應報文中使用。
請求報文中可選字段：
響應報文中可選字段：
若報文中同時出現了 pragma、expires 和 cache-control，會以 cache-control 為準
指的是檔案最後修改時間是否相同或伺服器判斷檔案是否被修改，來決定是否取快取資源。對應策略為etag 和 last-modified.
last-modified
last-modified 是檢驗檔案的最後修改時間是否與伺服器上的檔案相同，若一致，返回304狀態嗎， 否則返回412
last-modified 會有一些問題， 當檔案的內容未修改，但是實際內容沒變，會導致重新讀取返回整個檔案。
etag
為了解決last-modified不准的問題，http1.1 版本還推出了etag首部字段。
伺服器會通過某種演算法，給資源計算得出乙個唯一標誌符（比如md5標誌），在把資源響應給客戶端的時候，會在實體首部加上「etag: 唯一識別符號」一起返回給客戶端。
客戶端會保留該 etag 字段，並在下一次請求時將其一並帶過去給伺服器。伺服器只需要比較客戶端傳來的etag跟自己伺服器上該資源的etag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。
如果伺服器發現etag匹配不上，那麼直接以常規get 200回包形式將新的資源（當然也包括了新的etag）發給客戶端；如果etag是一致的，則直接返回304知會客戶端直接使用本地快取即可。
if-none-match: etag-value
告訴伺服器如果未匹配上資源，則需重發的資源，並返回304狀態碼
if-match: etag-value
告訴伺服器如果沒有匹配到etag，或者收到了「*」值而當前並沒有該資源實體，則應當返回412(precondition failed) 狀態碼給客戶端。否則伺服器直接忽略該欄位。
etag 的優先順序比last-modified的高
可以使用http1.0的標準 請求頭上新增 program：no-cache，或者設定expires：no-cache; 或者 cache-control的max-age 設定乙個過期時間。
pragma
當該字段值為「no-cache」的時候（事實上現在rfc中也僅標明該可選值），會知會客戶端不要對該資源讀快取，即每次都得向伺服器發一次請求才行。
前端快取之HTTP快取
說真的，當自己還很小白的時候，明明修改了js的內容了，但是就是沒有載入成功，那時候感覺好神奇，好沒道理。後來知道了這是因為快取的原因。說實話，現在基於各種框架的開發，基本上沒有在業務 過程中關注快取的事情了，當然，不包括使用localstorage和cookie。今天自己學習了一些關於前端快取的東西...
前端快取總結 HTTP快取
在前端面試中，可能或多或少都會被提及快取問題，而這個問題大多數都是作為業務中不得不考慮的乙個效能優化點，如果平時沒有怎麼關注或是特意去了解這塊的童鞋們，可能就是不太了解其中的原由，那麼今天我們就這個快取問題來細細分析，幫助一些還不是太明白的或是剛入門的前端童鞋們梳理梳理，理解理解，那就話不多說，開始...
http前端快取 二
文章分為三部分，我們先來統一梳理一下乙個快取請求的過程，然後從請求頭以及響應頭快取相關字段進行解析，最後總結一下前端需要了解的對於快取的操作 一 快取過程 當乙個使用者發起乙個靜態資源請求的時候,瀏覽器會通過以下幾步來獲取資源 當第一次傳送請求，http返回200的狀態碼，如果沒有關閉快取請求的話 ...