简单谈谈四种HTTP缓存控制和用法

为了有效降低浏览器多次访问同一资源造成的时间和数据成本，我们通常会利用缓存来优化页面性能。

缓存控制四种方式

Cache-Control

response.setHeader('Cache-Control','public,max-age=360')

服务器在响应时，回传max-age参数，表示缓存时间：xx秒

那么客户端在下次请求时，根据上次回传的max-age值，首先判断缓存的相对时间

如果还未超过时间，则不发起请求，直接从Cache中读取。反之，则重新请求。

Expires

response.setHeader('Expires','Mon Jan 01 2018 08:00:00 GMT') //必须用格林威治时间格式

服务器在响应时，回传格林威治时间，表示在次时间内的请求直接从Cache中读取

那么客户端在下次请求时，根据上次回传的时间，比对客户端本地时间，

如果本地时间未超过回传时间，则不发起请求，直接从Cache中读取。反之，则重新请求。

缺陷

由于返回的时间比对的是客户端本地时间，如果本地时钟修改，则会导致缓存出现异常

结论：

以上两种为早期缓存控制方式，虽然简单，但也暴力。如时间上不符合要求则直接放弃HTTP请求，改由Cache读取。一般使用Cache-Control相对时间形式。

这样从某种程度上存在不合理因素，如服务器的确在返回的这段时间内修改了页面内容，则会造成页面信息不对成。客户端依然在访问旧数据，但其实服务器早已更新。

为了解决这个问题，程序员早期是通过更改请求url解决的，一般在需要重新请求的页面后添加一个查询参数，如：

//其中?后面的version=1 即为查询参数，实际无意义，仅仅为了让客户端重新向服务器请求

---

Last-Modified

response.setHeader('Last-Modified','Fri,22 Jul 2016 08:00:00 GMT')

服务器在响应时，同样回传格林威治时间，不同的是，它表示的是服务器最新一次对页面修改的时间

那么客户端在下次请求时，会通过If-Modified-Since: Last-Modified-value带上之前回传回来的时间

如果客户端传来的最后修改时间与服务器上的依然一致，则直接回送304 和响应报头即可。

如果没有匹配上，说明服务器已对页面做了修改，则重新相应新的页面并回传新的Last-Modified

请求响应图.png

此种方式存在缺陷：

1、只要资源修改，无论内容是否发生实质性的变化，都会将该资源返回客户端。例如周期性重写，这种情况下该资源包含的数据实际上一样的。
2、以时刻作为标识，无法识别一秒内进行多次修改的情况。
3、某些服务器不能精确的得到文件的最后修改时间。

ETag

response.setHeader('ETag','3f'd729c07839068ebb6f7f4374981d9f') //一般可用MD5

服务器在响应时，回传一个唯一标志符（比如md5），服务器在把页面响应给客户端的时候，会在实体首部加上“ETag: 唯一标识符”一起返回给客户端

客服端会保留ETag字段，在下次请求时，通过在请求中添加if-none-match:ETag-value 给服务器，与服务器的ETag字段进行匹配，如果匹配上，则直接回送304 和响应报头即可。反之，则重新发送资源数据并回传新的ETag字段

结论：

由于ETag字段是唯一标识符，能更精确的判断资源是否修改，一般使用ETag来实现。但也必须考虑计算ETag值带来的性能损耗

---

总结：

Last-Modified/ ETag 属于同一种缓存类型，均需发起请求，根据请求来判断是否304，从而节省下载的时间

Cache-Control/Expires 属于同一种缓存类型，根据时间数据直接判断是否发起请求，从而节省了请求的时间和下载的时间

另外需留意的是：

浏览器对用户发的第一个请求，默认不缓存

如果请求头有Cache-Control，那个浏览器就不会在接受响应里的Cache-Control