[TOC]
简介
用户获取网络资源,需要通过非常长的网络去服务器上请求资源,另外服务端为了应对大量的用户请求而不断的提升硬件性能与带宽。这对用户与服务端都非常的不友好。而缓存就是为了解决用户请求速度与释放服务器压力而生的。
为什么我会写Http缓存,因为下面介绍的缓存都是通过Http定义的。浏览器缓存则是另外的如:SessionStorage,LocalStorage(个人见解)。
缓存的判断规则
1. 过期机制
过期机制就是浏览器根据缓存的有效期进行判断,如果在有效期内就使用缓存,否则就抛弃这个缓存。
一个缓存副本必须满足以下条件,浏览器会认为它是有效的,足够新的:
1. 含有完整的过期时间控制头信息(HTTP协议报头),并且仍在有效期内;
2. 浏览器已经使用过这个缓存副本,并且在一个会话中已经检查过新鲜度;
2. 验证机制
浏览器带上本地缓存副本的验证信息提交给服务器(Last-Modified,ETag),由服务器决定是否采用这个缓存。
客户端请求的时候带上Last-Modified,服务器进行验证返回If-Modified-Since来确定资源是否是有效缓存。
另外在控制头信息带上这个资源的实体标签Etag(Entity Tag),它可以用来作为浏览器再次请求过程的校验标识。如过发现校验标识不匹配,说明资源已经被修改或过期,浏览器需求重新获取资源内容。
缓存来源
1. from disk cache
此资源是从磁盘当中取出的,也是在已经在之前的某个时间加载过该资源,不会请求服务器但是此资源不会随着该页面的关闭而释放掉,因为是存在硬盘当中的,下次打开仍会from disk cache。
2. from memory cache
字面理解是从内存中,其实也是字面的含义,这个资源是直接从内存中拿到的,不会请求服务器一般已经加载过该资源且缓存在了内存当中,当关闭该页面时,此资源就被内存释放掉了,再次重新打开相同页面时不会出现from memory cache的情况。
3. 请求来源
当http状态为200是实实在在从浏览器获取的资源,当http状态为304时该数字是与服务端通信报文的大小,并不是该资源本身的大小,该资源是从本地获取的。
缓存类型
强缓存
1. Expires
服务器发送给客户端一个UTC时间(如 expires: Thu, 19 Nov 2019 08:52:00 GMT),浏览器接收到了这个头,就会为这个资源标记一个过期时间,在下次的请求时候判断未过期会直接使用这个资源缓存。来源会标记为from disk cache
。
浏览器在取到这个缓存资源的时候,会用客户机的时间与之对比
,如果还在有效期
内,则直接使用这个缓存,不进行网络请求
。否则会进入其他缓存依据判断。
而这个机制会有一个问题,就是,缓存资源是否过期依赖客户机时间。客户机可以通过修改
当前时间来使这个缓存资源失效
。
2. Cache-Control
HTTP/1.1定义的 Cache-Control 头用来区分对缓存机制的支持情况, 请求头和响应头都支持这个属性。通过它提供的不同的值来定义缓存策略。
2.1 max-age
示例:
Cache-Control: max-age=100
这个示例表示,这个缓存资源在本次请求后的100秒之后都有效。浏览器会直接返回from disk cache
,不进行网络资源请求。
2.2 no-cache
示例:
Cache-Control: no-cache
这个示例表示,这个缓存资源不进行强缓存校验,需要通过服务端的协商缓存判断是否启用。
协商缓存
1. Last-Modified,If-Modified-Since
当客户端访问资源时,服务器会将资源最后修改时间通过 Last-Modified
标识由服务器发往客户端,客户端记录修改时间,再次请求本地存在的缓存资源时,客户端会通过 If-Modified-Since
头将先前服务器端发过来的最后修改时间戳发送回去,服务器端通过这个时间戳判断客户端的页面是否是最新的,如果不是最新的,则返回新的内容,如果是最新的,则返回304
告诉客户端其本地缓存资源是最新的。
2. ETag
服务器为一个资源生成一个唯一的id值,一旦资源在服务端发生了改变则会重新生成一个tag,客户端请求资源时,带上了这个etag,如果不一致,服务端将会发送最新的资源给用户,否则重定向304
直接使用缓存资源。
浏览器缓存判断流程
参考文章
https://www.yodfz.com/detail/...
https://www.cnblogs.com/slly/...
https://blog.csdn.net/qq_3205...
https://blog.csdn.net/charlen...
https://segmentfault.com/a/11...
http://www.cnblogs.com/li0803...
https://developer.mozilla.org...
https://blog.csdn.net/alan199...