摘要：緩存緩存，也叫網關緩存反向代理緩存。瀏覽器先向網關發起請求，網關服務器后面對應著一臺或多臺負載均衡源服務器，會根據它們的負載請求，動態將請求轉發到合適的源服務器上。雖然這種架構負載均衡源服務器之間的緩存沒法共享，但卻擁有更好的處擴展性。

工作上遇到一個這樣的需求，一個H5頁面在APP端，如果勾選已讀狀態，則下次打開該鏈接，會跳過此頁面。用到了HTML5 的本地存儲 API 中的 localStorage作為解決方案，回顧了下Web緩存的知識，感覺自己了解得不夠多，所以想整理下，加深理解。

Web緩存是指一個Web資源（如html頁面，圖片，js，數據等）存在于Web服務器和客戶端（瀏覽器）之間的副本。緩存會根據進來的請求保存輸出內容的副本；當下一個請求來到的時候，如果是相同的URL，緩存會根據緩存機制決定是直接使用副本響應訪問請求，還是向源服務器再次發送請求。比較常見的就是瀏覽器會緩存訪問過網站的網頁，當再次訪問這個URL地址的時候，如果網頁沒有更新，就不會再次下載網頁，而是直接使用本地緩存的網頁。只有當網站明確標識資源已經更新，瀏覽器才會再次下載網頁。

減少網絡帶寬消耗（當Web緩存副本被使用時，只會產生極小的網絡流量，可以有效的降低運營成本。）

降低服務器壓力（給網絡資源設定有效期之后，用戶可以重復使用本地的緩存，減少對源服務器的請求，間接降低服務器的壓力。同時，搜索引擎的爬蟲機器人也能根據過期機制降低爬取的頻率，也能有效降低服務器的壓力。）

減少網絡延遲，加開頁面打開速度。

在Web應用領域，Web緩存大致可以分為以下幾種類型：

Web應用，特別是SNS類型的應用，往往關系比較復雜，數據庫表繁多，如果頻繁進行數據庫查詢，很容易導致數據庫不堪重荷。為了提供查詢的性能，會將查詢后的數據放到內存中進行緩存，下次查詢時，直接從內存緩存直接返回，提供響應效率。比如常用的緩存方案有memcached等。

服務器端緩存包含代理服務器緩存和CDN緩存:

代理服務器是瀏覽器和源服務器之間的中間服務器，瀏覽器先向這個中間服務器發起Web請求，經過處理后（比如權限驗證，緩存匹配等），再將請求轉發到源服務器。代理服務器緩存的運作原理跟瀏覽器的運作原理差不多，只是規模更大。可以把它理解為一個共享緩存，不只為一個用戶服務，一般為大量用戶提供服務，因此在減少相應時間和帶寬使用方面很有效，同一個副本會被重用多次。常見代理服務器緩存解決方案有Squid等，這里不再詳述。

CDN（Content delivery networks）緩存，也叫網關緩存、反向代理緩存。CDN緩存一般是由網站管理員自己部署，為了讓他們的網站更容易擴展并獲得更好的性能。瀏覽器先向CDN網關發起Web請求，網關服務器后面對應著一臺或多臺負載均衡源服務器，會根據它們的負載請求，動態將請求轉發到合適的源服務器上。雖然這種架構負載均衡源服務器之間的緩存沒法共享，但卻擁有更好的處擴展性。從瀏覽器角度來看，整個CDN就是一個源服務器。

瀏覽器緩存（Browser Caching）是瀏覽器端保存數據用于快速讀取或避免重復資源請求的優化機制，有效的緩存使用可以避免重復的網絡請求和瀏覽器快速地讀取本地數據，整體上加速網頁展示給用戶。

應用層緩存指的是從代碼層面上，通過代碼邏輯和緩存策略，實現對數據，頁面，圖片等資源的緩存，可以根據實際情況選擇將數據存在文件系統或者內存中，減少數據庫查詢或者讀寫瓶頸，提高響應效率。

接下來從Web前端的角度著重了解瀏覽器端緩存機制。

根據標準，到目前為止，H5 一共有6種緩存機制，有些是之前已有，有些是 H5 才新加入的。

 1. 瀏覽器緩存機制
 2. Dom Storgage（Web Storage）存儲機制
 3. Web SQL Database 存儲機制 
 4. Application Cache（AppCache）機制 
 5. Indexed Database （IndexedDB） 
 6. File System API

