HTTP緩存詳解

1、爲何要使用緩存

Web緩存能夠自動保存已獲取的資源，當Web請求抵達緩存時，若是本地有「已緩存的」副本，就能夠從本地存儲而不是原始服務器中提取這些資源，使用緩存有下列有點：

• 緩存減小了冗餘的數據傳輸
• 緩存緩解了網絡瓶頸問題，節省帶寬
• 緩存下降了對原始服務器的壓力
• 緩存下降了距離時延

2、各類類型的緩存

緩存大致能夠分爲兩種類型：私有緩存和公有緩存。 私有緩存是我的的緩存，包含了單個用戶最經常使用的資源；公有緩存包含了多個用戶經常使用的資源。

一、私有緩存

大多數瀏覽器都會將經常使用文檔緩存在我的電腦的磁盤或者內存中，這樣能夠避免再次向服務器發起多餘的請求。你能夠在瀏覽器的設置中配置緩存的各類設置。

二、公有代理緩存

公有代理緩存會接受來自多個用戶的訪問，代理緩存會從本地緩存中提供文檔，或者表明用戶和服務器進行聯繫。

3、緩存的處理步驟

常見的HTTP緩存只能存儲GET響應，對其餘累着的響應則無能爲力。Web緩存的基本工做原理大多很簡單，處理過程包括7個步驟。

一、接收 - 緩存圖片請求報文
二、解析 - 緩存對請求報文進行解析，提取出URL和各類首部
三、查詢 - 緩存查看是否有本地副本可用，若是沒有就從服務器獲取一份副本，並將其保存在本地
四、新鮮度檢測 - 若是本地有副本，緩存就會查看已緩存副本是否足夠新鮮，若是不是，就詢問服務器是否有任何更新
五、建立響應 - 若是資源沒有更新，緩存會用新的首部和已緩存的主體來構建一條響應報文
六、發送 - 緩存經過網絡將響應發回給客戶端
七、日誌 - 緩存可選地建立一個日誌文件條目來描述這個事務

緩存GET請求流程圖

4、新鮮度檢測

一、如何判斷文檔是否已過時

理論上當一個資源被緩存存儲後，該資源能夠永久存儲在緩存中，可是緩存的空間畢竟有限，因此緩存會按期將一些副本清除。瀏覽器如何斷定緩存的副本須要清除了？
服務端在返回一個資源時會爲這個定一個過時時間，服務器經過HTTP Cache-Control:max-age和Expires首部爲每個文檔附加一個「過時時間」。在文檔過時以前，緩存能夠無需與服務器聯繫而使用這些副本，除非客戶端請求報文中包含有阻止提供已緩存或未驗證資源的首部。

Expires

Expires是HTTP/1.0的首部，Expires是指定一個絕對的過時日期。若是過時日期已通過了，就說明文檔不在新鮮。

Cache-Contirl:max-age

Cache-Contirl:max-age是HTTP/1.1的響應首部，max-age值定義了文檔的最大使用時間，是距離請求發起的時間的秒數。max-age使用的是相對時間。對於不會改變的文件，例如js、css和圖片等靜態資源，能夠設置較長的過時時間，而後每次修改這些靜態資源時，文件名加上新的後綴來使用新的靜態資源。

二、過時文檔在驗證

有時候緩存裏的文檔副本已過時，但並不意外着服務器上的文檔已更新。緩存能夠經過一些條件請求首部到服務端去驗證文檔是否有更新，只有當服務端文檔和緩存中的文檔不一樣時，響應纔會返回主體。
對緩存再驗證最有用的2個首部是If-Modified-Since和If-None-Match。

If-Modified-Since:Date

請求報文中If-Modified-Since會待上上一次響應返回的Last-Modified日期，只有在這個日期以後資源發生了變化纔會指示服務器執行請求。

