一、什么是緩存？

瀏覽器緩存就是瀏覽器保存通過HTTP獲取的所有資源，是瀏覽器將網絡資源保存到本地的一種行為。那么，為什么要緩存？一個優(yōu)秀的緩存策略可以縮短網頁請求資源的距離，減少等待時間；并且由于緩存文件可以重復利用，可以減少帶寬，降低網絡負荷；減少了對源服務器的請求，有效降低服務器的壓力。

對于一個數據請求來說，可以分為發(fā)起網絡請求、后端處理、瀏覽器響應三個步驟。瀏覽器緩存可以幫助我們在第一和第三步驟中優(yōu)化性能。比如說直接使用緩存而不發(fā)起請求，或者發(fā)起了請求但后端存儲的數據和前端一致，那么就沒有必要再將數據回傳回來，這樣就減少了響應數據。

store.png

二、緩存的資源去哪里了呢？

如上圖所示，緩存位置分為四種，并且各自有優(yōu)先級，當依次查找緩存但沒有找到時才會去請求網絡。

1、Service Worker

Service Worker 是運行在瀏覽器背后的獨立線程，一般可以用來實現緩存功能。使用Service Worker的話，傳輸協(xié)議必須是HTTPS，因為Service Worker中涉及到請求攔截。Service Worker的緩存與瀏覽器其他內建的緩存機制不同，它可以讓我們自由控制緩存哪些文件、如何匹配緩存、如何讀取緩存，并且緩存是持續(xù)性的。如果需要向服務器發(fā)起請求的就轉給服務器，如果可以直接使用緩存的就直接返回緩存不再轉給服務器。
Service Worker 實現緩存一般分為三個步驟：首先需要注冊Service Worker ；然后監(jiān)聽到install事件以后就可以緩存需要的文件；在下次用戶訪問的時候就可以通過攔截請求的方式查詢是否存在緩存，存在的話就直接讀取，否則就去請求數據。
當Service Worker 沒有命中緩存的時候，需要去調用fetch函數獲取數據，也就是說，如果沒有在Service Worker 命中緩存的話，會根據緩存查找優(yōu)先級去查找數據，但是不管是從Memory Cache還是網絡請求中獲取的數據，瀏覽器都會顯示是從Service Worker 獲取的。

2、Memory Cache

Memory Cache就是將資源緩存到內存中，等下次訪問時不需要重新下載資源，而直接從內存中獲取，主要包含的是當前頁面中已經抓取到的資源，例如頁面上已經下載的樣式、腳本、圖片等。讀取內存中的數據肯定比磁盤快，但是內存緩存持續(xù)性短，會隨著進程的釋放而釋放，一旦關閉tab頁面，內存中的緩存就釋放了。
當我們訪問過頁面以后，再次刷新頁面，可以發(fā)現很多數據都來自于內存緩存。內存緩存中有一塊重要的緩存資源就是preloader指令（例如<link rel="prefetch">）下載的資源。眾所周知preloader的相關指令已經是頁面優(yōu)化的常見手段之一，它可以一邊解析js/css文件，一邊網絡請求下一個資源。
需要注意的是，內存緩存在緩存資源時不關心返回資源的HTTP緩存頭Cache-Control是什么值，同時資源的匹配也并非僅僅是對URL做匹配，還可能會對Content-Type、CORS 等其他特征做校驗。

3、Disk Cache

Disk Cache 就是將資源緩存在磁盤里，等待下次訪問時不需要重新下載資源，直接從磁盤中獲取，它的直接操作對象是CurlCacheManager。讀取速度慢點，與Memory Cache相比，勝在容量和存儲時效上。
在所有瀏覽器緩存中，Disk Cache覆蓋面基本是最大的。它會根據HTTP Header 中的字段判斷哪些資源需要緩存，哪些資源可以不請求直接使用，以及哪些資源已經過期需要重新請求。而且在跨站點的情況下，相同地址的資源一旦被硬盤緩存下來，就不會再次去請求數據，絕大部分的緩存都來自Disk Cache，關于HTTP的協(xié)議頭中的緩存字段，會在下文中詳細介紹。

