浏览器缓存详细介绍
一、整个流程过一遍
我们假设浏览器在请求一张图片：
- 浏览器会检查这张图片的HTTP头部字段，看看这张图片是不是满足强缓存，如果满足的话，浏览器会直接从本地缓存里面将图片取出来，不会向服务器发送请求。
- 如果第一步的强缓存没有满足的话，浏览器会向服务器发送一个请求，服务器会检查该图片的HTTP头部字段，看看是不是满足协商缓存，如果满足的话，服务器会返回一个没有相应体，只有响应头部的响应，浏览器获取该响应之后会直接从本地缓存中去获取该图片。并且，服务器返回的状态码是304！
- 最后，如果第二步的协商缓存也没有满足的话，浏览器就会正常的从服务器加载该图片。
二、强缓存及对应的头部字段
我们拿百度首页来举例： 百度搜索输入框上面的logo是一张png图片，当我们浏览器请求这张图片的时候，会先检查该图片的HTTP头部字段，是这样的
其中，Expires和Cache-Control这两个响应头部字段都可以控制该图片在浏览器缓存的有效期。
Expires和Cache-Control
Expires
Expires: Fri, 25 May 2029 13:53:52 GMT （必须是GMT格式的时间）
Cache-Control 部分说明：
Public 指示响应可被任何缓存区缓存。 Private 指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。 no-cache 指示请求或响应消息不能缓存（HTTP/1.0用Pragma的no-cache替换） no-store 用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。 max-age 指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。 min-fresh 指示客户机可以接收响应时间小于当前时间加上指定时间的响应。 max-stale 指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。
Expires是HTTP1.0的时候提出来的，他的时间是一个绝对时间，而Cache-Control是HTTP1.1提出来的，他的时间是一个相对时间。
Expires和Cache-Control工作原理
Expires：
- 浏览器向服务器请求一张图片，服务器在返回图片的同时会在响应头部中加入Expires这个字段，并且后面会跟上一个绝对时间。
- 当浏览器发现该头部之后会将该图片和头部一起缓存起来。
- 当浏览器再次请求该图片的时候，浏览器会先检查头部的Expires的时间是否大于当前时间，如果是的话则可以使用缓存。
- 如果时间已经超过过期时间，则浏览器会发起请求，获取该图片，并且再次获取该图片的时候会更新Expires。
Cache-Control： 和Expires不同之处就在时间那一块，Cache-Control计算的是一个相对时间。当浏览器第二次请求的时候会去缓存中寻找该图片，然后会根据第一次获取到该图片的时间和max-age的时间计算出一个相对的过期时间，如果当前时间没有超过这个过期时间，则使用缓存的资源。
此外，有一点需要注意的是Expires和Cache-Control可以同时存在，如果同时存在的话，后者的优先级更高。
三、协商缓存及对应的头部字段
假设我们还是加载一张图片，当我们不满足强缓存的时候就会给服务器发送一个请求，然后会根据协商缓存的几个头部字段判断是否满足协商缓存，如果满足，就会返回304状态码以及Not Modified短语。
协商缓存对应的头部字段
1. Last-Modified和If-Modified-Since
- 当浏览器第一次请求某个资源的时候，服务器会在返回资源的同时在头部字段加上Last-Modified，表示该资源在服务器上最后一次被修改的时间。
- 浏览器获得资源之后将其缓存。
- 当浏览器再次获取该资源的时候，会在请求头加上If-Modified-Since这个字段，这时候他等于第一次获取该资源的时候Last-Modified的值，服务器会根据传过来的时间判断该资源服务器上的最后修改时间和传过去的时间是否相等，如果相等，则表示没有发生变化，满足协商缓存。
- 如果不满足协商缓存，则会在更新资源的同时更新Last-Modified的值。
2. ETag和If-None-Match
靠时间来判断资源是否更新是很不可靠的，于是就有了更加可靠的ETag和If-None-Match，他们是直接判断实际内容是否有变化。
- 浏览器首次获取某个资源的时候，服务器会在返回资源的同时在响应头部加上Etag字段，该字段是根据被请求的资源生成的唯一标识字符串。
- 当浏览器再次请求该资源的时候，会在请求头加上If-None-Match字段，该字段的值就是第一次获取的Etag的值，服务器收到传过来的值，会再次将该资源生成一个唯一标识，并对比两者是否相同，如果相同，则满足协商缓存。
- 如果不满足协商缓存，则会在更新资源的同时更新Etag的值。
四、缓存，浏览器把东西存哪儿？
从缓存位置上来说分为四种，并且各自有优先级。
- Service Worker
- Memory Cache
- Disk Cache
- Push Cache
Service Worker
Service Worker是独立运行在浏览器里面的线程，是一个可以自由控制缓存文件的机制，一般经过Service Worker寻找缓存的请求，无论最终是在哪儿取到的资源，在浏览器网络窗格中显示的都是Service Worker。
Memory Cache
Memory Cache，就是将资源缓存到内存中，等待下次访问时不需要重新下载资源，而直接从内存中获取。Webkit早已支持Memory Cache。 目前Webkit资源分成两类，一类是主资源，比如HTML页面，或者下载项，一类是派生资源，比如HTML页面中内嵌的图片或者脚本链接。虽然Webkit支持Memory Cache，但是也只是针对派生资源，用于保存原始数据（比如CSS，JS等），以及解码过的图片数据。
Disk Cache
Disk Cache，就是将资源缓存到磁盘中，等待下次访问时不需要重新下载资源，而直接从磁盘中获取。它与Memory Cache最大的区别在于，当退出进程时，内存中的数据会被清空，而磁盘的数据不会，所以，当下次再进入该进程时，该进程仍可以从diskCache中获得数据，而Memory Cache则不行。 Disk Cache与Memory Cache相似之处就是也只能存储一些派生类资源文件。它的存储形式为一个index.dat文件，记录存储数据的url，然后再分别存储该url的response信息和content内容。
Push Cache
Push Cache（推送缓存）是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。它只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在Chrome浏览器中只有5分钟左右，同时它也并非严格执行HTTP头中的缓存指令。