• HTTP 强缓存和协商缓存介绍


    概述

    浏览器缓存,既是网页性能优化里面静态资源相关优化的一大利器,也是无数web开发人员在工作过程不可避免的一大问题,所以在产品开发的时候我们总是想办法避免缓存产生,而在产品发布之时又在想策略管理缓存提升网页的访问速度。了解浏览器的缓存命中原理,是开发web应用的基础,本文着眼于此。

    基本认知

    浏览器缓存分为强缓存和协商缓存:

    1. 浏览器在加载资源时,先根据这个资源的一些http header判断它是否命中强缓存,强缓存如果命中,浏览器直接从自己的缓存中读取资源,不会发请求到服务器,此请求返回的http状态为200,在chrome的开发者工具的network里面size会显示为from cache。

    2. 当强缓存没有命中的时候,浏览器一定会发送一个请求到服务器,通过服务器端依据资源的另外一些http header验证这个资源是否命中协商缓存,如果协商缓存命中,服务器会将这个请求返回,并且状态码为304,不会返回这个资源的数据,而是告诉客户端可以直接从缓存中加载这个资源,于是浏览器就又会从自己的缓存中去加载这个资源;

    3. 当协商缓存也没有命中的时候,浏览器直接从服务器加载资源数据。

    强缓存与协商缓存的共同点是:如果命中,都是从客户端缓存中加载资源,而不是从服务器加载资源数据;区别是:强缓存不发请求到服务器,协商缓存会发请求到服务器。

    强缓存原理

    强缓存是利用Expires或者Cache-Control这两个http response header实现的,它们都用来表示资源在客户端缓存的有效期。Expires是http1.0提出的一个表示资源过期时间的header,而Cache-Control则是http1.1提出的,如果同时存在则以Cache-Control为先。如下图

    Expires:Sat, 01 Apr 2017 15:53:40 GMT其实意味着在东八区2017/04/01 23:53:40的时候此资源过期。而Cache-Control:max-age=864000意味着从Date:Wed, 22 Mar 2017 15:53:40 GMT这个日期开始算往后10天则资源过期,这个时间在这里实际上就等同于Expires的时间。

    Expires是较老的强缓存管理header,由于它是服务器返回的一个绝对时间,在服务器时间与客户端时间相差较大时,缓存管理容易出现问题,比如随意修改下客户端时间,就能影响缓存命中的结果。而Cache-Control是相对时间就不会有这种问题,两个请求头都加上也是为了兼容不支持http1.1的终端或者路由器。

    协商缓存原理

    当浏览器对某个资源的请求没有命中强缓存,就会发一个请求到服务器,验证协商缓存是否命中,如果协商缓存命中,请求响应返回的http状态为304并且会显示一个Not Modified的字符串,并且让浏览器就又从自己的缓存中去加载这个资源。

    协商缓存是利用的是【Last-Modified,If-Modified-Since】和【ETag、If-None-Match】这两对Header来管理的。

    Last-Modified,If-Modified-Since

    1. 浏览器第一次跟服务器请求一个资源,服务器在返回这个资源的同时,在respone的header加上Last-Modified的header,这个header表示这个资源在服务器上的最后修改时间
    2. 浏览器再次跟服务器请求这个资源时,在request的header上加上If-Modified-Since的header,这个header的值就是上一次请求时返回的Last-Modified的值
    3. 服务器再次收到资源请求时,根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化,如果没有变化则返回304 Not Modified,但是不会返回资源内容;如果有变化,就正常返回资源内容。当服务器返回304 Not Modified的响应时,response header中不会再添加Last-Modified的header,因为既然资源没有变化,那么Last-Modified也就不会改变

    如果协商缓存没有命中,浏览器直接从服务器加载资源时,Last-Modified Header在重新加载的时候会被更新,下次请求时,If-Modified-Since会启用上次返回的Last-Modified值。

    有时候也会服务器上资源其实有变化,但是最后修改时间却没有变化的情况,就会影响协商缓存的可靠性。所以就有了另外一对header来管理协商缓存,这对header就是【ETag、If-None-Match】

    ETag和If-None-Match

    浏览器第一次跟服务器请求一个资源,会在respone的header加上ETag响应头,这是服务器根据当前请求的资源生成的一个唯一标识,只要资源有变化这个串就不同,只要资源有变化这个串就不同,跟最后修改时间没有关系,所以能很好的补充Last-Modified的问题

    浏览器再次跟服务器请求这个资源时,在request的header上加上If-None-Match的header,这个header的值就是上一次请求时返回的ETag的值。

    服务器再次收到资源请求时,根据浏览器传过来If-None-Match和然后再根据资源生成一个新的ETag,如果这两个值相同就说明资源没有变化,否则就是有变化;如果没有变化则返回304 Not Modified,但是不会返回资源内容;如果有变化,就正常返回资源内容。与Last-Modified不一样的是,当服务器返回304 Not Modified的响应时,由于ETag重新生成过,response header中还会把这个ETag返回,即使这个ETag跟之前的没有变化

    缓存管理

    协商缓存需要配合强缓存使用,你看前面这个截图中,除了Last-Modified这个header,还有强缓存的相关header,因为如果不启用强缓存的话,协商缓存根本没有意义。

    如果资源已经被浏览器缓存下来,在缓存失效之前,再次请求时,默认会先检查是否命中强缓存,如果强缓存命中则直接读取缓存,如果强缓存没有命中则发请求到服务器检查是否命中协商缓存,如果协商缓存命中,则告诉浏览器还是可以从缓存读取,否则才从服务器返回最新的资源。这是默认的处理方式,这个方式可能被浏览器的行为改变:

    • 当win上ctrl+f5、mac上command+shift+R来强制刷新网页时,直接从服务器加载,跳过强缓存和协商缓存;

    参考

    浏览器缓存知识小结及应用

  • 相关阅读:
    Python 多线程,文件io
    Python map/reduce函数式编程
    LeetCode 77 组合
    LeetCode 198 打家劫舍
    LeetCode 138 复制带随机指针的链表
    LeetCode 445 两数相加 II
    LeetCode 2 两数相加
    LeetCode 215 数组中的第K个最大元素
    和为S的两个数字
    数组中重复的数字
  • 原文地址:https://www.cnblogs.com/everlose/p/12779864.html
Copyright © 2020-2023  润新知