因為CSS文件加載一次就可渲染出來，不需要頻繁讀取，所以它不適合緩存到內存中。但是js類腳本文件隨時都會執(zhí)行，如果腳本存在磁盤中，執(zhí)行腳本的時候需要從磁盤中取到內存中，這樣IO開銷就會很大，有可能導致瀏覽器失去響應。

4、Push Cache

Push Cache，顧名思義，推送緩存，它是HTTP/2中的內容，當以上三種緩存都沒有命中的時候，它才會被使用。它只在會話（Session）中存在，一旦回話結束即被釋放，并且緩存時間也很短暫。在Chrome瀏覽器中只有5分鐘左右，同時它也并非嚴格的執(zhí)行HTTP頭中的緩存指令。

如果以上四種緩存都沒有命中的話，就需要發(fā)起網絡請求資源了，請求獲取的資源緩存到磁盤和內存中。

那么瀏覽器怎么確定一個資源該不該緩存呢？瀏覽器對緩存的處理是根據第一次請求資源時返回的響應頭來決定的。如下圖所示，

image.png

第一，瀏覽器每次發(fā)起請求時，都會先在瀏覽器緩存中查找該請求的結果和緩存標識；
第二，瀏覽器每次拿到返回的請求結果都會將該結果和緩存標識存入瀏覽器緩存中。
以上就是瀏覽器緩存機制的關鍵，它確保了每個請求的緩存存入與讀取。

三、緩存策略

出于性能考慮，大部分接口都應該做好緩存策略。通常瀏覽器緩存策略分為兩種：強緩存和協(xié)商緩存，并且緩存策略是通過設置 HTTP Header 來實現的。瀏覽器在向服務器請求資源時，首先判斷是否命中強緩存，再判斷是否命中協(xié)商緩存。

1、強緩存

強緩存不會向服務器發(fā)送請求，直接從緩存中獲取資源，在Chrome控制臺的network可以看到該請求返回200的狀態(tài)碼，并且size顯示from disk Cache 或者from memory cache。
HTTP header 中的信息指的是 Expires 和 Cache-Control。

- Expires

緩存過期時間，用來指定資源到期的時間，是服務器的具體的時間點。該字段是HTTP 1.0的規(guī)范，它的值為一個絕對時間的GMT格式的時間字符串，比如Expires:Mon,18 Oct 2020 23:59:59 GMT。這個時間代表著這個資源的失效時間，在此時間之前，即命中緩存。這種方式有一個明顯的缺點，由于失效時間是一個絕對時間，所以當服務器與客戶端時間偏差較大時或者修改了本地時間，就會導致緩存混亂。

- Cache-Control

Cache-Control 是HTTP 1.1時出現的header信息，主要是利用該字段的max-age值來判斷，它是一個相對時間。例如Cache-Control:max-age=3600，代表著資源的有效期是3600秒，表示3600秒后就過期，需要重新請求。Cache-Control除了該字段外，還有下面幾個比較常用的設置值：

• no-cahce：需要進行協(xié)商緩存，發(fā)送請求到服務器確認是否使用緩存。
• no-store：禁止使用緩存，每一次都要重新請求數據。
• public：可以被所有用戶緩存，包括終端用戶和CDN等中間代理服務器。
• private：只能被終端用戶的瀏覽器緩存，不允許CDN等中間代理服務器對其緩存。
• s-max-age=30：覆蓋max-age，作用一樣，只在代理服務器生效
• max-stale=30：30秒內，即使緩存過期，也使用該緩存
• min-fresh=30：希望在30秒內獲取最新的響應。

Cache-Control與Expires可以在服務端配置同時啟用，同時啟用的時候Cache-Control優(yōu)先級較高。在某些不支持HTTP 1.1的環(huán)境下，Expires就會發(fā)揮用處。所以Expires其實是過時的產物，現階段它的存在只是一種兼容性的寫法。

2、協(xié)商緩存

當強緩存沒有命中的時候，瀏覽器會發(fā)送一個請求到服務器，服務器根據header中的部分信息來判斷是否命中緩存。如果命中，返回304 Not Modified，告訴瀏覽器資源未更新，可以使用本地緩存。
HTTP header 中的信息指的是Last-Modify/If-Modify-Since 和 ETag/If-none-Match。

