nginx設置資源緩存實戰

一直很想學習緩存這一起的東西，畢竟前端性能優化緩存在其中佔了很大一部分做用。緩存分爲兩種：強制緩存和協商緩存。看過不少文章講它們之間的區別，可是沒有實戰過只知道其意義殊不知道怎樣去設置，沒有實戰過也致使記憶老是很模糊，實踐纔是最好的老師！記錄一下我使用nginx服務器學習緩存的過程。

初探

首先我在 nginx 的根目錄下新建了一個 index.html 文件以及 index.js 文件。此時 nginx 的配置文件是長這個樣子的：

server {
  listen       8080;
  server_name  localhost;
  location / {
     root  /Volumes/myFile/nginx_root;   
     index  index.html index.htm;
  }
}
複製代碼

而後咱們瀏覽器訪問 localhost:8080。打開控制檯，發現裏面有兩條請求：

能夠看到第一次訪問，兩條請求的狀態碼都是 200。咱們點開其中一條請求看看響應頭信息：

能夠看到，響應頭中給咱們攜帶了 Etag 以及 Last-Modified 信息。這就是協商緩存所使用的字段嘛。看來 nginx 已經默認給咱們使用了緩存。那咱們在不修改 html文件以及js文件的基礎上再次去刷新頁面驗證一下，命中協商緩存的話，狀態碼應該給咱們返回 304 Not Modified 。我刷新了幾回去觀察http請求的狀態碼。html文件每次都是返回的 304。可是 js 文件在最初是 304 後面卻變成了 200 OK (from memory cache) 。也就是說每一次html文件都是命中了協商緩存，而js文件都是命中了強緩存(強緩存的優先級是高於協商緩存的)。爲何會出現這樣的狀況呢，我百度一下：

爲何有的緩存是 200 OK (from cache)，有的緩存是 304 Not Modified 呢？很簡單，看是否移除了 Entity Tag。移除了，就老是 200 OK (from cache)。沒有移除，就二者會交替出現。

那麼，二者觸發的時機有什麼區別呢？200 OK (from cache) 是直接點擊連接訪問，輸入網址按回車訪問也能觸發；而 304 Not Modified 是刷新頁面時觸發，或是設置了強緩存、但 Entity Tags 沒有移除時觸發。

對照個人例子，我是這樣理解的：index.html 文件刷新頁面命中協商緩存返回了 304，而 js 文件是在 index.html 文件中連接引入的，因此命中強緩存 200 OK (from cache) 。爲了驗證個人想法，我用在地址欄直接訪問了 index.js 文件。地址欄鍵入：localhost:8080/index.js，此時的確是返回了 304 給我了，在來看一下此時的請求頭：

能夠看到此時 Cache-Control 給的是max-age=0；而後也攜帶上了協商緩存的相關參數。看來在瀏覽器是刷新操做的時候就會攜帶上 Cache-Control:max-age=0 以此來避免命中強緩存。

nginx禁用強緩存

在試試 nginx 禁用強緩存以後會發生什麼效果。修改 nginx 配置文件：

server {
  listen       8080;
  server_name  localhost;
  location / {
     root  /Volumes/myFile/nginx_root;   
     index  index.html index.htm;
     add_header Cache-Control no-cache;
     # 爲 public能夠被任何對象緩存，private只能針對我的用戶，而不能被代理服務器緩存
     add_header Cache-Control private;
  }
}
複製代碼

修改完 nginx 配置文件以後咱們重啓一下 nginx 服務器。此時在訪問 localhost:8080

能夠看到，此時 html 文件和 js文件都是 304 都是命中協商緩存了。

Cache-Control：no-store

禁止一切緩存（這個纔是響應不被緩存的意思）。緩存一般會像非緩存代理服務器同樣，向客戶端轉發一條 no-store 響應，而後刪除對象。

Cache-Control：no-cache

強制客戶端直接向服務器發送請求,也就是說每次請求都必須向服務器發送。服務器接收到請求，而後判斷資源是否變動，是則返回新內容，不然返回304，未變動。這個很容易讓人產生誤解，令人誤覺得是響應不被緩存。實際上Cache-Control: no-cache是會被緩存的，只不過每次在向客戶端（瀏覽器）提供響應數據時，緩存都要向服務器評估緩存響應的有效性。

其實將 Cache-Control 設置爲 no-store 纔是真正的不被緩存的意思，那在修改一下 nginx 文件將 Cache-Control 設置爲 no-store 看看會發生什麼。此時再次刷新瀏覽器。

能夠看到，修改完 nginx 的配置文件以後，除了第一次是304(此次訪問瀏覽器纔剛剛接收到 no-store的信息，請求頭上仍是攜帶了緩存相關信息) 外，剩下的幾回刷新頁面都是返回 200了。既沒有命中強緩存、也沒有命中協商緩存。在看一下 index.js 文件的 http 頭信息。

這裏的圖我沒有截完整，其實響應頭中還包含了Cache-Control: no-store。能夠看到，在Cache-Control: no-store 的加持下，即便在響應頭中服務請返回了協商緩存的參數，可是在瀏覽器在請求資源的時候，並無帶上緩存相關的參數了，因此，如今沒有緩存了，既不會命中強緩存，也不會命中協商緩存，每一次http請求的資源都是從服務器上返回的。

結語

此次的探索到如今就結束了，其實就是我一次學習的記錄吧。實踐了一次以後確實對緩存有了更清晰的理解和認知，果然實踐出真知。後續打算還會記錄一篇在如今前端使用 React.js 或者 Vue.js 等框架打包以後前端資源如何利用 nginx 作部署還有配置相關緩存的文章，到時候在看有沒有記錄下來的意義把。

最後要感謝一下 看完這篇還不清楚緩存，求你打我 文章的做者 三妹，文中的關於緩存字段的講解的部分是直接 copy 他文章裏面的。

若是文章中有什麼錯誤的地方還請你們指正。

---

參考文章： 看完這篇還不清楚緩存，求你打我