瀏覽器的緩存(1)

親，你知道緩存是什麼嗎？

其實緩存就像辦健身卡，我第一次花了699辦了一年的卡以後，接下來的一年我均可以避免費鍛鍊。 在web 中， 咱們交的不是錢，而是空間，咱們耗費必定的空間以後，可以得到網頁打開速度質的飛躍。 當咱們第一次訪問一個頁面時，咱們須要交納必定的空間， 將下載的css,js,html已經img等相關資源保存在本地。 在第二次，第三次。。。訪問時，就能夠不用去下載文件了。
一般來講，設置文件的緩存有兩種方式，一種是在服務器內設置響應頭文件，另一個是使用h5的manifest文件來進行相關設置.
咱們先看看報文設置響應頭的方式吧

服務器的緩存協商

這種方式設置的緩存有兩種，一種是須要服務器驗證，另一種是不用發送請求驗證。

ETag/Last-Modified

這兩種方式作法相似，都要向服務器發送一次請求進行驗證。簡直，緩存就緩存唄，爲何還要驗證呢？ 其實，這是該協議的一種特有方式，發送一次驗證主要是檢查文件是否發生變化。

ETag

ETag是用來計算文件的內容是否發生變化，好比，你在文件中刪除一個空格，這樣都算文件內容發生變化。 一般作法是用md5或者SHA1算法，計算出文件的惟一值。 在前端其實均可以完成， 找到一個文件文件解析的md5算法，而後將文件傳入，就能夠獲得ETag的值。 不過這裏，咱們着重點並非讓你生成Etag，而是看看ETag在緩存中的重要做用。
ETag是HTTP/1.1A的一種辦法，由Web服務器生成，並寫入響應頭中。

//response Headers
ETag:"751F63A30AB5F98F855D1D90D217B356"

接着，到了瀏覽器以後，便緩存在本地。 當下次打開一樣的文章時，會在請求頭中發送If-None-Match, 給服務器檢查文件是否發生變化。若是沒有，則告訴瀏覽器使用本地的，不然返回新文件

//request Headers
If-None-Match: "751F63A30AB5F98F855D1D90D217B356"

一般狀況下，服務器默認是打開Etag的，可是爲了防止你的同事，或者後臺哥哥的後臺配置文件不正確，關閉了Etag，這時候，就須要你對對配置文件作一些設置。 這裏我以Nginx爲例:
打開ngnix.conf文件，檢查是否有如下語句:

etag off;
more_set_headers -s 404 -t 'ETag';
more_clear_headers 'Etag';

若是有則將其刪除掉。而後重啓nginx就能夠了。他們將Etag關閉的緣由其實也很簡單，就是由於，Etag打開以後會增長服務器的負載，形成性能的侷限性，因此，關閉或者打開Etag都要通過權衡的。

Last-Modified

這和文檔內容信息驗證不一樣，這裏採用的是日期驗證辦法。 即，服務器上會對文件打上一個文件改動的日期，而後客戶端接受該日期，下次請求時，返回該日期，服務器驗證，若是日期未變，則告訴瀏覽器使用本地緩存便可。
即，在服務器的相應頭中，能夠設置Last-Modified，來啓用這一緩存協議.

//Response Header
Last-Modified:Tue, 03 Mar 2015 01:38:18 GMT

接受到這一響應頭以後，瀏覽器會對該文件作一個緩存，並保存該日期。當下次請求的時候，會經過If-Modified-Since將日期傳入並驗證:

If-Modified-Since:Tue, 03 Mar 2015 01:38:18 GMT

若是日期未變，則告訴瀏覽器使用緩存。
那咱們一般應該怎樣啓用服務器這一功能呢？
默認狀況下，服務器會對靜態資源發送Last-modified的tag。 可是，須要注意，Last-Modified的更新時間只能以秒來計，若是你文件改動過於頻繁，Last-Modified是無效的(不過，誰牛逼到1s內能屢次更新文件嘞~)
實際上.Last-Modified的這個標籤的咱們一般並不會單獨使用它，一般與expires結合，造成一個可降級的緩存.

Expires/Cache-Control

Expires/Cache協議與上述驗證協議最大的不一樣在於，他能夠省略發送驗證請求環節，不須要服務器的驗證，而直接使用本地緩存。 一般這種方式，適用於，項目穩定，版本迭代很少的時候。

Expires

在服務器端能夠設置Expires的一個絕對時間。

//Response Headers
Expires:Tue, 03 May 2016 09:33:34 GMT

這告訴瀏覽器,在2016.5.3號以前,能夠直接使用該文本的緩存副本。可是，可能會由於服務器和客戶端的GMT時間不一樣，會有必定的bug。 因此，這裏只提議在長時間緩存的狀況下使用。不然，應該選擇Cache-Control.
那在服務器端該怎麼設置呢？ 這裏以nginx爲例:

location ~* \.(?:css|js)$ {
  expires 1d;
  access_log off;
  add_header Cache-Control "public";
}

經過expires設置過時時間爲一天，此時，服務器會根據當前的時間，加上一天.同時添加Expires和Cache-Control頭部標籤。
即,獲得的Response Header爲:

Expires: Fri, 28 Feb 2014 10:42:09 GMT
Cache-Control: max-age=86400 //24*60*60

(HTTP規定，若是出現max-age和expires，則max-age默認覆蓋掉expires)
當expires爲負數表示no-cache，正數或零表示max-age=time。
若是你不想緩存，能夠直接設置:

expires -1;  //永遠過時，Cache-Control: no-cache

詳細能夠直接參閱:nginx配置

Cache-Control

這應該是HTTP1.1爲了解決HTTP1.0中expires的時間差的bug，而新添加的一個tag. 他的配置項不少，其實徹底均可以取代expires(如今大多數服務器都支持). 引用一段原話:

