浏览器HTTP缓存解读(HTTP Status:200 304)
为什么要有浏览器缓存?
浏览器缓存(Brower Caching)是浏览器对之前请求过的文件进行缓存,以便下一次访问时重复使用,节省带宽,提高访问速度,降低服务器压力
http缓存机制主要在http响应头中设定,响应头中相关字段为Expires、Cache-Control、Last-Modified、Etag。
浏览器缓存从无到有,再到利用缓存的流程:
浏览器首次请求,缓存从无到有,缓存文件可能不一定是从web服务器请求来的,也可能是从CDN来的,但总而言之第一次一定是请求来的
浏览器对同样的资源发起二次请求,针对不同资源类型(比如JS文件等等),服务器进行判断
部分静态资源文件,可以判断缓存时长,如果未过期就可以从本地读取
浏览器缓存类型
- 强缓存
浏览器不会向服务器发送任何请求,直接从本地缓存中读取文件并返回 Status Code: 200 OK
从内存读取,因为速度快于硬盘,所以最优先由内存读取
从硬盘读取,如果内存中没有,就会从硬盘中读取
如果以上两个地方都没有对应的缓存资源,才会去服务器寻找对应的缓存资源。
补充一下,在强缓存中,普通刷新会忽略它,但不会清除它,需要强制刷新。浏览器强制刷新时,请求会带上Cache-Control:no-cache和Pragma:no-cache,这样就会让浏览器对资源进行重新请求。而普通刷新的情况下,部分资源文件(比如js、图片),不会带上no-cache属性,也就是会到服务器进行协商,请注意,这里属性携带的位置均位于请求头,而响应头是否设置,则取决于浏览器
- 协商缓存
所谓协商缓存,简单说就是先看看本地缓存过期没有,没过期直接用,过期了去服务器看看本地这个缓存还能不能用,能用就接着用(返回304状态码)。不能用就请求最新的(返回200状态码)。
协商缓存HTTP Code : 304
服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存,如果命中,则返回304状态码并带上新的response header通知浏览器从缓存中读取资源;
协商缓存HTTP Code : 200
浏览器首次请求,本地没有缓存可用。去服务器请求缓存,得到200的响应
浏览器针对协商缓存判断流程
比如Get请求JS文件,请求头中会加入属性:Last-Modified/If-Modified-Since或者ETag/If-None-Match
Last-Modifed/If-Modified-Since和Etag/If-None-Match是分别成对出现的
,呈一一对应关系
之所以会有这两种属性,是因为前者是HTTP 1.0版本的,后者是HTTP 1.1版本出现的
这两个都是用来判断文件是否需要更新的时间戳或者hash值,服务器收到请求后,根据这两个属性进行判断,如果请求的文件没有更新,那么就返回HTTP304的状态码,让浏览器直接用缓存(Disk or Menmory)。而是否追加这个属性,由浏览器自行判断
但一般像是Ajax的Get、Post(类似这种的XHR)等,如果浏览器后端利用代码明确设置了Cache-Control:no-cache
的选项,则不会缓存数据,到了服务端就重新请求数据
也就是no-cache的情况下,必须到服务器进行check,当服务器返回304的时候,才允许使用浏览器缓存,否则必须请求新数据
注意:ETag的优先级是优于 Last-Modified&If-Modified-Since,如果校验Header是ETag+If-None-Match的情况下,就会优先验证ETag的Hash值
如何选择合适的缓存?
大致的顺序
- Cache-Control —— 请求服务器之前
- Expires —— 请求服务器之前
- If-None-Match (Etag) —— 请求服务器
- If-Modified-Since (Last-Modified) —— 请求服务器
协商缓存需要配合强缓存使用,如果不启用强缓存的话,协商缓存根本没有意义
大部分web服务器都默认开启协商缓存,而且是同时启用【Last-Modified,If-Modified-Since】和【ETag、If-None-Match】
但是下面的场景需要注意:
- 分布式系统里多台机器间文件的Last-Modified必须保持一致,以免负载均衡到不同机器导致比对失败;
- 分布式系统尽量关闭掉ETag(每台机器生成的ETag都会不一样);
CDN缓存参考:https://blog.csdn.net/Runnymmede/article/details/138315636
参考文章1:https://juejin.cn/post/6844904153043435533
参考文章2:https://juejin.cn/post/6844903838768431118
参考文章3:https://github.com/amandakelake/blog/issues/41
参考文章4:https://segmentfault.com/a/1190000008956069