- Last-Modified/If-Modified-Since

瀏覽器第一次請求一個資源時，服務器返回的response header中會加上Last-Modified，Last-Modified是一個時間標識該資源的最后修改時間。

Last-Modified：Fri，22 Jul 2016 01:47:00 GMT

當瀏覽器再次請求該資源時，request的請求頭中會包含If-Modified-Since，該值為緩存之前返回的Last-Modified。服務器收到If-Modified-Since后，根據資源的最后修改時間判斷是否命中緩存。如果命中，返回304，并且不會返回資源內容，并且不會返回Last-Modified。

缺點：

• 短時間內資源發(fā)生改變的話，Last-Modified 并不會發(fā)生變化，因為它以秒計時。
• 周期性變化。如果這個資源在一個周期內修改回原來的樣子，我們認為是可以使用緩存的，但是Last-Modified可不這樣認為，因此便有了ETag。

- ETag/If-none-Match

ETag是服務器響應請求時，返回當前資源文件的一個唯一標識（由服務器生成）。ETag/If-none-Match返回的是一個校驗碼。ETag可以保證每一個資源都是唯一的，資源變化都會導致ETag變化。

瀏覽器在下一次請求資源時，會將上一次返回的ETag值放到request header中的If-none-Match里，服務器只需要比較客戶端傳來的If-none-Match跟自己服務器上該資源的ETag值是否一致，如果匹配不上，直接以常規(guī)get 200回包形式將新的資源以及新的ETag返回給客戶端；如果匹配一致，則直接返回304給客戶端直接使用本地緩存即可。

與Last-Modified不同的是，當服務器返回304 Not Modified 的響應時，由于ETag 重新生成過，response header 中還會把ETag返回，即使這個ETag與之前的沒有變化。

二者的不同之處:

• 首先在精確度上，Etag要優(yōu)于Last-Modified。
  Last-Modified的時間單位是秒，如果某個文件在1秒內改變了多次，那么他們的Last-Modified其實并沒有體現出來修改，但是Etag每次都會改變確保了精度；如果是負載均衡的服務器，各個服務器生成的Last-Modified也有可能不一致。
• 第二在性能上，Etag要遜于Last-Modified，畢竟Last-Modified只需要記錄時間，而Etag需要服務器通過算法來計算出一個hash值。
• 第三在優(yōu)先級上，服務器校驗優(yōu)先考慮Etag。

Last-Modified 與 ETag 是可以一起使用的，服務器會優(yōu)先驗證ETag ，一致的情況下，才會繼續(xù)比對Last-Modified，最后才決定是否返回304。

四、緩存機制

強緩存優(yōu)先于協(xié)商緩存進行，若強緩存生效則直接使用緩存，若不生效則進行協(xié)商緩存，協(xié)商緩存由服務器決定是否使用緩存，若協(xié)商緩存失效，那么代表該請求的緩存失效，返回200，重新返回資源和緩存標識，再存入瀏覽器緩存中；若是生效則返回304，繼續(xù)使用緩存。具體流程圖如下：

image.png

如果瀏覽器沒有設置緩存策略，對于這種情況，瀏覽器有個啟發(fā)式的算法，通常會取響應頭中的Date減去Last-Modified 值得10%作為緩存時間。

五、實際場景應用緩存策略

1、頻繁變動的資源

Cache-Control：no-cache

對于頻繁變動的資源，首先需要使用Cache-Control：no-cache 使瀏覽器每次都請求服務器，然后配合ETag或者Last-Modified來驗證資源是否有效，這樣的做法雖然不能節(jié)省請求數量，但是能顯著減少響應數據大小。

2、不常變化的資源

Cache-Control：max-age=31536000

通常在處理這類資源時，給它們的Cache-Control：配置一個很大的max-age=31536000（一年），這樣瀏覽器之后請求相同的URL會命中強制緩存。而為了解決更新的問題，就需要在文件名或路徑中添加hash，版本號等動態(tài)字符，之后更改動態(tài)字符，從而達到更改引用URL的目的，讓之前的強制緩存失效（其實不是失效，只是不再使用了而已）。在線提供的類庫，如jquery-3.3.1.min.js，lodash.min.js等均采用這個模式。

