瀏覽器緩存js都有哪些

『壹』 瀏覽器緩存和伺服器緩存

一、瀏覽器緩存

瀏覽器緩存即http緩存；瀏覽器緩存根據是否需要向伺服器重新發起HTTP請求將緩存過程分為兩個部分，分別是 強制緩存 和 協商緩存  。

瀏覽器第一次請求資源的時候伺服器會告訴客戶端是否應該緩存資源，根據響應報文中HTTP頭的緩存標識，決定是否緩存結果，是則將請求結果和緩存標識存入瀏覽器緩存中。如下圖：

1.強制緩存 ：瀏覽器會對緩存進行查找，並根據一定的規則確定是否使用緩存。

強制緩存的緩存規則？

HTTP/1.0 Expires 這個欄位是絕對時間，比如2018年6月30日12:30，然後在這個時間點之前的請求都會使用瀏覽器緩存，除非清除了緩存。

這個欄位的缺點就是只會同步客戶端的時間，這就有可能修改客戶端時間導致緩存失效。

HTTP/1.1 cache-Control       這個是1.1的時候替換Expires的，它會有幾種取值：

public ：所有內容都將被緩存（客戶端和代理伺服器都可緩存）

private ：所有內容只有客戶端可以緩存， Cache-Control的默認取值

no-cache ：客戶端緩存內容，但是是否使用緩存則需要經過協商緩存來驗證決定

no-store ：所有內容都不會被緩存，即不使用強制緩存，也不使用協商緩存

max-age=xxx (xxx is numeric) ：緩存內容將在xxx秒後失效

比如max-age=500，則在500秒內再次請求會直接只用緩存。

優先性：cache-Control > Expires

如果同時存在，cache-Control會覆蓋Expires。

這個欄位的缺點就是：

如果資源更新的速度是秒以下單位，那麼該緩存是不能被使用的，因為它的時間單位最低是秒。

如果文件是通過伺服器動態生成的，那麼該方法的更新時間永遠是生成的時間，盡管文件可能沒有變化，所以起不到緩存的作用。

上圖中瀏覽器緩存中存在該資源的緩存結果，並且沒有失效，就會直接使用緩存的內容。

上圖中瀏覽器緩存中沒有該資源的緩存結果和標識，就會直接向伺服器發起HTTP請求。

2.協商緩存： 瀏覽器的強制緩存失效後(時間過期)，瀏覽器攜帶緩存標識請求伺服器，由伺服器決定是否使用緩存。

伺服器決定的規則？

控制協商緩存的欄位有 Last-Modified / If-Modified-Since 和 Etag / If-None-Match。

①Last-Modified 是伺服器返回給瀏覽器的本資源的最後修改時間。

當下次再次請求的時候，瀏覽器會在請求頭中帶 If-Modified-Since ,即上次請求下來的 Last-Modified 的值，

然後伺服器會用這個值和該資源最後修改的時間比較，如果最後修改時間大於這個值，則會重新請求該資源，返回狀態碼200。

如果這個值和最後修改時間相等，則會返回304，告訴瀏覽器繼續使用緩存。

② Etag 是伺服器返回的一個hash值。

當下次再次請求的時候，瀏覽器會在請求頭中帶 If-None-Match ,即上次請求下來的 Etag 值，

然後伺服器會用這個值和該資源在伺服器的 Etag 值比較，如果一致則會返回304，繼續使用緩存；如果不一致，則會重新請求，返回200。

二、伺服器緩存

上面是一個簡單的流程圖：

用戶1訪問A頁面，伺服器解析A頁面返回給用戶1，同時在伺服器內存上做一定映射，把A頁面緩存在硬碟上面

用戶2訪問A頁面，伺服器直接根據內存上的映射找到對應的頁面緩存，直接返回給用戶2，這樣就減少了伺服器對同一頁面的重復解析

伺服器緩存和瀏覽器緩存的區別：

伺服器緩存是把頁面緩存到伺服器上的硬碟里，而瀏覽器緩存是把頁面緩存到用戶自己的電腦里

Nginx伺服器 

Nginx是一個高性能的HTTP和反向代理伺服器。具有非常多的優越性：

在連接高並發的情況下，Nginx是Apache伺服器不錯的替代品，Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一。

