本文以Nginx，Rails，Mysql，Redis作為例子，換成其他web服務器，語言，數據庫，緩存服務都是類似的。
以下是3層的示意圖，方便后續引用：

1. 客戶端緩存

一個客戶端經常會訪問同一個資源，比如用瀏覽器訪問網站首頁或查看同一篇文章，或用app訪問同一個api，如果該資源和他之前訪問過的沒有任何改變，就可以利用http規范中的304 Not Modified 響應頭(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5)，直接用客戶端的緩存，而無需在服務器端再生成一次內容。
在Rails里面內置了fresh_when這個方法，一行代碼就可以完成：

class ArticlesController def show  @article = Article.find(params[:id])  fresh_when :last_modified => @article.updated_at.utc, :etag => @article endend

下次用戶再訪問的時候，會對比request header里面的If-Modified-Since和If-None-Match，如果相符合，就直接返回304，而不再生成response body。

但是這樣會遇到一個問題，假設我們的網站導航有用戶信息，一個用戶在未登陸專題訪問了一下，然后登陸以后再訪問，會發現頁面上顯示的還是未登陸狀態。或者在app訪問一篇文章，做了一下收藏，下次再進入這篇文章，還是顯示未收藏狀態。解決這個問題的方法很簡單，將用戶相關的變量也加入到etag的計算里面：

  fresh_when :etag => [@article.cache_key, current_user.id]  fresh_when :etag => [@article.cache_key, current_user_favorited]

另外提一個坑，如果nginx開啟了gzip，對rails執行的結果進行壓縮，會將rails輸出的etag header干掉，nginx的開發人員說根據rfc規范，對proxy_pass方式處理必須這樣（因為內容改變了），但是我個人認為沒這個必要，于是用了粗暴的方法，直接將src/http/modules/ngx_http_gzip_filter_module.c這個文件里面的這行代碼注釋掉，然后重新編譯nginx：

  //ngx_http_clear_etag(r); 

或者你可以選擇不改變nginx源代碼，將gzip off掉，將壓縮用Rack中間件來處理：

  config.middleware.use Rack::Deflater

除了在controller里面指定fresh_when以外，rails框架默認使用Rack::ETag middleware，它會自動給無etag的response加上etag，但是和fresh_when相比，自動etag能夠節省的只是客戶端時間，服務器端還是一樣會執行所有的代碼，用curl來對比一下。
Rack::ETag自動加入etag：

curl -v http://localhost:3000/articles/1< Etag: "bf328447bcb2b8706193a50962035619"< X-Runtime: 0.286958curl -v http://localhost:3000/articles/1 --header 'If-None-Match: "bf328447bcb2b8706193a50962035619"'< X-Runtime: 0.293798用fresh_when： curl -v http://localhost:3000/articles/1 --header 'If-None-Match: "bf328447bcb2b8706193a50962035619"'< X-Runtime: 0.033884