前端緩存機制

瀏覽器緩存步驟

1）瀏覽器在加載資源時，先根據這個資源的一些http header判斷它是否命中強緩存，強緩存若是命中，瀏覽器直接從本身的緩存中讀取資源，不會發請求到服務器。好比某個css文件，若是瀏覽器在加載它所在的網頁時，這個css文件的緩存配置命中了強緩存，瀏覽器就直接從緩存中加載這個css，連請求都不會發送到網頁所在服務器；

2）當強緩存沒有命中的時候，瀏覽器必定會發送一個請求到服務器，經過服務器端依據資源的另一些http header驗證這個資源是否命中協商緩存，若是協商緩存命中，服務器會將這個請求返回，可是不會返回這個資源的數據，而是告訴客戶端能夠直接從緩存中加載這個資源，因而瀏覽器就又會從本身的緩存中去加載這個資源；

3）強緩存與協商緩存的共同點是：若是命中，都是從客戶端緩存中加載資源，而不是從服務器加載資源數據；區別是：強緩存不發請求到服務器，協商緩存會發請求到服務器。

4）當協商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數據。

實例： 以常見的請求一個CSS樣式來講。

第一次請求

一般服務器會傳送這4個字段過來， 多是4個都要，也可能一個字段也沒有。這裏主要講解4個字段都存在的狀況。

第二次請求

前端：首先，瀏覽器會檢查Cache-Control與Expires，有Cache-Control的狀況下,以其爲標準，若是超時，則向後端發送請求，請求中會帶上 If-Modified-Since,If-None-Match。

後臺：後端服務器接收到請求以後，會對這兩個字段進行對比，一樣以If-None-Match爲標準，沒有If-None-Match的狀況下,比對If-Modified-Since，若是比對後發現文件沒有過時，即Etag沒有發生變化，或者Last-Modified與If-Modified-Since一致(只存在If-Modified-Since時)。若是改變了，就會發送新的文件，反之，則直接返回304。

瀏覽器緩存分類

強緩存

客戶端第一次問服務器要某個資源時，服務器丟還給客戶端所請求的這個資源同時，告訴客戶端將這個資源保存在本地，而且在將來的某個時點以前若是還須要這個資源，直接從本地獲取就好了，不用向服務器請求。這種方式緩存下來的資源稱爲強緩存。 強緩存利用http的返回頭部的中Expires（實體首部字段）或者Cache-Control（通用首部字段）兩個字段來控制的，用來表示資源的緩存時間。服務器經過這兩個首部字段告知客戶端資源的緩存過時時間和緩存最大生命週期。客戶端得知資源的緩存過時時間和最大生命週期後，便可自行判斷是否可不創建與服務器的連接，直接從瀏覽器緩存中獲取資源。

命中強緩存時，瀏覽器一樣會受到status=200的response，chrome中可經過size區分從服務器返回的資源仍是強緩存得到的資源。

Expires

該字段是http1.0時的規範，值爲一個絕對時間的GMT格式的時間字符串，表明緩存資源的過時時間，在這個時點以前，即命中緩存。其過程以下：

瀏覽器第一次跟服務器請求一個資源時，服務器在返回這個資源時，在相應頭部會加上Expires，如圖： clipboard.png

瀏覽器接收到該資源後，會把這個資源連同response header一塊兒緩存下來；

瀏覽器再次請求這個資源時，會先從緩存中找到這個資源，而後獲取Expires時間與當前的請求時間比較，若是Expires時間比當前瀏覽器的請求時間晚，說明緩存未過時，即命中緩存；

若是當前請求時間比Expires晚，說明緩存過時，即未命中緩存，瀏覽器就會發送請求到服務器申請獲取資源。

缺點：服務器返回的Expires時點是服務器上的時間，可能與客戶端有時間差，時間差太大時可能形成緩存混亂。

Cache-Control:max-age

Cache-Control有不少屬性，不一樣的屬性表明的意義也不一樣。

private：客戶端能夠緩存

public：客戶端和代理服務器均可以緩存

max-age=t：緩存內容將在t秒後失效

no-cache：須要使用協商緩存來驗證緩存數據

no-store：全部內容都不會緩存。

