资源请求的过程：
1.浏览器请求——>2.无缓存——>3.向web服务器请求——>4.请求响应、缓存协商——>5.呈现
在第4个步骤，在响应消息的头字段，会有Expires、Cache-Control、缓存时间、Etag、Last-Modified等信息。
再次发生请求时缓存管理是怎么回事？：
1.浏览器在请求某一资源时，会先获取该资源缓存的header信息，判断是否命中强缓存（Expires、Cache-Control），如果命中，就直接从缓存中获取资源，包括缓存header信息。请求不会到服务器端。
2.如果没有命中强缓存，浏览器会发送请求到服务器，请求会携带第一次请求返回的有关缓存的header信息（Last-Modified/If-Modified-Since和Etag/If-None-Match），由服务器根据请求中header信息来对比是否协商缓存命中，若命中，服务器返回新的响应header信息更新缓存中对应的header信息，但是不返回资源，它告知浏览器直接从缓存中获取；否则返回最新的资源内容。
Expires是较老的强缓存管理header，由于它是服务器返回的一个绝对时间，在服务器时间与客户端时间相差较大时，缓存管理容易出现问题，比如随意修改下客户端时间，就能影响缓存命中的结果。所以在http1.1的时候，提出了一个新的header，就是Cache-Control，这是一个相对时间，在配置缓存的时候，以秒为单位，用数值表示。当Expires和Cache-Control都存在时，Cache-Control优先。
Expires是绝对有效期，表示资源过期时间。校验规则是用再次请求的时间和该值比较。
Cache-Control的校验规则是：根据它第一次的请求时间和Cache-Control设定的有效期，计算出一个资源过期时间，再拿这个过期时间跟当前的请求时间比较，如果请求时间在过期时间之前，就能命中缓存，否则就不行。
Cache-Control描述的是一个相对时间，在进行缓存命中的时候，都是利用客户端时间进行判断，所以相比较Expires，Cache-Control的缓存管理更有效，安全一些。
协商缓存要配合强缓存使用，不然协商缓存没啥意义。
协商缓存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】这两对Header来管理的。
【Last-Modified，If-Modified-Since】：If-Modified-Since就是上次请求返回的Last-Modified，服务器再次收到资源请求时，根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化，如果有变化，就正常返回资源内容。如果没有变化，就返回304，不返回资源内容，不更新Last-Modified。
一般来说，在没有调整服务器时间和篡改客户端缓存的情况下，这两个header配合起来管理协商缓存是非常可靠的，但是有时候也会服务器上资源其实有变化，但是最后修改时间却没有变化的情况，而这种问题又很不容易被定位出来，而当这种情况出现的时候，就会影响协商缓存的可靠性。所以就有了另外一对header来管理协商缓存，这对header就是【ETag、If-None-Match】。它们的缓存管理的方式是：
【ETag、If-None-Match】：浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上ETag的header，这个header是服务器根据当前请求的资源生成的一个唯一标识，这个唯一标识是一个字符串，只要资源有变化这个串就不同，跟最后修改时间没有关系，服务器再次收到资源请求时，根据浏览器传过来If-None-Match和然后再根据资源生成一个新的ETag，如果这两个值相同就说明资源没有变化，否则就是有变化；如果没有变化，返回304返回ETag不返回资源；如果有变化，返回资源。
图结：
这两篇文章总结的都非常好，看完很受益，非常感谢作者。
