WPO基础：细说ETags以及如何在 IIS6和 IIS7下取消ETags

 

根据Steve Souders的14条军规，其中“合理配置Etags”常常让人疑惑，不少人询问在iis6或iis7找不到这一选项。

 

什么是ETags

看看下图是IIS6下，服务器发送反馈的头信息，红色线框中就是etag：

 

 

“325084dfa930cc1:33b”  就是Etag

Etag的全称是 entity tag。我们在之前的文章中，介绍了浏览器缓存，条件GET请求以及expires header的原理 ，我们为了达到性能优化的效果，会使用expires headers告诉浏览器，不用再发送条件GET请求给服务器啦，直接用缓存里面的数据就可以啦，从而加快访问速度。而Etag则是一个拖后腿的玩意儿，etag常常会误导浏览器，让浏览器忽略缓存重复下载相同的文件。

etag的目的是给组件增加一个标签，对于iis6来说，这个标签由两部分组成：

325084dfa930cc1  前半段的长串数字叫 Filetimestamp“文件时间戳”，这个时间戳生成原理得问比尔，但可以猜想是取决于文件（组件）属性以及文件（组件）的修改日期，换一个组件或者修改了组件（比如图片或php文件），这个时间戳就会发生改变。

33b  后半段取决于IIS，叫ChangeNumber，更换一台服务器，这部分代码会变化。

稍大一些的网站，可能会采用负载均衡，不止一台web服务器。也就是说网站的logo.jpg文件，可能存放在几台服务器中。用户每次请求logo.jpg，可能从不同的服务器中获取。假设我们先从A服务器获取了logo.jpg，然后再次刷新页面，第二次从B服务器获取logo.jpg：

logo.jpg 在A服务器Etag：“325084dfa930cc1:33b”

logo.jpg 在B服务器Etag：“325084dfa930cc1:6f8″

我们可以看到，尽管前半段Filetimestamp是相同的，但由于服务器不同导致后半段ChangeNumber产生了区别。用户的浏览器会认为来自B服务器的logo.jpg已经发生了改变，于是忽略了缓存内已有的logo.jpg，再次从B服务器上进行下载。这无疑是消耗了资源。

 

可能有人说，如果我设置了expires header，用户浏览器根本不会发送条件GET请求给服务器，不就避免了这种情况么？是，没错，可是我们的用户可能会点击reload或者在地址栏点击回车，这两个动作都会引发条件GET请求，上面的一幕就重现了。

 

所以我们应该取消ETags。在Apache下的取消Etag方法，在《high performance websites》书中已经详细介绍。

在IIS6下的取消方法，请参见如下两个地址：

http://support.microsoft.com/?id=922733

http://support.microsoft.com/kb/900245/zh-cn

 

 

那么在IIS7下如何取消呢？呵呵，好消息，IIS可能已经考虑到这个问题，所以对Etags做了如下变动：

请大家留意，Etag形式变成了

7e4e9d68ffcb1:0

在IIS7，微软可能意识到了上述问题，后半部分ChanceNumber都变成了0，也就是etags不再因为服务器和IIS的变化而改变。那么上述Etag的性能问题消失了，我们已经没有必要删除ETags了。

可能有洁癖的WPOer会说，在header中多了这段代码，总是觉得不爽，能不能彻底删掉？实际上这部分代码所造成的网页字节数的微乎其微的增加，并不会给性能带来任何变化，还是豁达一些，放下吧。

 

参考资料：http://blogs.iis.net/chrisad/archive/2006/12/18/iis7-deployments-calls-for-etag-usage-review-if-using.aspx

 

 

作者: 谭砚耘@用户体验与可用性设计-科研笔记

版权属于: 谭砚耘 （TOTHETOP至尚国际  ）

版权所有。转载时必须以链接形式注明作者和原始出处

如果你希望与作者交流，请发送邮件到 tanyanyun/at/163.com 别忘了修改小老鼠