六、用戶行為對瀏覽器緩存的影響

所謂用戶行為對瀏覽器緩存的影響，指的是用戶在瀏覽器如何操作時，會觸發(fā)怎樣的緩存策略，主要分三種：

• 打開網頁，地址欄輸入地址：查找disk cache中是否有匹配，如有則使用，如沒有則發(fā)送網略請求。
• 普通刷新（F5）：跳過強緩存，會檢查協(xié)商緩存。因為TAB頁沒有被關閉，因此memory cache 是可用的，會被優(yōu)先使用，其次才是disk cache。
• 強制刷新（Ctrl+F5）：瀏覽器不使用緩存，直接從服務器加載，跳過強緩存和協(xié)商緩存，因此發(fā)送的請求頭部均帶有Cache-control：no-cache（為了兼容，還帶了pragma：no-cache），服務器直接返回200和最新內容。

七、不會被緩存的情況

1、HTTP信息頭中包含Cache-Control:no-cache ，pragma:no-cache（HTTP1.0），或Cache-Control： max-age=0 等告訴瀏覽器不用緩存的請求;
2、需要根據cookie，認證信息等決定輸入內容的動態(tài)請求是不能被緩存的；
3、經過HTTPS安全加密的請求不能被緩存；
4、POST請求無法被緩存；
5、HTTP響應頭中不包含Last-Modified/Etag，也不包含 Cache-Control/Expires 的請求無法被緩存;

八、緩存種類

我們常見且常用的存儲方式主要有兩種：cookie、webStorage（localstorage和sessionstorage）。
HTML5提供了兩種客戶端存儲數據的新方法，localstorage和sessionstorage，掛載在Window對象下。webStorage 是本地存儲，數據不是由服務器請求傳遞的，從而它可以存儲大量的數據，而不影響網站的性能。webStorage的目的是為了克服由cookie帶來的一些限制，當數據需要被嚴格控制在客戶端時，無須持續(xù)的將數據發(fā)給服務器。比如客戶端需要緩存的一些用戶行為和數據，或者從接口獲取的一些短期內不會更新的數據。

1、cookie

cookie是什么

cookie的本職工作并非本地存儲，而是維護狀態(tài)。因為HTTP協(xié)議是無狀態(tài)的，HTTP協(xié)議自身不對請求和響應之間的通信狀態(tài)進行保存，通俗來說，服務器不知道用戶上一次做了什么，這嚴重阻礙了交互式web應用程序的實現，在典型的網上購物場景中，用戶瀏覽了幾個頁面，買了一盒餅干和兩瓶飲料，最后結賬時，由于HTTP的無狀態(tài)性，不通過額外的手段，服務器并不知道用戶到底買了什么，于是就誕生了cookie，它就是用來繞開HTTP無狀態(tài)的額外手段之一，服務器可以設置或讀取cookie中包含信息，借此維護用戶與服務器會話的狀態(tài)。

cookie是服務器發(fā)送到瀏覽器的一小段數據，會在瀏覽器下一次請求的時候被攜帶并發(fā)送到服務器。我們可以把cookie理解為一個存儲在瀏覽器中的一個小小的文本文件，它附著在HTTP請求上，在瀏覽器和服務器之間飛來飛去，它可以攜帶用戶信息，當服務器檢查cookie時，便可以獲取到客戶端的狀態(tài)。

在剛才的購物場景中，當用戶選購了第一個商品，服務器在向用戶發(fā)送網頁的同時，還發(fā)送了一段cookie，記錄著那項商品的信息，當用戶訪問另一個頁面，瀏覽器就會把cookie發(fā)送給服務器，于是服務器知道他選購了什么，用戶繼續(xù)選購飲料，服務器就在原來那段cookie里追加新的商品信息，結賬時，服務器讀取發(fā)送來的cookie就行。

使用場景

• 會話狀態(tài)管理（如用戶登錄狀態(tài)、購物車、游戲分數等等）
• 個性化設置（用戶自定義設置、主題等）
• 瀏覽器行為跟蹤（如跟蹤分析用戶行為進行商品推薦等）

