都9012了，據說你還不瞭解緩存？

前言：

前端er須要關注的點：緩存

這真是一個令開發者又愛又恨的東西
現代手機隨時隨地會緩存你的資源，可是要想清緩存，不能像PC使用強制刷新，你須要手動清理瀏覽器緩存，甚至有時候還要重啓...
因此理解緩存機制並可以掌控它就顯的相當重要（比較牛逼了）

下面咱們將先通讀理論而後結合實踐真正理解緩存機制

下文會涉及到

• DNS緩存
• CDN緩存
• 瀏覽器緩存(HTTP緩存)

DNS緩存

什麼是DNS？

全稱 Domain Name System 域名解析系統
它的做用很是簡單，就是根據域名查出IP地址

DNS解析

簡單的說，經過域名最終解析到該域名對應的IP地址

www.dnscache.com (域名)  - DNS解析 -> 11.222.33.444 (IP地址)
複製代碼

DNS緩存

有DNS的地方,就有緩存! 瀏覽器、操做系統、Local DNS、根域名服務器，它們都會對DNS結果作必定程度的緩存

DNS查詢過程

1. 首先搜索瀏覽器自身的DNS緩存,若是存在，則域名解析到此完成。
2. 若是瀏覽器自身的緩存裏面沒有找到對應的條目，那麼會嘗試讀取操做系統的hosts文件看是否存在對應的映射關係,若是存在，則域名解析到此完成。
3. 若是本地hosts文件不存在映射關係，則查找本地DNS服務器(ISP服務器,或者本身手動設置的DNS服務器),若是存在,域名到此解析完成。
4. 若是本地DNS服務器還沒找到的話,它就會向根服務器發出請求,進行遞歸查詢。

CDN緩存

什麼是CDN？

全稱 Content Delivery Network,即內容分發網絡。 相似於火車站代售點，乘客不用再去售票大廳去排隊買票 減輕了售票大廳的壓力（起到分流做用,減輕服務器負載壓力）

用戶在瀏覽網站的時候，CDN會選擇一個離用戶最近的CDN邊緣節點來響應用戶的請求，這樣海南移動用戶的請求就不會千里迢迢跑到北京電信機房的服務器（假設源站部署在北京電信機房）上了

CDN緩存

當瀏覽器本地緩存失效,瀏覽器會向CDN邊緣節點發起請求。相似瀏覽器緩存,CDN邊緣節點也存在着一套緩存機制

CDN邊緣節點緩存策略因服務商不一樣而不一樣，但通常都會遵循http標準協議，經過http響應頭中的 Cache-control: max-age的字段來設置CDN邊緣節點數據緩存時間。

CDN邊緣節點數據緩存機制

• 當瀏覽器向CDN節點請求數據時，CDN節點會判斷緩存數據是否過時，
• 未過時：直接將緩存數據返回給客戶端；
• 過時：CDN節點向服務器發出回源請求，拉取最新數據同時更新本地緩存，並將最新數據返回給客戶端。

CDN服務商通常會提供基於文件後綴、目錄多個維度來指定CDN緩存時間，爲用戶提供更精細化的緩存管理。

CDN 優點

1. CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大下降。
2. 大部分請求在CDN邊緣節點完成，CDN起到了分流做用，減輕了源服務器的負載。

瀏覽器緩存（HTTP緩存）

盯着這張圖

什麼是瀏覽器緩存？

瀏覽器緩存其實就是瀏覽器保存經過HTTP獲取的全部資源,是瀏覽器將網絡資源存儲在本地的一種行爲。

緩存的資源去哪裏了?

你可能會有疑問,瀏覽器存儲了資源,那它把資源存儲在哪裏呢？

• memory cache

MemoryCache顧名思義，就是將資源緩存到內存中，等待下次訪問時不須要從新下載資源，而直接從內存中獲取。Webkit早已支持memoryCache。
目前Webkit資源分紅兩類，一類是主資源，好比HTML頁面，或者下載項，一類是派生資源，好比HTML頁面中內嵌的圖片或者腳本連接，分別對應代碼中兩個類：MainResourceLoader和SubresourceLoader。雖然Webkit支持memoryCache，可是也只是針對派生資源，它對應的類爲CachedResource，用於保存原始數據（好比CSS，JS等），以及解碼過的圖片數據。
複製代碼

• disk cache

DiskCache顧名思義，就是將資源緩存到磁盤中，等待下次訪問時不須要從新下載資源，而直接從磁盤中獲取，它的直接操做對象爲CurlCacheManager。
複製代碼

訪問緩存優先級

1. 先在內存中查找,若是有,直接加載。
2. 若是內存中不存在,則在硬盤中查找,若是有直接加載。
3. 若是硬盤中也沒有,那麼就進行網絡請求。
4. 請求獲取的資源緩存到硬盤和內存。

瀏覽器緩存的分類

• 強緩存
• 協商緩存

須要說明的是 瀏覽器會先判斷是否命中強緩存

瀏覽器緩存的優勢

1. 減小了冗餘的數據傳輸 節省了網費
2. 減小了服務器的負擔，大大提高了網站的性能
3. 加快了客戶端加載網頁的速度

瀏覽器在第一次請求發生後，再次請求時：

1. 驗證是否命中強緩存，若是命中，就直接使用緩存了。
2. 若是沒有命中強緩存，就發請求到服務器檢查是否命中協商緩存。
3. 若是命中協商緩存，服務器會返回 304 告訴瀏覽器使用本地緩存。
4. 不然，返回最新的資源。

