apache設置靜態內容緩存時間

① Nginx緩存設置教程

| 這篇文章主要介紹了Nginx緩存設置案例詳解,本篇文章通過簡要的案例,講解了該項技術的了解與使用,以下就是詳細內容,需要的朋友可以參考下 |

在開發調試web的時候，經常會碰到因瀏覽器緩存(cache)而經常要去清空緩存或者強制刷新來測試的煩惱，提供下apache不緩存配置和nginx不緩存配置的設置。在常用的緩存設置裡面有兩種方式，都是使用add_header來設置：分別為Cache-Control和Pragma。

對於站點中不經常修改的靜態內容（如圖片，JS，CSS），可以在伺服器中設置expires過期時間，控制瀏覽器緩存，達到有效減小帶寬流量，降低伺服器壓力的目的。

以Nginx伺服器為例：

【背景】：Expires是Web伺服器響應消息頭欄位，在響應http請求時告訴瀏覽器在過期時間前瀏覽器可以直接從瀏覽器緩存取數據，而無需再次請求。

【相關資料】

1、Cache-control策略

Cache-Control與Expires的作用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據還是重新發請求到伺服器取數據。只不過Cache-Control的選擇更多，設置更細致，如果同時設置的話，其優先順序高於Expires。

http協議頭Cache-Control ：

值可以是public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age

各個消息中的指令含義如下：

Last-Modified/If-Modified-Since

其最終達到的就是等效於設置這三類html緩存技術：

② 誰熟悉APACHE的緩存配置

Apache中關於頁面緩存的設置

Expires、Cache-Control、Last-Modified、
ETag是RFC
2616（HTTP/1.1）協議中和網頁緩存相關的幾個欄位。前兩個用來控制緩存的失效日期，後兩個用來驗證網頁的有效性。要注意的是，
HTTP/1.0有一個功能比較弱的緩存控制機制：Pragma，使用HTTP/1.0的緩存將忽略Expires和Cache-Control頭。我們
這里以Apache2.0伺服器為例，只討論HTTP/1.1協議。

Expires

Expires欄位聲明了一個網頁或URL地址不再被瀏覽器緩存的時間，一旦超過了這個時間，瀏覽器都應該聯系原始伺服器。RFC告訴我們：「由於推斷的失效時間也許會降低語義透明度，應該被謹慎使用，同時我們鼓勵原始伺服器盡可能提供確切的失效時間。」

對於一般的純靜態頁面，如html、gif、jpg、css、js，默認安裝的Apache伺服器，不會在響應頭添加這個欄位。Firefox瀏覽

器接受到相應後，如果發現沒有Expires欄位，瀏覽器根據文件的類型和「Last-Modified」欄位來推斷出一個合適的失效時間，並存儲在客戶
端。推測出的時間一般是接受到響應時間後的三天左右。

Apache的expires_mole模塊可以在Http響應頭部自動加上Expires欄位。在Apache的httpd.conf文件中進行如下配置：

#啟用expires_mole模塊
LoadMole expires_mole moles/mod_expires.so
# 啟用有效期控制
ExpiresActive On
# GIF有效期為1個月
ExpiresByType image/gif A2592000
# HTML文檔的有效期是最後修改時刻後的一星期
ExpiresByType text/html M604800
#以下的含義類似
ExpiresByType text/css 「now plus 2 month」
ExpiresByType text/js 「now plus 2 day」
ExpiresByType image/jpeg 「access plus 2 month」
ExpiresByType image/bmp 「access plus 2 month」
ExpiresByType image/x-icon 「access plus 2 month」
ExpiresByType image/png 「access plus 2 month」

對於動態頁面，如果在頁面內部沒有通過函數強制加上Expires，例如header(」Expires: 」 . gmdate(」D, d M
Y H:i:s」) . 」 GMT」)，Apache伺服器會把Wed, 11 Jan 1984 05:00:00 GMT
作為Expires欄位內容，返回給瀏覽器。即認為動態頁面總是失效的。而瀏覽器仍然會保存已經失效的動態頁面。

可以發現Firefox瀏覽器總是緩存所有頁面，不管失效、不失效還是沒有聲明失效時間。即使緩存中聲明了一個網頁的實效日期是1970-01-
01 08:00:00，瀏覽器仍然會發送該文件在緩存中的Last-Modified和ETag欄位。
如果在伺服器端驗證通過，返回304狀態，瀏覽器就還會使用此緩存。

Cache-Control