瀏覽器緩存機制，其實主要就是HTTP協議定義的緩存機制（如： Expires； Cache-control等）。但是也有非HTTP協議定義的緩存機制，如使用HTML Meta 標簽，Web開發者可以在HTML頁面的節點中加入標簽，代碼如下：

　上述代碼的作用是告訴瀏覽器當前頁面不被緩存，每次訪問都需要去服務器拉取。使用上很簡單，但只有部分瀏覽器可以支持，而且所有緩存代理服務器都不支持，因為代理不解析HTML內容本身。下面主要介紹HTTP協議定義的緩存機制。

通過 HTTP 協議頭里的 Cache-Control（或 Expires）和 Last-Modified（或 Etag）等字段來控制文件緩存的機制。這應該是 WEB 中最早的緩存機制了，是在 HTTP 協議中實現的，有點不同于 Dom Storage、AppCache 等緩存機制，但本質上是一樣的。可以理解為，一個是協議層實現的，一個是應用層實現的。

Pragma：設置頁面是否緩存，為Pragma則緩存，no-cache則不緩存。

Expires：有了Pragma來禁用緩存，自然也需要有個東西來啟用緩存和定義緩存時間，對http1.0而言，Expires就是做這件事的首部字段。 Expires的值對應一個GMT（格林尼治時間），比如Mon, 22 Jul 2002 11:12:01 GMT來告訴瀏覽器資源緩存過期時間，如果還沒過該時間點則不發請求。
如果Pragma頭部和Expires頭部同時存在，則起作用的會是Pragma，需要注意的是，響應報文中Expires所定義的緩存時間是相對服務器上的時間而言的，其定義的是資源“失效時刻”，如果客戶端上的時間跟服務器上的時間不一致（特別是用戶修改了自己電腦的系統時間），那緩存時間可能就沒啥意義了。

Cache-Control： 針對上述的“Expires時間是相對服務器而言，無法保證和客戶端時間統一”的問題，http1.1新增了 Cache-Control 來定義緩存過期時間。注意：若報文中同時出現了 Expires 和 Cache-Control，則以 Cache-Control 為準。

(1) 最常見的，比如服務器回包：Cache-Control:max-age=600 表示文件在本地應該緩存，且有效時長是600秒（從發出請求算起）。在接下來600秒內，如果有請求這個資源，瀏覽器不會發出 HTTP 請求，而是直接使用本地緩存的文件。
(2) Cache-Control: no-cache；這個很容易讓人產生誤解，使人誤以為是響應不被緩存。實際上她是會被緩存的，只不過每次在向客戶端（瀏覽器）提供響應數據時，緩存都要向服務器評估緩存響應的有效性。
(3) Cache-Control: no-store；這個才是響應不被緩存的意思。

Last-Modified/If-Modified-Since：
(1) Last-Modified：標示這個響應資源的最后修改時間。web服務器在響應請求時，告訴瀏覽器資源的最后修改時間。
(2) If-Modified-Since：當資源過期時（使用Cache-Control標識的max-age），發現資源具有Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。web服務器收到請求后發現有頭If-Modified-Since 則與被請求資源的最后修改時間進行比對。若最后修改時間較新，說明資源又被改動過，則響應整片資源內容（寫在響應消息包體內），HTTP 200；若最后修改時間較舊，說明資源無新修改，則響應HTTP 304 (無需包體，節省瀏覽)，告知瀏覽器繼續使用所保存的cache。

Etag/If-None-Match：Etag/If-None-Match也要配合Cache-Control使用。

(1) Etag：web服務器響應請求時，告訴瀏覽器當前資源在服務器的唯一標識（生成規則由服務器覺得）。Apache中，ETag的值，默認是對文件的索引節（INode），大小（Size）和最后修改時間（MTime）進行Hash后得到的。

(2) If-None-Match：當資源過期時（使用Cache-Control標識的max-age），發現資源具有Etage聲明，則再次向web服務器請求時帶上頭If-None-Match （Etag的值）。web服務器收到請求后發現有頭If-None-Match 則與被請求資源的相應校驗串進行比對，決定返回200或304。

既生Last-Modified何生Etag？

