http協商快取和強快取
1.瀏覽器快取
為了節約網路資源，加速瀏覽，瀏覽器在使用者磁碟上對最近請求過的文件進行儲存，當訪問者再次請求這個頁面時，瀏覽器就可以直接從本地磁碟讀取資源並展示，這樣就可以加速頁面的閱覽。
快取這東西，第一次必須獲取到資源後，然後根據返回的資訊來告訴如何快取資源，可能採用的是強快取，也可能告訴客戶端瀏覽器是協商快取，這都需要根據響應的header內容來決定的。
瀏覽器第一次請求時：
瀏覽器後續再進行請求時：
2.快取策略
強快取和協商快取
根據獲取資源的請求頭（header）判斷是否中強快取。如命中，則直接從本地獲取快取資源，不會發請求到服務端；如沒有命中強快取，客戶端會傳送請求到服務端，服務端通過request headers裡面字段驗證這個資源是否命中協商快取，如命中，服務端將請求返回304，但不返回資源，從而告訴客戶端直接從快取中獲取資源；當協商快取也沒命中時，服務端將請求返回200，並將資源傳送給客戶端。
強快取概念：客戶端第一次問服務端要某個資源時，服務端丟還給客戶端所請求的這個資源同時，告訴客戶端將這個資源儲存在本地，並且在未來的某個時點之前如果還需要這個資源，直接從本地獲取就行了，不用向伺服器請求。這種方式快取下來的資源稱為強快取。
1）expires，這是http1.0時的規範；它的值為乙個絕對時間的gmt格式的時間字串，如mon, 10 jun 2015 21:31:12 gmt，如果傳送請求的時間在expires之前，那麼本地快取始終有效，否則就會傳送請求到伺服器來獲取資源
2）cache-control：max-age=number，這是http1.1時出現的header資訊，主要是利用該字段的max-age值來進行判斷，它是乙個相對值；資源第一次的請求時間和cache-control設定的有效期，計算出乙個資源過期時間，再拿這 個過期時間跟當前的請求時間比較，如果請求時間在過期時間之前，就能命中快取，否則就不行；cache-control除了該字段外，還有下面幾個比較常用的設定值：
public：可以被所有的使用者快取，包括終端使用者和cdn等中間**伺服器。
private：只能被終端使用者的瀏覽器快取，不允許cdn等中繼快取伺服器對其快取。
注意：如果cache-control與expires同時存在的話，cache-control的優先順序高於expires
協商快取
概念：客戶端第一次訪問伺服器請求某個資源時，伺服器返回請求這個資源的同時，將該資源的一些資訊也返回給客戶端，告訴客戶端將這個資源快取在本地。當客戶端下一次需要這個資源時，將請求以及相關資訊一併傳送給伺服器，由伺服器來判斷客戶端快取的資源是否需要更新：如不需要更新，就直接告知客戶端獲取本地快取資源（304）；如需要更新，則將最新的資源連同相應的資訊一併返回給客戶端。
協商快取都是由伺服器來確定快取資源是否可用的，所以客戶端與伺服器端要通過某種標識來進行通訊，從而讓伺服器判斷請求資源是否可以快取訪問，這主要涉及到下面兩組header欄位，這兩組搭檔都是成對出現的，即第一次請求的響應頭帶上某個字段（last-modified或者etag），則後續請求則會帶上對應的請求字段（if-modified-since或者if-none-match），若響應頭沒有last-modified或者etag欄位，則請求頭也不會有對應的字段。
last-modified/if-modified-since
二者的值都是gmt格式的時間字串，具體過程：
瀏覽器第一次跟伺服器請求乙個資源，伺服器在返回這個資源的同時，在respone的header加上last-modified的header，這個header表示這個資源在伺服器上的最後修改時間
瀏覽器再次跟伺服器請求這個資源時，在request的header上加上if-modified-since的header，這個header的值就是上一次請求時返回的last-modified的值
伺服器再次收到資源請求時，根據瀏覽器傳過來if-modified-since和資源在伺服器上的最後修改時間判斷資源是否有變化，如果沒有變化則返回304 not modified，但是不會返回資源內容；如果有變化，就正常返回資源內容。當伺服器返回304 not modified的響應時，response header中不會再新增last-modified的header，因為既然資源沒有變化，那麼last-modified也就不會改變，這是伺服器返回304時的response header
瀏覽器收到304的響應後，就會從快取中載入資源
etag/if-none-match
這兩個值是由伺服器生成的每個資源的唯一標識字串，只要資源有變化就這個值就會改變；其判斷過程與last-modified/if-modified-since類似，與last-modified不一樣的是，當伺服器返回304 not modified的響應時，由於etag重新生成過，response header中還會把這個etag返回，即使這個etag跟之前的沒有變化。
既生last-modified何生etag
你可能會覺得使用last-modified已經足以讓瀏覽器知道本地的快取副本是否足夠新，為什麼還需要etag呢？http1.1中etag的出現主要是為了解決幾個last-modified比較難解決的問題：
·一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get；
·某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了n次)，if-modified-since能檢查到的粒度是s級的，這種修改無法判斷(或者說unix記錄mtime只能精確到秒)；
·某些伺服器不能精確的得到檔案的最後修改時間。
·這時，利用etag能夠更加準確的控制快取，因為etag是伺服器自動生成或者由開發者生成的對應資源在伺服器端的唯一識別符號。
last-modified與etag是可以一起使用的，伺服器會優先驗證etag，一致的情況下，才會繼續比對last-modified，最後才決定是否返回304。
使用者的行為對快取的影響
基本能描述使用者行為對快取的影響
上面說到，使用強快取時，瀏覽器不會傳送請求到服務端，根據設定的快取時間瀏覽器一直從快取中獲取資源，在這期間若資源產生了變化，瀏覽器就在快取期內就一直得不到最新的資源，那麼如何防止這種事情發生呢？
通過更新頁面中引用的資源路徑，讓瀏覽器主動放棄快取，載入新資源。
類似下圖所示：
這樣每次檔案改變後就會生成新的query值，這樣query值不同，也就是頁面引用的資源路徑不同了，之前快取過的資源就被瀏覽器忽略了，因為資源請求的路徑變了。
Http強快取和協商快取
本文主要講解瀏覽器端的快取，快取的作用是不言而喻的，能夠極大的改善網頁效能，提高使用者體驗。快取這東西，第一次必須獲取到資源後，然後根據返回的資訊來告訴如何快取資源，可能採用的是強快取，也可能告訴客戶端瀏覽器是協商快取，這都需要根據響應的header內容來決定的。下面用兩幅圖來描述瀏覽器的快取是怎麼...
http協商快取VS強快取
之前一直對瀏覽器快取只能描述乙個大概，深層次的原理不能描述上來 終於在前端的兩次面試過程中被問倒下，為了洩恨，查閱一些資料最終對其有了乙個更深入的理解，廢話不多說，趕緊來看看瀏覽器快取的那些事吧，有不對的地方，請各位不吝賜教啊。本文主要講解瀏覽器端的快取，快取的作用是不言而喻的，能夠極大的改善網頁效...
http協商快取VS強快取
之前一直對瀏覽器快取只能描述乙個大概，深層次的原理不能描述上來 終於在前端的兩次面試過程中被問倒下，為了洩恨，查閱一些資料最終對其有了乙個更深入的理解，廢話不多說，趕緊來看看瀏覽器快取的那些事吧，有不對的地方，請各位不吝賜教啊。本文主要講解瀏覽器端的快取，快取的作用是不言而喻的，能夠極大的改善網頁效...