Cache-Control欄位中可以聲明多些元素，例如no-cache, must-revalidate,
max-age=0等。這些元素用來指明頁面被緩存最大時限，如何被緩存的，如何被轉換到另一個不同的媒介，以及如何被存放在持久媒介中的。但是任何一個
Cache-Control指令都不能保證隱私性或者數據的安全性。「private」和「no-store」指令可以為隱私性和安全性方面提供一些幫
助，但是他們並不能用於替代身份驗證和加密。

Apache的mod_cern_meta模塊允許文件級Http響應頭部的控制，同時它也可以配置Cache-Control頭（或任何其他頭）。響應頭文件是放在原始目錄的子目錄中，根據原始文件名所命名的一個文件。具體用法請參閱Apache的官方網站。

其中Cache-Control :
max-age表示失效日期。如果沒有啟動mod_cern_meta模塊，Apache伺服器會把Expires欄位中的日期換算成以秒為單位的一個
delta值，賦值給max-age。如果啟動mod_cern_meta模塊，並且配置了max-age值，Apache會將這個覆蓋Expires字
段。同時，max-age隱含了Canche-Control: public。這樣瀏覽器接受到的Cache-Control :
max-age和Expires值就是一致的。

如果失效日期Cache-Control : max-ag=0或者是負值，瀏覽器會在對應的緩存中把Expires設置為1970-01-01 08:00:00。

Last-Modified

Last-Modified和ETag是條件請求(Conditional
Request)相關的兩個欄位。如果一個緩存收到了針對一個頁面的請求，它發送一個驗證請求詢問伺服器頁面是否已經更改，在HTTP頭裡面帶上」
ETag」和」If Modify Since」頭。伺服器根據這些信息判斷是否有更新信息，如果沒有，就返回HTTP 304（Not
Modify）；如果有更新，返回HTTP 200和更新的頁面內容，並且攜帶新的」ETag」和」Last-Modified」。

使用這個機制，能夠避免重復發送文件給瀏覽器，不過仍然會產生一個HTTP請求。

一般純靜態頁面本身都會有Last-Modified信息，Apache伺服器會讀取頁面文件中的Last-Modified信息，並添加到http響應頭部。

對於動態頁面，如果在頁面內部沒有通過函數強制加上Last-Modified，例如header(」Last-Modified: 」 .
gmdate(」D, d M Y H:i:s」) . 」
GMT」)，Apache伺服器會把當前時間作為Last-Modified，返回給瀏覽器。

無論是純靜態頁面還是動態頁面，Firefox瀏覽器巧妙地按照接受到伺服器響應的時間設置緩存頁面的Last-Modified，而不是按照http響應頭部中的Last-Modified欄位。

ETag

既然有了Last-Modified，為什麼還要用ETag欄位呢？因為如果在一秒鍾之內對一個文件進行兩次更改，Last-Modified就會不正確。因此，HTTP/1.1利用Entity Tag頭提供了更加嚴格的驗證。

Apache伺服器默認情況下，會對所有的靜態、動態文件的響應頭添加ETag欄位。

在Apache的httpd.conf文件中可以通過FileETag指令配置該選項。FileETag指令配置了當文檔是基於一個文件時用以創建
Etag（entity tag）響應頭的文件的屬性。在Apache
1.3.22及以前，ETag的值是對文件的索引節（INode），大小（Size）和最後修改時間（MTime）進行Hash後得到的。
如果一個目錄的配置包含了『FileETag INode MTime Size』而其一個子目錄包含了『FileETag
-INode』那麼這個子目錄的設置（並會被其下任何沒有進行覆蓋的子目錄繼承）將等價於『FileETag MTime Size』。

在多台負載平衡的伺服器環境下，同一個文件會有不同的etag或者文件修改日期，瀏覽器每次都會重新下載。設置『FileETag None』可以使響應頭不再包含ETag欄位。

③ 如何設置靜態內容緩存時間

你好，
一、打開IIS，滑鼠右鍵你要設置的網站，然後「屬性」

(第一步操作)

二、選擇「HTTP頭」選項卡，勾選「啟用內容過期」，選中「立即過期」，然後「確定」。

(第二步操作)

解釋一下這一步的效果。設置此網站所有內容都不進行緩存，也就是每次訪問都全新載入。

三、展開網站，找到要進行緩存的目錄。（一般是存放上傳文件、圖片、JS等文件的目錄）然後「滑鼠右鍵」----「屬性」

(第三步操作)

四、選擇「HTTP頭」選項卡，勾選「啟用內容過期」，選中「此時間段後過期」，設置過期時間，然後「確定」

(第四步操作)

OK,這時候已經設置成功了。

④ 緩存靜態資源，不知怎麼解決

