<
META HTTP
-
EQUIV
=
"Pragma"
 CONTENT
=
"no-cache"
>

近一次移動端Vue應用的上線，導致某些用戶使用某些功能時出現問題，經主動清空緩存后恢復。有時候清空微信應用的存儲空間緩存仍不能解決問題，此時安卓機可借助微信TBS調試工具 http://debugx5.qq.com （微信中打開頁面，勾選最下面四個選項清除緩存），但該工具目前只支持安卓手機，蘋果機就比較麻煩了。為了找到問題的本質，從根本上避免問題，最近瀏覽了一些文章，其中有一篇對瀏覽器緩存的分析及在Nginx中對應的處理策略總結的比較好，這里分享給大家。

• 原文標題：http常用緩存策略及vue-cli單頁面應用服務器端(nginx)如何設置緩存
• 原文地址：http://www.shanhuxueyuan.com/news/detail/125.html

以下為原文。

關于http或者是瀏覽器緩存策略，我認為可以分為這三種：

• 不使用緩存
• 強制使用緩存
• 協商使用緩存

不使用緩存

有時，我們希望瀏覽器永遠都不要使用緩存，全部到服務器拉取數據，此時即為不使用緩存，我們可以在服務端通過Cache-Control為 no-store實現。

服務器端針對上面文件設置了no-store，可以看到在請求的時候，無論怎么刷新，都是返回200，不會顯示304，也不會顯示“memory cache”或“disk cache”，說明真的都是從服務器重新拉取數據。

比如我們想設置html文件不緩存，可以在域名的解析配置中如下設置，當文件后綴為html或htm時add_header Cache-Control "no-store"

server {
listen 80;
server_name yourdomain.com;
location / {
    try_files $uri $uri/ /index.html;
    root /yourdir/;
    index index.html index.htm;

    if ($request_filename ~* .*\.(?:htm|html)$)
    {
        add_header Cache-Control "no-store";  //對html文件設置永遠不緩存
    }  
  }
}

這種方式缺點就是每次都要去服務端拉取文件，即使文件沒有更新，很明顯這樣增加了不必要的帶寬消耗。

如果文件沒有更新，我們就使用緩存，只有更新了才去拉取最新文件，這樣多好，這就是協商緩存。

協商緩存

協商緩存就是瀏覽器攜帶文件緩存標識（如Last-Modified或ETag），向服務器發送請求，由服務器根據文件緩存標識來決定是否使用緩存，如果文件沒有更新，則告訴瀏覽器使用本地緩存，如果文件更新了，則直接返回新文件內容。

可以看出，相比不使用緩存，協商緩存是會大大減少帶寬消耗的。

• 協商緩存生效，返回304 和 Not Modified

• 協商緩存無效，返回200和請求文件

我們在瀏覽器調試頁面，可以看到有304的，即是使用了協商緩存

服務器返回的header中會有Last-Modified和ETag標識，而瀏覽器請求header中會包含If-Modified-Since和If-None-Match

Last-Modified和If-Modified-Since

在 http 1.0 版本中，第一次請求資源時服務器通過 Last-Modified 來設置響應頭的緩存標識，并且把資源最后修改的時間作為值填入，然后將資源返回給瀏覽器。在第二次請求時，瀏覽器會首先帶上 If-Modified-Since 請求頭去訪問服務器，服務器會將 If-Modified-Since 中攜帶的時間與資源修改的時間匹配，如果時間不一致，服務器會返回新的資源，并且將 Last-Modified 值更新，作為響應頭返回給瀏覽器。如果時間一致，表示資源沒有更新，服務器返回 304 狀態碼，瀏覽器拿到響應狀態碼后從本地緩存數據庫中讀取緩存資源。

這種方式有2個弊端，第一個就是當服務器中的資源增加了一個字符，后來又把這個字符刪掉，本身資源文件并沒有發生變化，但修改時間發生了變化。當下次請求過來時，服務器也會把這個本來沒有變化的資源重新返回給瀏覽器；第二個就是修改時間的單位為秒，所以存在1s的間隙，即使更新了，也會認為沒有更新。