該字段是http1.1的規範，強緩存利用其max-age值來判斷緩存資源的最大生命週期，它的值單位爲秒，Cache-Control : max-age=3600表明緩存資源有效時間爲1小時，即從第一次獲取該資源起一小時內的請求都被認爲可命中強緩存。其過程以下：

瀏覽器第一次跟服務器請求一個資源時，服務器在返回這個資源時，在相應頭部會加上Cache-Control:max-age=XXXXXXXX，如圖： clipboard.png

瀏覽器接收到資源後，連同response header一塊兒緩存下來；

瀏覽器再次跟服務器請求同一個資源時，會先從緩存中找到這個資源，獲取date(第一次資源返回的響應時間)和max-age並計算出一個有效期(date + max-age)，而後再和瀏覽器請求時間比較最後判斷是否命中緩存（邏輯同Expires）；

若是沒有命中緩存，瀏覽器直接從服務器請求資源，Cache-Control會在從新獲取到服務器返回資源時更新。

Cache-Control描述的是相對時間，採用本地時間來計算資源的有效期，因此相比Expires更可靠。

這兩個Header能夠只用其一，也能夠一塊兒使用。一塊兒使用時以Cache-Control爲準。

協商緩存

客戶端第一次問服務器要某個資源時，服務器丟還給客戶端所請求的這個資源同時，將該資源的一些信息（文件摘要、或者最後修改時間）也返回給客戶端，告訴客戶端將這個資源緩存在本地。當客戶端下一次須要這個資源時，將請求以及相關信息（文件摘要、或者最後修改時間）一併發送給服務器，由服務器來判斷客戶端緩存的資源是否須要更新：如不須要更新，就直接告訴客戶端獲取本地緩存資源；如須要更新，則將最新的資源連同相應的信息一併返回給客戶端。 當強緩存未命中時，瀏覽器就會發送請求到服務器，服務器會驗證協商緩存是否命中，若是協商緩存命中，請求返回的http狀態爲304，並會顯示說明Not Modified，瀏覽器收到該返回後，就會從緩存中加載了。

協商緩存利用[Last-Modified , If-Modified-Since] 和 [ETag , If-None-Match]這兩對Header來管理。

Last-Modified & If-Modified-Since

Last-Modified爲實體首部字段，值爲資源最後更新時間，隨服務器response返回。

If-Modified-Since爲請求首部字段，經過比較兩個時間來判斷資源在兩次請求期間是否有過修改，若是沒有修改，則命中協商緩存，瀏覽器從緩存中獲取資源；若是有過修改，則服務器返回資源，同時返回新的Last-Modified時間。其過程以下：

1. 瀏覽器第一次請求服務器資源，且服務器返回了該資源時，會在response headers中加上Last-Modified，這個header表示這個資源在服務器上的最後一次修改時間；

2. 當瀏覽器再次請求該資源時，會在request headers中加上If-Modified-Since，這個值即爲上一次服務器返回的Last-Modified時間；

3. 服務器再次收到資源請求時，將If-Modified-Since時間和資源在服務器上的最後修改時間與對比，若是If-Modifid-Since與最後修改時間一致，則命中緩存，服務器返回304，瀏覽器從緩存中獲取資源；若未命中緩存，服務器返回資源同時，瀏覽器緩存資源的Last-Modified會被更新。

ETag & If-None-Match

有些狀況下僅判斷最後修改日期來驗證資源是否有改動是不夠的：

存在週期性重寫某些資源，但資源實際包含的內容並沒有變化；

被修改的信息並不重要，如註釋等；

Last-Modified沒法精確到毫秒，但有些資源更新頻率有時會小於一秒。

爲解決這些問題，http容許用戶對資源打上標籤(ETag)來區分兩個相同路徑獲取的資源內容是否一致。一般會採用MD5等密碼散列函數對資源編碼獲得標籤(強驗證器)；或者經過版本號等方式，如W/」v1.0」(W/表示弱驗證器)。

ETag爲相應頭部字段，表示資源內容的惟一標識，隨服務器response返回；

If-None-Match爲請求頭部字段，服務器經過比較請求頭部的If-None-Match與當前資源的ETag是否一致來判斷資源是否在兩次請求之間有過修改，若是沒有修改，則命中協商緩存，瀏覽器從緩存中獲取資源；若是有過修改，則服務器返回資源，同時返回新的ETag。其過程以下：

