浏览器缓存机制

Code Crafter

于 2023-03-27 15:27:27 发布

阅读量647

点赞数 1

文章标签：缓存 java 前端

本文链接：https://blog.csdn.net/qq_42943914/article/details/129795804

版权

Web 缓存按照缓存位置来区分，包括数据库缓存、服务端缓存、CDN缓存和浏览器缓存

浏览器缓存主要通过HTTP/HTTPS实现，存储位置主要有四种：

<一>、Service Worker
1. service worker 是运行在浏览器背后的独立线程，可以用来实现缓存功能
2. 由于service worker 涉及到了请求拦截，所以必须使用HTTPS协议来保证安全
3. service worker 与浏览器其他内线缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存、并且缓存是持续性的

<二>、 Memory Cache(内存缓存)
1. memory cache 是内存中的缓存个，主药缓存的内容是页面中已经抓取到的资源，例如：
* 下载的样式
* 脚本
* 图片
2. 这种方式读取内存中的数据高效，但是缓存持续性很短，一旦我们关闭了Tab 页面，内存中的缓存就释放了
3. 由于计算机中的内存比硬盘小得多，我们能够使用存储的内存并不多
4. 内存缓存在缓存资源时，并不关心返回资源的HTTP 缓存头cache-control,同时资源的匹配也并非仅仅是对URL进行匹配，还可能会对 Content-Type, CORS 等其他特征做校验

<三>、 Disk Cache(硬盘缓存)
1. 硬盘缓存是是存储在硬盘中的缓存，读取速度比Memory Cache 慢，但是存储量大。
2. 硬盘缓存根据HTTP Header中的字段判断，哪些资源需要缓存，哪些资源可以在不请求直接使用，哪些资源已经过期需要重新请求

<四>、 Push Cache(推送缓存)
1. 推送缓存是HTTP/2中的内容，当其他三种缓存都没有命中的时候，它才会被使用。
2. 推送缓存只在会话中(session)存在，一旦会话结束就被释放，并且缓存时间也很短暂，在Chrome浏览器中只有5分钟左右，同时它也并非严格执行HTTP头中的缓存命令

思考：浏览器什么时候回讲混存存储到内存中，什么时候存储到硬盘中内？

小文件优先存储到内存中，反之存储到硬盘中
使用频率高的文件优选存储到硬盘中

HTTP 缓存
根据是否需要向服务器发起HTTP请求，将缓存过程分为两个部分：协商缓存和强制缓存; 两种缓存方式最终使用的都是本地缓存，强制缓存需要和服务器进行交互，协商缓存不需要和服务器进行交互。

<一>、强制缓存
1. 强制缓存是在浏览器加载资源的时候，先检查缓存时间是否过期，若未过期则直接从缓存中查找请求结果，如果缓存时间过期获取不存在该缓存的结果，则向服务器端发起请求
在这里插入图片描述

 2.   强制缓存设置缓存过期时间的方法有两种（响应头字段）: Expires 和 Cache-Control
 3. Expires (HTTP/1.0) : 客户端第一次请求时，服务端会在响应头部添加Expires字段.当浏览器再次发送请求时，客户端会先对比当前时间和Expires对应的时间。如果早于Expires 时间则直接使用，否则，需要再次相服务端发送请求
      * 存在的问题：服务端和客户端的时间可能不同，导致缓存过期时间出现偏差； 客户端可以通过修改系统时间来继续使用缓存或提前使缓存时间失效

Cache-Control (HTTP/1.1)：为了解决Expires 存在的时间偏差问题，提出了Cache-Control，Cache-Control常用的值有:
* no-cache: 表示协商缓存，即每次使用缓存前必须向服务端确认缓存资源是否更新；
* no-store: 禁止浏览器以及所有中间缓存存储响应内容
* public: 共有缓存，表示可以被代理服务器缓存，可以被多个用户共享
* private: 私有缓存，不能被代理服务器缓存，不可以被多个用户共享
* max-age: 以秒为单位的值，表示缓存的有效时间
* must-revalidate: 当缓存过期时，需要去服务端校验缓存的有效性
强制缓存中，cache-control的max-age的优先级高于Expires
状态码为200，一定是服务端返回的吗？
不是所有的200状态码都是服务端返回的，如果命中强缓存，会直接从内存或者磁盘中读取内容，并返回一个200的状态码。

<二>、协商缓存

协商缓存不指定缓存的有效时间，而是在请求时直接发送资源标识到服务端确认缓存是否需要更新，如果请求返回的HTTP状态码为304，则表示缓存仍然有效；否则返回状态码200、最新的资源和最新的资源标识
协商缓存的资源标识： Last-Modified(资源最后修改时间)、 Etag(资源的唯一标识)
Last-Modified 和 If-Modified-Since:
- 服务端通过响应头部字段Last-Modified 和请求头字段If-Modified-Since比对双方资源的修改时间，来确定缓存是否需要更新
- 浏览器第一次请求资源，服务端在返回资源的响应头中搅入Last-Modified字段，标识资源在服务端上最近一次的修改时间
- 当浏览器再次相服务端请求该资源时，请求头部带上之前服务端返回的Last-Modified, 这个请求头叫If-Modified-Since
- 当服务端再次收到请求，根据If-Modified-Since的值判断相关资源室友有变化，如果没有返回 304 Not Modified;否则返回更新后的资源，且更显Last-Modified响应头内容

这种方式存在的弊端
* 精度问题： last-Modified 的时间精度为秒，如果1秒内发生改变，那么缓存判断会失效
* 准度问题: 如果一些文件被修改后又还原了，内容没发上变化，却需要重新请求
* 服务器问题：某些服务器不能精确的得到文件的最后修改时间
在这里插入图片描述

ETag 和 If-None-Match
为了解决精度问题和准度问题，http提供了另一种依赖于文件哈希值的精确判断缓存的方式，响应头部字段ETag和请求头部If-None-Match
- 当浏览器第一次请求资源时，服务端在返响应头中加入Etag字段，Etag字段的值为该资源的哈希值
- 当客户端再次相服务端请求资源时，在请求头上加上If-None-Match,值为之前响应头部字段Etag的值
- 服务端再次收到请求，将请求头If-None-Match字段得值和响应资源的哈希值进行对比，如果两个值相同，则说明资源没变化，返回304 Not Modified; 否则就正常返回资源内容，无论是否发生变化，都会将计算出的哈希值放入响应头部的ETag字段中

Etag 协商缓存存在的问题:
* 计算成本：对于大文件而言，读取完整的文件内容生成的哈希值开销较大，只读取文件部分内容，又容易判断出错
* 计算误差: 不同服务端可能会采用不同的哈希值计算方式，所以同一个资源在两台服务端产生的ETag可能是不同的。对于使服务集群来处理请求的网站来说，使用ETag的缓存命中率会有所降低
在这里插入图片描述
Last-Modified 只能精确到秒，如果资源被重复生成，而内容不变，Etag更精准，会优先使用Etag