大型web應用緩存必不可少，本文我們講了前端本地緩存，服務器端緩存，HTTP緩存機制，CDN緩存，html5離線存儲等緩存策略。

緩存策略
　　瀏覽器端的緩存規則
　　對于瀏覽器端的緩存來講，這些規則是在HTTP協議頭和HTML頁面的Meta標簽中定義的。他們分別從新鮮度和校驗值兩個維度來規定瀏覽器是否可以直接使用緩存中的副本，還是需要去源服務器獲取更新的版本。
　　新鮮度（過期機制）：也就是緩存副本有效期。一個緩存副本必須滿足以下條件，瀏覽器會認為它是有效的，足夠新的：
　　 含有完整的過期時間控制頭信息（HTTP協議報頭），并且仍在有效期內；
　　 瀏覽器已經使用過這個緩存副本，并且在一個會話中已經檢查過新鮮度
　　滿足以上兩個情況的一種，瀏覽器會直接從緩存中獲取副本并渲染。
　　校驗值（驗證機制）：服務器返回資源的時候有時在控制頭信息帶上這個資源的實體標簽Etag（Entity Tag），它可以用來作為瀏覽器再次請求過程的校驗標識。如過發現校驗標識不匹配，說明資源已經被修改或過期，瀏覽器需求重新獲取資源內容。

一個重要的概念

緩存命中率：一個緩存的有效性是依照緩存的命中率來度量。它是根據得到數據請求次數與所有請求次數的比率。緩存命中率高意味著有很高的比率數據是從緩存中獲取到數據的。
　　Web緩存的作用
　　減少網絡帶寬消耗
　　 降低服務器壓力
　　減少網絡延遲，加快頁面打開速度
　　HTTP緩存機制
　　緩存行為主要由緩存策略決定，而緩存策略由內容擁有者設置。這些策略主要通過特定的HTTP頭部來清晰地表達。
　　當一個用戶發起一個靜態資源請求的時候，瀏覽器會通過以下幾步來獲取資源：
　　 本地緩存階段：先在本地查找該資源，如果有發現該資源，而且該資源還沒有過期，就使用這一個資源，完全不會發送http請求到服務器；
　　協商緩存階段：如果在本地緩存找到對應的資源，但是不知道該資源是否過期或者已經過期，則發一個http請求到服務器,然后服務器判斷這個請求，如果請求的資源在服務器上沒有改動過，則返回304，讓瀏覽器使用本地找到的那個資源；
 　　緩存失敗階段：當服務器發現請求的資源已經修改過，或者這是一個新的請求(在本來沒有找到資源)，服務器則返回該資源的數據，并且返回200， 當然這個是指找到資源的情況下，如果服務器上沒有這個資源，則返回404。
用戶操作行為與緩存
　　瀏覽器中的操作對緩存的影響:
 　　強制刷新 ? 當按下ctrl+F5來刷新頁面的時候, 瀏覽器將繞過各種緩存(本地緩存和協商緩存), 直接讓服務器返回最新的資源;
