HTTP 協(xié)議的緩存機(jī)制涉及到多個請求頭字段，而且整個緩存機(jī)制的細(xì)節(jié)行為也存在各種情況的差異，譬如說什么時候訪問本地緩存不發(fā)送請求，什么時候發(fā)送請求查看資源是否更新，獲取 response 什么情況下更新緩存等。以前我對此一知半解只是籠統(tǒng)的知道一些概念，譬如 Cache-Control 可以控制緩存的時間和是否需要緩存，但是緩存過期后的行為，有緩存后瀏覽器是否有 http 請求都不甚了解。所以特地 google 下，此篇是對此的知識梳理。

協(xié)議概述

什么情況下可以使用本地緩存？譬如說我們用 get 方式請求了一個資源 http://mytest.domain.com/static/images/bg.png，那么我們下次再請求這個圖片資源的時候符合哪些條件可以使用本地緩存呢？

url 必須是 http://mytest.domain.com/static/images/bg.png，如果是 http://mytest.domain.com/static/images/bg.png?t=12312321 就會發(fā)起新的請求，因為 url 不同。

發(fā)送請求的 method 必須可被緩存，譬如 get。

第一次請求 response(即本地緩存)如果有一個 Vary 頭，他的值列出的是一系列 http header，第二次請求的請求頭中那些在 Vary 值中所列的頭，必須和第一次請求相同(具體規(guī)則)。

第二次請求不包含請求頭 Pragma: no-cache

第二次請求不包含請求頭 Cache-Control: no-cache|max-age=0

第一次請求的 response(即本地緩存)不包含 Cache-Control: no-cache

本地緩存沒有過期

或者雖然本地緩存已經(jīng)過期，但是服務(wù)器驗證緩存和服務(wù)器資源一致，允許使用本地緩存的情況(即獲得304 response)

注2：response header中不僅僅可以 Cache-Control: no-cache，還可以 Cache-Control: no-cache="Set-Cookie" 詳見

如何計算本地緩存是否過期

瀏覽器是通過比較緩存剩余有效時間和當(dāng)前緩存已存在時間來判斷的：response_is_fresh = (freshness_lifetime > current_age)。freshness_lifetime 取值優(yōu)先級次序如下列表所示(排在上面的優(yōu)先級越高)：

Cache-Control: s-maxage=xx

Cache-Control: max-age=xx

Expires: xxxxx

按規(guī)則進(jìn)行計算(推測)

注1；如果有多個重復(fù)的上述頭，那么是非法的，視作 response(資源)過期

freshness_lifetime 計算(推測)規(guī)則：

規(guī)范并沒有給出具體的算法，但是給出了最壞情況(but does impose worst-case constraints on their results)，如果 response(資源)有 Last-Modified 頭，那么推薦用從當(dāng)前到lastmodified這個時間段的 10% 作為 freshness_lifetime，并且 response(資源)的 current_age 如果已經(jīng)超過24小時，必須在這個 response 上加上113 warn-code頭。很少有瀏覽器實現(xiàn)了freshness_lifetime的自助計算(推測)，所以還是還是鼓勵給出上述顯式的1 - 3三種情況。

current_age 計算規(guī)則：

泛泛來說就是 response(資源)在本地的駐足時間加上網(wǎng)絡(luò)傳輸時間，因為網(wǎng)絡(luò)傳輸時間的計算有多個條件，規(guī)范實在看的我頭暈，所以具體計算規(guī)則詳見規(guī)范

本地緩存過期，如何通過服務(wù)器驗證緩存的是否依然有效(即304的情況)

首先，如果第一次的 response(資源)頭中顯示申明了一些禁止緩存的頭(譬如："no-store" or "no-cache" 等等)，就不存在過期不過期的問題，因為這個資源不允許緩存。其次，過期緩存也不一定不可用，如果在斷網(wǎng)或者第二次請求帶上 max-stale 這個請求頭，那么瀏覽器可以使用過期的緩存(masx-stale 表示在緩存過期后多少時間內(nèi)瀏覽器依然可以使用緩存)。碰到過期緩存，瀏覽器可以發(fā)送一個條件請求(conditional request)。這個請求的 url 依然是第一次請求的 url，只是會帶上些當(dāng)前資源的一些信息，以供服務(wù)器驗證這個緩存是否依然可用還是需要更新：