Nginx提供了expires、etag、if-modified-since指令來實現瀏覽器緩存控制。

nginx -s reload#重新載入配置文件 

nginx -s reopen#重新打開log文件 

nginx -s stop#快速關閉nginx服務 

nginx -s quit #優雅的關閉nginx服務，等待工作進程處理完所有的請求

Nginx設置靜態文件的緩存過期時間 

location ~.*\.(js|css|html|png|jpg)$ {

  expires 3d;

}

 expires    3d;//表示緩存3天

expires    3h;//表示緩存3小時

expires    max;//表示緩存10年

expires    -1;//表示永遠過期。

如果設置為-1在js、css等靜態文件在沒有修改的情況下返回的是http 304，如果修改返回http 200

對於靜態資源會自動添加ETag，可以通過添加etag off指令禁止生成ETag。如果是靜態文件，那麼Last-Modified值為文件的最後修改時間。

在開發調試web的時候，經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱，提供下apache不緩存配置和nginx不緩存配置的設置。在常用的緩存設置裡面有兩種方式，都是使用add_header來設置：分別為Cache-Control和Pragma。

location ~ .*\.(css|js|swf|php|htm|html )$ {

  add_header Cache-Control no-store;

  add_header Pragma no-cache;

  }

nginx gzip壓縮

使用 gzip 壓縮可以降低網站帶寬消耗，同時提升訪問速度。

主要在nginx服務端將頁面進行壓縮，然後在瀏覽器端進行解壓和解析，

目前大多數流行的瀏覽器都遲滯gzip格式的壓縮，所以不用擔心。

默認情況下，Nginx的gzip壓縮是關閉的，同時，Nginx默認只對text/html進行壓縮

gzip on;

ersio #開啟gzip壓縮輸出

gzip_http_vn 1.0 ;#默認1.1

#其中的gzip_http_version的設置，它的默認值是1.1，就是說對HTTP/1.1協議的請求才會進行gzip壓縮

#如果我們使用了proxy_pass進行反向代理，那麼nginx和後端的upstream server之間是用HTTP/1.0協議通信的。

gzip_vary on ;

#和http頭有關系，加個vary頭，給代理伺服器用的，有的瀏覽器支持壓縮，有的不支持，

#所以避免浪費不支持的也壓縮，所以根據客戶端的HTTP頭來判斷，是否需要壓縮

gzip_comp_level 6;

#設置gzip壓縮等級，等級越底壓縮速度越快文件壓縮比越小，反之速度越慢文件壓縮比越大 1-9

gzip_proxied any;

#Ngnix作為反向代理的時候啟用

#expample:gzip_proxied no-cache;

# off – 關閉所有的代理結果數據壓縮

# expired – 啟用壓縮，如果header中包含」Expires」頭信息

# no-cache – 啟用壓縮，如果header中包含」Cache-Control:no-cache」頭信息

# no-store – 啟用壓縮，如果header中包含」Cache-Control:no-store」頭信息

# private – 啟用壓縮，如果header中包含」Cache-Control:private」頭信息

# no_last_modified – 啟用壓縮，如果header中包含」Last_Modified」頭信息

# no_etag – 啟用壓縮，如果header中包含「ETag」頭信息

# auth – 啟用壓縮，如果header中包含「Authorization」頭信息

# any – 無條件壓縮所有結果數據

gzip_types text/html ;#壓縮的文件類型

#設置需要壓縮的MIME類型,非設置值不進行壓縮

#param:text/html|application/x-javascript|text/css|application/xml

gzip_buffers 16 8k; #設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間

#設置gzip申請內存的大小,其作用是按塊大小的倍數申請內存空間

# param1:int 增加的倍數

# param2:int(k) 後面單位是k

# example: gzip_buffers 4 8k;

# Disable gzip for certain browsers.

gzip_disable 「MSIE [1-6].(?!.*SV1)」; #ie6不支持gzip，需要禁用掉ie6

『貳』 能用JS或者前端的什麼方法實現清除瀏覽器緩存嗎

原生JavaScript無法清除瀏覽器緩存，但部分瀏覽器開發了清除緩存的js調用介面
但這些方法只在特定頁面可以調用，只能由瀏覽器廠商製作的頁面調用，其他域名是無法調用這些高級API的
另外，Chrome擴展有清除瀏覽器緩存的API，必須由用戶安裝才可使用，無法在頁面上直接調用

