写作不易，未经作者容许禁止以任何模式转载！
如果感觉文章不错，欢送关注、点赞和分享！
原文链接：浅析 HTTP 缓存

为什么须要缓存

• 通过缓存机制，能够在相应场景下复用以前获取的资源。
• 显著进步网站的性能和响应速度
• 缩小网络流量和期待渲染工夫
• 升高服务器压力

HTTP 缓存类型

• 强缓存
• 协商缓存

强缓存

对于强缓存，服务器返回的动态资源响应头会设置一个强制缓存的工夫，在缓存工夫内，如刷新浏览器申请雷同资源，在缓存工夫未过期的状况下，则间接应用已缓存资源。如缓存资源已过期，执行协商缓存策略。

• 以下为与强缓存相干的 HTTP 头部字段

Expires

• 响应头 Expires 字段蕴含强缓存资源的过期工夫
• 值为 0 示意资源已过期或非强缓存

Cache-Control

通用音讯头字段，通过指令来实现缓存机制。阐明一下容易弄混的两个字段，其余指令参考指令大全。

• no-cache

在公布缓存正本之前，强制要求缓存把申请提交给原始服务器进行验证 (协商缓存验证)。

• no-store

缓存不应存储无关客户端申请或服务器响应的任何内容，即不应用任何缓存。

Expires 和 Cache-Control 的区别

• 工夫区别

  • Expires 过期工夫为相对工夫，指将来某个工夫点缓存过期。
  • Cache-Control 为绝对工夫，绝对于以后工夫，如 60s 后缓存过期

• 优先级

  • Expires 的优先级低于 Cache-Control 字段
  • 同时存在 Cache-Control 和 Expires 时，以 Cache-Control 指令为准

• HTTP 版本

  • Expires 是 HTTP/1.0 提出的，其浏览器兼容性更好
  • Cache-Control 是 HTTP/1.1 提出的，浏览器兼容性不佳，所以 Expires 和 Cache-Control 能够同时存在，在不反对 Cache-Control 的浏览器则以 Expires 为准

协商缓存

• 协商缓存即和服务器协商是否应用缓存，通过判断后决定从新加载资源 or HTTP StatusCode 304
• 以下字段决定是否应用协商缓存，而非强缓存：

Pragma

• Pragma 是一个 HTTP1.0 中规定的通用首部，如果 Cache-Control 不存在的话，它的行为与 Cache-Control: no-cache 统一。强制要求缓存服务器在返回缓存的版本之前将申请提交到源头服务器进行协商验证。
• Pragma 的值就只有一个，no-cache，并且它的优先级比 Cache-Control 高。

Cache-Control

• 上文介绍过 Cache-Control，它的指令既能够用于强缓存又可利用于协商缓存策略中
• 其中 Cache-Control: no-cache 和 Cache-Control: max-age=0 的作用一样，强制要求发动申请给服务器进行验证 (协商资源验证)。

协商策略

当呈现 Pragma 字段或者 Cache-Control:no-cache 时，就须要应用协商策略，常见的两对协商缓存字段如下

• ETag/If-None-Match
• Last-Modified/If-Modfied-Since

优缺点

• 如果服务端批改了一段代码，而后又改回去了。

  • 此时资源文件的批改工夫变了
  • 实际上文件没有产生扭转
  • 这样缓存就生效了，产生了不必要的传输
• 而 ETag 能够依据内容生成的 hash 来比拟的，只有资源文件内容不变，就会利用客户端的缓存，缩小不必要的传输。
• 所以 ETag 比 Last-Modified 缓存更准确、高效和节俭带宽。

ETag

什么是 ETag？

Etag 是 Entity tag 的缩写，能够了解为“被申请资源的摘要标识”，Etag 是服务端的一个资源的标识，在 HTTP 响应头中将其传送到客户端，相似这样，ETag:W/”50b1c1d4f775c61:df3″

ETag 格局

• ETag:W/”xxxxxxxx”
• ETag:”xxxxxxx”

强类型验证

• 比对资源每个字节都要一样。

W/ 前缀代表应用弱类型验证

• 不须要每个字节都一样，例如页脚的工夫 or 展现的广告不一样，都能够认为是一样的。构建利用于弱验证类型的标签（etag）体系可能会比较复杂，因为这会波及到对页面上不同的元素的重要性进行排序，然而会对缓存性能优化相当有帮忙。

ETag 生成须要满足什么条件？

1. 当文件更改时，ETag 值必须扭转

2. 尽量便于计算，不会特地耗 CPU。

   1. 利用摘要算法生成（MD5, SHA128, SHA256）需慎重考虑，这些为 CPU 密集型运算。
   2. 不是不能用，没有最好的算法，只有适宜响应场景的算法。
3. 必须横向扩大，分布式部署时多个服务器节点上生成的 ETag 值保持一致。

ETag 是怎么生成的（Nginx）

Nginx 的源码中 ETag 由 last_modified 和 content_length 拼接而成

etag->value.len = ngx_sprintf(etag->value.data, "\"%xT-%xO\"",
                                  r->headers_out.last_modified_time,
                                  r->headers_out.content_length_n)
                      - etag->value.data;                                

• 翻译为以下伪代码

etag = header.last_modified + "-" + header.content_lenth

• 总结：Nginx 中 ETag 由响应头的 Last-Modified 和 Content-Length 示意为十六进制组合而成。

Lodash 网站申请测验

const LAST_MODIFIED = new Date(parseInt('5fc4907d', 16) * 1000).toJSON()
const CONTENT_LENGTH = parseInt('f48', 16)

console.log(LAST_MODIFIED) // 2020-11-30T06:26:05.000Z
console.log(CONTENT_LENGTH) // 3912

• 输入后果

• 既然在 nginx 中 ETag 由 Last-Modified 和 Content-Length 组成，那它便算是一个加强版的 Last-Modified 了，那增强在什么中央呢？
• Last-Modified 只能作用于秒级的扭转，而 nginx 中的 ETag 增加了文件大小的附加条件，不仅和批改工夫无关，也和内容无关，使之更加准确。

Last-Modified 是怎么生成的

在 linux 中

• mtime：modified time 指文件内容扭转的工夫戳
• ctime：change time 指文件属性扭转的工夫戳，属性包含 mtime。而在 windows 上，它示意的是 creation time
• 而 HTTP 服务抉择 Last-Modified 时个别会抉择 mtime，示意文件内容批改的工夫，来兼容 Windows 和 Linux。
• 以下为 nginx 源码

    r->headers_out.status = NGX_HTTP_OK;     
    r->headers_out.content_length_n = of.size;     
    r->headers_out.last_modified_time = of.mtime;

如果 http 响应头中 ETag 值扭转了，是否意味着文件内容肯定曾经更改？

• 不肯定
• 文件在一秒内产生了扭转而且文件大小不变
• 这种状况十分极其，概率很低
• 因而在失常状况下能够容忍一个不太完满然而高效的算法。

原文链接：浅析 HTTP 缓存

掘金：前端 LeBron

知乎：前端 LeBron

继续分享技术博文，关注微信公众号👇🏻