簡介
通過複用以前獲取的資源,可提高性能,減輕服務端的壓力
分類
緩存種類有很多,網關緩存、CDN、反向代理緩存和負載均衡器等部署在服務器上的緩存方式,大致上分兩類
私有緩存:瀏覽器緩存
共享緩存:架設的web代理
緩存操作目標
只能緩存GET 請求,普遍的緩存案例
- 一個檢索請求的成功響應: 對於
GET請求，響應狀態碼爲：200，則表示爲成功。一個包含例如HTML文檔，圖片，或者文件的響應。 - 永久重定向: 響應狀態碼：
301。 - 錯誤響應: 響應狀態碼：
404的一個頁面。 - 不完全的響應: 響應狀態碼
206，只返回局部的信息。 - 除了
GET請求外，如果匹配到作爲一個已被定義的cache鍵名的響應。
緩存控制
Cache-control取值
no-store:緩存中不得存儲任何關於客戶端請求和服務端響應的內容
no-cache:每次有請求發出時,會將帶有本地緩存相關的驗證字段發到服務器,服務器會驗證緩存是否過期,若未過期(返回304),則緩存才使用本地緩存副本
私有與公共緩存
private|public:控制中間人是否能緩存 目標用戶的頁面
過期機制
Cache-Control: max-age=31536000
- 表示資源能夠被緩存的最大時間
- max-age是距離請求發起的時間的秒數
- 針對應用中那些不會改變的文件，通常可以手動設置一定的時長以保證緩存有效，例如圖片、css、js等靜態資源
must-revalidate
- 使用一個陳舊的資源時，必須先驗證它的狀態
Pragma 頭
-
Pragma是HTTP/1.0標準中定義的一個header屬性， -
請求中包含Pragma的效果跟在頭信息中定義Cache-Control: no-cache相同，但是HTTP的響應頭沒有明確定義這個屬性，
-
所以它不能拿來完全替代HTTP/1.1中定義的Cache-control頭
新鮮度
計算緩存壽命
-
首先 查
Cache-control: max-age=N的頭 -
然後 expires屬性,比較Expires的值和頭裏面Date屬性的值來判斷是否緩存還有效
-
Last-Modified信息:緩存的壽命就等於頭裏面Date的值減去Last-Modified的值除以10（注：根據rfc2626其實也就是乘以10%）。
expirationTime = responseTime + freshnessLifetime - currentAge
改進資源
revving
- 給 不頻繁更新的文件在URL後面（通常是文件名後面）會加上版本號
- 加上版本號後的資源就被視作一個完全新的獨立的資源，同時擁有一年甚至更長的緩存過期時長
- 所有引用這個資源的地方都需要更新鏈接,通常會採用自動化構建工具在實際工作中完成這些瑣碎的工作
- 加在加速文件後面的版本號不一定是一個正式的版本號字符串，如1.1.3這樣或者其他固定自增的版本數。它可以是任何防止緩存碰撞的標記例如hash或者時間戳。
緩存驗證
- 用戶點擊刷新按鈕時會開始緩存驗證
- 如果緩存的響應頭信息裏含有"Cache-control: must-revalidate”的定義
- 另外，在瀏覽器偏好設置裏設置Advanced->Cache爲強制驗證緩存也能達到相同的效果。
ETags
- 強校驗器,是服務器給 UA的 一個不透明的值, UA可以在後續的 if-none-match 頭來驗證緩存
last-modified
- 弱校驗器: 只能精確到秒,客戶端後續可以在請求中帶上 if-modified-since 來驗證緩存
- 客戶端向 服務端 發起校驗時,服務端會返回 200,或者304 not modified ,304響應頭也可以同時更新緩存文檔的過期時間
Vary響應
Vary HTTP 響應頭 決定了對於後續的請求頭，如何判斷是請求一個新的資源還是使用緩存的文件。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-kxQX4CZ3-1589807649327)(C:\Users\weisanju\Desktop\實用圖\HTTPVary.png)]
- vary頭有利於內容服務的動態多樣性
- 除了 請求的URI 不同 導致緩存失效以外,還有 區分移動端,桌面端緩存,區分不通編碼類型的緩存,區別不通瀏覽器的緩存