配置ETags

前言

網站設計的優化是一個很大的話題,有一些通用的原則,也有針對不一樣開發平臺的一些建議。這方面的研究一直沒有中止過，我在不一樣的場合也分享過這樣的話題。

做爲通用的原則，雅虎的工程師團隊曾經給出過35個最佳實踐。這個列表請參考  Best Practices for Speeding Up Your Web Site http://developer.yahoo.com/performance/rules.html，同時，他們還發布了一個相應的測試工具Yslow http://developer.yahoo.com/yslow/

我強烈推薦全部的網站開發人員都應該學習這些最佳實踐，並結合本身的實際項目狀況進行應用。 接下來的一段時間，我將結合ASP.NET這個開發平臺，針對這些原則，經過一個系列文章的形式，作些講解和演繹，以幫助你們更好地理解這些原則，而且更好地使用他們。

準備工做

爲了跟隨我進行後續的學習，你須要準備以下的開發環境和工具

1. Google Chrome 或者firefox ，而且安裝 Yslow這個擴展組件.請注意，這個組件是雅虎提供的，但目前沒有針對IE的版本。
   1. https://chrome.google.com/webstore/detail/yslow/ninejjcohidippngpapiilnmkgllmakh
   2. https://addons.mozilla.org/en-US/firefox/addon/yslow/
   3. 你應該對這些瀏覽器的開發人員工具備所瞭解，你能夠經過按下F12鍵調出這個工具。
2. Visaul Studio 2010 SP1 或更高版本，推薦使用Visual Studio 2012
   1. http://www.microsoft.com/visualstudio/eng/downloads
3. 你須要對ASP.NET的開發基本流程和核心技術有至關的瞭解，本系列文章很難對基礎知識作普及。

本文要討論的話題

這一篇我和你們討論的是第十三條原則：Configure ETags （配置ETags）。

ETag，全稱爲：Entity Tag，意思是實體標籤，從名字上看，是對於某種實體的一個標識。它屬於HTTP協議的一部分，也就是全部的Web服務器都應該（也確實能）支持這個特性。它的做用是用一個特殊的字符串來標識某個資源的「版本」，客戶端（瀏覽器）來請求的時候，能夠比較，若是ETag一致，則表示該資源並無修改過，客戶端（瀏覽器）可使用本身緩存的版本。

工做原理

咱們經過實例來了解ETag的工做原理，當用戶第一次請求某個資源（一般爲靜態資源）的時候

正常狀況下，他將獲得一個狀態碼爲200的響應，而且在響應頭部中會包含一個ETag的信息（ETag    "6ab823201a4ece1:0"）

【備註】這個值是我本機的IIS 8.0提供，不一樣的服務器可能會有所不一樣。我後面會解釋大體的含義。

 

接下來，若是用戶再次請求這個資源的話，瀏覽器會嘗試在請求頭部中包含這個信息，以便服務器能夠比較，肯定是要再次發送資源的內容。

咱們注意這一行 If-None-Match    "6ab823201a4ece1:0"

而後，服務器會怎麼樣響應這個請求呢？

服務器其實是比較了ETag的值，它發現瀏覽器提供的值與該資源實際的值是同樣的，因此它就返回了304的狀態碼，並且不須要在響應的正文裏面包含任何實際內容。瀏覽器獲得304這個狀態碼以後，就知道該資源並無被修改，因此直接使用本地緩存的版本。

 

ETag的配置

在IIS產品家族中，新的版本（例如IIS 7之後的版本）會自動配置一個ETag，這個ETag的值很相似於下面這樣：

6ab823201a4ece1:0

它是由兩個部分組成的