之前看過apach及nginx對於靜態資源（含js，圖片，css等）部分的緩存，用於加速並減輕後台實際web伺服器的壓力。
靜態資源緩存是WEB伺服器優化的一種手段，基本原理如下：
1.客戶端瀏覽器請求伺服器一個服務(該服務含有圖片，js等靜態資源)，通常會對於每一個網頁中的獨立圖片或js文件發送一個http請求
2.WEB伺服器對於每個資源HTTP請求進行解析，並生成一個資源修改時間的唯一值（可以是etag或last_modified參數），放入伺服器端map，key為資源url，value為資源修改時間。最後將此資源修改時間的唯一值包含在http頭上返回，因為是首次請求，所以會將所有內容放在http body中一並返回給客戶瀏覽器端
3.客戶瀏覽器接收服伺服器響應，並將伺服器返回的資源修改時間作為key放入瀏覽器客戶端，value為http body中的實際資源內容
4.客戶瀏覽器再次請求靜態資源時，會將資源修改時間一並發送給伺服器
5.服務端會從最新的map中取出該資源url對應的修改時間，如果值晚於客戶端請求的資源修改時間，這時會返回最新的已經修改過的資源給客戶端。否則返回304 not modifed

這里記錄資源修改時間的方式有etag及last_modified。最先有的是last_modified，它的工作方式就是上述介紹的，但缺點是只能精確到秒級別。也就是說當你在一秒中修改資源兩次，而客戶端拿到的是第一次修改，那之後就算客戶端第二次再次請求也不會拿到最新的資源。
而etag的出現正是為了解決last_modified的秒級問題，於http 1.1被提出。

今天測試了下，在沒有nginx等前端反向代理伺服器時，tomcat竟然默認對靜態資源做了緩存。
tomcat默認運用etag及last_modifed。etag與if_no_match(客戶端瀏覽器上傳時在http head中應該放的屬性名)一起使用，last_modified與If-Modified-Since一起使用。

客戶端首次請求時，得到請求響應數據如下：

GET http://localhost:8080/webTest/jsp/index.jsp [HTTP/1.1 200 OK 1ms]
GET http://localhost:8080/webTest/js/hello.js [HTTP/1.1 200 OK 1ms]
GET http://localhost:8080/webTest/img/a.jpg [HTTP/1.1 200 OK 2ms]
我們看一下Hello.js這個請求響應具體信息：
server Apache-Coyote/1.1 (表明伺服器是tomcat)
Last-Modified: Sun, 11 May 2014 10:54:33 GMT
Etag: W/"175-1399805673000"
Date: Sun, 11 May 2014 10:59:23 GMT
Content-Type: application/javascript;charset=UTF-8
Content-Length: 175
Accept-Ranges: bytes

從上面可以看到tomcat即返回了last_modified也返回了etag。

客戶端再次請求時，請求數據如下：
If-None-Match: W/"175-1399805673000"
If-Modified-Since: Sun, 11 May 2014 10:54:33 GMT
響應如下：

GET http://localhost:8080/webTest/jsp/index.jsp [HTTP/1.1 200 OK 1ms]
GET http://localhost:8080/webTest/js/hello.js [HTTP/1.1 304 Not Modified 1ms]
GET http://localhost:8080/webTest/img/a.jpg [HTTP/1.1 304 Not Modified 1ms]
從中我們可以看到tomcat對於靜態數據作了緩存。

接著我們分析tomcat對於這部分靜態緩存的判斷處理，這部分邏輯是寫在DefaultServlet類中，
我們可以在doGet方法中進入ServiceContext方法中找到以下源碼：
// Check if the conditions specified in the optional If headers are
// satisfied.
if (cacheEntry.context == null) {

// Checking If headers
boolean included =
(request.getAttribute(Globals.INCLUDE_CONTEXT_PATH_ATTR) != null);
if (!included
&& !checkIfHeaders(request, response, cacheEntry.attributes)) { //這句判斷是否需要返回整個資源請求
return;
}

}
上面源碼的 if (!included
&& !checkIfHeaders(request, response, cacheEntry.attributes))
用於判斷是否需要返回整個資源，如果indcluded與checkIfHeaders方法返回的都是false，這時就直接返回，說明資源未修改，或者是緩存不支持的請求方式。
我們接著查看checkIfHeaders方法：
/**
* Check if the conditions specified in the optional If headers are
* satisfied.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param resourceAttributes The resource information
* @return boolean true if the resource meets all the specified conditions,
* and false if any of the conditions is not satisfied, in which case
* request processing is stopped
*/
protected boolean checkIfHeaders(HttpServletRequest request,
HttpServletResponse response,
ResourceAttributes resourceAttributes)
throws IOException {

return checkIfMatch(request, response, resourceAttributes)
&& checkIfModifiedSince(request, response, resourceAttributes)
&& checkIfNoneMatch(request, response, resourceAttributes)
&& checkIfUnmodifiedSince(request, response, resourceAttributes);

}