原理

第一次訪問網站時，瀏覽器發(fā)出請求，服務器響應請求后，會在響應頭里添加一個Set-Cookie選項，將cookie放入到響應請求中，在瀏覽器第二次發(fā)請求的時候，會通過cookie請求頭部將cookie信息發(fā)送到服務器，服務器會辨認用戶信息，另外，cookie的過期時間、域、路徑、有效期、適用站點都可以根據需要來指定。cookie實際上存儲在計算機的本地硬盤里。

cookie的缺陷

• cookie不夠大
  cookie的大小限制在4KB左右，對于復雜的存儲需求來說是不夠用的。當cookie超過4KB時，它將面臨被裁的命運。這樣看來，cookie只能用來存取少量的信息，此外很多瀏覽器對一個站點的cookie個數也是有限制的。
• 過多的cookie會帶來巨大的性能浪費
  cookie是緊跟域名的。同一個域名下的所有請求，都會攜帶cookie。如果僅僅是請求一個圖片或一個css文件，也要攜帶一個cookie飛來飛去，而且cookie里攜帶的信息并不需要，隨著請求的疊加，這樣不必要的cookie越來越多，造成巨大的性能浪費。
  cookie是用來維護用戶信息的，而域名下所有請求都會攜帶cookie，但對于靜態(tài)文件的請求，攜帶cookie信息根本沒有用，此時可以通過CDN的域名和主站的域名分開來解決。
• 由于HTTP請求中的cookie是明文傳遞的，所以安全性成問題，很容易被用戶篡改，除非用HTTPS。（session可以解決這個問題）
• cookie默認有效期理論上在用戶關閉頁面后就失效，實際上在20分鐘左右，不同瀏覽器策略不同，但是后端可以強制設置有效期。

讀寫操作

①、cookie的HttpOnly屬性

為避免跨域腳本XSS攻擊，通過JavaScript的Document.cookie API無法訪問帶有
HttpOnly標記的cookie，它們只應該發(fā)送給服務器。如果包含服務端session信息的cookie不想被客戶端JavaScript腳本調用，那么就應該為其設置HttpOnly標記。

Set-cookie：id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

②、如何設置cookie

在HTTP響應頭中設置Set-cookie即可。具體參數如下：

Set-cookie：<cookie-name>=<cookie-value>
// 普通的cookie，所有參數默認
Set-cookie：<cookie-name>=<cookie-value>; Expires=<date>
// cookie的最長有效時間，形式為符合HTTP-date規(guī)范的時間戳
Set-cookie：<cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
// 在cookie失效之前需要經過的秒數。一位或多位非零數字。假如Expires和Max-Age都存在，那么Max-Age優(yōu)先級更高。
Set-cookie：<cookie-name>=<cookie-value>; Domain=<domain-value>
// 指定cookie可以送達的主機名。假如沒有指定，那么默認值為當前文檔訪問地址中的主機部分，但不包含子域名。域名之前的點號會被忽略，假如指定了域名，那么相當于各個子域名也包含在內了。
Set-cookie：<cookie-name>=<cookie-value>; Path=<path-value>
// 指定一個URL路徑，這個路徑必須出現在要請求的資源的路徑中才可以發(fā)送Cookie首部。
Set-cookie：<cookie-name>=<cookie-value>; Secure
// 設置了HttpOnly屬性的cookie不能使用JavaScript經由Document.cookie屬性。
XmlHttRrequest和Request APIs 進行訪問，以防范跨站腳本攻擊（XSS）。
Set-cookie：<cookie-name>=<cookie-value>; SamSite=Strict
Set-cookie：<cookie-name>=<cookie-value>; SamSite=Lax
上面兩個允許服務器設定一則cookie不隨著跨域請求一起發(fā)送，這樣可以在一定程度上防范跨站請求偽造攻擊（CSRF）。

③、如何刪除cookie

通過設置cookie的有效期在當前時間之前，就可以刪除cookie了。

var delete_cookie = function (name) {
  document.cookie = name + '=;expires=Thu, 01 Jan 1970 00:00:01 GMT;';
};

2、localstorage