　　普通刷新 ? 當按下F5來刷新頁面的時候,瀏覽器將繞過本地緩蹲來發送請求到服務器, 此時, 協商緩存是有效的
　　 回車或轉向 ? 當在地址欄上輸入回車或者按下跳轉按鈕的時候, 所有緩存都生效
　　本地緩存階段
　　Expires
　　指定緩存到期GMT的絕對時間，如果設了max-age，max-age就會覆蓋expires。如果expires到期需要重新請求。
　　Cache-Control
　　Cache-Control:這個是http 1.1中為了彌補 Expires 缺陷新加入的。
　　對已緩存的內容進行控制：
　　Cache-control: public表示緩存的版本可以被代理服務器或者其他中間服務器識別。
　　Cache-control: private意味著這個文件對不同的用戶是不同的。只有用戶自己的瀏覽器能夠進行緩存，公共的代理服務器不允許緩存。
　　Cache-control: no-cache意味著文件的內容不應當被緩存。這在搜索或者翻頁結果中非常有用，因為同樣的URL，對應的內容會發生變化。
　　其他相關控制字段：
　　max-age: 指定緩存過期的相對時間秒數，max-ag=0或者是負值，瀏覽器會在對應的緩存中把Expires設置為1970-01-01 08:00:00 。
　　s-maxage: 類似于max-age，只用在共享緩存上，比如proxy.
　　public: 通常情況下需要http身份驗證的情況，響應是不可cahce的，加上public可以使它被cache。
　　no-cache: 強制瀏覽器在使用cache拷貝之前先提交一個http請求到源服務器進行確認。這對身份驗證來說是非常有用的,能比較好的遵守 (可以結合public進行考慮)。它對維持一個資源總是最新的也很有用，與此同時還不完全喪失cache帶來的好處)，因為它在本地是有拷貝的，但是在用之前都進行了確認，這樣http請求并未減少，但可能會減少一個響應體。
　　no-store: 告訴瀏覽器在任何情況下都不要進行cache，不在本地保留拷貝。
　　must-revalidate: 強制瀏覽器嚴格遵守你設置的cache規則。
　　proxy-revalidate: 強制proxy嚴格遵守你設置的cache規則。
　　用法舉例: Cache-Control: max-age=3600, must-revalidate
　　cache:使用本地緩存，不發生請求。
　　協商緩存階段
　　Last-Modified & if-modified-since
　　Last-Modified與If-Modified-Since是一對報文頭，屬于http 1.0。
　　last-modified是WEB服務器認為對象的最后修改時間，比如文件的最后修改時間，動態頁面的最后產生時間。
　　ETag & If-None-Match
　　ETag與If-None-Match是一對報文，屬于http 1.1。
　　ETag可以用來解決這種問題。ETag是一個文件的唯一標志符。就像一個哈希或者指紋，每個文件都有一個單獨的標志，只要這個文件發生了改變，這個標志就會發生變化。
　　ETag機制類似于樂觀鎖機制，如果請求報文的ETag與服務器的不一致，則表示該資源已經被修改過來，需要發最新的內容給瀏覽器。
　　同時使用這兩個報文頭，在完全匹配If-Modified-Since和If-None-Match即檢查完修改時間和Etag之后，如都與服務器的相符，服務器返回304，否則，發送最新內容給瀏覽器。
　　Etag/lastModified過程如下：
　　1.客戶端請求一個頁面（A）。
　　2.服務器返回頁面A，并在給A加上一個Last-Modified/ETag。
　　3.客戶端展現該頁面，并將頁面連同Last-Modified/ETag一起緩存。
　　4.客戶再次請求頁面A，并將上次請求時服務器返回的Last-Modified/ETag一起傳遞給服務器。
　　5.服務器檢查該Last-Modified或ETag，并判斷出該頁面自上次客戶端請求之后還未被修改，直接返回響應304和一個空的響應體。
　　 304：通過If-Modified-Since If-Match判斷資源是否修改，如未修改則返回304，發生了一次請求，但請求內容長度為0，節省了帶寬。 如果有多臺負載均衡的服務器，不同服務器計算出的Etag可能不同，這樣就會造成資源的重復加載。
　　Etag 主要為了解決 Last-Modified 無法解決的一些問題：
　　1、一些文件也許會周期性的更改，但是他的內容并不改變(僅僅改變的修改時間)，這個時候我們并不希望客戶端認為這個文件被修改了，而重新GET；
　2、某些文件修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒)；
　　3、某些服務器不能精確的得到文件的最后修改時間。
　　其他標簽
　　Content-Length：盡管并沒有在緩存中明確涉及，Content-Length頭部在設置緩存策略時很重要。某些軟件如果不提前獲知內容的大小以留出足夠空間，則會拒絕緩存該內容。
　　Vary：緩存系統通常使用請求的主機和路徑作為存儲該資源的鍵。當判斷一個請求是否是請求同樣內容時，Vary頭部可以被用來提醒緩存系統需要注意另一個附加頭部。它通常被用來告訴緩存系統同樣注意Accept-Encoding頭部，以便緩存系統能夠區分壓縮和未壓縮的內容。
　　服務器端緩存
　　CDN緩存
　　CDN緩存，也叫網關緩存、反向代理緩存。瀏覽器先向CDN網關發起WEB請求，網關服務器后面對應著一臺或多臺負載均衡源服務器，會根據它們的負載請求，動態地請求轉發到合適的源服務器上。

