expires cache-control

Expires/Cache-Contro

Expires/Cache協議與上述驗證協議最大的不一樣在於，他能夠省略發送驗證請求環節，不須要服務器的驗證，而直接使用本地緩存。 一般這種方式，適用於，項目穩定，版本迭代很少的時候。
Expires
在服務器端能夠設置Expires的一個絕對時間。

//Response Headers
Expires:Tue, 03 May 2016 09:33:34 GMT

這告訴瀏覽器,在2016.5.3號以前,能夠直接使用該文本的緩存副本。可是，可能會由於服務器和客戶端的GMT時間不一樣，會有必定的bug。 因此，這裏只提議在長時間緩存的狀況下使用。不然，應該選擇Cache-Control.
那在服務器端該怎麼設置呢？ 這裏以nginx爲例:

location ~* \.(?:css|js)$ {
  expires 1d;
  access_log off;
  add_header Cache-Control "public";
}

經過expires設置過時時間爲一天，此時，服務器會根據當前的時間，加上一天.同時添加Expires和Cache-Control頭部標籤。
即,獲得的Response Header爲:

Expires: Fri, 28 Feb 2014 10:42:09 GMT
Cache-Control: max-age=86400 //24*60*60

(HTTP規定，若是出現max-age和expires，則max-age默認覆蓋掉expires)
當expires爲負數表示no-cache，正數或零表示max-age=time。
若是你不想緩存，能夠直接設置:

expires -1; //永遠過時，Cache-Control: no-cache

詳細能夠直接參閱:nginx配置

Cache-Control
這應該是HTTP1.1爲了解決HTTP1.0中expires的時間差的bug，而新添加的一個tag. 他的配置項不少，其實徹底均可以取代expires(如今大多數服務器都支持). 引用一段原話:

Cache-Control 頭在 HTTP/1.1 規範中定義，取代了以前用來定義響應緩存策略的頭（例如 Expires）。當前的全部瀏覽器都支持 Cache-Control，所以，使用它就夠了。
不過，目前大部分服務器都會將二者添加上，由於HTTP規定，若是Cache-Control和expires同時出現的話，expires會默認被覆蓋掉。
此時，返回的響應碼再也不是304(文件未改動),而是200(資源成功訪問).

當前每次發送請求以前瀏覽器會檢查緩存系統裏，是否有相應文件的備份，若是有的話，則直接從本地模仿一個Response頭
理論知識鋪墊完畢，咱們來take a look. 看看cache-control 有哪些能夠配置的屬性(如下屬性都跟在cache-control後)

public: 共有緩存，可被緩存代理服務器緩存,好比CDN
private: 私有緩存，不能被共有緩存代理服務器緩存，可被用戶的代理緩存如瀏覽器。

max-age=[秒]：表示在這個時間範圍內緩存是新鮮的無需更新。相似Expires時間，不過這個時間是相對的，而不是絕對的。也就是某次請求成功後多少秒內緩存是新鮮的。

s-maxage=[秒]：相似max-age, 除了僅應用於共享緩存（如代理）。

no-cache：這裏不是不緩存的意思，只是每次在使用緩存以前都強制發送請求給源服務器進行驗證，檢查文件該沒改變(其實這裏和ETag/Last區別不大)

no-store：就是禁止緩存，不讓瀏覽器保留緩存副本

must-revalidate：告訴瀏覽器，你這必須再次驗證檢查信息是否過時, 返回的代號就不是200而是304了。

proxy-revalidate：相似must-revalidate，除了只能應用於代理緩存。
好比，這裏我能夠設置Cache-Control爲:

//Response Headers
Cache-Control:private, max-age=0, must-revalidate

該文件是一個私有文件,只能被瀏覽器緩存，而不能被代理緩存。max-age標識該緩存當即過時，其實和no-cache實際上區別不大. 而後must-revalidate告訴瀏覽器，你必須給我再驗證文件過沒過時，好比接下來可能會驗證Last-Modified或者ETag.若是沒有過時則使用本地緩存.