localstorage用于存儲一個域名下的需要永久存儲在本地的數據，這些數據可以一直被訪問，直到這些數據被刪除。

特點：

• 保存的數據長期存在，除非清除瀏覽器緩存。下一次訪問該網站時，網頁可以直接讀取以前保存的數據，
• 大小為5M左右
• 僅在客戶端使用，不和服務端通信
• 接口封裝較好

使用場景：

localstorage可以作為瀏覽器本地緩存方案，用來提升網頁首屏渲染速度，根據第一次請求返回時，將一些不變的信息直接存儲在本地。

讀寫操作

localstorage.setItem(key, value)  保存數據，key和value都必須是字符串類型
localstorage.getItem(key)  獲取數據
localstorage.removeItem(key)  刪除數據
localstorage.clear()  刪除全部數據

3、sessionstorage

sessionstorage保存的數據用于瀏覽器的一次會話，當會話結束（通常是該窗口關閉），數據被清空；sessionstorage特別的一點在于，即便是相同域名的兩個頁面，只要他們不在同一個瀏覽器窗口打開，那么它們的sessionstorage內容便無法共享；localstorage在所有同源窗口都是共享的；cookie也是在所有同源窗口中都是共享的。除了保存的期限長短不同，sessionstorage與localstorage的屬性和方法完全一樣。

特點

• 會話級別的瀏覽器存儲
• 大小為5M左右
• 僅在客戶端使用，不和服務端通信
• 接口封裝較好

使用場景

有效對表單信息進行維護，比如刷新時，表單信息不丟失。單頁面應用較多，敏感賬號一次性登錄等。

讀寫操作

sessionstorage.setItem(key, value)  保存數據，key和value都必須是字符串類型
sessionstorage.getItem(key)  獲取數據
sessionstorage.removeItem(key)  刪除數據
sessionstorage.clear()  刪除全部數據

4、三者區(qū)別

5、indexedDB

indexedDB是一個運行在瀏覽器上的非關系型數據庫，沒有存儲上限，一般不會小于250M，它不僅可以存儲字符串，還可以存儲二進制數據。

特點

• 鍵值對存儲
  indexedDB 內部采用對象倉庫（object store）存放數據。所有類型的數據都可以直接存入，包括JavaScript對象，對象倉庫中，數據以“鍵值對”形式保存，每一個數據記錄都有對應的主鍵，主鍵是獨一無二的。
• 異步
  indexedDB 操作時不會鎖死瀏覽器，用戶依然可以進行其他操作，這與localstorage形成對比，后者的操作是同步的，異步設計是為了防止大量數據的讀寫，拖慢網頁的表現。
• 支持事務
  indexedDB 支持事務（transaction），這意味著一系列操作步驟之中，只要有一步失敗，整個事務就都取消，數據庫回滾到事務發(fā)生之前的狀態(tài)，不存在只改寫一部分數據的情況。
• 同源限制
  indexedDB 受到同源限制，每一個數據庫對應創(chuàng)建它的域名，網頁只能訪問自身域名下的數據庫，而不能訪問跨域的數據庫。
• 儲存空間大
  indexedDB 的儲存空間比localstorage大得多，一般來說不少于250M，甚至沒有上限。
• 支持二進制儲存
  indexedDB 不僅可以儲存字符串，還可以儲存二進制數據。

常見操作

• 建立打開indexedDB --- window.indexedDB.open("testDB")

function openDB(name) {
    var request = window.indexedDB.open(name) //建立打開IndexedDB
    console.log('request', request)
    request.onerror = function (e) {
        console.log('open indexdb error')
    }
    request.onsuccess = function (e) {
        myDB.db = e.target.result //這是一個 IDBDatabase對象，這就是IndexedDB對象
        console.log(myDB.db) //此處就可以獲取到db實例
    }
}
var myDB = {
    name: 'testDB',
    version: '1',
    db: null
}
    
openDB(myDB.name)

• 關閉indexedDB --- indexedDB.close()

function closeDB(db){
    db.close();
}

• 刪除indexedDB --- window.indexedDB.deleteDatabase(indexdb)

function deleteDB(name) {
  indexedDB.deleteDatabase(name)
}