ETag和If-None-Match

在 http 1.1 版本中，服務器通過 Etag 來設置響應頭緩存標識。Etag 的值由服務端生成，可以認為是文件內容的hash值。在第一次請求時，服務器會將資源和 Etag 一并返回給瀏覽器，瀏覽器將兩者緩存到本地緩存數據庫。在第二次請求時，瀏覽器會將 Etag 信息放到 If-None-Match 請求頭去訪問服務器，服務器收到請求后，會將服務器中的文件標識與瀏覽器發來的標識進行對比，如果不相同，服務器返回更新的資源和新的 Etag ，如果相同，服務器返回 304 狀態碼，瀏覽器讀取緩存。

兩者對比

• 首先在精確度上，Etag要優于Last-Modified。Last-Modified的時間單位是秒，如果某個文件在1秒內改變了多次，那么他們的Last-Modified其實并沒有體現出來修改，但是Etag每次都會改變確保了精度；如果是負載均衡的服務器，各個服務器生成的Last-Modified也有可能不一致。
• 第二在性能上，Etag要遜于Last-Modified，畢竟Last-Modified只需要記錄時間，而Etag需要服務器通過算法來計算出一個hash值。
• 第三在優先級上，服務器校驗優先考慮Etag

協商緩存服務端配置

可以在服務端通過設置Cache-Control為 no-cache或者max-age=0來實現

強制緩存

有時我們希望文件強制使用緩存，比如通過vue-cli產生的js和css，文件名上帶有hash值，所以如果文件名沒有變的時候，我們希望文件永久緩存，這樣可以減少網絡請求。

強制緩存整體流程比較簡單，就是在第一次訪問服務器取到數據之后，在過期時間之內不會再去重復請求。實現這個流程的核心就是如何知道當前時間是否超過了過期時間。

強制緩存的過期時間通過第一次訪問服務器時返回的響應頭獲取。在 http 1.0 和 http 1.1 版本中通過不同的響應頭字段實現。

在 http 1.0 版本中，強制緩存通過 Expires 響應頭來實現。 expires 表示未來資源會過期的時間。也就是說，當發起請求的時間超過了 expires 設定的時間，即表示資源緩存時間到期，會發送請求到服務器重新獲取資源。而如果發起請求的時間在 expires 限定的時間之內，瀏覽器會直接讀取本地緩存數據庫中的信息（from memory or from disk），兩種方式根據瀏覽器的策略隨機獲取。

在 http 1.1 版本中，可以設置Cache-Control中的 max-age=xxx ，來表示緩存的資源將在 xxx 秒后過期。一般來說，為了兼容，兩個版本的強制緩存都會被實現。

為什么有了Expires，后來又增加了max-age呢，這是因為Expires是一個絕對時間，有可能客戶端的時間和服務器不一致，導致緩存不能按照預期進行，而max-age則是個相對時間，比如3600s，自瀏覽器請求后3600s之內，都使用本地緩存，和客戶端的時間沒關系。

vue-cli緩存策略

由于打包后的js、css和圖片，一般名稱都帶有hash值，名稱中的hash變了，自然會拉取新文件，所以我們可以將這類文件設置為強制緩存，只要文件名不變，就一直緩存，比如緩存100天或者一年。

而html文件則不能設為強制緩存，一般html名稱是沒法帶hash值的，所以html如果設置了強制緩存，則永遠也沒法更新，html不更新，其引用的js、css等名稱也不會更新，則整個服務都沒有更新，只能讓用戶清除緩存了。所以針對html文件，我們可以設置協商緩存或者直接不使用緩存，本身html文件都比較小，我是直接使用了不緩存，nginx配置如下。

