http缓存图解

在前端开发中，减少不必要的静态资源请求可以在很大程度上提升我们的页面性能，因此有一个优秀的缓存策略是十分有必要的。

这里我们将详细的聊聊http缓存下的强缓存和协商缓存。

http缓存策略图解：

1、强缓存（判断字段：Expires和Cache-Control)

强缓存是利用http的返回的响应头中的Expires或者Cache-Control (优先级更高) 两个字段来控制的，用来表示资源的缓存时间。

命中强缓存时，浏览器并不会将请求发送给服务器。

Expires: 指定一个具体时间(2020年12月12日 17:00), 到了这个时间了, 缓存过期了, 在时间内, 都是有效的, 可以直接读

Cache-Control : max-age字段指定一个过期时间 (3600s), 这个资源你加载到后, 可以用 3600s

1、Expires

expires，缓存过期时间，用来指定资源到期的时间，是服务器端的具体的时间点。也就是说，Expires=(max-age) + 请求时的时间，需要和Last-modified（最后一次修改时间）结合使用。

该字段会返回一个时间，比如 Expires: Thu, 25 Mar 2032 12:25:53 GMT。这个时间代表着这个资源的失效时间，也就是说在xx年xx月xx日时间之前都是有效的，即命中缓存。

这种方式有一个明显的缺点，由于失效时间是一个绝对时间，所以当客户端本地时间被修改以后，服务器与客户端时间偏差变大以后，就会导致缓存混乱。于是发展出了Cache-Control。

2、Cache-Control

Cache-Control是一个相对时间，例如Cache-Control:max-age 3600，代表着资源的有效期是3600秒。

由于是相对时间，并且都是与客户端时间比较，所以服务器与客户端时间偏差也不会导致问题。

Cache-Control与Expires可以在服务端配置同时启用或者启用任意一个，同时启用的时候Cache-Control优先级高。

Cache-Control 可以由多个字段组合而成，主要有以下几个取值：

a、max-age

        指定一个时间长度，在这个时间段内缓存是有效的，单位是s。

        例如上图中设置 Cache-Control:max-age=31536000，也就是说缓存有效期为（31536000 / 24 / 60 / 60）天，第一次访问这个资源的时候，服务器端也返回了 Expires 字段，并且过期时间是一年后。在没有禁用缓存并且没有超过有效时间的情况下，再次访问这个资源就命中了缓存，不会向服务器请求资源而是直接从浏览器缓存中取。

b、no-cache

         强制所有缓存了该响应的用户，在使用已缓存的数据前，发送带验证的请求到服务器, 问服务器是否可以读缓存。

不是字面意思上的不缓存。

c、no-store

         禁止缓存，每次请求都要向服务器重新获取数据。

注意: 如果命中强缓存, 在有效期内, 使用了本地浏览器的缓存, 请求该资源是不会向服务器发送请求的! (大大减轻了服务器压力)

2、协商缓存  (强缓存未命中-发送请求进行协商)

若未命中强缓存(强缓存过期了)，则浏览器会将请求发送至服务器。

服务器根据http请求头中的Last-Modify(服务器给客户端）/If-Modify-Since（客户端给服务器）或Etag(服->客）/If-None-Match(客->服)来判断是否命中协商缓存。

如果命中，则http返回码为304 (你本地之前加载的资源是有效的)，浏览器从缓存中加载资源。

1、Last-Modify/If-Modify-Since

浏览器第一次请求一个资源的时候, 服务器返回的header中会加上Last-Modify，

Last-modify是一个时间标识，标识该资源的最后修改时间，例如下图的response中Last-Modify: Wed, 03 Sep 2014 10:00:27 GMT。

当浏览器再次请求该资源时(进行协商请求时)，发送的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。

服务器收到If-Modify-Since后，根据实际服务器的资源的最后修改时间, 进行判断是否命中缓存。

如果命中缓存，则返回 http304，并且不会返回资源内容，并且不会返回Last-Modify。

由于对比的是服务端的修改时间，所以就算客户端与服务端时间差距, 也不会有问题。

但是有时候通过最后修改时间来判断资源是否修改还是不太准确（资源变化了最后修改时间也可以一致）。

比如: 最后修改只能精确到秒级, 一秒进行了多次修改, 就不行了, 于是出现了ETag/If-None-Match。

2、ETag/If-None-Match

与Last-Modify/If-Modify-Since (最后修改时间)不同的是，Etag/If-None-Match返回的是一个校验码（ETag: entity tag）。

ETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。

ETag值的变更则说明资源状态已经被修改。

服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存。

ETag生成靠以下几种因子

1. 文件的i-node编号，是Linux/Unix用来识别文件的编号。

2. 文件最后修改时间

3. 文件大小

既生 Last-Modified 何生 Etag ？

你可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag（实体标识）呢？

Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

1. Last-Modified标注的最后修改只能精确到秒级

   如果某些文件在1秒钟以内，被修改多次的话，它将不能准确标注文件的修改时间

2. 有可能存在服务器没有准确获取文件修改时间，或者与代理服务器时间不一致等情形

Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符，能够更加 准确的控制缓存。

不会仅仅只根据最后的修改时间判断是否进行使用缓存

Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，

最后才决定是否返回304。