『叄』 瀏覽器的渲染過程及涉及到的緩存機制

答：dns解析-》tcp鏈接-》發送HTTP請求-》伺服器處理請求並且返回報文-》瀏覽器解析渲染頁面-》鏈接結束

是一個將網址解析成IP 地址的過程。
首先從本地域名伺服器中查找，如果找不到就繼續向上根域名伺服器查找，直到頂級域名，這個過程中存在dns優化有的環節。當查找資源時， 會先找緩存，（瀏覽器緩存-》系統緩存-》路由器緩存等等），也會根據機器的負載量和距離用戶的位置進行dns負載均衡。

A.客戶端發送syn到伺服器要求連接
B.服務端向客戶端發送ack
C.客戶端收到ack並確認後，向服務端發送ack，連連接建立。

tcp連接建立之後，開始通過HTTP協議傳輸資源，根據情況判斷是否使用HTTPS，HTTP包括請求行，請求報頭，請求正文（post，put客戶端向伺服器傳輸數據的情況）。keepalive什麼的可以在請求頭里添加。

（此處涉及強制緩存和協商緩存， 為了先講清楚瀏覽器渲染過程，我把他們放在文章末尾。）

服務端接到請求開始對tcp進行處理，對http進行解析，按照報文格式封裝成HTTP request對象。響應報文碼（1xx：請求已接受，2XX：成功，3xx：重定向，4xx：客戶端錯誤，5xx：服務端錯誤）

邊解析邊渲染，首先解析html,構建dom樹，然後解析css，構建cssom。

我思考過很久HTML和css誰先渲染。我的理解是，不一定，看位置了，如果dom構建的過程中遇到了css的link，那就會先去載入並構建cssom，這個過程不是一次性的。 css和同步的js文件都是阻塞DOM樹渲染的，但不阻塞DOM解析， 直到js載入並且執行完畢。遇到阻塞的css也會延遲js的執行和dom構建。（因為js可能會修改dom或者cssom）,css同樣，當cssom構建時，js也會停止被阻塞，等待cssom構建完成。

defer & async
1.正常模式
<script src="script.js"></script>
遇到這樣的js標簽，瀏覽器會立即載入並執行，不等待後續載入的文檔元素。

2.async模式
<script async src="script.js"></script>
有async的js文件會和後續的DOM解析渲染並行執行，當js載入完成，立即執行，這時html解析暫停。因此不會按照標簽引入順序執行。

3.defer模式
<script defer src="script.js"></script>
有defer的js文件的載入，也會和文檔的解析構建並行。這一點與async一致。
不同的是，defer的js文件載入完不會立即執行， 會等到所有文檔解析完成後，DOMContentLoaded事件觸發之前完成， 因此會按照引入順序執行。

DOMContentLoaded & onload
DOM解析完（阻塞DOM的內容解析完，DOM才真正解析完）會觸發DOMContentLoaded事件。如果在DOMContentLoaded之後引入css樣式表，DOMContentLoaded可能無法獲取樣式表裡的樣式，此時DOM樹已經構建完成，但外部css文件還沒載入完成，這也是 css文件放在頭部的原因 。

onLoad
頁面的所有資源被載入以後觸發onLoad事件，會在DOMContentLoaded之後觸發。

這個過程中有兩個重要的過成是迴流和重繪。計算盒模型的大小位置還有解析顏色字體等 屬性，這些都確定下來的時候開始repain，合成一個rendertree渲染樹，render-tree中必須同時存在dom和cssom，瀏覽器開始布局並渲染到屏幕上。首次載入必然會經歷迴流和重繪的過程。

無論何時總會有一個初始化的頁面布局伴隨著一次繪制。（除非你希望你的頁面是空白的:)）之後，每一次改變用於構建渲染樹的信息都會導致以下至少一個的行為：

部分渲染樹（或者整個渲染樹）需要重新分析並且節點尺寸需要重新計算。這被稱為重排。注意這里至少會有一次重排-初始化頁面布局。

由於節點的幾何屬性發生改變或者由於樣式發生改變，例如改變元素背景色時，屏幕上的部分內容需要更新。這樣的更新被稱為重繪。

