http缓存

HTTP缓存

背景

需求开发中不断的往项目中添加图片、字体等这些静态资源使得项目打包体积越来越大。

打包后这些静态资源占据了包体积的大部分。

基于此，我们准备将静态资源从项目中移出来放到 oss 云服务上，这样项目的体积会缩小很多，打包速度也会快很多

但是，想法是好的，但是具体的操作上存在一些问题需要解决：

• 静态资源的缓存问题
• 目录结构问题
• 资源更新问题

这篇文章我会重点分享静态资源缓存问题的解决方案。

HTTP 缓存

说到静态资源的缓存问题其实就是HTTP缓存的问题，我们既要保证客户端能快速的加载静态资源还需要保证当静态资源变化时，客户端能及时更新。

缓存过程

由上图我们可以发现：

• 浏览器在请求资源时，都会去查看当前浏览器缓存中是否存在缓存结果和缓存标识
• 当请求结果返回浏览器时，浏览器都会将当前结果和缓存标识存入浏览器缓存中

以上两点是浏览器缓存机制的关键，它确保了每个请求的缓存存入与读取。

根据是否需要向服务器重新发起 HTTP 请求将缓存过程分为两个部分，分别是强缓存和协商缓存。

强缓存

强缓存，顾名思义就是强制缓存，是不需要向原服务器发起请求直接使用浏览器缓存**(针对的是客户端)**

强缓存的实现方案主要是有两种：Expires 和 cache-control

• Expires：即过期时间，存在于服务器端返回的响应头中，告诉浏览器在过期时间内直接使用缓存，无需再次发送请求。潜在问题：Expires 是 HTTP1.0 的产物，受限于本地时间，如果人为修改了本地时间，可能会造成缓存失效。

• cache-control：采用过期时长来控制缓存，常用有以下几个设置：

• • max-age：表示缓存可以使用多长时间，是一个相对时间
  • public：表示响应可以被任何区缓存
  • private：只针对个人用户，不可被代理服务器缓存
  • no-cache：可以在本地缓存，可以在代理服务器缓存，但是这个缓存要服务器验证才可以使用，强制客户端总是向服务器发送请求，由服务器判断缓存是否可用，即总是启用协商缓存
  • no-store：彻底禁用缓存，每次都需要从服务器获取资源，流量消耗增加

Expires 和 cache-control 都可以实现强缓存

---

资源在 2023 年 2 月 28 号 22:22:22 过期

Expires: Tue, 28 Feb 2023 22:22:22 GMT

资源在1小时内可使用缓存

Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
Cache-Control: max-age=3600

但是Expires 是http1.0的产物，cache-control是http1.1的产物，现阶段，我们会认为cache-control使用更广泛，Expires只是一种降级方案。

当Expires 和 cache-control同时存在时，浏览器会优先使用cache-control。

协商缓存

​ 强缓存失效后，浏览器在请求头中携带相应的缓存tag来向服务器发送请求，由服务器根据这个tag来决定是否使用缓存**(针对的是客户端与服务器端)**

缓存tag分为：Last-Modified和Etag。

• Last-Modified：即服务器返回的文件最后修改时间，在浏览器第一次给服务器发送请求之后，服务器会在响应头中加上这个字段。浏览器接收到以后如果再次请求，会在请求头中携带If-Modified-Since（再次请求资源是，带上上一次服务器返回的Last-Modified值）字段，这个字段的值也就是浏览器传来的最后修改时间。服务器拿到请求头中的If-Modified-Since的字段之后，会和服务器中的该资源的最后修改时间进行对比：

  • 若请求头中的这个值小于最后修改时间，说明需要进行更新了。返回新的资源，与常规http请求相应一致。
  • 否则返回304状态码，告诉浏览器直接使用缓存。

• Etag：服务器根据当前文件的内容，给文件生成的唯一标识，只要文件的内容有改动，这个值就会改变。服务器通过响应头把这个值发送给浏览器。浏览器接收到Etag值后，会在下次请求时，将这个值作为If-None-Match字段的内容，并放在请求头中，然后发送给服务器。服务器接收到If-None-Match后，会与服务器中该资源的Etag进行对比：

  • 如果二者不一样，说明需要更新。返回新的资源，与常规http请求相应一致。
  • 否则返回304状态码，告诉浏览器直接使用缓存。

ETag的优先级高于Last-Modified,服务器会优先验证ETag

Last-Modified是以秒为单位的，所以在资源频繁更改的情况下，Last-Modified是不安全的，而ETag可以检查文件大小和文件的唯一索引节点，故即使修改频繁的资源依然能检测到更改

缓存策略

基于上面介绍的强缓存和协商缓存特点，以下是笔者总结的缓存策略；

频繁变动的资源

对于频繁变动的资源，肯定首先要保证的就是及时性，即服务器文件更新，需要尽快展示在客户端，所以对于此种资源，建议禁用强制缓存，采用协商缓存的策略。

cache-control: no-cache
Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT
ETag: deadbeef

以上标识中

• cache-control: no-cache ，表示每次都从服务器询问资源是否更改
• Last-Modified: Tue, 22 Feb 2022 22:00:00 GMT， 表示资源的最后修改时间
• ETag: deadbeef ，表示资源对应的唯一标识

过程如下：

1. 当浏览器查发现cache-control: no-cache 时，会向服务器发起该资源的请求
2. 但是在请求前，浏览器会先在自己的缓存中查找该资源， 如果发现存在该资源的缓存文件，则将该缓存文件的Etag和Last-Modified字段转换为请求头中的If-None-Match和If-Modified-Since一同发送到服务端
3. 如果发现不存在该资源，则直接请求
4. 服务器接收到资源请求，如果不存在If-None-Match和If-Modified-Since请求头，则说明客户端没有缓存，直接返回资源
5. 如果存在If-None-Match和If-Modified-Since请求头，服务器比对当前的If-None-Match与资源相对应的ETag是否相同，如果相同则说明文件没有更改，返回304让浏览器使用缓存，如果不相同，返回新文件。

不经常变化的资源

对于不经常变化的资源，建议设置强缓存，

cache-control:max-age=31536000

如上设置会强缓存该资源一年时间，如果我们中间需要修改该资源，可以采用在资源链接末尾添加唯一hash或是唯一时间戳来解决。

加餐

对于需要缓存的文件，建议明确指出cache-control字段，如果没有设置该字段，则浏览器会采用一种叫做启发式缓存的方式缓存文件。

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
Date: Tue, 22 Feb 2022 22:22:22 GMT
Last-Modified: Tue, 22 Feb 2021 22:22:22 GMT

如果存在以上响应，不存在cache-control字段

试探性地知道，整整一年没有更新的内容在那之后的一段时间内不会更新。

因此，客户端存储此响应（尽管缺少 max-age）并重用它一段时间。

复用多长时间取决于实现，但规范建议存储后大约 10%（在本例中为 0.1 年）的时间。

由此可见，如果不指明cache-control字段会导致不必要的缓存，或是无谓的流量消耗。

一段时间内不会更新。

因此，客户端存储此响应（尽管缺少 max-age）并重用它一段时间。

复用多长时间取决于实现，但规范建议存储后大约 10%（在本例中为 0.1 年）的时间。

由此可见，如果不指明cache-control字段会导致不必要的缓存，或是无谓的流量消耗。

所以，建议所有静态资源都明确指出cache-control字段，明确缓存策略。