• 若是在指定日期後，文檔被修改，GET請求就會成功執行。響應會攜帶新的首部和新文檔返回，新首部中就包括新的過時時間（Last-Modified）。
• 若是自指定日期後，文檔沒有被修改，服務器會返回一個304 Not Modified響應報文，爲了提升有效性，不會返回文檔的主體，通常還會返回一個新的過時時間（Last-Modified）。
  If-Modified-Since: < cached last-modified date >

If-None-Match

有時候僅使用最後修改日期來驗證仍是不夠。好比有些文檔可能被重寫，內容沒有變化，但最後修改日期會發生變化。這個時候可使用ETag(實體標籤)來進行比較。ETag相似於文檔的序列號或版本好，當文檔修改時，能夠修改文檔的實體標籤來講明這是個新的版本。
請求頭If-None-Match能夠帶上上次返回的ETage，來去服務端驗證文檔是否有修改過。若是修改過，服務端會返回200，若是沒有修改過，服務端會返回304 Not Modified，但不返回body。304的響應頭也能夠同時更新緩存文檔的過時時間。
若是服務器返回一個實體標籤，客戶端就必須使用If-None-Match來驗證。若是服務器只返回一個Last-Modified值，客戶端就可使用If-Modified-Since驗證。若是Etag和Last-Modified都提供了，客戶端就應該使用着兩種方案驗證。

Etag / If-None-Match（優先級高於Last-Modified / If-Modified-Since）

5、控制緩存的能力

HTTP/1.1定義的 Cache-Control頭用來區分對緩存機制的支持狀況， 請求頭和響應頭都支持這個屬性。 能夠替換以前用來定義響應緩存策略的標頭（例如Expires)

• 每一個資源均可經過 Cache-Control HTTP 標頭定義其緩存策略
• Cache-Control 指令控制誰在什麼條件下能夠緩存響應以及能夠緩存多久。

禁止進行緩存

Cache-Control: no-store
Cache-Control: no-cache, no-store
Pragma: no-cache

「no-store」直接禁止瀏覽器以及全部中間緩存存儲任何版本的返回響應

「no-cache」表示必須先與服務器確認返回的響應是否發生了變化，而後才能使用該響應來知足後續對同一網址的請求。 所以，若是存在合適的驗證令牌 (ETag)，no-cache 會發起往返通訊來驗證緩存的響應，但若是資源未發生變化，則可避免下載

Pragma 是HTTP/1.0標準中定一個的一個header屬性，請求中包含Pragma的效果跟在頭信息中定義Cache-Control: no-cache相同，可是HTTP的響應頭不支持這個屬性。一般定義Pragma以向後兼容基於HTTP/1.0的客戶端。

強制確認緩存

Cache-Control: must-revalidate

「must-revalidate」規定每次有請求發出時，緩存會將此請求發到服務器，服務器端會驗證請求中所描述的緩存是否過時，若未過時返回304，緩存使用本地緩存副本。

私有緩存和公共緩存

Cache-Control: private
Cache-Control: public

若是響應被標記爲「public」，則即便它有關聯的 HTTP 身份驗證，甚至響應狀態代碼一般沒法緩存，也能夠緩存響應。 大多數狀況下，「public」不是必需的，由於明確的緩存信息（例如「max-age」）已表示響應是能夠緩存的。

相比之下，瀏覽器能夠緩存「private」響應。 不過，這些響應一般只爲單個用戶緩存，所以不容許任何中間緩存對其進行緩存。 例如，用戶的瀏覽器能夠緩存包含用戶私人信息的 HTML 網頁，但 CDN 卻不能緩存。

緩存過時機制

Cache-Control: max-age=31536000

過時機制中，最重要的指令是 "max-age="，表示資源可以被緩存（保持新鮮）的最大時間。相對Expires而言，max-age是距離請求發起的時間的秒數。針對應用中那些不會改變的文件，一般能夠手動設置必定的時長以保證緩存有效，例如圖片、css、js等靜態資源。