摘要：整個請求響應鏈的緩存機制必須遵循的特別指令。基本的緩存機制就是由這些參數形成的。如果此文章中有什么問題的話，煩請一定要指出，謝謝參考資料緩存機制淺析移動端加載性能優化淺談瀏覽器的緩存機制

之前對http的緩存知識一知半解，只能說出個大概。和同事交流這塊內容時稍一深入探討就捉襟見肘，自慚形穢。故痛定思痛，花了一兩天時間去研究了下這塊內容，寫下這篇筆記方便以后的查詢與修正。

http的頭字段包括通用頭字段（general-header）、請求頭字段（request-header）、響應頭字段（response-header）以及實體頭字段（entity-header）。

我個人對實體頭字段這個說法有點陌生，所以查閱了相關資料：根據RFC-2616（7.1 Entity Header Fields）中的解釋是：實體頭字段（entity header）定義了實體主體（entity-body）的元信息，如果實體主體（entity-body）不存在，則表示http請求所標識的資源的元信息。

Entity-header fields define metainformation about the entity-body or,
   if no body is present, about the resource identified by the request.

Cache-Control: 整個請求響應鏈的緩存機制必須遵循的特別指令。這個指令是單向的，因為請求中該指令的效果和響應中的效果并不一樣。其值包括max-age，no-cache等。

The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain.   
Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.

Date: 請求或響應的時間和日期。(注：這里的日期格式使用的是GMT格式，即格林威治時間，要換算成北京時間的話要加上8小時)

Pragma：可被應用到整個請求響應鏈中的自定義設置，例如：Pragma: no-cache。

The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along the request/response chain.

If-Modified-Since: 如果從該參數指定的時間開始，請求并沒有被修改的話，服務器會返回304（not modified）狀態碼，而不是一個實體。

if the requested variant has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (not modified) response will be returned without any message-body.

If-Unmodified-Since: 如果從該參數指定的時間開始，請求并沒有被修改的話，服務器應該執行請求的操作。如果被修改過的話，服務器不執行操作病返回412（Precondition Failed）狀態碼

If the requested resource has not been modified since the time specified in this field, the server SHOULD perform the requested operation as if the If-Unmodified-Since header were not present.
If the requested variant has been modified since the specified time, the server MUST NOT perform the requested operation, and MUST return a 412 (Precondition Failed).

If-None-Match: 允許在對應的內容未被修改的情況下返回304未修改（ 304 Not Modified ）,判斷依據為客戶端該參數存儲的Etag值與服務器上存儲的Etag是否相匹配。（原文太長，暫時拿wiki百科來填坑）

If-Match: 僅當客戶端提供的實體與服務器上對應的實體相匹配時，才進行對應的操作。主要用作像 PUT 這樣的方法中，僅當從用戶上次更新某個資源以來，該資源未被修改的情況下，才更新該資源。如果不匹配，則返回412（Precondition Failed）狀態碼，該參數也會被忽略。（原文太長，暫時拿wiki百科來填坑）

ETag: 指定請求變量的當前實體Tag。該字段用來比較來自同一資源的變化的實體。(只是直譯，后面會有詳細解釋和用法)

The ETag response-header field provides the current value of the entity tag for the requested variant.

Expires: 指定過期時間。

The Expires entity-header field gives the date/time after which the response is considered stale.

Last-Modified: 指定了服務器認為資源最近一次修改的時間。

The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.

字段參數可能會有翻譯或者理解錯誤，請各位大大指出。

了解了參數的含義后，接下來就是看具體的緩存機制了。

Pragma在RFC1945文檔中只提供了“no-cache”值，當"no-cache"出現在請求消息中時，應用程序應當向原始服務器推送此請求，即使它已經在上次請求時已經緩存了一份拷貝。這樣將保證客戶端能接收到最權威的回應。它也用來在客戶端發現其緩存中拷貝不可用或過期時，對拷貝進行強制刷新。
（HTTP1.1會把請求中的pragma="no-cache"視為發送了Cache-Control: no-cache）

有Pragma用來禁用緩存的話，那就有Expires來設置緩存。
就如上文介紹所說，Expires是用來指定過期時間的，時間格式為GMT，如果客戶端時間沒有超過該時間點的話，則不發送請求。但是值得注意的是，Expires所定義的緩存時間是相對服務器上的時間而言的，如果客戶端的時間和服務器的時間不一致的話（例如用戶修改了系統時間），那么這個資源失效時間也沒有意義了。

http1.1新增了 Cache-Control 來定義緩存過期時間，若報文中同時出現了Expires 和 Cache-Control，會以 Cache-Control 為準。
如上文介紹所說，Cache-Control是通用頭部參數，格式為

"Cache-Control" ":" cache-directive

作為請求頭部時，cache-directive的可選值為：（圖片來自網絡）

作為響應頭部時，cache-directive的可選值為：（圖片來自網絡）

cache-control設置緩存的使用方法為：Cache-Control:max-age=31536000，緩存單位為秒。

如果客戶端請求的資源未超過緩存時間，則直接取本地緩存，狀態碼為200（from memory cache），
但是如果超過緩存時間或者直接不走緩存的話，那我們就需要和其他的字段配合來校驗緩存了。

服務端傳遞資源給客戶端的時候會在響應報文中帶上這個信息，而客戶端接受到資源后會將該信息的值設置為請求頭中If-Modified-Since參數的值（If-Modified-Since: Last-Modified value）。在下次發送請求的時候（max-age過期之后），會將請求頭中的If-Modified-Since參數的值與服務端Last-Modified的值去比較，如果仍是一致的，那么說明該資源未被修改，直接返回304狀態碼即可，如果不一致，則返回狀態碼200，以及新的Last-Modified。

但是Last-Modified會有不準確的時候，比如服務端的資源做了無實際變化的修改（加一個空格再刪掉），這樣也會使服務端Last-Modified的時間更新，導致客戶端請求中If-Modified-Since的值與其無法匹配，就會返回整個實體。（即使返回的實體內容與客戶端的緩存內容沒有區別）

Etag是一種比Last-Modified更為精確的校驗方式。服務器會通過某種算法，給資源計算得出一個唯一標志符。其判斷依據和Last-Modified類似，只是服務端在傳遞資源給客戶端的相應報文中帶上Etag后，客戶端會將其設置為請求頭中If-None-Match參數的值（If-None-Match: Etag-value），然后在傳遞資源時進行比較。

如果同時使用Last-Modified和Etag進行驗證的話，那么兩者中有一個通過校驗（即傳遞的值可以匹配），則可以認為資源并沒有被修改。

基本的緩存機制就是由這些參數形成的。

最后我們來看下，不同的頁面打開方式對緩存機制的影響

主要有以下兩點要注意：

1.手動刷新頁面（F5刷新），瀏覽器會直接認為緩存已經過期，即使緩存并沒有過期，在請求中加上字段：Cache-Control:max-age=0，發包向服務器查詢是否有文件是否有更新。

2.強制刷新頁面（ctrl+F5刷新），瀏覽器會直接忽略本地緩存內容，即使本地有緩存可用，在請求中加上字段：Cache-Control:no-cache（或 Pragma:no-cache），發包向服務器重新請求文件。
其他的直接上圖(圖片來自網絡)：

此篇文章的很多想法是借鑒網上高手的文章，我會在底部標明參考出處。如果此文章中有什么問題的話，煩請一定要指出，謝謝！

參考資料
RFC2616
H5 緩存機制淺析 移動端 Web 加載性能優化
淺談瀏覽器http的緩存機制