HTTP快取——304與200 from cache

wclimb發表於2018-06-06

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來讓服務端判斷。位址列輸入的地址按下Enter鍵,該地址頁面請求(僅僅是該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沒有移除時觸發

流程圖

流程圖

ps: 如有錯誤還望指正

部落格原文地址:HTTP快取——304與200 from cache

GayHub:wclimb

相關文章