让ETags正确

我一直在读一本书,我对ETag章节有一个特别的问题.作者说ETag可能会损害性能,你必须对它们进行精细调整或完全禁用它们.

我已经知道ETag是什么并且了解风险,但是难以让ETag正确吗？

我刚刚创建了一个发送ETag的应用程序,其值为响应主体的MD5哈希值.这是一个简单的解决方案,易于用多种语言实现.

使用响应体的MD5哈希作为ETag是错误的吗？如果是这样,为什么？

为什么作者(显然超出我的许多数量级)不提出这样一个简单的解决方案？

除非你是作者:),否则最后一个问题很难回答,所以我试图找到使用MD5哈希作为ETag的弱点.

1> Will Hartung..：

---

ETag类似于Last-Modified标头.这是一种由客户确定变更的机制.

可以说,一个只能发生最后修改日期(即同一文本)的ETag符合ETag所需的所有标准.它只需要是表示资源状态的唯一值.在整个资源域中并不是唯一的,只需在资源内.

现在,从技术上讲,与Last-Modified标头相比,ETag具有"无限"分辨率.Last-Modified仅以1秒的粒度更改,而ETag可以是次秒.

您既可以实现ETag和Last-Modified,也可以只实现其中一种(当然也可以不使用).如果您的Last-Modified不够,那么请考虑一个ETag.

记住,我不会为每个"资源"设置ETag.基本上,我不会将它设置为任何不期望被缓存的东西(特别是动态内容).在这种情况下没有意义,只是浪费了工作.

编辑:我看到你的编辑,并澄清.

MD5很好.唯一的缺点是一直在计算MD5.例如,在200K PDF文件上运行MD5是很昂贵的.在不期望缓存的资源上运行MD5简直就是浪费(即动态内容).

诀窍很简单,无论你使用什么机制,它都应该像Last-Modified一样便宜.Last-Modified通常也是资源的属性,通常非常便宜.

ETag应该同样便宜.如果您使用的是MD5,并且可以缓存/存储资源和MD5哈希之间的关联,那么这是一个很好的解决方案.但是,每次需要ETag时重新计算MD5,基本上与使用ETag提高整体服务器性能的想法相反.

---

"一个只能发生最后修改日期的ETag(即同一文本)符合ETag所需的所有标准".这不是真的,因为Gzipped和unGzipped响应都具有相同的修改日期; 但他们应该有不同的Etags:https://issues.apache.org/bugzilla/show_bug.cgi？id = 39727

---

"运行MD5,例如,一个200K的PDF文件,价格昂贵" - 通常不会,在现代处理器上,MD5比Gbit以太网快很多倍,更不用说最终用户的互联网连接了.如果您的ETag有可能避免甚至1%的传输,它可能会弥补使用的CPU时间.

2> Çağatay Gürt..：

---

我们在instela中使用etags作为动态内容.

我们的策略是在输出结束时生成要发送的内容的md5哈希,如果if-none-match标头存在,我们将标头与生成的哈希进行比较.如果两个值相同,我们发送304代码并且在不返回任何内容的情况下交错请求.

确实,我们消耗了一些cpu来散列内容,但最后我们节省了很多带宽.

我们有一个facebook新闻源样式主页面,每个用户都有不同的内容.由于新闻源内容每小时仅更改3-4次,因此主页刷新对于客户端来说非常有效.在移动时代,我认为花费更多的CPU时间比花费带宽更好.带宽仍然比CPU更昂贵,这对客户来说是更好的体验.