- 当文件更改时,etag 值必须改变。
- 尽量便于计算,不会特别耗 CPU。这样子利用摘要算法生成 (MD5, SHA128, SHA256) 需要慎重考虑,因为他们是 CPU 密集型运算
- 必须横向扩展,分布式部署时多个服务器节点上生成的 etag 值保持一致。这样子 inode 就排除了
以上几个条件是理论上的成立条件,那在真正实践中,应该如何处理?
我们来看一下 nginx 中是如何做的
nginx 中 ETag 的生成
我翻阅了 nginx 的源代码,并翻译成伪代码如下:由 last_modified 与 content_length 拼接而成
可见源码位置,并在以下贴出: ngx_http_core_modules.c
总结:nginx 中 etag 由响应头的 Last-Modified 与 Content-Length 表示为十六进制组合而成。
随手在我的k8s集群里找个 nginx 服务测试一下
由 etag 计算 Last-Modified 与 Content-Length,使用 js 计算如下,结果相符
Nginx 中的 ETag 算法及其不足
协商缓存用来计算资源是否返回 304,我们知道协商缓存有两种方式
- Last-Modified/if-Modified-Since
- ETag/If-None-Match
既然在 nginx 中 ETag 由 Last-Modified 和 Content-Length 组成,那它便算是一个加强版的 Last-Modified 了,那加强在什么地方呢?
Last-Modified 是由一个 unix timestamp 表示,则意味着它只能作用于秒级的改变,而 nginx 中的 ETag 添加了文件大小的附加条件
那下一个问题:如果 http 响应头中 ETag 值改变了,是否意味着文件内容一定已经更改
答案:不能。
因此使用 nginx 计算 304 有一定局限性:在 1s 内修改了文件并且保持文件大小不变。但这种情况出现的概率极低就是了,因此在正常情况下可以容忍一个不太完美但是高效的算法。
文章出自:前端餐厅,如有转载本文请联系前端餐厅ReTech今日头条号。
github:https://github.com/zuopf769