重排和重繪代價是高昂的，它們會破壞用戶體驗，並且讓UI展示非常遲緩。

一些重排可能開銷更大。想像一下渲染樹，如果你直接改變body下的一個子節點，可能並不會對其它節點造成影響。但是當你給一個當前頁面頂級的div添加動畫或者改變它的大小，就會推動整個頁面改變-聽起來代價就十分高昂。

瀏覽器一直致力於減少這些消極的影響，瀏覽器會創建一個變化的隊列，瀏覽器可以向隊列添加或變更這些變化，在一個特定的時間或達到一定的數量時，執行一次重排或重繪，通過這種方式，多次重排或重繪會整合起來最終減少重排或重繪的次數，以節省瀏覽器渲染的開銷。

所以 ，同時set和get樣式是非常糟糕的做法

看到的一個答案，有可能是這個原因，但是我不確定。
開發環境會把css都打包到js里，所以要等js載入好了才有樣式，因此會出現這種情況；但是在生產環境下，css會生成css文件，並插入到<style />里，因此就不會出現這種情況了。

兩個優化點：css先載入，js後載入
js盡量不要修改dom樹。

以下是我在OneNote的筆記，粘貼過來就會變成圖片沒有找到好的辦法。
強制緩存和協商緩存是http請求這一步的內容。

『肆』 js緩存問題怎麼解決

面對的緩存問題有兩個：一是頁面引入的JS文件緩存。二是JS請求後台的緩存。對於第一種情況，有兩種處理方式：
1、可以在頁面引入的JS文件後面增加日趨，如果不經常改動的文件，可以在每次改動後修改後綴。
2、對於第二種情況，一般的處理方式是在請求的路徑後面加上毫秒值，這樣每次請求的路徑都不一樣，但是對於後台來說都是一樣的，用來欺騙瀏覽器，進行實時請求，不調用瀏覽器緩存。

『伍』 JS如何清除IE瀏覽器緩存

一、CSS和JS為什麼帶參數（形如.css?t=與.js?t=）怎樣獲取代碼
css和js帶參數（形如.css?t=與.js?t=）
使用參數有兩種可能：
第一、腳本並不存在，而是服務端動態生成的，因此帶了個版本號，以示區別。 即上面代碼對於文件來說 等價於 但瀏覽器會認為他是 該文件的某個版本！
第二、客戶端會緩存這些css或js文件，因此每次升級了js或css文件後，改變版本號，客戶端瀏覽器就會重新下載新的js或css文件 ，刷性緩存的作用。
第二種情況最多，也可能兩種同時存在。
版本號，可以是一個隨機數，也可以是一個遞增的值，大版本小版本的方式，或者根據腳本的生成時間書寫，比如就是精確到了生成腳本的秒，而 2.3.3 就是大版本小版本的方式。
二、關於瀏覽器緩存
瀏覽器緩存，有時候我們需要他，因為他可以提高網站性能和瀏覽器速度，提高網站性能。但是有時候我們又不得不清除緩存，因為緩存可能誤事，出現一些錯誤的數據。像股票類網站實時更新等，這樣的網站是不要緩存的，像有的網站很少更新，有緩存還是比較好的。今天主要介紹清除緩存的幾種方法。
清理網站緩存的幾種方法
meta方法
<META HTTP-EQUIV="pragma" CONTENT="no-cache"> <META HTTP-EQUIV="Cache-Control" CONTENT="no-cache, must-revalidate"> <META HTTP-EQUIV="expires" CONTENT="0">123

清理form表單的臨時緩存
方式一：用ajax請求伺服器最新文件，並加上請求頭If-Modified-Since和Cache-Control,如下:
$.ajax({
url:'www.haorooms.com',
dataType:'json',
data:{},
beforeSend :function(xmlHttp){
xmlHttp.setRequestHeader("If-Modified-Since","0");
xmlHttp.setRequestHeader("Cache-Control","no-cache");
},
success:function(response){
//操作
}
async:false
});12345678910111213

方法二，直接用cache:false,
$.ajax({
url:'www.haorooms.com',
dataType:'json',
data:{},
cache:false,
ifModified :true ,

success:function(response){
//操作
}
async:false
});123456789101112