server {
listen 80;
server_name yourdomain.com;
location / {
    try_files $uri $uri/ /index.html;
    root /yourdir/;
    index index.html index.htm;

    if ($request_filename ~* .*\.(js|css|woff|png|jpg|jpeg)$)
    {
        expires    100d;  //js、css、圖片緩存100天
        #add_header Cache-Control "max-age = 8640000"; //或者設置max-age
    }

    if ($request_filename ~* .*\.(?:htm|html)$)
    {
        add_header Cache-Control "no-store";  //html不緩存
    }
  }
}

歡迎微信搜索關注公眾號：半路雨歌，查看更多技術干貨文章

言

緩存，這個問題在面試中出現的頻率還是很高的，也是我們日常工作中必知必會的。

所以在本文中，我們來嘗試對HTTP 協議中規定的很多請求頭和響應頭來做總結和歸納，讓大家了解到瀏覽器是如何通過他們來控制緩存的。

經典 GET 請求過程

下圖是一個經典的 GET 請求的處理過程：

當一個請求達到時，瀏覽器會先檢查被訪問的資源是否已被緩存。

如果未被緩存（緩存未命中 cache miss），則將請求轉發給原始服務器。

如果已被緩存（緩存命中，cache hit），則會檢查緩存是否足夠新鮮。

如果緩存的副本足夠新鮮，則直接將副本返回給客戶端，否則會向服務端發起新鮮度驗證（revalidation）。如果發現與服務端文件一致，則將本地緩存副本返回給客戶端，否則將請求轉發給原始服務器。

在這個過程中，由緩存提供的服務在所有請求占比中的比例稱為緩存命中率（cache hit rat）。

這種描述方式只能描述請求級別的命中情況，無法體現具體有多少流量來自緩存。

比如一個訪問頻次很低，尺寸又很大的文件，如果以該命中率來描述的話，命中率非常低。但是這個文件卻占據了絕大多數的訪問流量。

因此還需要另一個命中率指標來描述，那就是字節命中率（byte hit rate）。字節命中率表示的是緩存提供的字節在所有傳輸字節中的占比。

緩存機制

瀏覽器常用校驗緩存的機制有兩種：

• 文檔過期（document expiration）
• 服務端再驗證（server revalidation）

下面我們來分別介紹下這兩種機制。

文檔過期

HTTP 通過 Cache-Control:max-age 和 Expires 這兩個響應頭信息， 讓原始服務器向每個文檔附加一個“過期日期”。在緩存文檔過期之前，緩存可以以任意頻次使用這些副本，而無需與服務端聯系。
Expires 首部與 Cache-Control:max-age 首部本質上是一樣的，區別是 Expires 是 HTTP/1.0 協議規定的首部，且首部取值為一個絕對時間，在這個時間之后緩存失效；Cache-Control:max-age 是 HTTP/1.1 協議規定的首部，且首部取值是一個相對時間，單位為秒。

一個絕對，一個相對。

服務端再驗證

HTTP 定義了 5 個條件請求首部來完成服務器再驗證：

1. If-Modified-Since
2. If-None-Match
3. If-Unmodified-Since
4. If-Range
5. If-Match

其中最有用的是 If-Modified-Since 和 If-None-Match 兩個首部。

一、If-Modified-Since: Date 再驗證

If-Modified-Since: Date 再驗證請求流程分兩種：

1、自指定日期后，文檔被修改了，If-Modified-Since 條件為真，GET 請求就會執行。攜帶新首部的新文檔會被返回給緩存，新首部除了其他信息以外，還包含了一個新的過期日期。

2、自指定日期后，文檔沒有被修改過，If-Modified-Since 條件為假，則會向客戶端返回一個304 Not Modified 響應報文，為了提高有效性，一般會發送一個新的過期日期，不會返回文檔的主體。

If-Modified-Since 請求首部通常與 Last-Modified 服務器響應首部配合工作。原始服務器會將最后的修改日期附加到文檔上去。當瀏覽器要對已緩存的文檔進行再驗證時，就會包含一個 If-Modified-Since首部，其中攜帶有最后修改已緩存副本的日期：

