寫給後端程序員的HTTP緩存原理介紹

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

經過Internet獲取資源既緩慢，成本又高。爲此，Http協議裏包含了控制緩存的部分，以使Http客戶端能夠緩存和重用之前獲取的資源，從而優化性能，提高體驗。雖然Http中關於緩存控制的部分，隨着協議演進，有一些變化。但我覺着，做爲後端程序員，在開發Web服務時，只須要關注請求頭If-None-Match、響應頭ETag、響應頭Cache-Control就足夠了。由於這三個Http頭就能夠知足你的需求，而且，當今絕大多數的瀏覽器，都支持這三個Http頭。咱們所要作的就是，確保每一個服務器響應都提供正確的 HTTP 頭指令，以指導瀏覽器什麼時候能夠緩存響應以及能夠緩存多久。

緩存在哪兒？

上圖中有三個角色，瀏覽器、Web代理和服務器，如圖所示Http緩存存在於瀏覽器和Web代理中。固然在服務器內部，也存在着各類緩存，但這已經不是本文要討論的Http緩存了。所謂的Http緩存控制，就是一種約定，經過設置不一樣的響應頭Cache-Control來控制瀏覽器和Web代理對緩存的使用策略，經過設置請求頭If-None-Match和響應頭ETag，來對緩存的有效性進行驗證。

響應頭ETag

ETag全稱Entity Tag，用來標識一個資源。在具體的實現中，ETag能夠是資源的hash值，也能夠是一個內部維護的版本號。但無論怎樣，ETag應該能反映出資源內容的變化，這是Http緩存能夠正常工做的基礎。

如上例中所展現的，服務器在返回響應時，一般會在Http頭中包含一些關於響應的元數據信息，其中，ETag就是其中一個，本例中返回了值爲x1323ddx的ETag。當資源/file的內容發生變化時，服務器應當返回不一樣的ETag。

請求頭If-None-Match

對於同一個資源，好比上一例中的/file，在進行了一次請求以後，瀏覽器就已經有了/file的一個版本的內容，和這個版本的ETag，當下次用戶再須要這個資源，瀏覽器再次向服務器請求的時候，能夠利用請求頭If-None-Match來告訴服務器本身已經有個ETag爲x1323ddx的/file，這樣，若是服務器上的/file沒有變化，也就是說服務器上的/file的ETag也是x1323ddx的話，服務器就不會再返回/file的內容，而是返回一個304的響應，告訴瀏覽器該資源沒有變化，緩存有效。

如上例中所示，在使用了If-None-Match以後，服務器只須要很小的響應就能夠達到相同的結果，從而優化了性能。

響應頭Cache-Control

每一個資源均可以經過Http頭Cache-Control來定義本身的緩存策略，Cache-Control控制誰在什麼條件下能夠緩存響應以及能夠緩存多久。 最快的請求是沒必要與服務器進行通訊的請求：經過響應的本地副本，咱們能夠避免全部的網絡延遲以及數據傳輸的數據成本。爲此，HTTP 規範容許服務器返回一系列不一樣的 Cache-Control 指令，控制瀏覽器或者其餘中繼緩存如何緩存某個響應以及緩存多長時間。

Cache-Control 頭在 HTTP/1.1 規範中定義，取代了以前用來定義響應緩存策略的頭（例如 Expires）。當前的全部瀏覽器都支持 Cache-Control，所以，使用它就夠了。

如下我來介紹能夠再Cache-Control中設置的經常使用指令。

max-age

該指令指定從當前請求開始，容許獲取的響應被重用的最長時間（單位爲秒。例如：Cache-Control:max-age=60表示響應能夠再緩存和重用 60 秒。須要注意的是，在max-age指定的時間以內，瀏覽器不會向服務器發送任何請求，包括驗證緩存是否有效的請求，也就是說，若是在這段時間以內，服務器上的資源發生了變化，那麼瀏覽器將不能獲得通知，而使用老版本的資源。因此在設置緩存時間的長度時，須要慎重。

public和private

若是設置了public，表示該響應能夠再瀏覽器或者任何中繼的Web代理中緩存，public是默認值，即Cache-Control:max-age=60等同於Cache-Control:public, max-age=60。

在服務器設置了private好比Cache-Control:private, max-age=60的狀況下，表示只有用戶的瀏覽器能夠緩存private響應，不容許任何中繼Web代理對其進行緩存 - 例如，用戶瀏覽器能夠緩存包含用戶私人信息的 HTML 網頁，可是 CDN 不能緩存。

no-cache

若是服務器在響應中設置了no-cache即Cache-Control:no-cache，那麼瀏覽器在使用緩存的資源以前，必須先與服務器確認返回的響應是否被更改，若是資源未被更改，能夠避免下載。這個驗證以前的響應是否被修改，就是經過上面介紹的請求頭If-None-match和響應頭ETag來實現的。

須要注意的是，no-cache這個名字有一點誤導。設置了no-cache以後，並非說瀏覽器就再也不緩存數據，只是瀏覽器在使用緩存數據時，須要先確認一下數據是否還跟服務器保持一致。若是設置了no-cache，而ETag的實現沒有反應出資源的變化，那就會致使瀏覽器的緩存數據一直得不到更新的狀況。

no-store

若是服務器在響應中設置了no-store即Cache-Control:no-store，那麼瀏覽器和任何中繼的Web代理，都不會存儲此次相應的數據。當下次請求該資源時，瀏覽器只能從新請求服務器，從新從服務器讀取資源。

怎樣決定一個資源的Cache-Control策略呢？

下面這個流程圖，能夠幫到你。

Reference

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn