前端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...