方法三：用隨機數，隨機數也是避免緩存的一種很不錯的方法！
URL 參數後加上 "?ran=" + Math.random(); //當然這里參數 ran可以任意取了eg:
<script>
document.write("<s"+"cript type='text/javascript' src='/js/test.js?"+Math.random()+"'></scr"+"ipt>");
</script>

其他的類似，只需在地址後加上+Math.random()
注意：因為Math.random() 只能在Javascript 下起作用，故只能通過Javascript的調用才可以 12345678

方法四：用隨機時間，和隨機數一樣。
在 URL 參數後加上 "?timestamp=" + new Date().getTime(); 1

用php後端清理
在服務端加 header("Cache-Control: no-cache, must-revalidate");等等(如php中)1

方法五：
5、window.location.replace("WebForm1.aspx");
參數就是你要覆蓋的頁面，replace的原理就是用當前頁面替換掉replace參數指定的頁面。
這樣可以防止用戶點擊back鍵。使用的是javascript腳本，舉例如下：
a.html
以下是引用片段：
<html>
<head>
<title>a</title>
<script language="javascript">
function jump(){
window.location.replace("b.html");
}
</script>
</head>
<body>
<a href="javascript:jump()">b</a>
</body> </html> b.html
以下是引用片段：
<html>
<head>
<title>b</title>
<script language="javascript">
function jump(){
window.location.replace("a.html");
}
</script>
</head>
<body>
<a href="javascript:jump()">a</a>
</body> </html>

轉載地址：http://www.haorooms.com/post/js_llq_hc

『陸』 js 瀏覽器緩存 -- 強緩存與協商緩存

既然根據文件修改時間來決定是否緩存尚有不足，能否可以直接根據文件內容是否修改來決定緩存策略？所以在 HTTP / 1.1 出現了 ETag 和If-None-Match

『柒』 ☆前端優化：瀏覽器緩存技術介紹

在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在WEB技術體系中扮演非常重要角色，是快速且有效地提升性能的手段。

一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷。

所以，緩存技術是無數WEB開發從業人員在工作過程中不可避免的一大問題。 在產品開發的時候我們總是想辦法避免緩存產生，而在產品發布之時又在想策略管理緩存提升網頁的訪問速度 。了解瀏覽器的緩存命中原理，是開發WEB應用的基礎，本文著眼於此，學習瀏覽器緩存的相關知識，總結緩存避免和緩存管理的方法，結合具體的場景說明緩存的相關問題。希望能對有需要的人有所幫助。

在實際WEB開發過程中，緩存技術會涉及到不同層、不同端，比如：用戶層、系統層、代理層、前端、後端、服務端等， 每一層的緩存目標都是一致的，就是盡快返回請求數據、減少延遲 ，但每層使用的技術實現是各有不同，面對不同層、不同端的優劣，選用不同的技術來提升系統響應效率。所以，我們首先看下各層的緩存都有哪些技術，都緩存哪些數據，從整體上，對WEB的緩存技術進行了解，如下圖所示：

本篇文章重點講的就是上面紅色框部分緩存內容。

當瀏覽器請求一個網站的時候，會載入各種各樣的資源，比如：HTML文檔、圖片、CSS和JS等文件。對於一些不經常變的內容，瀏覽器會將他們保存在本地的文件中，下次訪問相同網站的時候，直接載入這些資源，加速訪問。

那麼如何知曉瀏覽器是讀取了緩存還是直接請求伺服器？如下圖網站來做個示例：

第一次打開該網站後，如果再次刷新頁面。會發現瀏覽器載入的眾多資源中，有一部分size有具體數值，然而還有一部分請求，比如圖片、css和js等文件並沒有顯示文件大小，而是顯示了 from dis cache 或者 from memory cache 字樣。這就說明了，該資源直接從本地硬碟或者瀏覽器內存讀取，而並沒有請求伺服器。

瀏覽器啟用緩存至少有兩點顯而易見的好處： （1）減少頁面載入時間；（2）減少伺服器負載；

瀏覽器是否使用緩存、緩存多久，是由伺服器控制的 。准確來說，當瀏覽器請求一個網頁（或者其他資源）時， 伺服器發回的響應的「響應頭」部分的某些欄位指明了有關緩存的關鍵信息 。下面看下，HTTP報文中與緩存相關的首部欄位：

