前端Http协议缓存初解

[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...