你可能會覺得使用Last-Modified已經足以讓瀏覽器知道本地的緩存副本是否足夠新，為什么還需要Etag（實體標識）呢？HTTP1.1中Etag的出現主要是為了解決幾個Last-Modified比較難解決的問題：
(1) Last-Modified標注的最后修改只能精確到秒級，如果某些文件在1秒鐘以內，被修改多次的話，它將不能準確標注文件的修改時間。
(2) 如果某些文件會被定期生成，當有時內容并沒有任何變化，但Last-Modified卻改變了，導致文件沒法使用緩存。
(3) 有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形。
Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的唯一標識符，能夠更加準確的控制緩存。Last-Modified與ETag是可以一起使用的，服務器會優先驗證ETag，一致的情況下，才會繼續比對Last-Modified，最后才決定是否返回304。

小結
(1) 瀏覽器第一次請求：

(2) 瀏覽器第二次請求：

DOM Storage 是指 HTML5 的本地存儲 API sessionStorage 和 localStorage。在介紹HTML5本地存儲之前，先來看一看前面幾個存儲方式的概念。

(1) HTTP Cookie: Cookie是為了解決HTTP無狀態的特性而出現的，也可以叫用戶識別機制。常用的用戶識別機制包括：

承載用戶信息的HTTP首部

客戶端IP地址追蹤技術，通過用戶的IP地址對其進行識別

用戶登錄，用認證機制來識別用戶

胖URL，一種在URL中嵌入識別信息的技術

cookie，一種強大且高效的持久身份識別技術

對于購物網站而言，cookie是非常重要的，為了實現購物車功能，把已選物品加入cookie，可以實現不同頁面之間數據的同步，同時在提交訂單的時候又會把這些cookie傳到后臺，大大方便了前后端開發。
設置cookie:

function setCookie(name, value, options) {
      var expires = options.expires;
      var path = options.path;
      var domain = options.domain;
      var secure = options.secure;

      // 緩存時間轉為日期對象
      if (typeof expires === "number") {
        expires = new Date(new Date().getTime() + expires * 864e+5); // 緩存時間單位：天
      }
        document.cookie =
        name + "=" + escape(value) +
        (expires ? "; expires=" + expires.toUTCString() : "") +
        (path ? "; path=" + path : "") +
        (domain ? "; domain=" + domain : "") +
        (secure ? "; secure" : "");

      return true;
    }

獲取cookie:

function getCookie(name) {
      var arr = document.cookie.match(new RegExp("(^| )" + name + "=([^;]*)(;|$)"));
      if (arr !== null) {
        return unescape(arr[2]);
      }

      // return null;
      return "";
    }

(2) userData是微軟在上世紀90年代的瀏覽器大戰時推出的本地存儲方案，借助DHTML的behaviour屬性來存儲本地數據， 允許每個頁面最多存儲64K數據，每個站點最多640K數據，userData的缺點顯而易見，它不是Web標準的一部分，除非你的程序只需要支持IE， 否則它基本沒什么用處。
(3) Flash cookie的名字有些誤導，它實際上和HTTP cookie并不是一回事，或許它的名字應該叫做"Flash本地存儲”，Flash cookie默認允許每個站點存儲不超過100K的數據，如果超出了，Flash會自動向用戶請求更大的存儲空間，借助Flash的 ExternalInterface接口，你可以很輕松地通過Javascript操作Flash的本地存儲。Flash的問題很簡單，就是因為它是 Flash。
(4) Gears是Google在07年發布的一個開源瀏覽器插件，旨在改進各大瀏覽器的兼容性，Gears內置了一個基于SQLite的嵌入式 SQL數據庫，并提供了統一API對數據庫進行訪問，在取得用戶授權之后，每個站點可以在SQL數據庫中存儲不限大小的數據，Gears的問題就是 Google自己都已經不用它了。
(5) HTML5 的本地存儲 API sessionStorage 和 localStorage
Dom Storage 是通過存儲字符串的 Key/Value 對來提供的，并提供 5MB （不同瀏覽器可能不同，分 HOST)的存儲空間（Cookies 才 4KB)。另外 Dom Storage 存儲的數據在本地，不像 Cookies，每次請求一次頁面，Cookies 都會發送給服務器。
DOM Storage 分為 sessionStorage 和 localStorage。localStorage 對象和 sessionStorage 對象使用方法基本相同，它們的區別在于作用的范圍不同。sessionStorage 用來存儲與頁面相關的數據，它在頁面關閉后無法使用。而 localStorage 則持久存在，在頁面關閉后也可以使用。
簡單用法：