根據上面四種類型的首部欄位不同使用策略， 瀏覽器中緩存可分為強緩存和協商緩存 ：

當瀏覽器對某個資源的請求命中了強緩存時， 返回的HTTP狀態為200 ，在chrome的開發者工具的network裡面 size會顯示為from cache ，比如：京東的首頁里就有很多靜態資源配置了強緩存，用chrome打開幾次，再用f12查看network，可以看到有不少請求就是從緩存中載入的：

Expires是HTTP 1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由伺服器返回，用GMT格式的字元串表示 ，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires頭標簽的文件，就說明瀏覽器對於該文件緩存具有非常大的控制權。

例如，一個文件的Expires值是2020年的1月1日，那麼就代表，在2020年1月1日之前，瀏覽器都可以直接使用該文件的本地緩存文件，而不必去伺服器再次請求該文件，哪怕伺服器文件發生了變化。

所以， Expires是優化中最理想的情況，因為它根本不會產生請求 ，所以後端也就無需考慮查詢快慢。它的緩存原理，如下：

Expires是較老的強緩存管理header， 由於它是伺服器返回的一個絕對時間 ，在伺服器時間與客戶端時間相差較大時，緩存管理容易出現問題， 比如：隨意修改下客戶端時間，就能影響緩存命中的結果 。所以在HTTP 1.1的時候，提出了一個新的header， 就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒為單位，用數值表示 ，如：Cache-Control:max-age=315360000，它的緩存原理是：

Cache-Control描述的是一個相對時間 ，在進行緩存命中的時候， 都是利用客戶端時間進行判斷 ，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。

這兩個header可以只啟用一個，也可以同時啟用， 當response header中，Expires和Cache-Control同時存在時，Cache-Control優先順序高於Expires ：

此外，還可以為 Cache-Control 指定 public 或 private 標記。 如果使用 private，則表示該資源僅僅屬於發出請求的最終用戶，這將禁止中間伺服器（如代理伺服器）緩存此類資源 。對於包含用戶個人信息的文件（如一個包含用戶名的 HTML 文檔），可以設置 private，一方面由於這些緩存對其他用戶來說沒有任何意義，另一方面用戶可能不希望相關文件儲存在不受信任的伺服器上。需要指出的是，private 並不會使得緩存更加安全，它同樣會傳給中間伺服器（如果網站對於傳輸的安全性要求很高，應該使用傳輸層安全措施）。 對於 public，則允許所有伺服器緩存該資源 。通常情況下，對於所有人都可以訪問的資源（例如網站的 logo、圖片、腳本等）， Cache-Control 默認設為 public 是合理的 。

當瀏覽器對某個資源的請求沒有命中強緩存， 就會發一個請求到伺服器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字元串 ，比如你打開京東的首頁，按f12打開開發者工具，再按f5刷新頁面，查看network，可以看到有不少請求就是命中了協商緩存的：

查看單個請求的Response Header， 也能看到304的狀態碼和Not Modified的字元串，只要看到這個就可說明這個資源是命中了協商緩存，然後從客戶端緩存中載入的 ，而不是伺服器最新的資源：

【Last-Modified，If-Modified-Since】的控制緩存的原理，如下 ：

【Last-Modified，If-Modified-Since】都是根據伺服器時間返回的header，一般來說， 在沒有調整伺服器時間和篡改客戶端緩存的情況下，這兩個header配合起來管理協商緩存是非常可靠的，但是有時候也會伺服器上資源其實有變化，但是最後修改時間卻沒有變化的情況 ，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商緩存的可靠性。 所以就有了另外一對header來管理協商緩存，這對header就是【ETag、If-None-Match】 。它們的緩存管理的方式是：

Etag和Last-Modified非常相似，都是用來判斷一個參數，從而決定是否啟用緩存。 但是ETag相對於Last-Modified也有其優勢，可以更加准確的判斷文件內容是否被修改 ，從而在實際操作中實用程度也更高。

協商緩存跟強緩存不一樣，強緩存不發請求到伺服器， 所以有時候資源更新了瀏覽器還不知道，但是協商緩存會發請求到伺服器 ，所以資源是否更新，伺服器肯定知道。大部分web伺服器都默認開啟協商緩存，而且是同時啟用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:

如果沒有協商緩存，每個到伺服器的請求，就都得返回資源內容，這樣伺服器的性能會極差。

【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同時啟用，這是為了處理Last-Modified不可靠的情況。有一種場景需要注意：

比如，京東頁面的資源請求，返回的repsonse header就只有Last-Modified，沒有ETag：

協商緩存需要配合強緩存使用，上面這個截圖中，除了Last-Modified這個header，還有強緩存的相關header， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。

如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：

『捌』 能用JS或者前端的什麼方法實現清除瀏覽器緩存嗎

可以用JS實現清除瀏覽器緩存，解決方法如下：

1、在靜態頁面也就是以.html，.jsp，.aspx，.php結尾的文件中在<dead></head>中加入以下代碼。

注意事項：

JavaScriptJavaScript基於對象和事件驅動並具有相對安全性的客戶端腳本語言。也是一種廣泛用於客戶端Web開發的腳本語言，常用來給HTML網頁添加動態功能，比如響應用戶的各種操作。

『玖』 瀏覽器緩存機制

有dns的地方,就有緩存。瀏覽器、操作系統、Local DNS、根域名伺服器，它們都會對DNS結果做一定程度的緩存。

DNS查詢過程如下:

首先搜索瀏覽器自身的DNS緩存,如果存在，則域名解析到此完成。
如果瀏覽器自身的緩存裡面沒有找到對應的條目，那麼會嘗試讀取操作系統的hosts文件看是否存在對應的映射關系,如果存在，則域名解析到此完成。
如果本地hosts文件不存在映射關系，則查找本地DNS伺服器(ISP伺服器,或者自己手動設置的DNS伺服器),如果存在,域名到此解析完成。
如果本地DNS伺服器還沒找到的話,它就會向根伺服器發出請求,進行遞歸查詢。

瀏覽器本地緩存失效後，瀏覽器會向CDN邊緣節點發起請求。類似瀏覽器緩存,CDN邊緣節點也存在著一套緩存機制。CDN邊緣節點緩存策略因服務商不同而不同，但一般都會遵循http標准協議，通過http響應頭中的
Cache-control: max-age 的欄位來設置CDN邊緣節點數據緩存時間。

當瀏覽器向CDN節點請求數據時，CDN節點會判斷緩存數據是否過期，若緩存數據並沒有過期，則直接將緩存數據返回給客戶端；否則，CDN節點就會向伺服器發出回源請求，從伺服器拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。 CDN服務商一般會提供基於文件後綴、目錄多個維度來指定CDN緩存時間，為用戶提供更精細化的緩存管理。

CDN 優勢
CDN節點解決了跨運營商和跨地域訪問的問題，訪問延時大大降低。
大部分請求在CDN邊緣節點完成，CDN起到了分流作用，減輕了源伺服器的負載。

http請求報文（request）
請求行
請求方法  空格  URL 空格  協議版本 回車符 換行符
請求頭（通用信息頭、請求頭、實體頭）
頭部欄位名 冒號  值  回車鍵 換行符
...
頭部欄位名 冒號  值  回車鍵 換行符
空行
回車符   換行符
實體主體（只有post請求有）
主體

http響應報文（response）
狀態行
協議版本  空格  狀態碼 空格  狀態碼描述 回車符 換行符
響應頭部
頭部欄位名 冒號  值   回車符 換行符
...
頭部欄位名 冒號  值   回車符 換行符
空行
回車符   換行符
響應正文
正文

瀏覽器初次向伺服器發起請求後拿到請求結果，會根據響應報文中HTTP頭的緩存標識，決定是否緩存返回的結果，是則將請求結果和緩存標識存入瀏覽器緩存中

瀏覽器每次發起請求，都會現在瀏覽器緩存中查找該請求的結果以及緩存標識
瀏覽器                瀏覽器緩存        伺服器

——————第一次發起http請求——————>

<——沒有該請求的緩存結果和緩存標識————

——————————————發起http請求——————————————>

<——————————返回該請求結果和緩存規則————————————

——將請求結果和緩存標識存入瀏覽器緩存——>