CDN緩存策略

CDN邊緣節點緩存策略因服務商不同而不同，但一般都會遵循http標準協議，通過http響應頭中的Cache-control: max-age的字段來設置CDN邊緣節點數據緩存時間。
　　當客戶端向CDN節點請求數據時，CDN節點會判斷緩存數據是否過期，若緩存數據并沒有過期，則直接將緩存數據返回給客戶端；否則，CDN節點就會向源站發出回源請求（back to the sourcerequest），從源站拉取最新數據，更新本地緩存，并將最新數據返回給客戶端。
　　CDN服務商一般會提供基于文件后綴、目錄多個維度來指定CDN緩存時間，為用戶提供更精細化的緩存管理。
CDN緩存時間會對“回源率”產生直接的影響。若CDN緩存時間較短，CDN邊緣節點上的數據會經常失效，導致頻繁回源，增加了源站的負載，同時也增大的訪問延時；若CDN緩存時間太長，會帶來數據更新時間慢的問題。開發者需要增對特定的業務，來做特定的數據緩存時間管理。
　　CDN緩存刷新CDN邊緣節點對開發者是透明的，相比于瀏覽器Ctrl+F5的強制刷新來使瀏覽器本地緩存失效，開發者可以通過CDN服務商提供的“刷新緩存”接口來達到清理CDN邊緣節點緩存的目的。這樣開發者在更新數據后，可以使用“刷新緩存”功能來強制CDN節點上的數據緩存過期，保證客戶端在訪問時，拉取到最新的數據。
　　CDN的優勢
　　 CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低；
　　大部分請求在CDN邊緣節點完成，CDN起到了分流作用，減輕了源站的負載。
　　CDN緩存的缺點
　　當網站更新時，如果CDN節點上數據沒有及時更新，即便用戶再瀏覽器使用Ctrl +F5的方式使瀏覽器端的緩存失效，也會因為CDN邊緣節點沒有同步最新數據而導致用戶訪問異常。
　　Combo服務
　　Combo服務，也就是我們在最終拼接生成頁面資源引用的時候，并不是生成多個獨立的link標簽，而是將資源地址拼接成一個url路徑，請求一種線上的動態資源合并服務，從而實現減少HTTP請求的需求。
　　/??fle1,file2,file3,...的url請求響應就是動態combo服務提供的，它的原理很簡單，就是根據url找到對應的多個文件，合并成一個文件來響應請求，并將其緩存，以加快訪問速度。
　　但它也存在一些缺陷：
　　瀏覽器有url長度限制，因此不能無限制的合并資源。
　　如果用戶在網站內有公共資源的兩個頁面間跳轉訪問，由于兩個頁面的combo的url不一樣導致用戶不能利用瀏覽器緩存來加快對公共資源的訪問速度。如果combo的url中任何一個文件發生改變，都會導致整個url緩存失效，從而導致瀏覽器緩存利用率降低。
　　HTML5緩存思路
　　HTML5離線應用緩存manifest
　　用戶可離線訪問你的應用，這對于無法隨時保持聯網狀態的移動終端用戶來說尤其重要
　　 用戶訪問本地的緩存文件，通常意味著更快的訪問速度
　　僅僅加載被修改過的資源，避免同一資源對服務器多次的請求，大大降低了對服務器的訪問壓力manifest文件羅列了需要被緩存的文件清單。