1. 第一部分稱爲FileTimeStamp（時間戳），咱們很容易聯想到這多是跟文檔修改時間有關係，事實上確實是，但你沒法將其直接還原爲文檔修改時間（微軟並無公開這部分的算法）。我確實對此作過一些研究，但最終仍是沒有辦法解釋這個值如何生成的，因此你們也只須要知道，這個是相似於一個時間戳的值就能夠了。
2. 第二部分爲ChangeNumber（修改編號）。這個值在IIS 7.0以及後續的版本中，被統一設置爲0。設置爲一個統一值有利於解決一些問題（例如在服務器場模式下，該問題我後續也會討論到）。事實上，保留這個ChangeNumber我以爲主要是歷史遺留問題，由於早期版本是有這個值，並且能夠不同。既然若是這個值不同的話，會給咱們惹一些麻煩，那麼其實最好的作法是乾脆就不要這個字段了。但我想，爲了保持格式上的一向性，微軟最終保留了這個字段。

 

這個默認的ETag不須要任何的配置就會存在（反過來，你若是要刪除它卻是很不容易，這個問題後續也會提到），但咱們能夠繼續添加本身想要的特殊ETag。也就是說，對於一個資源，其實是能夠有多個ETag的。咱們看看在IIS 中的設置。

你能夠在這裏設置任意的值。

咱們能夠預見到，若是這樣設置的話，那麼在響應的頭部中應該就會有多個ETag了。以下圖所示

 

ETag與其餘技術的比較

通過上面的介紹，你們應該知道ETag的功能，主要能提供對資源的版本標識，以免無謂的重複下載。這從必定意義上，確定是有利的，它能夠提升性能。

若是這樣的話，那麼它和「優化網站設計（三）：對資源添加緩存控制」 中提到過的一些技術比較起來，有什麼本身的特色呢？

響應標頭	優點 和特色	劣勢 和可能的問題
Expires	HTTP 1.0就有，簡單易用。 服務器經過這個Header告訴瀏覽器，某資源直到某個時間纔會過時，因此在沒有過時以前，瀏覽器就直接使用本地的緩存了。	由於這是時間是由服務器發送的（UTC），但若是服務器時間和客戶端事件存在不一致，可能會有些問題。 可能存在版本的問題，由於若是在到期以前修改過了，客戶端是不會知道的。 Cache-Control中的max-age能夠實現相似的效果，但更加好，由於max-age是一個以秒爲單位的時間數，而不是具體的時間，因此不存在上面提到的第一個問題。
Cache-Control	服務器經過一個Header（Last-Modified）告訴瀏覽器，某資源最後修改的時間 瀏覽器在請求的時候，包含一個Header（If-Modified-Since）,而後服務器能夠進行比較，若是在該時間後沒有修改過，則返回304 它比Expires多不少選項設置	Last-Modified 也是一個時間，但該時間只能精確到秒，若是在同一個秒中有屢次修改（這個在如今的環境下應該確實是可能的），則可能會發生問題。
ETag	能夠更加精確地判斷資源是否被修改，由於它不是一個時間值，而是對時間通過處理的一個長整型數值（固然具體算法咱們目前還不得而知） 瀏覽器發起新請求時須要包含 If-None-Match	若是部署在服務器場環境中，配置不當的話，可能每一個服務器會對相同的資源生成不同的ETag，這樣就增長了重複下載的可能性。要理解這個問題的緣由，以及如何解決，請參考這裏的文檔：http://support.microsoft.com/kb/922703/en-us 該問題在IIS 7以及之後的版本中應該不存在了

這幾個技術其實不少時候是會結合起來用的，並且優先級也有所不一樣。一般，ETag是優先於Cache-Control的，而Cache-Control又是優先於Expires的

 

 

什麼時候以及如何刪除ETag的功能？

因爲以前談到可能的一些問題，雅虎團隊在當年寫這個原則的時候，是建議在服務器場的環境下面禁用ETag的，在Apache中，能夠經過修改配置文件來實現。而在IIS 中，若是你所使用的是7.0以及後續的版本，實際上應該能夠不由用，由於如今不會存在他們所提到的那個問題了。但若是你真的想要了解一下如何禁用，那麼請參考下面的操做

1. 安裝這個擴展：http://www.iis.net/downloads/microsoft/url-rewrite 
2. 建立一個地址重寫規則

這樣配置了以後，就不會再有ETag，整個世界清靜了。