強制緩存就是向瀏覽器緩存查找結果，並根據該結果的緩存規則來決定是否使用該緩存結果的過程

強制緩存的情況分為三種：
1、不存在該緩存結果和緩存標識，強制緩存失效，直接向伺服器發起請求
2、存在該緩存結果和緩存標識，但結果已經失效，強制緩存失效，使用協商緩存
3、存在該緩存結果和緩存標識，且該結果沒有失效，強制緩存生效，直接返回該結果

控制強制緩存的欄位：Expires，Cache-Control

Expires 是 HTTP/1.0 控制緩存的欄位，值為伺服器返回該請求的結果緩存時間
即再次發送請求是，客戶端時間 小於 Expires的值，直接使用緩存結果

Cache-Control 是HTTP/1.1的規則，主要用於控制網頁緩存，主要取值為：
public：所有的內容都緩存（客戶端和代理伺服器都可以緩存）
private：所有內容只有客戶端可以緩存（默認值）
no-cache：客戶端緩存內容，但是是否使用緩存則需要經過協商緩存來驗證決定
no-store：即不使用強制緩存，也不使用協商緩存
max-age=xxx：緩存內容將在xxx秒後失效

Expires 是一個絕對值
Cache-Control 中 max-age 是相對值，解決了 Expires時期 服務端與客戶端 可能出現時間差的問題

註：Expires和Cache-Control同時存在時，只有Cache-Control生效

協商緩存就是強制緩存失效後，瀏覽器攜帶緩存標識向伺服器發起請求，由伺服器根據緩存標識決定是否使用緩存的過程

協商緩存的兩種情況：
1、協商緩存生效，返回304，繼續使用緩存
過程：
瀏覽器                 瀏覽器緩存     伺服器

————————發起http請求————————>

<——該請求的緩存結果失效，只返回緩存標識——

————————攜帶該資源的緩存標識，發起http請求————————>

<—————————————304，該資源無更新————————————

——————獲取該請求的緩存結果——————>

<——————返回該請求的緩存結果——————

2、協商緩存失敗，返回200和請求結果
過程：
瀏覽器                 瀏覽器緩存     伺服器

————————發起http請求————————>

<——該請求的緩存結果失效，只返回緩存標識——

————————攜帶該資源的緩存標識，發起http請求————————>

<————————200，資源已更新，重新返回請求和結果———————

——將該請求結果和緩存標識存入瀏覽器緩存中—>

協商緩存的標識也是在響應報文的HTTP頭中和請求結果一起返回給瀏覽器的

控制協商緩存的欄位：
(1) Last-Modified/If-Modified-Since：Last-Modified是伺服器響應請求是，返回該資源文件在伺服器最後被修改的時間；If-Modified-Since再次發起請求時，攜帶上次返回的Last-Modified的值，伺服器將該欄位值與該資源最後修改時間對比，決定是否用緩存
(2)Etag/If-None-Match：Etag伺服器響應請求時，返回當前資源文件的一個唯一標識，由伺服器生成之；If-None-Match是再次發起請求時，攜帶上次返回的唯一標識Etag的值，伺服器收到後，將該欄位值與該資源在伺服器上的Etag對比，一致 則返回304，否則返回200

註：Etag/If-None-Match優先順序高於Last-Modified/If-Modified-Since，同時存在時只有Etag/If-None-Match生效

瀏覽器緩存分為：內存緩存 和 硬碟緩存

內存緩存特性：
(1)快速讀取：內存緩存會將編譯解析後的文件，存入該進程的內存中，便於下次運行時快速讀取
(2)時效性：一旦關閉進程，進程內存清空

硬碟緩存特性：
永久性：直接寫入硬碟文件中
復雜、緩慢：讀取緩存對該緩存存放的硬碟文件進行I/O操作，重新解析

from memory cache：使用內存中的緩存

from disk cache：使用硬碟中的緩存

瀏覽器讀取順序：memory ——> disk

瀏覽器將js和圖片等文件解析執行後直接存入內存緩存中，F5刷新頁面時，from memory cache(使用內存中的緩存)
css文件存入硬碟中，F5刷新頁面時，from disk cache(使用硬碟中的緩存)

參考文章
https://segmentfault.com/a/1190000017962411
https://www.cnblogs.com/chengxs/p/10396066.html