1、伺服器會存在大量重複請求
比如我們每次重新整理頁面的時候都會傳送一次請求到伺服器，而多次請求的引數和響應的內容都完全一致，其實這種請求完全就是多餘的，我們完全可以就用上一次的響應內容。
2、提高響應的速度
對於重複的請求，我們將響應內容儲存到本地，下一次請求時可以直接返回而無需請求伺服器，那麼會提高響應的速度，增強使用者體驗
3、提高伺服器的吞吐量
如果我們能夠減少對伺服器傳送重複的請求，那麼伺服器就有更多的時間和資源去處理那些真正有效的請求了，無疑是會增大我們伺服器的吞吐量的。
快取雖然可以伺服器的吞吐量和請求的響應速度，但是快取並不適用於所有情況，用的不好的，反而會使使用者體驗變得很差，因此我們需要針對不同的請求制定不同的快取策略。
快取策略我們可以使用請求頭中的cache-control字段進行設定，取值主要有以下幾種：
指令作用
private
快取響應指令，表示只對當前的服務提供快取服務，對於其他使用者的請求，快取伺服器不會返回快取
public
與private對立，表示其他客戶也可以利用快取
max-age = time
請求快取過期的時間小於max-age指定的時間，客戶端都可以接受快取；作為相應的頭部欄位則表示指定的時間內不再向服務發起資源有效性確認，而指定的時間就是快取存在的最大時間。
s-max-age = time
僅在**伺服器中生效，覆蓋 max-age 效果。只限於供多位使用者使用的公共快取伺服器
no-store
不快取響應。
no-cache
快取，但快取立即失效，強制向伺服器再驗證一次，配合etag使用。
max-stable = time
在 time 時間內，即使快取失效，也使用快取。
min-fresh = time
要求返回至少還沒過指定時間的快取
指令可以組合使用，使用可以遵從一下邏輯：
注意：快取失效並不意味著清楚快取，只是快取失效後需要向伺服器發起協商，通過協商結果決定是否繼續使用快取。
存在這樣的情況：瀏覽器的快取失效後，向伺服器發起請求，但是請求返回的內容還是一樣的。
在這種情況下，我們其實可以直接告訴瀏覽器繼續用本地的快取就可以了，並且重新整理快取的時間，這樣做可以避免再在伺服器走一遍完整的流程，如果這個請求還是比較耗時的操作，那麼我們可以進一步提高響應的效率。
我們通常也是這麼做的，我們通常會在瀏覽器第一次請求某個資源的時候，根據資源的內容生成識別符號，通過報文頭etag返回給瀏覽器。在快取失效後瀏覽器會向伺服器發起請求，並且攜帶上etag（通過if-none-match給服伺服器etag的資訊），伺服器收到請求後判斷etag是否有效
優先使用etag進行判斷，如果沒有etag，就判斷last-modified（資源最後被修改的時間），客戶端傳送的匹配資源最後修改時間的識別符號（若if-modified-since晚於last-modified則證明資源是有效的）
協商機制，也就是比較last-modified和etag到服務端，若服務端判斷沒變化則304不返回資料，否則200返回資料
下面是流程圖展示：
f5重新整理或command+r重新整理:去掉cache-control中的max-age或直接設定max-age為0，然後進入快取協商邏輯
ctrl+f5或commond+shift+r重新整理:去掉cache-control和協商頭，強制重新整理
瀏覽器快取策略
1.三種區別在哪 from memory cache 字面理解是從記憶體中，其實也是字面的含義，這個資源是直接從記憶體中拿到的，不會請求伺服器一般已經載入過該資源且快取在了記憶體當中，當關閉該頁面時，此資源就被記憶體釋放掉了，再次重新開啟相同頁面時不會出現from memory cache的情況 f...
瀏覽器快取詳解
報文頭里的一些關鍵資訊 e xpires http1.0 中的標準，表明過期時間，注意此處的時間都是指的是伺服器的時間。cache control http1.1 中的標準，可以看成是 expires 的補充。使用的是相對時間的概念。cache control的屬性 max age 設定快取的最大的...
瀏覽器快取詳解
第一次請求了 100 個檔案,再次訪問的時候,如果全部重新請求,非常浪費時間,也很笨拙.分析 因為有些檔案,在使用者的多次請求中,都是相同的,如果多次請求都重複請求這個檔案,無疑是一種浪費.那麼就想到了快取 把資源快取到本地,再次請求的時候直接使用本地的快取檔案.走極端 把所有的檔案都快取起來.分析...