強快取客戶端第一次向伺服器請求資源時，伺服器返回某個資源的同時，新增某些頭部資訊，告訴客戶端將資源儲存在本地，並在未來的某個時點之前再次請求這個資源時，直接從本地獲取就可以了。
【字段控制】
瀏覽器再次請求這個資源時，會先從快取中找到這個資源，然後獲取expires時間與當前的請求時間比較，如果expires時間比當前瀏覽器的請求時間晚，說明快取未過期，即命中快取；
【比較】資源的 expires 值 與 當前的請求時間
缺點：伺服器返回的expires時點是伺服器上的時間，可能與客戶端有時間差，時間差太大時可能造成快取混亂。
瀏覽器再次跟伺服器請求同乙個資源時，會先從快取中找到這個資源，獲取date(第一次資源返回的響應時間)和max-age並計算出乙個有效期(date + max-age)，然後再和瀏覽器請求時間比較最後判斷是否命中快取（邏輯同expires）；
【比較】資源的date 值 、max-age 與 當前的請求時間
cache-control描述的是相對時間，採用本地時間來計算資源的有效期，所以相比expires更可靠。
【優先順序】 如果同時出現，max-age 優先順序比較高
【特點】不向伺服器發出請求，由客戶端判斷
協商快取客戶端第一次問伺服器請求某個資源時，伺服器返回請求資源的同時，將該資源的一些資訊（檔案摘要、或者最後修改時間）也返回給客戶端，告訴客戶端將這個資源快取在本地。當客戶端下一次需要這個資源時，將請求以及相關資訊（檔案摘要、或者最後修改時間）一併傳送給伺服器，由伺服器來判斷客戶端快取的資源是否需要更新：如不需要更新，就直接告訴客戶端獲取本地快取資源；如需要更新，則將最新的資源連同相應的資訊一併返回給客戶端。當強快取未命中時，瀏覽器就會傳送請求到伺服器，伺服器會驗證協商快取是否命中，如果協商快取命中，請求返回的http狀態為304，並會顯示說明not modified，瀏覽器收到該返回後，就會從快取中載入了。
【字段控制】
last-modified為實體首部字段，值為資源最後更新時間，隨伺服器response返回。
if-modified-since為請求首部字段，通過比較兩個時間來判斷資源在兩次請求期間是否有過修改，如果沒有修改，則命中協商快取，瀏覽器從快取中獲取資源；如果有過修改，則伺服器返回資源，同時返回新的last-modified時間。
【steps】
1) 瀏覽器第一次請求伺服器資源，且伺服器返回了該資源時，會在response
headers中加上last-modified，這個header表示這個資源在伺服器上的最後一次修改時間；
2)當瀏覽器再次請求該資源時，會在request headers中加上if-modified-since，這個值即為上一次伺服器返回的last-modified時間；
3)伺服器再次收到資源請求時，將if-modified-since時間和資源在伺服器上的最後修改時間與對比，如果if-modifid-since與最後修改時間一致，則命中快取，伺服器返回304，瀏覽器從快取中獲取資源；若未命中快取，伺服器返回資源同時，瀏覽器快取資源的last-modified會被更新。
【比較】 if-modified-since時間 與 伺服器上的 last-modified時間
etag為實體頭部字段，表示資源內容的唯一標識，隨伺服器response返回；
if-none-match為請求頭部字段，伺服器通過比較請求頭部的if-none-match與當前資源的etag是否一致來判斷資源是否在兩次請求之間有過修改，如果沒有修改，則命中協商快取，瀏覽器從快取中獲取資源；如果有過修改，則伺服器返回資源，同時返回新的etag。
【steps】
1) 伺服器第一次收到瀏覽器發出的資源請求時，會在response
headers中加上etag，這個etag是根據該資源生成的唯一標識，這個唯一標識是個字串，只要伺服器認為資源有變化且應該提供新的資源，則etag就必須有變化。瀏覽器將資源連同etag一併快取。
2) 當瀏覽器再一次向伺服器傳送該資源的請求時，會在request headers中加上if-none-match，該值即為第一次伺服器返回的etag值；
3)伺服器收到資源請求後，會根據要請求的資源重新計算生成相應的etag，然後與if-none-match比較。對比結果一致即命中快取，不一致則未命中快取，返回資源同時將新的etag傳送至瀏覽器。
【比較】 if-none-match 值 與請求的資源重新計算生成相應的etag
【為什麼要有etag】
1) 一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get；
2) 某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了n次)，if-modified-since能檢查到的粒度是s級的，這種修改無法判斷(或者說unix記錄mtime只能精確到秒)；
3) 某些伺服器不能精確的得到檔案的最後修改時間。
【優先順序】 last-modified與etag是可以一起使用的，伺服器會優先驗證etag，一致的情況下，才會繼續比對last-modified，最後才決定是否返回304。
【特點】都要向伺服器發起一次請求
整理自：
強快取和協商快取
對於一次已經有快取存在的請求來說 即之前已經發過針對這個資源的請求，在本地已經有快取 如果發起請求，那麼 首先會去找到快取資源的響應頭中的expires 過期時間 和cache control 控制快取的失效性 來判斷當前是否直接使用快取，如果當前時間還在expires之前，即快取仍未失效的情況下，...
強快取和協商快取
一 瀏覽器快取 1，第一次請求，無快取請求過程 流程如下所示 第二次請求，有快取請求的過程 流程如下圖所示 瀏覽器的快取分為二種，第一種的是強快取，另外一種是協商快取 2 強快取 定義 強快取在請求資源的時候，會從header裡面讀取是否是強快取，在有效的時間時間期內，從快取裡讀取不能從服務那裡讀取...
強快取與協商快取
強制快取 當瀏覽器去請求某個檔案的時候，服務端就在respone header裡面對該檔案做了快取配置。快取的時間 快取型別都由服務端控制 expires 失效時間 伺服器時間與客戶端時間有偏差時，就可能會導致快取失效，比如使用者隨意修改了本地時間 http1.1新增cache control 1....