HTTP緩存——304與200 from cache

我的博客原文地址

HTTP與緩存相關的字段

1. 通用字段

字段名稱	釋義
Cache-Control	控制緩存具體的行爲
Pragma	HTTP1.0時的遺留字段，當值爲"no-cache"時強制驗證緩存
Date	建立報文的日期時間(啓發式緩存階段所用)

2. response字段

字段名稱	釋義
ETag	服務器生成資源的惟一標識
Vary	代理服務器緩存的管理信息
Age	資源在緩存代理中存貯的時長(取決於max-age和s-maxage的大小)

3. request字段

字段名稱	釋義
If-Match	條件請求，攜帶上一次請求中資源的ETag，服務器根據這個字段判斷文件是否有新的修改
If-None-Match	和If-Match做用相反，服務器根據這個字段判斷文件是否有新的修改
If-Modified-Since	比較資源先後兩次訪問最後的修改時間是否一致
If-Unmodified-Since	比較資源先後兩次訪問最後的修改時間是否一致

4. 實體字段

字段名稱	釋義
Expires	告知客戶端資源緩存失效的絕對時間
Last-Modified	資源最後一次修改的時間

協商緩存（304）

If-modified-Since/Last-Modified

• 瀏覽器在發送請求的時候服務器會檢查請求頭request header裏面的If-modified-Since，若是最後修改時間相同則返回304，不然給返回頭(response header)添加last-Modified而且返回數據(response body)。

if-modified-since:Wed, 31 May 2017 03:21:09 GMT
if-none-match:"42DD5684635105372FE7720E3B39B96A"

If-None-Match/Etag

• 瀏覽器在發送請求的時候服務器會檢查請求頭(request header)裏面的if-none-match的值與當前文件的內容經過hash算法（例如 nodejs: cryto.createHash('sha1')）生成的內容摘要字符對比，相同則直接返回304，不然給返回頭(response header)添加etag屬性爲當前的內容摘要字符，而且返回內容。

etag:"42DD5684635105372FE7720E3B39B96A"
last-modified:Wed, 31 May 2017 03:21:09 GMT

請求頭last-modified的日期與響應頭的last-modified一致
請求頭if-none-match的hash與響應頭的etag一致
所用會返回Status Code: 304

強緩存（200 from cache）

• 若是設置了Expires(XX時間過時)或者Cache-Control（http1.0不支持）(經歷XX時間後過時)且沒有過時，命中cache的狀況下，from cache不去發出請求。若是強刷（如ctrl+r）會發起請求，可是若是沒有修改會返回304內容未修改，若是已經改變則返回新內容。max-age > Expires。
• expires/cache-control 雖然是強緩存，但用戶主動觸發的刷新行爲，仍是會採用緩存協商的策略，主動觸發的刷新行爲包括點擊刷新按鈕、右鍵刷新、f5刷新、ctrl+f5刷新等。
• 固然若是在控制檯裏面選中了disable cahce則不管如何都會請求最新內容(304協商緩存、強緩存都無效)，由於1.不會檢查本地是否有緩存。2.請求頭信息(request header)既沒有If-Modified-Since也沒有If-None-Match來讓服務端判斷。地址欄輸入的地址按下回車鍵，該地址頁面請求（僅僅是該url）的request header都會帶上cache-contro:max-age=0，因此不會命中強緩存，可是經過連接點擊的地址會命中緩存
• chrome下查看全部的from cache文件：chrome://view-http-cache/

區別

• 觸發 200 from cache：

1. 直接點擊連接訪問
2. 輸入網址按回車訪問
3. 二維碼掃描

• 觸發 304：

1. 刷新頁面時觸發
2. 設置了長緩存、但Entity Tags沒有移除時觸發

流程圖

GitHub：wclimb