強緩存

強緩存是利用http的返回頭中的Expires或者Cache-Control兩個字段來控制的，用來表示資源的緩存時間。

Expires： 該字段是http1.0時的規範，它的值爲一個絕對時間的GMT格式的時間字符串，好比Expires:Mon,18 Oct 2066 23:59:59 GMT。這個時間表明着這個資源的失效時間，在此時間以前即命中緩存

缺點：

1. 因爲失效時間是一個絕對時間，因此當服務器與客戶端時間誤差較大時，就會致使緩存混亂

Cache-Control： Cache-Control是http1.1時出現的header信息，主要是利用該字段的max-age值來進行判斷，它是一個相對時間，例如Cache-Control:max-age=3600，表明着資源的有效期是3600秒。cache-control除了該字段外，還有下面幾個比較經常使用的設置值：

• no-cache：不使用本地緩存。須要使用緩存協商，先與服務器確認返回的響應是否被更改，若是以前的響應中存在ETag，那麼請求的時候會與服務端驗證，若是資源未被更改，則能夠避免從新下載。
• no-store：直接禁止遊覽器緩存數據，每次用戶請求該資源，都會向服務器發送一個請求，每次都會下載完整的資源。
• public：能夠被全部的用戶緩存，包括終端用戶和CDN等中間代理服務器。
• private：只能被終端用戶的瀏覽器緩存，不容許CDN等中繼緩存服務器對其緩存。

Cache-Control與Expires能夠在服務端配置同時啓用，同時啓用優先級 Cache-Control > Expires

協商緩存

當強緩存沒有命中的時候，瀏覽器會發送一個請求到服務器，服務器根據 header 中的部分信息來判斷是否命中緩存。若是命中，則返回304 ，告訴瀏覽器資源未更新，可以使用本地的緩存。

header： `Last-Modify/If-Modify-Since `和 `ETag/If-None-Match`
複製代碼

Last-Modify/If-Modify-Since：瀏覽器第一次請求一個資源的時候，服務器返回的 header 中會加上 Last-Modify，Last-modify 是一個時間標識該資源的最後修改時間。 當瀏覽器再次請求該資源時，request 的請求頭中會包含 If-Modify-Since，該值爲緩存以前返回的 Last-Modify。服務器收到 If-Modify-Since 後，根據資源的最後修改時間判斷是否命中緩存。 若是命中緩存，則返回 304，而且不會返回資源內容，而且不會返回 Last-Modify。

缺點:

1. 短期內資源發生了改變,Last-Modified並不會發生變化。
2. 週期性變化,若是這個資源在一個週期內修改回原來的樣子了，咱們認爲是可使用緩存的，可是 Last-Modified 可不這樣認爲,所以便有了 ETag

ETag/If-None-Match 與 Last-Modify/If-Modify-Since 不一樣的是，Etag/If-None-Match返回的是一個校驗碼。ETag 能夠保證每個資源是惟一的，資源變化都會致使 ETag變化。服務器根據瀏覽器上送的 If-None-Match 值來判斷是否命中緩存。 與 Last-Modified 不同的是，當服務器返回 304 Not Modified的響應時，因爲 ETag從新生成過，response header中還會把這個 ETag 返回，即便這個 ETag 跟以前的沒有變化。

Last-Modified 與 ETag 是能夠一塊兒使用的，服務器會優先驗證 ETag，一致的狀況下，纔會繼續比對 Last-Modified，最後才決定是否返回 304。

實踐檢驗

我討厭文字記憶，因此堅決果斷選了理工科～～ talk is cheap , show me your code

⚠️ 實踐過程控制檯不要禁用緩存

利用koa啓動server服務 port：8000

引入靜態資源 加載前端模版 去內蒙的航拍 哈哈哈 有我

如圖可見 初次訪問 正常加載模版頁面 cache與圖片資源 1.jpeg

實現強緩存

1. 服務端設置響應頭Cache-Control 資源有效期爲300秒

app.use(async (ctx, next) => {
  ctx.set({
    'Cache-Control': 'max-age=300'  
  });
  await next();
});
複製代碼

2. 刷新頁面

響應頭的 Cache-Control變成了 max-age=300

驗證訪問緩存的優先級: 第一次的網絡請求,瀏覽器把圖片資源緩存到了磁盤和內存裏，根據約定 應該會先從內存中找資源

3. 再次刷新頁面

確實是從內存獲取的

4.關掉頁面再從新打開 （內存是存在進程中的,因此關閉該頁面,內存中的資源也被釋放掉了,磁盤中的資源是永久性的,因此還存在）

from disk cache 從磁盤中獲取資源

5.接下來 有效期 300秒 後.

緩存失效 從新向服務器載入資源

實現協商緩存 協商緩存本地測試直接攔截url給定code

Cache-Control 取默認值 no-cache

app.use( async(ctx, next) => {
// 協商緩存測試
if(ctx.url === '/imgs/1.jpeg'){
  ctx.status = 304;
  return;
}
await next();
});
複製代碼

服務器返回304 同時size變小了不少 由於只返回了必要信息

也可利用現成的插件幫咱們計算文件的ETag

npm install koa-tag -D
npm install koa-conditional-get -D
複製代碼

具體細節不演示了

經測試發現當加載資源發生變化時（好比換了張圖片），ETag改變了進而協商緩存策略失效了

動手試一下 理解並掌握它！

寫在最後的話

day day up ！