Cache-Control 頭在 HTTP/1.1 規範中定義，取代了以前用來定義響應緩存策略的頭（例如 Expires）。當前的全部瀏覽器都支持 Cache-Control，所以，使用它就夠了。

不過，目前大部分服務器都會將二者添加上，由於HTTP規定，若是Cache-Control和expires同時出現的話，expires會默認被覆蓋掉。
此時，返回的響應碼再也不是304(文件未改動),而是200(資源成功訪問).

當前每次發送請求以前瀏覽器會檢查緩存系統裏，是否有相應文件的備份，若是有的話，則直接從本地模仿一個Response頭
理論知識鋪墊完畢，咱們來take a look. 看看cache-control 有哪些能夠配置的屬性(如下屬性都跟在cache-control後)

public: 共有緩存，可被緩存代理服務器緩存,好比CDN
private: 私有緩存，不能被共有緩存代理服務器緩存，可被用戶的代理緩存如瀏覽器。

max-age=[秒]：表示在這個時間範圍內緩存是新鮮的無需更新。相似Expires時間，不過這個時間是相對的，而不是絕對的。也就是某次請求成功後多少秒內緩存是新鮮的。

s-maxage=[秒]：相似max-age, 除了僅應用於共享緩存（如代理）。

no-cache：這裏不是不緩存的意思，只是每次在使用緩存以前都強制發送請求給源服務器進行驗證，檢查文件該沒改變(其實這裏和ETag/Last區別不大)

no-store：就是禁止緩存，不讓瀏覽器保留緩存副本

must-revalidate：告訴瀏覽器，你這必須再次驗證檢查信息是否過時, 返回的代號就不是200而是304了。

proxy-revalidate：相似must-revalidate，除了只能應用於代理緩存。

好比，這裏我能夠設置Cache-Control爲:

//Response Headers
Cache-Control:private, max-age=0, must-revalidate

該文件是一個私有文件,只能被瀏覽器緩存，而不能被代理緩存。max-age標識該緩存當即過時，其實和no-cache實際上區別不大. 而後must-revalidate告訴瀏覽器，你必須給我再驗證文件過沒過時，好比接下來可能會驗證Last-Modified或者ETag.若是沒有過時則使用本地緩存.
其實上面能夠直接等同於:

//Response Headers
Cache-Control:private,no-cache

使用no-store的結果

//Response Headers
Cache-Control:no-store;

這樣代表，無論一不同都須要從新下載. 強烈表示，不讓你使用緩存文件。後續的就不會去驗證ETag了。
固然，若是你將IE6那種古老的瀏覽器考慮進來的話，那你乾脆就作的不要臉一點，直接用下面的tag就行:

Cache-Control: no-cache, no-store, must-revalidate //HTTP1.1
Pragma: no-cache //HTTP1.0
Expires: 0 //Proxy

不過如今基本上也沒有不支持Cache-Control的瀏覽器了。因此，正常狀況下，能夠直接使用.以下的策略來進行設置:(From google developer)

咱們一般在nginx怎麼配置對應的cache-control頭呢？

##設置no-cache
//Nginx
expires -1;
//cache-control
Cache-Control:no-cache

##設置max-age=0
//Nginx
expires 0;
//cache-control
Cache-Control:max-age=0

##設置其餘頭部
//nginx
add_header  Cache-Control "no-cache";
add_header  Pragma no-cache;

上面說的基本上是服務器的響應頭，那在瀏覽器的Request headers裏存在cache-control表明什麼呢？
當請求頭中有:Cache-Control: max-age=0,表示緩存須要進行驗證(ETag||Last-Modified)，若是緩存未過時,則可使用。
當請求頭中有:Cache-Control: no-cache,表示瀏覽器只能獲取最新的文件。 和Response Header中的no-store相對應。

組合拳法之緩存策略

上面介紹的last/ETag/Expires/Cache都是HTTP協議的緩存策略。固然，緩存不止這一種，好比在HTML 4.0中定義的某些meta也能夠實現自定義緩存的

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />

但，實際狀況是，這些meta只能在file:// 本地文件中使用，若是是服務器則默認被覆蓋。如今目前主流的就是使用HTTP1.1協議緩存
不過咱們通常都不會單獨使用某一項。 可是，組合以後他們的效果是怎樣的呢？

若是你的網頁不是什麼特別定製化的(私密)的，使用緩存能給你網站的性能帶來極大的提高。因此很推薦使用。
一個網站，說白了就是HTML+JS+CSS+fonts+img 這幾類文件(視頻就呵呵了).
咱們能夠針對這幾類文件作一些緩存層級

文件	緩存層級
HTML	Cache-Control: no-cache,must-revalidate
JS	Cache-Control:private,max-age=86400
CSS	Cache-Control:max-age=2629000
img\fonts	Cache-Control:max-age=2629000

上面只是一個簡單的設置，要知道HTML是必定不能緩存的(大部分網頁)。 緩存設置時間應該在你版本穩定以後設置，不然會得不償失。 另外設置Cache-Control還能夠配合ETag或者Last-Modified進行補償驗證，若是後面文件變化也能夠及時反映出來。

清除緩存

最經常使用的辦法就是修改文件的版本號，或者生成隨機文件名。
若是你只是在本地測試，想手動清楚緩存的話，可使用.
可是在Mac中不同，使用command+R = F5刷新， command+shift+R= ctrl+F5硬性從新加載.另外，即便你設置了緩存策略，可是他也不會進行緩存的文件。 這些文件包括動態認證的文件，好比須要cookie驗證，輸入驗證碼等產生的文件。POST請求文件不能被緩存。