Last-Modify,Etag,Cache-Control请求头在缓存中的作用

Last-Modify(响应头) + If-Modified-Since（请求头）
服务器在返回资源的时候设置Last-Modify当前资源最后一次修改的时间，浏览器会把这个时间保存下来，在下次请求的时候，请求头部If-Modified-Since 会包含这个时间，服务端收到请求后，会比对资源最后更新的时间是否在If-Modified-Since设置的时间之后，如果不是，返回304状态码，浏览器将从缓存中获取资源。反之返回200和资源内容。

ETag（响应头） + If-None-Match（请求头）
根据资源标识符来确定文件是否存在修改，服务器每一次返回资源，都会在Etag中存放资源的标识符，浏览器收到这个标识符，在下一次请求的时候将标识符放在If-None-Match中，服务端将判断是否匹配，如果不匹配，返回200以及新的资源，反之返回304，浏览器从缓存中获取资源

附上控制台一张图片的信息

响应头

请求头

ETag和Last-Modify原理看起来是不是差不多？那么区别在哪里呢？在分布式后台系统Last-Modify更准确，因为每台电脑生成的Etag不一样

Cache-Control/Expires(响应头)
在http 1.0的时代，基于Pragma 和 Expires 控制缓存的生命周期。可以通过设置Pragma为no-cache关闭缓存功能，同样也可以在Expires中设置一个缓存失效的时间。这个失效的时间是相对于服务器的时间而言的，如果人为地改变了客户端的时间，是会导致缓存失效的。
所以，为了解决这个问题，HTTP1.1的协议加入了Cache-Control，通过设置Cache-Control的max-age可以控制缓存的周期，Cache-Control与Expires同时存在时以Cache-Control的为准。Cache-Control是相对时间，比如设置7000s内该资源一直有效，在这个周期内，浏览器再一次需要使用资源的时候，就不会发出请求。

再看一张有设置Cache-Control的

在浏览器请求时，如果在Cache-Control设置的时间内，直接会使用浏览器的缓存，而Last-Modify和Etag依旧是有向服务器器发送了一个http请求的，只是服务器再返回了304告诉浏览器我这资源没有变化