HTTP深刻之緩存

HTTP緩存在WEB系統性能優化的過程當中，起到了不可忽視的做用。而咱們又經常將它忽視😂，此次給它一個面子，好好了解一下緩存。

緩存的目標以及順序

目標

常見的 HTTP 緩存只能存儲 GET 響應，對於其餘類型的響應則無能爲力。緩存的關鍵主要包括request method和目標URI。

順序

1. 接收、解析—從網絡中讀取抵達的請求報文，對報文進行解析，提取出 URL 和各類首部。
2. 查詢—緩存查看是否有本地副本可用，若是沒有，就獲取一份副本（並將其保存在本地）。
3. 新鮮度檢測—緩存查看已緩存副本是否足夠新鮮，若是不是，就詢問服務器是否有任何更新。
4. 建立響應—緩存會用新的首部和已緩存的主體來構建一條響應報文。
5. 發送—緩存經過網絡將響應發回給客戶端。
6. 日誌—緩存可選地建立一個日誌文件條目來描述這個事務。

---

爲何使用緩存？

1. 冗餘的數據傳輸

 多個客戶端同時訪問一個WEB服務頁面，服務器會屢次傳輸同一份文檔，每次傳送給一個客戶端。一些相同的字節會在網絡中一遍遍地傳輸。這些冗餘的數據傳輸會耗盡昂貴的網絡帶寬，下降傳輸速度，加劇 Web 服務器的負載。

2. 帶寬瓶頸

 不少網絡爲本地網絡客戶端提供的帶寬比爲遠程服務器提供的帶寬要寬，客戶端會以路徑上最慢的網速訪問服務器。若是客戶端從一個快速局域網的緩存中獲得了一份副本，那麼緩存就能夠提升性能——尤爲是要傳輸比較大的文件時。

3. 瞬間擁塞

 緩存在破壞瞬間擁塞（Flash Crowds）時顯得很是重要。'突發事件'，使不少人幾乎同時去訪問一個 Web 文檔時，就會出現瞬間擁塞。由此形成的過多流量峯值，可能會使網絡和 Web 服務器產生災難性的崩潰。

4. 距離時延

 即便帶寬不是問題，距離也可能成爲問題。每臺網絡路由器都會增長因特網流量的時延。即便客戶端和服務器之間沒有太多的路由器，光速自身也會形成顯著的時延。

---

常見的緩存頭

緩存控制字段	說明
Cache-Control 頭	HTTP/1.1定義的 Cache-Control 頭用來區分對緩存機制的支持狀況， 請求頭和響應頭都支持這個屬性。經過它提供的不一樣的值來定義緩存策略。
Pragma 頭	Pragma 是HTTP/1.0標準中定義的一個header屬性，請求中包含Pragma的效果跟在頭信息中定義Cache-Control: no-cache相同，可是HTTP的響應頭不支持這個屬性，因此它不能拿來徹底替代HTTP/1.1中定義的Cache-Control頭。一般定義Pragma以向後兼容基於HTTP/1.0的客戶端。
Etag	http1.1時期新加屬性 ，使用inode+mtime（如下有解釋）來計算。根據實體內容生成的一段hash字符串（相似於MD5或者SHA1以後的結果），能夠標識資源的狀態。 當資源發送改變時，ETag也隨之發生變化。
Last-Modified	http1.1時期屬性，比較資源最後一次修改時間

緩存對比字段	說明
Expires	http1.0時期屬性，在響應http請求時告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器緩存取數據，而無需再次請求。通常用來作兼容。
Vary	HTTP 響應頭決定了對於後續的請求頭，如何判斷是請求一個新的資源仍是使用緩存的文件。
If-Match	比較ETag是否一致， 在請求方法爲 GET 和 HEAD 的狀況下，服務器僅在請求的資源知足此首部列出的 ETag 之一時纔會返回資源。而對於 PUT 或其餘非安全方法來講，只有在知足條件的狀況下才能夠將資源上傳。
If-None-Match	比較ETag是否不一致，對於 GETGET 和 HEAD 請求方法來講，當且僅當服務器上沒有任何資源的 ETag 屬性值與這個首部中列出的相匹配的時候，服務器端會才返回所請求的資源，響應碼爲 200 。對於其餘方法來講，當且僅當最終確認沒有已存在的資源的 ETag 屬性值與這個首部中所列出的相匹配的時候，纔會對請求進行相應的處理。
If-Modified-Since	比較資源最後更新的時間是否一致，若是請求的資源從那時起未經修改，那麼返回一個不帶有消息主體的 304 響應，而在 Last-Modified 首部中會帶有上次修改時間。 不一樣於 If-Unmodified-Since, If-Modified-Since 只能夠用在 GET 或 HEAD 請求中。
If-Unmodified-Since	比較資源最後更新的時間是否不一致，只有當資源在指定的時間以後沒有進行過修改的狀況下，服務器纔會返回請求的資源，或是接受 POST 或其餘 non-safe 方法的請求。若是所請求的資源在指定的時間以後發生了修改，那麼會返回 412 (Precondition Failed) 錯誤。
If-Range	頭字段一般用於斷點續傳的下載過程當中，用來自從上次中斷後，確保下載的資源沒有發生改變。

