浏览器缓存机制
瀏覽器緩存基本認識
分為強緩存和協商緩存
瀏覽器在加載資源的時候,會根據這個資源的http header判斷它是否命中強緩存,如果命中,就直接從緩存中讀取資源,不會發請求到服務器。
當強緩存沒有命中的時候,瀏覽器一定會發送一個請求到服務器,通過服務器端一句資源的另外一些http header驗證這個資源是否命中協商緩存,如果協商緩存命中,服務器會將這個請求返回,告訴客戶端可以直接從緩存中加載這個資源,于是瀏覽器就又會從自己的緩存中去加載這個資源。
當協商緩存也沒有命中的時候,瀏覽器直接從服務器加載資源數據。
強緩存原理
強緩存是利用Expires或者Cache-Control這兩個http response header實現的,它們都用來表示客戶端緩存的有效期,請求響應返回的狀態為200
Expire
Expire:Thu, 31 Dec 2037 23:55:55 GMT
1)瀏覽器第一次跟服務器請求一個資源,服務器在返回這個資源的同時,在response的header加上Expires的header;
2)瀏覽器再請求這個資源時,先從緩存中尋找,找到這個資源后,拿出它的Expires跟當前的請求時間比較,如果請求時間在Expire指定的時間之前,就能命中緩存;
3)如果緩存沒有命中,瀏覽器直接從服務器加載資源時,Expire Header在重新加載的時候會被更新
缺點
Exipires是較老的強緩存管理header,由于它是服務器返回的一個絕對時間,在服務器時間與客戶端時間相差較大的時候,緩存管理容易出現問題,比如隨意修改一下客戶端時間就能影響緩存命中的結果。
Cache-Control
Cache-Control: max-age = 315360000
1)瀏覽器第一次跟服務器請求一個資源,服務器在返回這個資源的同時,在response的header加上Cache-Control的header;
2)瀏覽器在接收到這個資源后,會把這個資源連同所有response header一起緩存下來
3)瀏覽器再請求這個資源時,先從緩存中尋找,找到這個資源后,根據它第一次的請求時間和Cache-Control設定的有效期,計算出一個資源過期時間,再拿這個過期時間跟當前的請求時間比較,如果請求時間再過期時間之前,就能命中緩存;
4)如果緩存沒有命中,瀏覽器直接從服務器加載資源時,Cache-Control Header 在重新加載的時候會被更新。
Expire和Cache-Control的聯系和區別
前者描述的是絕對時間,后者是相對時間
可以只啟用一個,也可以同時啟用,同時存在時,Cache-Control優先級高于Expire
如何設置強緩存
1)通過代碼方式,在web服務器返回的相應中添加Expires和Cache-Control Header;
2)通過配置web服務器的方式,讓web服務器在響應資源的時候統一添加Expires和Cache-Control Header
協商緩存的原理
請求響應返回的狀態為304并且會顯示一個Not Modified的字符串,協商緩存是利用的是Last-Modified,If-Modified-since和ETag,If-None-Match這兩對Header來管理的
Last-Modified,If-Modified-since原理
Last-Modified: Tue, 12 Jan 2016 03:08:53 GMT
If-Modified-Since: Tue, 12 Jan 2016 03:08:53 GMT
1)瀏覽器第一次跟服務器請求一個資源,服務器在返回這個資源的同時,在respone的header加上Last-Modified的header,這個header表示這個資源在服務器上的最后修改時間;
2)瀏覽器再次跟服務器請求這個資源時,在request的header上加上If-Modified-Since的header,這個header的值就是上一次請求時返回的Last-Modified的值;
3)服務器再次收到資源請求時,根據瀏覽器傳過來If-Modified-Since和資源在服務器上的最后修改時間判斷資源是否有變化,如果沒有變化則返回304 Not Modified,但是不會返回資源內容;如果有變化,就正常返回資源內容。當服務器返回304 Not Modified的響應時,response header中不會再添加Last-Modified的header,因為既然資源沒有變化,那么Last-Modified也就不會改變,這是服務器返回304時的response header;
4)瀏覽器收到304的響應后,就會從緩存中加載資源;
5)如果協商緩存沒有命中,瀏覽器直接從服務器加載資源時,Last-Modified Header在重新加載的時候會被更新,下次請求時,If-Modified-Since會啟用上次返回的Last-Modified值;
缺點:
有時候服務器上資源其實有變化,但是最后修改時間卻沒有變化,而這種問題又很不容易被定位出來,而當這種情況出現的時候,就會影響協商緩存的可靠性
ETag, If-None-Match原理
ETag: "17fd8-5291a5f96fd20"
1)瀏覽器第一次跟服務器請求一個資源,服務器在返回這個資源的同時,在respone的header加上ETag的header,這個header是服務器根據當前請求的資源生成的一個唯一標識,這個唯一標識是一個字符串,只要資源有變化這個串就不同,跟最后修改時間沒有關系,所以能很好的補充Last-Modified的問題;
2)瀏覽器再次跟服務器請求這個資源時,在request的header上加上If-None-Match的header,這個header的值就是上一次請求時返回的ETag的值;
3)服務器再次收到資源請求時,再根據資源生成一個新的ETag,與瀏覽器傳過來If-None-Match比較,如果這兩個值相同就說明資源沒有變化,否則就是有變化;如果沒有變化則返回304 Not Modified,但是不會返回資源內容;如果有變化,就正常返回資源內容。與Last-Modified不一樣的是,當服務器返回304 Not Modified的響應時,由于ETag重新生成過,response header中還會把這個ETag返回,即使這個ETag跟之前的沒有變化
4)瀏覽器收到304的響應后,就會從緩存中加載資源。
注意的問題
分布式系統里多臺機器間文件的Last-Modified必須保持一致,以免負載均衡到不同機器導致比對失敗;
分布式系統盡量關閉掉ETag(每臺機器生成的ETag都會不一樣);
總結
- 上一篇: asm管理的dg数据文件缺失的处理方法
- 下一篇: listview条目用状态选择器没反应