利用nginx設置瀏覽器協商緩存

強緩存與協商緩存的區別

　　強緩存：瀏覽器不與服務端協商直接取瀏覽器緩存

　　協商緩存：瀏覽器會先向服務器確認資源的有效性後才決定是從緩存中取資源仍是從新獲取資源

---

協商緩存運做原理

　　如今有一個這樣的業務情景：後端的靜態資源會不定時地發生更新，而由於瀏覽器默認使用強緩存，會默認從瀏覽器緩存中取到過期的資源。

　　如今咱們但願瀏覽器每次獲取資源的時候都向後端確認資源是否更新，就要設置瀏覽器使用協商緩存

　　那麼後端如何判斷資源是否更新了呢？這時就要用到Etag和Last-Modified兩項響應頭。

　　每次收到一個靜態資源的請求時，後端都將資源的最後修改時間（Last-Modified）、根據資源內容計算出來的Etag放在響應頭給前端。

　　前端收到響應後將這兩項緩存起來，而後在下次請求一樣資源的時候，將這兩項的內容放到If-Modified-Since和If-None-Match這兩項請求頭中。

　　服務端收到這兩項後，會與資源當前生成的Etag和Last-Modified作比較，若是二者都一致，說明資源沒有更新，服務端會返回304空響應；不然，說明資源有更新，服務端會將完整的資源內容返回

---

實現

　　那麼如何實現這樣一個複雜的過程呢？其實很簡單，只要使用nginx做爲靜態資源的服務器，再在響應頭加上Cache-Control:no-cache就能夠了。

　　下面來分步驟實現一下

　　1.  使用nginx做爲靜態資源的服務器

　　　　在nginx的配置中，將對靜態資源的請求映射到資源的磁盤路徑上

 1 http {
 2     server {
 3     listen 80;
 4     ...
 5     location /picture/ {
 6         alias D:/luozixi/tcp_test/picture/;
 7         # alias是重定義路徑
 8         # 好比訪問127.0.0.1/picture/1_new.gif，則會映射爲訪問D:/luozixi/tcp_test/picture/1_new.gif
 9         # web應用根本不會收到請求，picture的請求都被nginx處理了
10         # alias是替換，root是拼接
11         autoindex on;
12         # 訪問127.0.0.1/picture/，會獲得目錄的索引界面
13         }
14     }
15 }    

 

 

　　2.  從新加載nginx配置

nginx -s reload

 

　　3.  此時，請求靜態資源的時候nginx會自動在response頭中加上Etag和Last-Modified兩項

 　　

 

　　4.  可是這時發現，若是不配置Cache-Contrl: no-cache，瀏覽器在下次請求這個資源的時候不會將請求發向後端，而是直接從緩存中獲取資源

 

　　5. 在nginx中配置

location /picture/ { 
    add_header Cache-Control no-cache;
    alias D:/luozixi/tcp_test/picture/; 
}  

 

　　6. 清除瀏覽器緩存後第一次發起請求，會獲得一個正常的200 Response，並且響應頭裏已經有了Cache-Control: no-cache，表示使用協商緩存

 

　　7.  再次發起請求後，會發現請求頭已經帶上了If-Modified-Since和If-None-Match兩項

　　

 

　　8.  服務端（nginx）收到這兩項後，會與資源當前生成的Etag和Last-Modified作比較，若是二者都一致，說明資源沒有更新，服務端會返回304空響應；不然，說明資源有更新，服務端會將完整的資源內容返回

　　　　另外，服務器驗證If-Modified-Since的方式只是簡單的字符串比較，即便資源的Last-Modified比If-Modified-Since要早，服務端仍認爲資源有更新

 

　　9. 瀏覽器在收到304響應後，會從瀏覽器緩存中取資源。所以速度很是塊

　　

---

no-cache與no-store的區別

　　no-cache表示不緩存過時資源，緩存會向服務器進行有效處理確認以後處理資源

　　而no-store纔是真正的不進行緩存。