1. 服務器第一次收到瀏覽器發出的資源請求時，會在response headers中加上ETag，這個ETag是根據該資源生成的惟一標識，這個惟一標識是個字符串，只要服務器認爲資源有變化且應該提供新的資源，則ETag就必須有變化。瀏覽器將資源連同ETag一併緩存。

2. 當瀏覽器再一次向服務器發送該資源的請求時，會在request headers中加上If-None-Match，該值即爲第一次服務器返回的ETag值；

3. 服務器收到資源請求後，會根據要請求的資源從新計算生成相應的ETag，而後與If-None-Match比較。對比結果一致即命中緩存，不一致則未命中緩存，返回資源同時將新的ETag發送至瀏覽器。

協商緩存管理 [Last-Modified , If-Modified-Since]和[ETag , If-None-Match]通常同時啓用，這是爲了處理Last-Modified不可靠的狀況。

前端部署方案

以前你們可能都知道 通常的公司對於靜態資源以及緩存的處理方式無非就這麼幾種。 1 在靜態資源後面加一個版本號 v=1.111

相似於上面這種方式。

2 爲了準確的肯定文件是否修改，將後面的版本號修改成文件摘要（主要根據文件內容生成的一個值）。

相似於上面這種，後面的紅框表示的部分就是根據文件的摘要生成的key.

3 直接將資源文件名使用文件摘要或者說某個固定的字符串加上一個文件摘要拼接成一個文件名。

相似上面這種方式，最後面紅圈內表示的代碼是根據文件摘要來生成的，這裏須要區別和第二種方式，第二種方式是拿來放在url後面做爲一個參數，但文件名沒有改變。而這裏直接選擇修改了文件名。

（彩蛋：有意思的，找了幾個TX的網站，發現其實並非全部的網站都採用了最後一種方式。我想應該技術都是用來追求完美的，但實現仍是人實現的，畢竟人的天性是喜歡偷懶的。）

那麼問題來了？ 以上三種方式的區別是什麼？爲何最後會最終演變爲第三種方式？

1 第一種方式，須要維護版本號，若是在一個文件中，存在多個資源，那麼沒有被修改過的資源文件也會被修改版本號，致使沒必要要的資源加載。（固然，若是須要加上時間戳之類的，就已經不屬於第一個的範圍了）

2 第二種方式，能夠精確的發現哪個文件被修改過。從而要求客戶端進行從新加載。可是一樣會存在一些問題。 通常能作到第二種方式的公司，網頁流量天然能夠想像（小公司請自動忽略）。 那麼當在發佈版本的時候，會存在兩個類型的文件須要發佈： 1） html文件，上面有資源文件的引用 2 ）資源文件

那麼發佈以上兩個文件的順序就成問題了。

若是先發 html文件： 那麼會致使從新加載資源，但同樣仍是沒法訪問到最新的特性。（畢竟資源文件尚未真正的更新。），如是Html頁面的結構有更新，但加載了舊的資源，頗有可能致使頁面結構的錯亂。而且會緩存資源，直到資源過時，不然除非強制刷新，會一直是錯誤頁面。（這裏要注意到，因爲第一次加載了舊的資源，版本號又是新的版本號，因此即便在這以後上了資源，這裏依舊會讀取舊的資源.)

若是先發資源文件： 若是以前訪問過頁面，那就會有保存有本地緩存，那麼因爲訪問的仍是緩存文件，不會出現問題。但若是是新用戶，那麼就會訪問到新的資源文件，頗有可能致使頁面錯亂。而等到頁面html也發佈以後，頁面又恢復了正常。

PS: 固然有的人可能會說，發佈就那麼一會的時間，有必要那麼在意這些一點點時間麼？ 若是你這麼想，那麼我只能說，我無話可說。

發上兩種都是屬於覆蓋式資源發佈，無論如何處理，都會存在這樣的問題。那麼解決方案就是第三種。非覆蓋式發佈。

3 第三種方式，應該是最完美的解決方案： 1 首先發資源文件，因爲文件名已經不同了，因此不會覆蓋掉以前存在的資源文件，客戶端依舊能夠安全的訪問。 2 再發客戶端文件，在客戶端文件一旦發佈成功，那麼就會立馬切成新的特性，中間能夠作到無縫銜接。 這就是所謂的非覆蓋發佈的方案。