浏览器缓存机制

拼搏现实的明天。 2021-09-18 06:26 380阅读 0赞

### 浏览器缓存机制 ###

--------------------

#### **一、浏览器缓存类型** ####

*  1.强缓存：**不会向服务器发送请求，直接从缓存中读取资源**，在chrome控制台的network选项中可以看到该请求返回**200的状态码**，并且**size显示from disk cache或from memory cache**；
 *  2.协商缓存：向服务器发送请求，服务器会根据这个请求的request header的一些参数来判断是否命中协商缓存，如果**命中**，则**返回304状态码**并带上新的response header通知浏览器从缓存中读取资源；
 *  两者的共同点：都是从客户端缓存中读取资源；区别是强缓存不会发请求，协商缓存会发请求

#### **二、缓存有关的header**（请求头） ####

*  ##### **强缓存** #####
    
     *  **Expires**：response header里的过期时间，浏览器再次加载资源时，如果在这个过期时间内，则命中强缓存。  
        ![在这里插入图片描述][20210402155842585.png_pic_center]
     *  **Cache-Control**：当值设为max-age=300时，则代表在这个请求正确返回时间（浏览器也会记录下来）的5分钟内再次加载资源，就会命中强缓存。
     *  **Expires和Cache-Control区别**：
        
         *  max-age=\*\*\* 的作用是差不多的，区别就在于 Expires 是http1.0的产物，Cache-Control是http1.1的产物，两者同时存在的话，Cache-Control优先级高于Expires；在某些不支持HTTP1.1的环境下，Expires就会发挥用处。所以Expires其实是过时的产物，现阶段它的存在只是一种兼容性的写法
         *  编辑补充：Expires和Cache-Control的区别还有一个：Expires是一个具体的服务器时间，这就导致一个问题，如果客户端时间和服务器时间相差较大，缓存命中与否就不是开发者所期望的。Cache-Control是一个时间段，控制就比较容易。）
 *  ##### **协商缓存** #####
 *  **Tag和If-None-Match**：这两个要一起说。Etag是上一次加载资源时，服务器返回的response header，是对该资源的一种唯一标识，只要资源有变化，Etag就会重新生成。浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到request header里的If-None-Match里，服务器接受到If-None-Match的值后，会拿来跟该资源文件的Etag值做比较，如果相同，则表示资源文件没有发生改变，命中协商缓存。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyNTM4OQ_size_16_color_FFFFFF_t_70_pic_center]
 *  **Last-Modified和If-Modified-Since区别**：这两个也要一起说。Last-Modified是该资源文件最后一次更改时间，**服务器会在response header里返回**，同时浏览器会将这个值保存起来，在下一次发送请求时，放到request header里的If-Modified-Since里，服务器在接收到后也会做比对，如果相同则命中协商缓存。
    
    请求头：  
    ![在这里插入图片描述][20210402160610364.png_pic_center]
 *  **ETag和Last-Modified**的作用和用法也是差不多，说一说他们的**区别**：
    
     *  首先在精确度上，Etag要优于Last-Modified。Last-Modified的时间单位是秒，如果某个文件在1秒内改变了多次，那么他们的Last-Modified其实并没有体现出来修改，但是Etag每次都会改变确保了精度；如果是负载均衡的服务器，各个服务器生成的Last-Modified也有可能不一致。
     *  第二在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。  
        第三在优先级上，服务器校验优先考虑Etag。

#### 三、浏览器缓存过程 ####

*  浏览器第一次加载资源，服务器返回200，浏览器将资源文件从服务器上请求下载下来，并把response header及该请求的返回时间一并缓存；
 *  下一次加载资源时，先比较当前时间和上一次返回200时的时间差，如果没有超过cache-control设置的max-age，则没有过期，命中强缓存，不发请求直接从本地缓存读取该文件（如果浏览器不支持HTTP1.1，则用expires判断是否过期）；如果时间过期，则向服务器发送header带有If-None-Match和If-Modified-Since的请求；
 *  服务器收到请求后，优先根据Etag的值判断被请求的文件有没有做修改，Etag值一致则没有修改，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回200；
 *  如果服务器收到的请求没有Etag值，则将If-Modified-Since和被请求文件的最后修改时间做比对，一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回200；

#### 四、用户行为对浏览器缓存的控制 ####

*  地址栏访问，链接跳转是正常用户行为，将会触发浏览器缓存机制；
 *  F5刷新，浏览器会设置max-age=0，跳过强缓存判断，会进行协商缓存判断；
 *  ctrl+F5刷新，跳过强缓存和协商缓存，直接从服务器拉取资源。

#### 五、缓存的不同来源 ####

*  from disk cache：从磁盘中获取缓存资源，等待下次访问时不需要重新下载资源，而直接从磁盘中获取。它的直接操作对象为CurlCacheManager。
 *  from memory cache：从内存中获取资源，等待下次访问时不需要重新下载资源，而直接从内存中获取。
 *  两者区别：当退出进程时，内存中的数据会被清空，而磁盘的数据不会，所以，当下次再进入该进程时，该进程仍可以从diskCache中获得数据，而memoryCache则不行。

#### 六、不能被缓存的请求 ####

*  当然并不是所有请求都能被缓存。无法被浏览器缓存的请求：
    
     *  HTTP信息头中包含Cache-Control:no-cache，pragma:no-cache（HTTP1.0），
     *  Cache-Control:max-age=0等告诉浏览器不用缓存的请求
     *  需要根据Cookie，认证信息等决定输入内容的动态请求是不能被缓存的
     *  经过HTTPS安全加密的请求
     *  POST请求无法被缓存
     *  HTTP响应头中不包含Last-Modified/Etag，也不包含Cache-Control/Expires的请求无法被缓存

#### 七、设置页面禁止缓存 ####

*  no-cache : 协商缓存
 *  no-store : 不缓存
 *  must-revalidate : 过期强制请求服务器

#### 八、浏览器缓存流程图 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyNTM4OQ_size_16_color_FFFFFF_t_70_pic_center 1]  
[参考][Link 1]

[20210402155842585.png_pic_center]: /images/20210918/c3f0cdc3aa8d4263beed9f4e2e27d8ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyNTM4OQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20210918/66c38f24c82c44cd9d786dae059d61b3.png
[20210402160610364.png_pic_center]: /images/20210918/cf15fed9e6c845ff9024b8d9be56b614.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyNTM4OQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20210918/fc718c8a221d4916bd2eb3102db922e4.png
[Link 1]: https://blog.csdn.net/i13738612458/article/details/80383390?utm_medium=distribute.pc_relevant_t0.none-task-blog-2~default~BlogCommendFromMachineLearnPai2~default-1.control&dist_request_id=&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2~default~BlogCommendFromMachineLearnPai2~default-1.control