http://www.cnblogs.com/lyzg/p/5125934.html

分類

強緩存
協(xié)商緩存

基本過程

• 瀏覽器在加載資源時，先根據(jù)這個資源的一些http header判斷它是否命中強緩存，強緩存如果命中，瀏覽器直接從自己的緩存中讀取資源，不會發(fā)請求到服務器。
• 當強緩存沒命中，瀏覽器會發(fā)送請求到服務器，通過服務器端依據(jù)資源的另外一些http header驗證這個資源是否命中協(xié)商緩存，如果協(xié)商緩存命中，服務器會將這個請求返回，但是不會返回這個資源的數(shù)據(jù)，而是告訴客戶端可以直接從緩存中加載這個資源，于是瀏覽器就又會從自己的緩存中去加載這個資源。
• 當協(xié)商緩存也沒有命中的時候，瀏覽器直接從服務器加載資源數(shù)據(jù)。

區(qū)別

強緩存與協(xié)商緩存的共同點是：如果命中，都是從客戶端緩存中加載資源，而不是從服務器加載資源數(shù)據(jù)；區(qū)別是：強緩存不發(fā)請求到服務器，協(xié)商緩存會發(fā)請求到服務器。

強緩存

狀態(tài)碼：命中了強緩存時，返回的http狀態(tài)為200。
http header：

• Expires：資源過期時間，一個絕對時間，由服務器返回
• Cache-Control：新的，一個相對時間，在配置緩存的時候，以秒為單位，用數(shù)值表示，如：Cache-Control:max-age=315360000

原理

Expires原理

• 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Expires的header。
• 瀏覽器在接收到這個資源后，會把這個資源連同所有response header一起緩存下來。
• 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源后，拿出它的Expires跟當前的請求時間比較，如果請求時間在Expires指定的時間之前，就能命中緩存，否則就不行。
• 如果緩存沒有命中，瀏覽器直接從服務器加載資源時，Expires Header在重新加載的時候會被更新。

Cache-Control原理（十分相似）

• 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Cache-Control的header。
• 瀏覽器在接收到這個資源后，會把這個資源連同所有response header一起緩存下來。
• 瀏覽器再請求這個資源時，先從緩存中尋找，找到這個資源后，根據(jù)它第一次的請求時間和Cache-Control設定的有效期，計算出一個資源過期時間，再拿這個過期時間跟當前的請求時間比較，如果請求時間在過期時間之前，就能命中緩存，否則就不行。
• 如果緩存沒有命中，瀏覽器直接從服務器加載資源時，Cache-Control Header在重新加載的時候會被更新。

• Cache-Control描述的是一個相對時間，在進行緩存命中的時候，都是利用客戶端時間進行判斷，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。
• 這兩個header可以只啟用一個，也可以同時啟用，當response header中，Expires和Cache-Control同時存在時，Cache-Control優(yōu)先級高于Expires：

設置

• 通過代碼的方式，在web服務器返回的響應中添加Expires和Cache-Control Header；
• 通過配置web服務器的方式，讓web服務器在響應資源的時候統(tǒng)一添加Expires和Cache-Control Header。

應用場景

有大量靜態(tài)資源的網(wǎng)頁，強緩存是前端性能優(yōu)化最有力的工具。通常的做法是，為這些靜態(tài)資源全部配置一個超時時間超長的Expires或Cache-Contro。

協(xié)商緩存

當瀏覽器對某個資源的請求沒有命中強緩存，就會發(fā)一個請求到服務器，驗證協(xié)商緩存是否命中，如果協(xié)商緩存命中，請求響應返回的http狀態(tài)為304并且會顯示一個Not Modified的字符串。
http headers:

• Last-Modified，If-Modified-Since
• ETag、If-None-Match

• 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上Last-Modified的header，這個header表示這個資源在服務器上的最后修改時間
• 瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-Modified-Since的header，這個header的值就是上一次請求時返回的Last-Modified的值：
• 服務器再次收到資源請求時，根據(jù)瀏覽器傳過來If-Modified-Since和資源在服務器上的最后修改時間判斷資源是否有變化，如果沒有變化則返回304 Not Modified，但是不會返回資源內(nèi)容；如果有變化，就正常返回資源內(nèi)容。
• 瀏覽器收到304的響應后，就會從緩存中加載資源。
• 如果協(xié)商緩存沒有命中，瀏覽器直接從服務器加載資源時，Last-Modified Header在重新加載的時候會被更新，下次請求時，If-Modified-Since會啟用上次返回的Last-Modified值。

時候也會服務器上資源其實有變化，但是最后修改時間卻沒有變化的情況,所以就有了另外一對header來管理協(xié)商緩存，這對header就是【ETag、If-None-Match】

• 瀏覽器第一次跟服務器請求一個資源，服務器在返回這個資源的同時，在respone的header加上ETag的header, 這個header是服務器根據(jù)當前請求的資源生成的一個唯一標識，這個唯一標識是一個字符串，只要資源有變化這個串就不同
• 瀏覽器再次跟服務器請求這個資源時，在request的header上加上If-None-Match的header，這個header的值就是上一次請求時返回的ETag的值：
• 服務器再次收到資源請求時，根據(jù)瀏覽器傳過來If-None-Match和然后再根據(jù)資源生成一個新的ETag，如果這兩個值相同就說明資源沒有變化，否則就是有變化；如果沒有變化則返回304 Not Modified，但是不會返回資源內(nèi)容；如果有變化，就正常返回資源內(nèi)容。與Last-Modified不一樣的是，當服務器返回304 Not Modified的響應時，由于ETag重新生成過，response header中還會把這個ETag返回，即使這個ETag跟之前的沒有變化：

管理

• 強緩存不發(fā)請求到服務器，所以有時候資源更新了瀏覽器還不知道，但是協(xié)商緩存會發(fā)請求到服務器，所以資源是否更新，服務器肯定知道。大部分web服務器都默認開啟協(xié)商緩存，而且是同時啟用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】
• 【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同時啟用，這是為了處理Last-Modified不可靠的情況。

瀏覽器行為

• ctrl+f5強制刷新網(wǎng)頁時，直接從服務器加載，跳過強緩存和協(xié)商緩存；
• 當f5刷新網(wǎng)頁時，跳過強緩存，但是會檢查協(xié)商緩存；