---

緩存的發展

HTTP1.0近時代

給客戶端設定緩存可經過兩個字段，Pragma跟Expires來實現。

1. Pragma字段值爲no-cache的時候，會告訴客戶端不要對該資源讀緩存，即每次都得向服務器發一次請求才行。
2. Expires的值對應一個GMT（格林尼治時間），好比Tue, 09 Oct 2018 10:22:09 GMT GMT來告訴瀏覽器資源緩存過時時間，若是還沒過該時間點則不發請求。

   • 響應報文中Expires所定義的緩存時間是相對服務器上的時間而言的，其定義的是資源過時時刻。

   • 若是客戶端上的時間跟服務器上的時間不一致（特別是用戶修改了本身電腦的系統時間），那緩存時間可能就沒啥意義了。

若是Pragma頭部和Expires頭部同時存在，則起做用的會是Pragma

HTTP1.1後時代

由於1.0時代的緩存問題，「Expires時間是相對服務器而言的，沒法保證和客戶端時間統一」，http1.1新增了 Cache-Control 來定義緩存過時時間。

1. 若報文中同時出現了 Expires 和 Cache-Control，則以 Cache-Control 爲準。
2. 優先級從低到高 Expires <- Cache-Control <- Pragma

Cache-Control 字段簡介

在RFC中規範了 Cache-Control 的格式爲："Cache-Control" ":" cache-directive。

做用	字段	說明
禁止進行緩存	no-store	緩存中不得存儲任何關於客戶端請求和服務端響應的內容。每次由客戶端發起的請求都會下載完整的響應內容。
強制確認緩存	no-cache	每次有請求發出時，緩存會將此請求發到服務器（該請求應該會帶有與本地緩存相關的驗證字段），服務器端會驗證請求中所描述的緩存是否過時，若未過時（實際就是返回304），則緩存才使用本地緩存副本。
私有緩存	private	則表示該響應是專用於某單個用戶的，中間人不能緩存此響應，該響應只能應用於瀏覽器私有緩存中。
公共緩存	public	指令表示該響應能夠被任何中間人（好比中間代理、CDN等）緩存。若指定了"public"，則一些一般不被中間人緩存的頁面（由於默認是private）（好比 帶有HTTP驗證信息（賬號密碼）的頁面 或 某些特定影響狀態碼的頁面），將會被其緩存。
緩存過時機制	max-age=<seconds>	表示資源可以被緩存（保持新鮮）的最大時間。相對Expires而言，max-age是距離請求發起的時間的秒數。針對應用中那些不會改變的文件，一般能夠手動設置必定的時長以保證緩存有效，例如圖片、css、js等靜態資源。
緩存驗證確認	must-revalidate	緩存在考慮使用一個陳舊的資源時，必須先驗證它的狀態，已過時的緩存將不被使用

客戶端決定是否向服務器發送請求，好比設置的緩存時間未過時，那麼天然直接從本地緩存取數據便可，若緩存時間過時了或資源不應直接走緩存，則會發請求到服務器去。

可是隻有這樣還不夠，咱們來假設一種狀況。緩存過時了，服務器上的這個資源數據量夠多，但又沒更改過。那這個時候從新請求的話，至關於白白加載了一遍，浪費帶寬跟時間。

Last-Modified 響應頭

服務器將資源傳遞給客戶端時，會將資源最後更改的時間以「Last-Modified: GMT」的形式加在實體首部上一塊兒返回給客戶端。

這個響應頭也被叫作弱類型校驗器，說它弱是由於它只能精確到一秒。

Last-Modified: Thu, 30 Aug 2018 08:03:28 GMT
複製代碼

1. 當向服務端發起緩存校驗的請求時，會比較兩個時間是否一致，服務端會返回 200 表示返回正常的結果或者 304 Not Modified(不返回body)表示瀏覽器可使用本地緩存文件。
2. 須要注意的是，304的響應頭也能夠同時更新緩存文檔的過時時間。

跟其配合的經常有 If-Modified-Since、If-Unmodified-Since等（看上面緩存頭解釋）

ETag 響應頭

1. 做爲緩存的一種強校驗器，ETag 響應頭是一個對用戶代理(User Agent)不透明的值。
2. 爲了解決上述Last-Modified可能存在的不許確的問題，Http1.1還推出了 ETag 實體首部字段。 服務器會經過某種算法，給資源計算得出一個惟一標誌符（好比md5標誌），在把資源響應給客戶端的時候，會在實體首部加上「ETag: 惟一標識符」一塊兒返回給客戶端。

Etag: "4280832337"
Etag: W/"57a1bb7b-10c8" // 表示使用弱驗證器
複製代碼

1. 客戶端會保留該 ETag 字段，並在下一次請求時將其一併帶過去給服務器。

2. 服務器只須要比較客戶端傳來的ETag跟本身服務器上該資源的ETag是否一致，就能很好地判斷資源相對客戶端而言是否被修改過了。

3. 若是服務器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（固然也包括了新的ETag）發給客戶端。

4. 若是ETag是一致的，則直接返回304知會客戶端直接使用本地緩存便可。

