一、瀏覽器快取
1，第一次請求，無快取請求過程
流程如下所示
第二次請求，有快取請求的過程
流程如下圖所示
瀏覽器的快取分為二種，第一種的是強快取，另外一種是協商快取
2 ：強快取
定義：強快取在請求資源的時候，會從header裡面讀取是否是強快取，在有效的時間時間期內，從快取裡讀取不能從服務那裡讀取
介紹使用：
expires，這是http1.0時的規範；它的值為乙個絕對時間的gmt格式的時間字串，如mon, 10 jun 2015 21:31:12 gmt，如果傳送請求的時間在expires之前，那麼本地快取始終有效，否則就會傳送請求到伺服器來獲取資源
cache-control：的含義和使用
可快取性屬性說明
pubilc:http只要經過的地方都要進行快取
privite：發出的瀏覽器端要進行快取
no-cache:本地可以有快取，需要伺服器驗證才可以使用
no-store:本地和伺服器都沒有快取
max-age= ：快取的最大的時間
3，**案例分析：
1，簡單的建立乙個服務
// 建立乙個http服務
4，解決的方法呢：
上面說到，使用強快取時，瀏覽器不會傳送請求到服務端，根據設定的快取時間瀏覽器一直從快取中獲取資源，在這期間若資源產生了變化，瀏覽器就在快取期內就一直得不到最新的資源，那麼如何防止這種事情發生呢？
通過更新頁面中引用的資源路徑，讓瀏覽器主動放棄快取，載入新資源。
前端常常後面加上版本號和一些hash值重新的讀取
二、介紹協商快取
協商快取都是由伺服器來確定快取資源是否可用的，所以客戶端與伺服器端要通過某種標識來進行通訊，從而讓伺服器判斷請求資源是否可以快取訪問，這主要涉及到下面兩組header欄位，這兩組搭檔都是成對出現的，即第一次請求的響應頭帶上某個字段（last-modified或者etag），則後續請求則會帶上對應的請求字段（if-modified-since或者if-none-match），若響應頭沒有last-modified或者etag欄位，則請求頭也不會有對應的字段。
3、既生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。
4，**案例
if (etag === 『777』) )
response.end(』』);
} else )
response.end(『fffff』);
}三、強快取與協商快取的區別，可以用下表來進行描述：
獲取資源形式 狀態碼 傳送請求到伺服器協商快取: 從快取取 304（not modified） 是，正如其名，通過伺服器來告知快取是否可用
強快取和協商快取
對於一次已經有快取存在的請求來說 即之前已經發過針對這個資源的請求，在本地已經有快取 如果發起請求，那麼 首先會去找到快取資源的響應頭中的expires 過期時間 和cache control 控制快取的失效性 來判斷當前是否直接使用快取，如果當前時間還在expires之前，即快取仍未失效的情況下，...
前端強快取和協商快取
快取是前端面試的乙個常見知識點，下面對於實際專案中如何進行快取的設定給出方案。瀏覽器快取是瀏覽器將使用者請求過的靜態資源儲存到電腦本地磁碟中，當再次訪問時，就可以直接從本地快取中載入而不需要去向伺服器請求了。但是快取也有缺點，如果服務端資源更新了，客戶端沒有強制重新整理的情況下，看到的內容還是舊的。...
Http強快取和協商快取
本文主要講解瀏覽器端的快取，快取的作用是不言而喻的，能夠極大的改善網頁效能，提高使用者體驗。快取這東西，第一次必須獲取到資源後，然後根據返回的資訊來告訴如何快取資源，可能採用的是強快取，也可能告訴客戶端瀏覽器是協商快取，這都需要根據響應的header內容來決定的。下面用兩幅圖來描述瀏覽器的快取是怎麼...