在使用 google page analysis 和 yslow 進行網頁效能分析的時候，都會遇到
configure entity tags (etags)
這一項。
要理解etage，首先要弄清楚 http 響應頭的last-modified.
在瀏覽器第一次請求某乙個url時，伺服器端的返回狀態會是200，內容是你請求的資源，同時有乙個last-modified的屬性標記此檔案在服務期端最後被修改的時間，格式類似這樣：
last-modified: fri, 12 may 2006 18:53:33 gmt
客戶端第二次請求此url時，根據 http 協議的規定，瀏覽器會向伺服器傳送 if-modified-since 報頭，詢問該時間之後檔案是否有被修改過：
if-modified-since: fri, 12 may 2006 18:53:33 gmt
如果伺服器端的資源沒有變化，則自動返回 http 304 （not changed.）狀態碼，內容為空，這樣就節省了傳輸資料量。當伺服器端**發生改變或者重啟伺服器時，則重新發出資源，返回和第一次請求時類似。從而保證不向客戶端重**出資源，也保證當伺服器有變化時，客戶端能夠得到最新的資源。
那麼，理論上根據last-modified 就可以判斷該檔案是否被修改過，是否使用本地快取，將伺服器端的返回狀態為304。但是遇到如下情況，last-modified就無法解決了：
1、一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get;
2、某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了n次)，if-modified-since能檢查到的粒度是s級的，這種修改無法判斷(或者說unix記錄mtime只能精確到秒)
3、某些伺服器不能精確的得到檔案的最後修改時間；
為此，http/1.1引入了etag(entity tags).etag僅僅是乙個和檔案相關的標記，可以是乙個版本標記,比如說v1.0.0或者說"2e681a-6-5d044840"這麼一串看起來很神秘的編碼。但是http/1.1 標準並沒有規定etag的內容是什麼或者說要怎麼實現，唯一規定的是etag需要放在""內。
可以將etag看做是乙個可以與web資源關聯的記號（token）。典型的web資源可以乙個web頁，但也可能是json或xml文件。伺服器單獨負責判斷記號是什麼及其含義，並在http響應頭中將其傳送到客戶端，以下是伺服器端返回的格式：
etag: "50b1c1d4f775c61:df3"
客戶端的查詢更新格式是這樣的：
if-none-match: w/"50b1c1d4f775c61:df3"
如果etag沒改變，則返回狀態304然後不返回
下面我們來看個例子：
請求位址為
第一次請求：
response header 中會附加上伺服器新增的last-modified 以及etag（如果伺服器進行配置的話）
第二次請求：
在請求 request header 中，會新增 if-modified-since 用於比對第一次請求之後的響應頭中的 last-modified。
以及 if-none-match ,用於比對 第一次請求之後的響應頭中伺服器生成的etag.
如果兩個值均相同，則返回304，不再向客戶端傳送資源。
最後，關鍵是我們如何使用last-modified 和etag 進行web優化，提高**效能。
我們可以把last-modified 和etags請求的http報頭一起使用，這樣可利用客戶端（例如瀏覽器）的快取。因為伺服器首先產生 last-modified/etag標記，伺服器可在稍後使用它來判斷頁面是否已經被修改。本質上，客戶端通過將該記號傳回伺服器要求伺服器驗證其（客戶端）快取。
過程如下:
1. 客戶端請求乙個頁面（a）。
2. 伺服器返回頁面a，並在給a加上乙個last-modified/etag。
3. 客戶端展現該頁面，並將頁面連同last-modified/etag一起快取。
4. 客戶再次請求頁面a，並將上次請求時伺服器返回的last-modified/etag一起傳遞給伺服器。
5. 伺服器檢查該last-modified或etag，並判斷出該頁面自上次客戶端請求之後還未被修改，直接返回響應304和乙個空的響應體。
HTTP協議ETag窺探
我們都知道，http 1.1中有乙個etag，用來判斷請求的檔案是否被修改。為什麼要使用etag呢？etag主要為了解決last modified無法解決的一些問題 1 一些檔案也許會週期性的更改，但是他的內容並不改變 僅僅改變的修改時間 這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get...
http 304響應的理解
我們經常會看到請求位址中狀態存在304 200 如果客戶端 瀏覽器 傳送的是乙個 條件驗證請求 則web伺服器可能會返回304響應,這就表明了客戶端中所請求資源的快取仍然是有效的,也就是說該資源從上次快取到現在沒有被修改過，瀏覽器會自動識別並讀取快取中的檔案來顯示 在進行條件請求時，一般請求頭會帶上...
理解HTTP 304響應
剛剛開始使用fiddler的使用者經常會對fiddler的網路會話 web sessions 列表中的http 304響應感到困惑 如果客戶端傳送的是乙個條件驗證 conditional validation 請求,則web伺服器可能會返回http 304響應,這就表明了客戶端中所請求資源的快取仍然...