跟其配合的經常有 If-Match、If-None-Match等（看上面緩存頭解釋）

---

緩存頭部效果對比

頭部	優點和特色	劣勢和問題
Expires	1. HTTP 1.0 產物，能夠在HTTP 1.0和1.1中使用，簡單易用。 2. 以時刻標識失效時間。	1. 時間是由服務器發送的(UTC)，若是服務器時間和客戶端時間存在不一致，可能會出現問題。 2. 存在版本問題，到期以前的修改客戶端是不可知的。
Cache-Control	1. HTTP 1.1 產物，以時間間隔標識失效時間，解決了Expires服務器和客戶端相對時間的問題。 2. 比Expires多了不少選項設置。	1. HTTP 1.1 纔有的內容，不適用於HTTP 1.0 。 2. 存在版本問題，到期以前的修改客戶端是不可知的。
Last-Modified	不存在版本問題，每次請求都會去服務器進行校驗。服務器對比最後修改時間若是相同則返回304，不一樣返回200以及資源內容。	1. 只要資源修改，不管內容是否發生實質性的變化，都會將該資源返回客戶端。例如週期性重寫，這種狀況下該資源包含的數據實際上同樣的。 2. 以時刻做爲標識，沒法識別一秒內進行屢次修改的狀況。 3. 某些服務器不能精確的獲得文件的最後修改時間。
ETag	1. 能夠更加精確的判斷資源是否被修改，能夠識別一秒內屢次修改的狀況。 2. 不存在版本問題，每次請求都回去服務器進行校驗。	1. 計算ETag值須要性能損耗。 2. 分佈式服務器存儲的狀況下，計算ETag的算法若是不同，會致使瀏覽器從一臺服務器上得到頁面內容後到另一臺服務器上進行驗證時發現ETag不匹配的狀況。

---

緩存實踐

強緩存（200 from cache）

1. 爲靜態資源配置一個超過當前時長的Expires或Cache-Control。
2. 這樣用戶在訪問網頁時，只會在第一次加載時從服務器請求靜態資源。
3. 只要緩存沒有失效而且用戶沒有強制刷新的條件下都會從本身的緩存中加載。

協商緩存(304 Not Modified)

當瀏覽器對某個資源的請求沒有命中強緩存

1. 服務器還能夠配置 http response header 的 ETag (http1.1) 字段，表示當前資源的惟一標識。
2. 若是資源在客戶端過時，發送資源請求到服務器有 http request header 有 If-None-Match 字段，則表示當前資源配置過 ETag 字段。
3. 此時服務器須要判斷當前資源的惟一標識 ETag 值是否與請求的 If-None-Match 字段值一致，若是一致則表示當前資源未修改，能夠繼續使用緩存資源，這就是 304 not-modified (協商緩存)。

緩存命中速度

緩存命中 > 緩存再驗證成功 > 緩存未命中 = 緩存再驗證失敗；

200(from memory cache) 和 200(from disk cache)

在用chrome查看緩存的過程當中，發現了一個問題，那就是有的緩存資源是200(from memory cache)，而有的資源是200(from disk cache)，這一奇特的現象讓我百思不得解呀！

先看看他們的解釋。

• MemoryCache顧名思義，就是將資源緩存到內存中，等待下次訪問時不須要從新下載資源，而直接從內存中獲取。

• diskCache顧名思義，就是將資源緩存到磁盤中，等待下次訪問時不須要從新下載資源，而直接從磁盤中獲取，它的直接操做對象爲CurlCacheManager。它與memoryCache最大的區別在於，當退出進程時，內存中的數據會被清空，而磁盤的數據不會，因此，當下次再進入該進程時，該進程仍能夠從diskCache中得到數據，而memoryCache則不行。

• chrome的解釋 Chrome employs two caches — an on-disk cache and a very fast in-memory cache. The lifetime of an in-memory cache is attached to the lifetime of a render process, which roughly corresponds to a tab. Requests that are answered from the in-memory cache are invisible to the web request API. If a request handler changes its behavior (for example, the behavior according to which requests are blocked), a simple page refresh might not respect this changed behavior. To make sure the behavior change goes through, call handlerBehaviorChanged() to flush the in-memory cache. But don't do it often; flushing the cache is a very expensive operation. You don't need to call handlerBehaviorChanged() after registering or unregistering an event listener.

  • 大意是說chrome會使用兩個緩存，一個是磁盤緩存一個是很是快的內存緩存，內存緩存是和渲染進程綁定的，大部分狀況下於瀏覽器Tab對應。不要輕易強制刷新緩存，代價很是昂貴...

腳本文件的差別

隨便打開兩個

• 紅線圈出來的是不一樣的地方，難道是這樣的嗎？
• 發現一個不同的，沒有content-length字段

  

• 而後我又發現了一個不一樣的。並且這玩意在我強制刷新瀏覽器的狀況下，仍是200 OK (from disk cache)

  

  因此結論就是，留給你們思考吧。

---

參考文章：

• MDN Headers
• 淺談瀏覽器http的緩存機制
• 瀏覽器緩存知識小結
• HTTP權威指南--緩存篇