強快取與協商快取的區別
強快取：瀏覽器不與服務端協商直接取瀏覽器快取
協商快取：瀏覽器會先向伺服器確認資源的有效性後才決定是從快取中取資源還是重新獲取資源
協商快取運作原理
現在有一個這樣的業務情景：後端的靜態資源會不定時地發生更新，而因為瀏覽器預設使用強快取，會預設從瀏覽器快取中取到過時的資源。
現在我們希望瀏覽器每次獲取資源的時候都向後端確認資源是否更新，就要設定瀏覽器使用協商快取
那麼後端如何判斷資源是否更新了呢？這時就要用到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才是真正的不進行快取。