使ETags正确

etag类似于上次修改的头。这是一种由客户决定变更的机制。

可以说,恰好是最后修改日期(即相同文本)的etag满足etag所需的所有标准。它只需要是表示资源状态的唯一值。在整个资源领域中不是唯一的,只是在资源中。

现在,从技术上讲,与上次修改的头段相比,ETAG具有“无限”的分辨率。最后一次修改的粒度只有1秒,而etag可以是次秒。

您可以同时实现etag和last modified,或者只实现其中一个(当然,也可以不实现)。如果最后一次修改是不够的,那么考虑ETag。

记住,我不会为“每个”资源设置etag。基本上,我不会为任何不希望缓存的内容设置它(特别是动态内容)。在这种情况下没有意义,只是浪费了工作。

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

MD5很好。唯一的缺点是一直在计算MD5。在20万PDF文件上运行MD5很昂贵。在不希望缓存的资源上运行MD5简直是浪费(即动态内容)。

诀窍很简单,无论您使用什么机制,它都应该和上次修改的通常一样便宜。最后一次修改通常是资源的一个属性,访问成本通常很低。

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

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

我们的策略是在输出结束时生成要发送内容的MD5哈希,如果不存在匹配的头,则将该头与生成的哈希进行比较。如果两个值相同,我们将发送304代码并在不返回任何内容的情况下对请求进行内部搜索。

我们确实需要消耗一点CPU来散列内容,但最后我们节省了很多带宽。

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

由于没有读过这本书,我不能就作者的确切问题发表看法。

但是,etag的生成应该这样,当页面发生更改时,etag只生成一次。生成一个网页的MD5哈希需要在服务器上花费处理能力和时间;如果您有许多客户机连接,它可能会导致性能问题。

因此,您需要一种生成etags的良好技术 只有 必要时在服务器上缓存它们,直到相关页面发生更改。

我认为 perceived problem 对于etags,您的浏览器可能必须为页面上的每个资源发出并解析(简单和小)请求/响应,以检查etag值是否已更改服务器端。

我个人认为这些额外的小型往返服务器可以接受经常更改的图像、CSS、javascript(如果浏览器的etag是最新的,服务器不需要重新发送内容),因为这种机制使标记“更新”内容变得非常容易。