稍微解釋一下：
1.Cache-
max-age（單位為s）指定設置緩存最大的有效時間，定義的是時間長短。當瀏覽器向服務器發送請求后，在max-age這段時間里瀏覽器就不會再向服務器發送請求了。我們來找個資源看下。比如QQ推廣上的css資源，max-age=3600，也就是說緩存有效期為3600秒（也就是1h）。于是在1天內都會使用這個版本的資源，即使服務器上的資源發生了變化，瀏覽器也不會得到通知。max-age會覆蓋掉，后面會有討論
s-（單位為s）同max-age，只用于共享緩存（比如CDN緩存）。比如，當s-=60時，在這60秒中，即使更新了CDN的內容，瀏覽器也不會進行請求。也就是說max-age用于普通緩存，而s-用于代理緩存。如果存在s-，則會覆蓋掉max-age和 。
指定響應會被緩存，并且在多用戶間共享。也就是下圖的意思。如果沒有指定還是，則默認為。
響應只作為私有的緩存（見下圖），不能在用戶間共享。如果要求HTTP認證，響應會自動設置為
no-cache指定不緩存響應，表明資源不進行緩存，但是設置了 no-cache 之后并不代表瀏覽器不緩存，而是在獲取緩存前要向服務器確認資源是否被更改。因此有的時候只設置 no-cache 防止緩存還是不夠保險，還可以加上 指令，將過期時間設為過去的時間。
no-store絕對禁止緩存緩存文件是什么意思，一看就知道如果用了這個命令當然就是不會進行緩存啦～每次請求資源都要從服務器重新獲取。
must-指定如果頁面是過期的，則去服務器進行獲取。這個指令并不常用，就不做過多的討論了。
cache-的種類這么多，然而怎么使用它們呢，參看下圖：
2.
緩存過期時間，用來指定資源到期的時間，是服務器端的具體的時間點。也就是說， =max-age + 請求時間 ，需要和Last-結合使用。但在上面我們提到過，cache-的優先級更高。是Web服務器響應消息頭字段，在響應http請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據，而無需再次請求。
3.Last- & If--since
服務器端文件的最后修改時間，需要和cache-共同使用，是檢查服務器端資源是否更新的一種方式。當瀏覽器再次進行請求時，會向服務器傳送If--Since報頭，詢問Last-時間點之后資源是否被修改過。如果沒有修改，則返回碼為304，使用緩存；如果修改過，則再次去服務器請求資源，返回碼和首次請求相同為200，資源為服務器最新資源。
4.Etag & & If-None-Match
根據實體內容生成一段hash字符串，標識資源的狀態，由服務端產生。瀏覽器會將這串字符串傳回服務器，驗證資源是否已經修改，如果沒有修改，過程如下：
2.2.3 緩存報頭種類與優先級1.Cache-與
Cache-與 的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到服務器取數據。只不過 Cache-的選擇更多，設置更細致，如果同時設置的話，其優先級高于 。
2.Last-與ETag
你可能會覺得使用 Last- 已經足以讓瀏覽器知道本地的緩存副本是否足夠新，為什么還需要 Etag（實體標識）呢？HTTP1.1中Etag的出現主要是為了解決幾個 Last- 比較難解決的問題：
Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的唯一標識符，能夠更加準確的控制緩存。Last-與ETag是可以一起使用的，服務器會優先驗證ETag緩存文件是什么意思，一致的情況下，才會繼續比對Last-，最后才決定是否返回304。Etag的服務器生成規則和強弱Etag的相關內容可以參考，《互動百科-Etag》和《HTTP 》，這里不再深入。
3.Last-/ETag 與 Cache-/
配置 Last-/ETag的情況下，瀏覽器再次訪問統一URI的資源，還是會發送請求到服務器詢問文件是否已經修改，如果沒有，服務器會只發送一個304回給瀏覽器，告訴瀏覽器直接從自己本地的緩存取數據；如果修改過那就整個數據重新發給瀏覽器；
Cache-/則不同，如果檢測到本地的緩存還是有效的時間范圍內，瀏覽器直接使用本地副本，不會發送任何請求。兩者一起使用時， Cache-/的優先級要高，即當本地副本根據 Cache-/發現還在有效期內時，則不會再次發送請求去服務器詢問修改時間 Last-或實體標識 Etag了。
一般情況下，兩者會配合一起使用，因為即使服務器設置緩存時間, 當用戶點擊“刷新”按鈕時，瀏覽器會忽略緩存繼續向服務器發送請求，這時 Last-/ETag將能夠很好利用304，從而減少響應開銷。
2.2.4 哪些請求不能被緩存？
無法被瀏覽器緩存的請求：
3. 使用緩存流程
一個用戶發起一個靜態資源請求的時候，瀏覽器會通過以下幾步來獲取并展示資源：
緩存行為主要由緩存策略決定，而緩存策略由內容擁有者設置。這些策略主要通過特定的HTTP頭部來清晰地表達。
以上過程也可以被概括為三個階段：
本地緩存階段：先在本地查找該資源，如果有發現該資源，而且該資源還沒有過期，就使用這一個資源，完全不會發送http請求到服務器；
協商緩存階段：如果在本地緩存找到對應的資源，但是不知道該資源是否過期或者已經過期，則發一個http請求到服務器，然后服務器判斷這個請求，如果請求的資源在服務器上沒有改動過，則返回304，讓瀏覽器使用本地找到的那個資源；
緩存失敗階段：當服務器發現請求的資源已經修改過，或者這是一個新的請求(在本來沒有找到資源)，服務器則返回該資源的數據，并且返回200， 當然這個是指找到資源的情況下，如果服務器上沒有這個資源，則返回404。
4.用戶操作行為與緩存的關系
用戶在使用瀏覽器的時候，會有各種操作，比如輸入地址后回車，按F5刷新等，這些行為會對緩存有什么影響呢？
通過上表我們可以看到，當用戶在按 F5進行刷新的時候，會忽略/Cache-的設置，會再次發送請求去服務器請求，而Last-/Etag還是有效的，服務器會根據情況判斷返回304還是200；
而當用戶使用 Ctrl+F5進行強制刷新的時候，只是所有的緩存機制都將失效，重新從服務器拉去資源。
5. 如何從緩存角度改善站點
— 網上的帖子大多深淺不一，甚至有些前后矛盾，在下的文章都是學習過程中的總結，如果發現錯誤，歡迎留言指出~
參考：
Web緩存機制系列：
淺談web緩存：
Web前后端緩存技術：