response(資源)的 Last-Modified 頭所帶的值會放到條件請求的 If-Modified-Since 頭中，或者是 If-Unmodified-Since 又或者 If-Range。

response(資源)的 ETag 頭所帶的值會放到條件請求的 If-None-Match 頭中，或者 If-Match 又或者 If-Range。

服務(wù)器會根據(jù)不同的條件請求頭來驗證資源，具體的行為詳見規(guī)范，這里不細(xì)致展開。針對條件請求，服務(wù)器返回會有三種情況：

一個帶有304 status code 的返回。表示緩存可以被更新和重用。

一個帶有 body 的完整的 response。表示用這個 response 作為請求的返回，并且視條件可以用這個完整的 response 替換瀏覽器原有的緩存(此資源)。

如果返回一個5xx的 response，那么瀏覽器可以選擇就顯示這個5xx的返回，或者使用本地緩存(盡管可能是過期的)- 規(guī)范沒有規(guī)定應(yīng)該選擇哪種處理，應(yīng)該是取決于瀏覽器的行為。

如果是一個304的返回，規(guī)范說這個返回可以更新本地緩存，更新策略分三種：

如果這個304 response 帶有資源有效性的強(qiáng)驗證頭，那么瀏覽器會尋找本地緩存，尋找那些帶有同樣強(qiáng)驗證頭的緩存，然后用這個最新的 response 去更新這些匹配的緩存(同一個資源可能瀏覽器保存有多份緩存，譬如日期不同等)。

如果這個304 response 帶有資源有效性的弱驗證頭，那么瀏覽器同樣會找相匹配的緩存，但是只會更新最新的那條匹配的緩存。

如果這個304 response 沒有帶有任何資源有效性驗證頭，并且瀏覽器緩存只有一份，并且這份也同樣沒帶有任何資源有效性驗證頭，那么瀏覽器就會用這個304 response，更新本地緩存。

協(xié)議流程圖

假設(shè)第一次請求一個資源，返回 header 里面帶上如下字段：

Cache-Control: max-age=600

Last-Modified: Wed, 28 Aug 2013 10:36:42 GMT

ETag: "124752e0d85461a16e76fbdef2e84fb9"

拋開細(xì)枝末節(jié)的東西，那么第二次請求通常大致流程圖如下：

當(dāng)前資源緩存是否過期：response_is_fresh = (freshness_lifetime > current_age)

|

-----------------------------------

| |

是 否

| |

發(fā)送請求，帶上請求頭 從本地緩存中獲取資源(不發(fā)請求)

If-Modified-Since: 此資源Last-Modified的值

If-None-Match: 此資源ETag的值

|

服務(wù)器根據(jù) If-Modified-Since 和 If-None-Match

兩個值判斷資源是否更新過

|

-------------------------

| |

是 否

| |

返回一個 status code:200 的 response 返回一個 status code:304 的 response

response body 里面是請求的資源 response body 為空

| |

瀏覽器用 response body里面的資源 依然從本地緩存里面獲取資源

替換本地緩存中的資源

特殊情況

當(dāng)你去瀏覽器驗證的時候可能會碰到一些特殊情況，就是緩存有效，但是你刷新瀏覽器依然發(fā)送的條件請求。其實是因為瀏覽器在請求頭中加入了一些料，譬如： Cache-Control: max-age=0。你刷新的方式可以有很多種，譬如：按F5，按ctrl+F5，在地址欄按回車等等。這些不同的行為都會影響瀏覽器發(fā)送請求的行為。這里有一些參考《在瀏覽器地址欄按回車、F5、Ctrl+F5刷新網(wǎng)頁的區(qū)別》

參考資料

總結(jié)

以上是生活随笔為你收集整理的缓存服务器协议有哪些,HTTP 协议的缓存机制概述的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。