http協(xié)商緩存VS強(qiáng)緩存
轉(zhuǎn)載
之前一直對瀏覽器緩存只能描述一個大概蛮瞄，深層次的原理不能描述上來；終于在前端的兩次面試過程中被問倒下，為了泄恨，查閱一些資料最終對其有了一個更深入的理解兼搏，廢話不多說，趕緊來看看瀏覽器緩存的那些事吧沙郭，有不對的地方佛呻，請各位不吝賜教啊。
本文主要講解瀏覽器端的緩存病线，緩存的作用是不言而喻的吓著，能夠極大的改善網(wǎng)頁性能，提高用戶體驗(yàn)送挑。
1绑莺、瀏覽器緩存
緩存這東西，第一次必須獲取到資源后让虐，然后根據(jù)返回的信息來告訴如何緩存資源紊撕，可能采用的是強(qiáng)緩存，也可能告訴客戶端瀏覽器是協(xié)商緩存赡突，這都需要根據(jù)響應(yīng)的header內(nèi)容來決定的对扶。下面用兩幅圖來描述瀏覽器的緩存是怎么玩的，讓大家有個大概的認(rèn)知惭缰。
瀏覽器第一次請求時：
瀏覽器后續(xù)在進(jìn)行請求時：
從上圖可以知道浪南，瀏覽器緩存包含兩種類型，即強(qiáng)緩存（也叫本地緩存）和協(xié)商緩存漱受，瀏覽器在第一次請求發(fā)生后络凿，再次請求時：
-
瀏覽器在請求某一資源時，會先獲取該資源緩存的header信息昂羡，判斷是否命中強(qiáng)緩存（cache-control和expires信息）絮记，若命中直接從緩存中獲取資源信息，包括緩存header信息虐先；本次請求根本就不會與服務(wù)器進(jìn)行通信怨愤；在firebug下可以查看某個具有強(qiáng)緩存資源返回的信息，例如本地firebug查看的一個強(qiáng)緩存js文件
image 如果沒有命中強(qiáng)緩存蛹批，瀏覽器會發(fā)送請求到服務(wù)器撰洗，請求會攜帶第一次請求返回的有關(guān)緩存的header字段信息（Last-Modified/If-Modified-Since和Etag/If-None-Match），由服務(wù)器根據(jù)請求中的相關(guān)header信息來比對結(jié)果是否協(xié)商緩存命中腐芍；若命中差导，則服務(wù)器返回新的響應(yīng)header信息更新緩存中的對應(yīng)header信息，但是并不返回資源內(nèi)容猪勇，它會告知瀏覽器可以直接從緩存獲壬韬帧；否則返回最新的資源內(nèi)容
強(qiáng)緩存與協(xié)商緩存的區(qū)別，可以用下表來進(jìn)行描述：
| | 獲取資源形式 | 狀態(tài)碼 | 發(fā)送請求到服務(wù)器 |
| 強(qiáng)緩存 | 從緩存取 | 200（from cache） | 否络断，直接從緩存取 |
| 協(xié)商緩存 | 從緩存取 | 304（not modified） | 是裁替，正如其名，通過服務(wù)器來告知緩存是否可用 |
2貌笨、強(qiáng)緩存相關(guān)的header字段
強(qiáng)緩存上面已經(jīng)介紹了，直接從緩存中獲取資源而不經(jīng)過服務(wù)器襟沮；與強(qiáng)緩存相關(guān)的header字段有兩個：
- expires锥惋，這是http1.0時的規(guī)范；它的值為一個絕對時間的GMT格式的時間字符串开伏，如Mon, 10 Jun 2015 21:31:12 GMT膀跌，如果發(fā)送請求的時間在expires之前，那么本地緩存始終有效固灵，否則就會發(fā)送請求到服務(wù)器來獲取資源
-
cache-control：max-age=number捅伤，這是http1.1時出現(xiàn)的header信息，主要是利用該字段的max-age值來進(jìn)行判斷巫玻，它是一個相對值丛忆；資源第一次的請求時間和Cache-Control設(shè)定的有效期，計算出一個資源過期時間仍秤，再拿這個過期時間跟當(dāng)前的請求時間比較熄诡，如果請求時間在過期時間之前，就能命中緩存诗力，否則就不行凰浮；cache-control除了該字段外，還有下面幾個比較常用的設(shè)置值：
no-cache：不使用本地緩存苇本。需要使用緩存協(xié)商袜茧，先與服務(wù)器確認(rèn)返回的響應(yīng)是否被更改，如果之前的響應(yīng)中存在ETag瓣窄，那么請求的時候會與服務(wù)端驗(yàn)證笛厦，如果資源未被更改，則可以避免重新下載康栈。
no-store：直接禁止游覽器緩存數(shù)據(jù)递递，每次用戶請求該資源，都會向服務(wù)器發(fā)送一個請求啥么，每次都會下載完整的資源登舞。
public：可以被所有的用戶緩存，包括終端用戶和CDN等中間代理服務(wù)器悬荣。
private：只能被終端用戶的瀏覽器緩存菠秒，不允許CDN等中繼緩存服務(wù)器對其緩存。
注意：如果cache-control與expires同時存在的話，cache-control的優(yōu)先級高于expires
3践叠、協(xié)商緩存相關(guān)的header字段
協(xié)商緩存都是由服務(wù)器來確定緩存資源是否可用的言缤，所以客戶端與服務(wù)器端要通過某種標(biāo)識來進(jìn)行通信，從而讓服務(wù)器判斷請求資源是否可以緩存訪問禁灼，這主要涉及到下面兩組header字段管挟，這兩組搭檔都是成對出現(xiàn)的，即第一次請求的響應(yīng)頭帶上某個字段（Last-Modified或者Etag）弄捕，則后續(xù)請求則會帶上對應(yīng)的請求字段（If-Modified-Since或者If-None-Match）僻孝，若響應(yīng)頭沒有Last-Modified或者Etag字段，則請求頭也不會有對應(yīng)的字段守谓。
-
Last-Modified/If-Modified-Since
二者的值都是GMT格式的時間字符串穿铆，具體過程：瀏覽器第一次跟服務(wù)器請求一個資源，服務(wù)器在返回這個資源的同時斋荞，在respone的header加上Last-Modified的header荞雏，這個header表示這個資源在服務(wù)器上的最后修改時間
瀏覽器再次跟服務(wù)器請求這個資源時，在request的header上加上If-Modified-Since的header平酿，這個header的值就是上一次請求時返回的Last-Modified的值
服務(wù)器再次收到資源請求時凤优，根據(jù)瀏覽器傳過來If-Modified-Since和資源在服務(wù)器上的最后修改時間判斷資源是否有變化，如果沒有變化則返回304 Not Modified染服，但是不會返回資源內(nèi)容别洪；如果有變化，就正常返回資源內(nèi)容柳刮。當(dāng)服務(wù)器返回304 Not Modified的響應(yīng)時挖垛，response header中不會再添加Last-Modified的header，因?yàn)榧热毁Y源沒有變化秉颗，那么Last-Modified也就不會改變痢毒，這是服務(wù)器返回304時的response header
瀏覽器收到304的響應(yīng)后，就會從緩存中加載資源
如果協(xié)商緩存沒有命中蚕甥，瀏覽器直接從服務(wù)器加載資源時哪替，Last-Modified的Header在重新加載的時候會被更新，下次請求時菇怀，If-Modified-Since會啟用上次返回的Last-Modified值
Etag/If-None-Match
這兩個值是由服務(wù)器生成的每個資源的唯一標(biāo)識字符串凭舶，只要資源有變化就這個值就會改變；其判斷過程與Last-Modified/If-Modified-Since類似爱沟，與Last-Modified不一樣的是帅霜，當(dāng)服務(wù)器返回304 Not Modified的響應(yīng)時，由于ETag重新生成過呼伸，response header中還會把這個ETag返回身冀，即使這個ETag跟之前的沒有變化。
4、既生Last-Modified何生Etag
你可能會覺得使用Last-Modified已經(jīng)足以讓瀏覽器知道本地的緩存副本是否足夠新搂根，為什么還需要Etag呢珍促？HTTP1.1中Etag的出現(xiàn)主要是為了解決幾個Last-Modified比較難解決的問題：
一些文件也許會周期性的更改，但是他的內(nèi)容并不改變(僅僅改變的修改時間)剩愧，這個時候我們并不希望客戶端認(rèn)為這個文件被修改了猪叙，而重新GET；
某些文件修改非常頻繁隙咸，比如在秒以下的時間內(nèi)進(jìn)行修改沐悦，(比方說1s內(nèi)修改了N次)，If-Modified-Since能檢查到的粒度是s級的五督，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒)；
某些服務(wù)器不能精確的得到文件的最后修改時間瓶殃。
這時充包，利用Etag能夠更加準(zhǔn)確的控制緩存，因?yàn)镋tag是服務(wù)器自動生成或者由開發(fā)者生成的對應(yīng)資源在服務(wù)器端的唯一標(biāo)識符遥椿。
Last-Modified****與ETag****是可以一起使用的基矮，服務(wù)器會優(yōu)先驗(yàn)證ETag****，一致的情況下冠场，才會繼續(xù)比對Last-Modified****家浇，最后才決定是否返回304。
5碴裙、用戶的行為對緩存的影響
盜用網(wǎng)上的一張圖钢悲，基本能描述用戶行為對緩存的影響
6、強(qiáng)緩存如何重新加載緩存緩存過的資源
上面說到舔株，使用強(qiáng)緩存時莺琳，瀏覽器不會發(fā)送請求到服務(wù)端，根據(jù)設(shè)置的緩存時間瀏覽器一直從緩存中獲取資源载慈，在這期間若資源產(chǎn)生了變化惭等，瀏覽器就在緩存期內(nèi)就一直得不到最新的資源，那么如何防止這種事情發(fā)生呢办铡？
通過更新頁面中引用的資源路徑辞做，讓瀏覽器主動放棄緩存，加載新資源寡具。
類似下圖所示：
這樣每次文件改變后就會生成新的query值秤茅，這樣query值不同，也就是頁面引用的資源路徑不同了晒杈，之前緩存過的資源就被瀏覽器忽略了嫂伞，因?yàn)橘Y源請求的路徑變了。
