<轉>瀏覽器緩存機制

本篇博客轉載自github，原文地址：瀏覽器緩存篇

 

前言

在前端開發中，緩存有利於加快網頁的加載速度，同時緩存可以被反覆利用，因此能夠減小流量和帶寬的開銷。

緩存的分類有不少種，CDN緩存、數據庫緩存、代理服務器緩存和瀏覽器緩存。

本篇講解一下Web開發中的瀏覽器緩存。這個在實際開發環境中每每也會被問到，或者使用到。如何去準確認清楚緩存的概念，是前端必需要去學習的。

 

正文

瀏覽器的緩存問題，主要指的是http的緩存——即協議層。而h5新增的storage和數據庫緩存，那是應用層緩存，並不被計入本篇的分析內容裏面。下面咱們正式開始來進行緩存的分析。

協議層的緩存，其實，能夠被分紅強制緩存和對比緩存。

一、強制緩存

首先，咱們先來看一張強制緩存時的時序圖，來了解一下強制緩存在不一樣狀況下的請求模式：

從圖中，咱們不難看出，只有當緩存失效時，纔會去服務器獲取最新資源的方式，就是強制緩存。而在協議層的字段中，能夠形成強制緩存的字段有兩個Expires和Cache-Control。

1.0的時候見到我——Expires

最先使用的是Expires字段，該字段表示緩存到期時間，即有效時間+當時服務器的時間，而後將這個時間設置在header中返回給服務器。所以，該時間是一個絕對時間，舉例說明：

Expires: Thu, 10 Nov 2017 08:45:11 GMT

圖片示例：

在響應消息頭中，設置這個字段以後，就能夠告訴瀏覽器，在未過時以前不須要再次請求。

可是，這個字段設置時有缺點：

因爲是絕對時間，用戶可能會將客戶端本地的時間進行修改，而致使瀏覽器判斷緩存失效，從新請求該資源，同時，還致使客戶端與服務端的時間不一致，導致緩存失效。

1.1的時候我來了——Cache-Control

已知Expires的缺點以後，在HTTP/1.1中，增長了一個字段Cache-Control，該字段表示資源緩存的最大有效時間，在該時間內，客戶端不須要向服務器發送請求

這二者的區別就是前者是絕對時間，然後者是相對時間。咱們不妨舉個例子來講明一下：

Cache-Control: max-age=2592000

圖片示例：

下面列舉一下Cache-Control的字段能夠帶的值：

①、max-age：即最大有效時間，在上面的例子中咱們能夠看到

②、no-cache：表示沒有緩存，即告訴瀏覽器該資源並無設置緩存

③、s-maxage：同max-age，可是僅用於共享緩存，如CDN緩存

④、public：多用戶共享緩存，默認設置

⑤、private：不可以多用戶共享，HTTP認證以後，字段會自動轉換成private。

總結：自從http1.1開始，Expires逐漸被Cache-Control取代。

     Cache-Control是一個相對時間，即便客戶端時間發生改變，相對時間也不會隨之改變，這樣能夠保持服務器和客戶端的時間一致性。並且Cache-Control的可配置性比較強大。

 

二、對比緩存

扯完強制緩存，咱們來看看對比緩存。在解釋這個以前，是否能夠先猜測一下，強制緩存是，緩存在未過有效期時，不須要請求資源。那麼，對比緩存的原理又該如何呢？

廢話很少說，咱們也先從對比緩存的時序圖講起，如圖：

對比緩存的過程是，先從緩存中獲取對應的數據標識，而後向服務器發送請求，確認數據是否更新，若是更新，則返回新數據和新緩存；反之，則返回304狀態碼，告知客戶端緩存未更新，可繼續使用。

這正好彌補了一些強制緩存的缺陷。對比緩存主要應用於一些時常須要動態更新的資源文件。

對比緩存在協議裏的字段是Last-Modified和If-Modified-Since。

別人的好夥伴——Last-Modified

Last-Modified：服務器告知客戶端，資源最後一次被修改的時間，例如

Last-Modified: Thu, 10 Nov 2015 08:45:11 GMT

If-Modified-Since：再次請求時，請求頭中帶有該字段，服務器會將If-Modified-Since的值與Last-Modified字段進行對比，若是相等，則表示未修改，響應304；

                   反之，則表示修改了，響應200狀態碼，返回數據；這個字段能夠和Cache-Control配合使用。

可是它仍是有必定缺陷的：

①、若是資源更新的速度是秒如下單位，那麼該緩存是不能被使用的，由於它的時間單位最低是秒。

②、若是文件是經過服務器動態生成的，那麼該方法的更新時間永遠是生成的時間，儘管文件可能沒有變化，因此起不到緩存的做用。

我來完善它——Etag

因爲Last-modified仍是存在缺陷的，儘管大多數狀況下，會使用它，但當遇到咱們上面所說的場景時，咱們可能就須要瞭解一下，咱們另外一個小夥伴了——Etag。

Etag存儲的是文件的特殊標識(通常都是hash生成的)，服務器存儲着文件的Etag字段，能夠在與每次客戶端傳送If-no-match的字段進行比較，若是相等，則表示未修改，響應304；

反之，則表示已修改，響應200狀態碼，返回數據。

最後，經過一張原理圖，咱們來加深一下記憶：

至此爲止，兩種緩存類型的緩存方式已經闡述完成了，不知你是否已經心中已經有個大體的印象，當別人問起時，你能夠對答如流。但願咱們一同進步吧，fighting。

 

三、瀏覽器行爲引發的不一樣

最後，咱們來聊聊瀏覽器行爲會引發緩存的變化吧。

下面說一下瀏覽器的行爲會產生怎樣的請求：

①、刷新網頁 => 若是緩存沒有失效，瀏覽器會直接使用緩存；反之，則向服務器請求數據

②、手動刷新（F5） => 瀏覽器會認爲緩存失效，在請求服務器時加上Cache-Control: max-age=0字段，而後詢問服務器數據是否更新。

③、強制刷新（Ctrl + F5） => 瀏覽器會直接忽略緩存，在請求服務器時加上Cache-Control: no-cache字段，而後從新向服務器拉取文件。

 

四、移動端的緩存處理

在PC端或許這樣子的緩存機制就已經足夠了，由於PC端不須要爲網絡的問題擔憂。

可是，移動端卻不行，任何一個網絡請求的增長，對於移動端的加載消耗時間都是比較大的（誰叫移動端的網太差呢，3G、2G）。那麼，上述的緩存有什麼問題呢？

其實，強制緩存是沒有太大問題的，由於只要緩存不到期，是不會想服務器發送請求的；可是若是是對比緩存的狀況下，304的問題就比較巨大，由於它會形成無用的請求。

每次在使用緩存前，都會向服務器發送請求確認，致使網絡的延時。

一次完美的緩存必須保證兩點：

①、數據緩存以後，儘可能減小服務器的請求

②、若是資源更新的話，必須使得客戶端的資源一塊兒更新。

因此，通常咱們會運用的方式是：

在資源文件後面加上表示，如config.f1ec3.js、config.v1.js之類的，而後給資源設置較長的緩存時間，如一年；

Cache-Control: max-age=31536000

這樣子，就不會形成304的回包現象。

而後一旦資源發生更新時，咱們能夠改變資源後面的標識符，實現靜態資源非覆蓋式更新。

 

總結

本篇大體分析了瀏覽器緩存部分的分類狀況，以及細化分析。主要可分爲：

一、強制緩存

~Expires字段

~Cache-Control字段

二、對比緩存

~Last-Modefied字段

~Etag標識

三、瀏覽器行爲引發的緩存變化

四、移動端的緩存策略