可以看到tomcat只有當這四個屬性全部返回true(也就是說全部認為資源已經改變)才會返回true，這樣最終會將整個資源（最新修改過的）返回客戶端。
在這里，我們從上面實際過程當中看到，瀏覽器第二次請求資源時在http請求header中放了
If-None-Match: W/"175-1399805673000"
If-Modified-Since: Sun, 11 May 2014 10:54:33 GMT
這兩個屬性。
因此我們查看
&& checkIfModifiedSince(request, response, resourceAttributes)
&& checkIfNoneMatch(request, response, resourceAttributes)
這兩個方法
checkIfModifiedSince源碼如下：
/**
* Check if the if-modified-since condition is satisfied.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param resourceInfo File object
* @return boolean true if the resource meets the specified condition,
* and false if the condition is not satisfied, in which case request
* processing is stopped
*/
protected boolean checkIfModifiedSince(HttpServletRequest request,
HttpServletResponse response,
ResourceAttributes resourceAttributes) {
try {
long headerValue = request.getDateHeader("If-Modified-Since");
long lastModified = resourceAttributes.getLastModified();
if (headerValue != -1) {

// If an If-None-Match header has been specified, if modified since
// is ignored.
if ((request.getHeader("If-None-Match") == null)
&& (lastModified < headerValue + 1000)) {
// The entity has not been modified since the date
// specified by the client. This is not an error case.
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
response.setHeader("ETag", resourceAttributes.getETag());

return false;
}
}
} catch (IllegalArgumentException illegalArgument) {
return true;
}
return true;

}
源碼中可以看到:
if ((request.getHeader("If-None-Match") == null)
&& (lastModified < headerValue + 1000)) {
這句話表明只有在客戶端瀏覽器發送的請求頭中不包含If-None-Match，IfModifiedSince才會生效。
我們接著看checkIfNoneMatch，源碼如下：
/**
* Check if the if-none-match condition is satisfied.
*
* @param request The servlet request we are processing
* @param response The servlet response we are creating
* @param resourceInfo File object
* @return boolean true if the resource meets the specified condition,
* and false if the condition is not satisfied, in which case request
* processing is stopped
*/
protected boolean checkIfNoneMatch(HttpServletRequest request,
HttpServletResponse response,
ResourceAttributes resourceAttributes)
throws IOException {

String eTag = resourceAttributes.getETag();
String headerValue = request.getHeader("If-None-Match");
if (headerValue != null) {

boolean conditionSatisfied = false;

if (!headerValue.equals("*")) {

StringTokenizer commaTokenizer =
new StringTokenizer(headerValue, ",");

while (!conditionSatisfied && commaTokenizer.hasMoreTokens()) {
String currentToken = commaTokenizer.nextToken();
if (currentToken.trim().equals(eTag))
conditionSatisfied = true;
}

} else {
conditionSatisfied = true;
}

if (conditionSatisfied) {

// For GET and HEAD, we should respond with
// 304 Not Modified.
// For every other method, 412 Precondition Failed is sent
// back.
if ( ("GET".equals(request.getMethod()))
|| ("HEAD".equals(request.getMethod())) ) {
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
response.setHeader("ETag", eTag);

return false;
}
response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);
return false;
}
}
return true;

}
這里：
String eTag = resourceAttributes.getETag();
String headerValue = request.getHeader("If-None-Match");
這兩句比較簡單，就是分別從伺服器緩存和http請求頭中中取出etag。
接著判斷這兩個etag如果相等，則conditionSatisfied為true，會執行到以下語句：
if (conditionSatisfied) {

// For GET and HEAD, we should respond with
// 304 Not Modified.
// For every other method, 412 Precondition Failed is sent
// back.
if ( ("GET".equals(request.getMethod()))
|| ("HEAD".equals(request.getMethod())) ) {
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
response.setHeader("ETag", eTag);

return false;
}
response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);
return false;
}
這段語句中可以發現，如果資源未改變的情況下，並且請求方式為GET或者HEAD時，會返回304狀態碼。否則返回一個412狀態碼，同樣不會返回資源內容。
如果上述最終
if ((request.getHeader("If-None-Match") == null)
&& (lastModified < headerValue + 1000))
條件不成立，即資源更新了或者是第一次請求，這里會讀取當前請求資源文件，並最終放入http響應中。