If-Modified-Since: <cached last-modified date>

這里以W3C網站為例：

從上面兩張圖上，可以分別看到請求頭信息中的 If-Modified-Since 和響應頭信息中的 Last-Modified。

說白了，就是本地記錄的修改日期，與服務器那邊記錄的修改日期做對比。如果服務的比較新，就重新過去，否則加載本地的。

上圖我第一次進來，因為本地并沒有If-Modified-Since 記錄，所以只能看到響應頭中有最后修改時間信息，以及返回的200狀態碼。

當我再次刷新網頁之后：

瞧，請求頭也有信息了。因為If-Modified-Since 和 Last-Modified兩個值是一樣的，所以服務器校驗本頁面為緩存，返回304狀態碼。

If-None-Match: etag 實體標簽驗證

在某些情況下，If-Modified-Since: Date 可能無法很好地解決緩存問題。

比如一個被周期性復寫的文件，雖然修改日期每次都有變化，但是文件的內容往往是一樣的，如果此時還根據最后修改時間去判定是否為緩存，顯示是不合適的。

這種情況下，就需要借助實體標簽（Etag）驗證了。

實體標簽就是“版本標識符”，是附加到文檔上的任意標簽（引用字符串），可能包含了文檔的序列號或版本名，或者是文檔內容的校驗信息。
If-None-Match: etag 實體標簽驗證的工作過程與 If-Modified-Since: Date 再驗證的工作過程基本一致，不同的是，服務器會在響應中附加一個 Etag 響應頭。當緩存要對已緩存的文檔進行再驗證時，就會將這個 etag 放到 If-None-Match 請求頭中去。

還是以上面的請求為例：

可以看到，If-none-match 在chrome網絡面板中的位置，就是在 If-modifed-since 后面，只是它對應的不是修改日期，而是上面相應的etag罷了。

說簡單點，就是hash字符串校驗。

注意：如果你是第一次訪問該頁面，請求頭中同樣沒有 if-none-match 信息。

其他相關屬性

一、服務器端響應

服務端通過Cache-Control 來對響應緩存做限制，以下控制優先級按順序依次遞減：

Cache-Control: no-store 禁止緩存對響應進行復制。
Cache-Control: no-cache/ Pragma: no-cache 緩存可以復制響應，但是在與原始服務器進行新鮮度再驗證之前不能將其提供給客戶端。Pramga: no-cache 為了兼容 HTTP/1.0，優先級低于 Cache-Control: no-cache。
Cache-Control: must-revalidate 在事前沒有跟原始服務器進行再驗證的情況下，緩存不能提供緩存副本。
Cache-Control: max-age max-age 指定的秒數內有效。max-age 為零時，不可緩存。
Expires: Date 在實際的絕對日期之前有效。

二、客戶端請求
客戶端同樣可以通過 Cache-Control 請求首部來強化或放松對過期時間的限制。以下是使用時的具體參數及說明：

Cache-Control: max-stale=< s > 緩存可以隨意提供副本，如果指定的秒數，那么在這段時間內，文檔不能過期。
Cache-Control: min-fresh=< s > 至少在未來< s >秒內文檔保持新鮮。
Cache-Control: max-age=< s > 緩存無法返回緩存時間超過< s >的文檔。如果與 max-stale 通用，max-stale 優先級更高。
Cache-Control: no-cache/Pragma: no-cache 除非進行了再驗證，否則客戶端不接受已緩存的資源。
Cache-Control: no-store 緩存應該刪除本地緩存副本，使用原始服務器響應。
Cache-Control: only-if-cache 只有當緩存中有副本存在時，客戶端才會獲取一份副本。

總結

好了，緩存就暫時先說到這里。最后讓我們再來看下瀏覽器的緩存執行流程，鞏固一下吧。

瀏覽器首次請求：

瀏覽器再次請求時：