var name = sessionStorage.setItem("name","wangjuan");
alert(sessionStorage.getItem("name"));

并不是所有的瀏覽器都支持這兩個對象。在沒有原生支持localStorage的瀏覽器中使用時，MDN給出了兼容代碼：https://developer.mozilla.org...
不同瀏覽器對于這兩種用法的差異的兼容代碼可參考: https://github.com/mortzdk/lo...

H5 也提供基于 SQL 的數據庫存儲機制，用于存儲適合數據庫的結構化數據。根據官方的標準文檔，Web SQL Database 存儲機制不再推薦使用，將來也不再維護，而是推薦使用 AppCache 和 IndexedDB。
查看更多：戳這里

Application Cache（簡稱 AppCache)似乎是為支持 Web App 離線使用而開發的緩存機制。它的緩存機制類似于瀏覽器的緩存（Cache-Control 和 Last-Modified）機制，都是以文件為單位進行緩存，且文件有一定更新機制。但 AppCache 是對瀏覽器緩存機制的補充，不是替代。
AppCache 的原理有兩個關鍵點：manifest 屬性和 manifest 文件。
W3C 官方的一個例子：

上面 HTML 文檔，引用外部一個 JS 文件和一個 GIF 圖片文件，在其 HTML 頭中通過 manifest 屬性引用了一個 appcache 結尾的文件（即manifest文件）。
緩存的結果是：我們在 Google Chrome 瀏覽器中打開這個 HTML 鏈接，JS 功能正常，圖片也顯示正常。禁用網絡，關閉瀏覽器重新打開這個鏈接，發現 JS 工作正常，圖片也顯示正常。當然也有可能是瀏覽緩存起的作用，我們可以在文件的瀏覽器緩存過期后，禁用網絡再試，發現 HTML 頁面也是正常的。
manifest 文件就是以 appcache 結尾的文件，是一個普通文件文件，列出了需要緩存的文件。
完整的 manifest 文件，如：

CACHE MANIFEST
# 2012-02-21 v1.0.0
/theme.css
/logo.gif
/main.js

NETWORK:
login.asp

FALLBACK:
/html/ /offline.html 

了解更多：戳我

IndexedDB 也是一種數據庫的存儲機制，但不同于已經不再支持的 Web SQL Database。IndexedDB 不是傳統的關系數據庫，indexedDB中沒有表的概念，類似于 Dom Storage 的 key-value 的存儲方式，但功能更強大，且存儲空間更大。它的特點是：

以key-value 的方式存取對象，可以是任何類型值或對象，包括二進制。

可以對對象任何屬性生成索引，方便查詢。

較大的存儲空間，默認推薦250MB(分 HOST)，比 Dom Storage 的5MB要大的多。

通過數據庫的事務（tranction）機制進行數據操作，保證數據一致性。

異步的 API 調用，避免造成等待而影響體驗。

了解更多：資料1，資料2

File System API 是 H5 新加入的存儲機制。它為 Web App 提供了一個虛擬的文件系統，就像 Native App 訪問本地文件系統一樣。由于安全性的考慮，這個虛擬文件系統有一定的限制。Web App 在虛擬的文件系統中，可以進行文件（夾）的創建、讀、寫、刪除、遍歷等操作。

File System API 也是一種可選的緩存機制，和前面的 SQLDatabase、IndexedDB 和 AppCache 等一樣。File System API 有自己的一些特定的優勢：

可以滿足大塊的二進制數據（ large binary blobs）存儲需求。

可以通過預加載資源文件來提高性能。

可以直接編輯文件。

了解更多：資料

之前對web緩存沒有系統的認知，接觸過一兩點，不過也不是很懂。這兩天查看了許多資料，雖然看過之后理解得也不太深入，不過有個整體的認知也好，后面自己遇到相關問題再細究。
參考資料：
1、九種瀏覽器端緩存機制知多少
2、瀏覽器緩存原理
3、Web緩存機制系列
4、Web 前端實現本地存儲
5、H5 緩存機制淺析 - 移動端 Web 加載性能優化
6、瀏覽器緩存機制
7、瀏覽器緩存機制詳解
8、透過瀏覽器看HTTP緩存
9、淺談瀏覽器http的緩存機制
10、瀏覽器緩存機制淺析