浏览器缓存浅析

by admin on 2019年10月8日

浏览器缓存机制浅析

2015/08/05 · HTML5 · 1
评论 ·
缓存

本文作者: 伯乐在线 –
韩子迟
。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

非HTTP协议定义的缓存机制

  浏览器缓存机制,其实主要就是HTTP协议定义的缓存机制(如: Expires;
Cache-control等)。但是也有非HTTP协议定义的缓存机制,如使用HTML Meta
标签,Web开发者可以在HTML页面的<head>节点中加入<meta>标签,代码如下:

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

  上述代码的作用是告诉浏览器当前页面不被缓存,每次访问都需要去服务器拉取。使用上很简单,但只有部分浏览器可以支持,而且所有缓存代理服务器都不支持,因为代理不解析HTML内容本身。下面主要介绍HTTP协议定义的缓存机制

前瞻

做前端开发有一个很头疼的事:缓存。缓存问题在移动端尤其严重,要想清缓存,不能像PC端使用强制刷新,需要手动清APP缓存等操作。对于缓存问题,我一直以来有点模棱两可,总想找时间好好梳理一下。

一者,前几天项目出了一个生产问题,关于版本控制,因为少加了一个随机数导致APP在IOS系统上登录后无法回调到模块页面。

二者,早上起床,看到微信订阅号推送一篇关于面试中遇到缓存问题被问倒的文章。

终于这两者促使我查阅并整理关于浏览器缓存问题的理解。

非HTTP协议定义的缓存机制

浏览器缓存机制,其实主要就是HTTP协议定义的缓存机制(如: Expires;
Cache-control等)。但是也有非HTTP协议定义的缓存机制,如使用HTML Meta
标签,Web开发者可以在HTML页面的<head>节点中加入<meta>标签,代码如下:

XHTML

<META HTTP-EQUIV=”Pragma” CONTENT=”no-cache”>

1
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

上述代码的作用是告诉浏览器当前页面不被缓存,每次访问都需要去服务器拉取。使用上很简单,但只有部分浏览器可以支持,而且所有缓存代理服务器都不支持,因为代理不解析HTML内容本身。下面主要介绍HTTP协议定义的缓存机制

大话浏览器缓存

  浏览器缓存一直是一个让人又爱又恨的存在,一方面极大地提升了用户体验,而另一方面有时会因为读取了缓存而展示了“错误”的东西,而在开发过程中千方百计地想把缓存禁掉。如果没听说过浏览器缓存或者不知道浏览器缓存的用处,可以先浏览一下这篇文章->Web缓存的作用与类型。

  那么浏览器缓存机制到底是如何工作的呢?核心就是把缓存的内容保存在了本地,而不用每次都向服务端发送相同的请求,设想下每次都打开相同的页面,而在第一次打开的同时,将下载的js、css、图片等“保存”在了本地,而之后的请求每次都在本地读取,效率是不是高了很多?真正的浏览器工作的时候并不是将完整的内容保存在本地,各种浏览器都有不同的方式,譬如firefox是一种类似innodb的方式存储的key
value 的模式,在地址栏中输入 about:cache
可以看见缓存的文件,chrome会把缓存的文件保存在一个叫User
Data的文件夹下。但是如果每次都读取缓存也会存在一定的问题,如果服务端的文件更新了呢?这时服务端就会和客户端约定一个有效期,譬如说服务端告诉客户端1天内我服务端的文件不会更新,你就放心地读取缓存吧,于是在这一天里每次遇到相同的请求客户端都开心地可以读取缓存里的文件。但是如果一天过去了,客户端又要读取该文件了,发现和服务端约定的有效期过了,于是就会向服务端发送请求,试图下载一个新的文件,但是很有可能服务端的文件其实并没有更新,其实还是可以读取缓存的。这时该怎么判断服务端的文件有没有更新呢?有两种方式,第一种在上一次服务端告诉客户端约定的有效期的同时,告诉客户端该文件最后修改的时间,当再次试图从服务端下载该文件的时候,check下该文件有没有更新(对比最后修改时间),如果没有,则读取缓存;第二种方式是在上一次服务端告诉客户端约定有效期的同时,同时告诉客户端该文件的版本号,当服务端文件更新的时候,改变版本号,再次发送请求的时候check一下版本号是否一致就行了,如一致,则可直接读取缓存。

  而事实上真正的浏览器缓存机制大抵也是如此,接下来就可以分别对号入座了。

  需要注意的是,浏览器会在第一次请求完服务器后得到响应,我们可以在服务器中设置这些响应,从而达到在以后的请求中尽量减少甚至不从服务器获取资源的目的。浏览器是依靠请求和响应中的的头信息来控制缓存的

浏览器缓存

浏览器缓存的优点有:

  1. 减少冗余的数据传输,节省了流量
  2. 减少了服务器的负担,大大提升了网站的性能
  3. 加快了客户端加载网页的速度

浏览器缓存主要有两类:缓存协商和强制缓存

第一次访问服务器并且获取资源后,客户端会根据返回的信息来确定如何缓存资源,可能采用强缓存,也可能采用协商缓存,这都需要根据响应的header内容来决定的。

  1. 强缓存:不会向服务器发送请求,直接从缓存中读取资源,在控制台的network中可以看到该请求返回200的状态码,并且可以看到有些size是from
    disk,直接从本地获取。
  2. 协商缓存:向服务器发送请求,服务器会根据这个请求头中的参数(后续会详细讲解)来判断是否命中了协商缓存,如果命中了,则返回304状态码并带回新的参数通知浏览器从缓存中读取资源。

两个区别在于:都从客户端获取资源,强缓存不会发送请求,协商缓存会发请求。

大话浏览器缓存

浏览器缓存一直是一个让人又爱又恨的存在,一方面极大地提升了用户体验,而另一方面有时会因为读取了缓存而展示了“错误”的东西,而在开发过程中千方百计地想把缓存禁掉。如果没听说过浏览器缓存或者不知道浏览器缓存的用处,可以先浏览一下这篇文章->Web缓存的作用与类型 。

那么浏览器缓存机制到底是如何工作的呢?核心就是把缓存的内容保存在了本地,而不用每次都向服务端发送相同的请求,设想下每次都打开相同的页面,而在第一次打开的同时,将下载的js、css、图片等“保存”在了本地,而之后的请求每次都在本地读取,效率是不是高了很多?真正的浏览器工作的时候并不是将完整的内容保存在本地,各种浏览器都有不同的方式,譬如firefox是一种类似innodb的方式存储的key
value 的模式,在地址栏中输入 about:cache
可以看见缓存的文件,chrome会把缓存的文件保存在一个叫User
Data的文件夹下。但是如果每次都读取缓存也会存在一定的问题,如果服务端的文件更新了呢?这时服务端就会和客户端约定一个有效期,譬如说服务端告诉客户端1天内我服务端的文件不会更新,你就放心地读取缓存吧,于是在这一天里每次遇到相同的请求客户端都开心地可以读取缓存里的文件。但是如果一天过去了,客户端又要读取该文件了,发现和服务端约定的有效期过了,于是就会向服务端发送请求,试图下载一个新的文件,但是很有可能服务端的文件其实并没有更新,其实还是可以读取缓存的。这时该怎么判断服务端的文件有没有更新呢?有两种方式,第一种在上一次服务端告诉客户端约定的有效期的同时,告诉客户端该文件最后修改的时间,当再次试图从服务端下载该文件的时候,check下该文件有没有更新(对比最后修改时间),如果没有,则读取缓存;第二种方式是在上一次服务端告诉客户端约定有效期的同时,同时告诉客户端该文件的版本号,当服务端文件更新的时候,改变版本号,再次发送请求的时候check一下版本号是否一致就行了,如一致,则可直接读取缓存。

而事实上真正的浏览器缓存机制大抵也是如此,接下来就可以分别对号入座了。

需要注意的是,浏览器会在第一次请求完服务器后得到响应,我们可以在服务器中设置这些响应,从而达到在以后的请求中尽量减少甚至不从服务器获取资源的目的。浏览器是依靠请求和响应中的的头信息来控制缓存的

Expires与Cache-Control

  Expires和Cache-Control就是服务端用来约定和客户端的有效时间的。

  图片 1

  比如如上一个响应头,Expires规定了缓存失效时间(Date为当前时间),而Cache-Control的max-age规定了缓存有效时间(2552s),理论上这两个值计算出的有效时间应该是相同的(上图好像不一致)。Expires是HTTP1.0的东西,而Cache-Control是HTTP1.1的,规定如果max-age和Expires同时存在,前者优先级高于后者。Cache-Control的参数可以设置很多值,譬如(参考浏览器缓存机制):

图片 2

强制缓存

浏览器在请求某资源时,会先获取该资源缓存的header信息,判断是否命中强缓存(cache-control和expires信息),若命中直接从缓存中获取资源信息。

  1. exprires,这是http1.0时的规范;它的值是一个绝对时间GMT格式的时间字符串,也就是说告诉浏览器强缓存最终失效的时间点。如果在这个时间点前,都会从本地缓存中获取,否则就会发送请求到服务器获取新资源。
  2. cache-control:max-age=number
    ,这是http1.1时出现的规范;max-age的值是一个相对值,告诉浏览器一段时间内请求会命中强制缓存。cache-control除了该字段外,还有下面几个比较常用的设置值:

    1. no-cache:不使用本地缓存。需要使用缓存协商,先与服务器确认返回的响应是否被更改,如果之前的响应中存在ETag,那么请求的时候会与服务端验证,如果资源未被更改,则可以避免重新下载。
    2. no-store:直接禁止游览器缓存数据,每次用户请求该资源,都会向服务器发送一个请求,每次都会下载完整的资源。
    3. public:可以被所有的用户缓存,包括终端用户和CDN等中间代理服务器。
    4. private:只能被终端用户的浏览器缓存,不允许CDN等中继缓存服务器对其缓存。

最佳实践:一般来说,图片、js、css等静态资源会添加强制缓存,并且给适当的过期时间,比如一个月。如果有版本更改,可以给文件名后添加随机数或者hash,当这个参数变化的时候,强缓存都会失效并重新加载。

注意:如果cache-control与expires同时存在的话,cache-control的优先级高于expires

Expires与Cache-Control

Expires和Cache-Control就是服务端用来约定和客户端的有效时间的。

图片 3

比如如上一个响应头,Expires规定了缓存失效时间(Date为当前时间),而Cache-Control的max-age规定了缓存有效时间(2552s),理论上这两个值计算出的有效时间应该是相同的(上图好像不一致)。Expires是HTTP1.0的东西,而Cache-Control是HTTP1.1的,规定如果max-age和Expires同时存在,前者优先级高于后者。Cache-Control的参数可以设置很多值,譬如(参考浏览器缓存机制):

图片 4

Last-Modified/If-Modified-Since

  而Last-Modified/If-Modified-Since就是上面说的当有效期过后,check服务端文件是否更新的第一种方式,要配合Cache-Control使用。比如第一次访问我的主页simplify
the
life,会请求一个jquery文件,响应头返回如下信息:

图片 5

  然后我在主页按下ctrl+r刷新,因为ctrl+r会默认跳过max-age和Expires的检验直接去向服务器发送请求(下文再探讨各种刷新后如何读取缓存),我们看看请求截图:

图片 6

  请求头中包含了If-Modified-Since项,而它的值和上次请求响应头中的Last-Modified一致,我们发现这个日期是在遥远的2013年,也就是说这个jquery文件自从2013年的那个日期后就没有再被修改过了。将If-Modified-Since的日期和服务端该文件的最后修改日期对比,如果相同,则响应HTTP304,从缓存读数据;如果不相同文件更新了,HTTP200,返回数据,同时通过响应头更新last-Modified的值(以备下次对比)。

协商缓存

浏览器在请求某资源时,如果没有命中强制缓存,浏览器会发送请求到服务器,此请求会携带参数(If-Modified-Since和If-None-Match),这里的参数是根据第一次请求返回的有关缓存的header字段信息(Last-Modified和Etag)来匹配的。由服务器根据请求中的相关header信息来比对结果是否协商缓存命中;若命中,则服务器返回新的响应header信息更新缓存中的对应header信息,但是并不返回资源内容,浏览器会直接从缓存获取;否则返回新的响应header信息以及最新的资源内容。

  1. Etag:web服务器响应请求时,告诉浏览器当前资源在服务器的唯一标识(生成规则由服务器决定)。

  2. If-None-Match:当资源过期时(使用Cache-Control标识的max-age),发现资源具有Etage声明,则再次向web服务器请求时带上头If-None-Match
    (Etag的值)。web服务器收到请求后发现有头If-None-Match
    则与被请求资源的相应校验串进行比对,决定是否命中协商缓存;

ETag和Last-Modified的作用和用法,他们的区别:

1.Etag要优于Last-Modified。Last-Modified的时间单位是秒,如果某个文件在1秒内改变了多次,那么他们的Last-Modified其实并没有体现出来修改,但是Etag每次都会改变确保了精度;
2.在性能上,Etag要逊于Last-Modified,毕竟Last-Modified只需要记录时间,而Etag需要服务器通过算法来计算出一个hash值;
3.在优先级上,服务器校验优先考虑Etag。

Last-Modified/If-Modified-Since

而Last-Modified/If-Modified-Since就是上面说的当有效期过后,check服务端文件是否更新的第一种方式,要配合Cache-Control使用。比如第一次访问我的主页simplify
the
life,会请求一个jquery文件,响应头返回如下信息:

图片 7

然后我在主页按下ctrl+r刷新,因为ctrl+r会默认跳过max-age和Expires的检验直接去向服务器发送请求(下文再探讨各种刷新后如何读取缓存),我们看看请求截图:

图片 8

请求头中包含了If-Modified-Since项,而它的值和上次请求响应头中的Last-Modified一致,我们发现这个日期是在遥远的2013年,也就是说这个jquery文件自从2013年的那个日期后就没有再被修改过了。将If-Modified-Since的日期和服务端该文件的最后修改日期对比,如果相同,则响应HTTP304,从缓存读数据;如果不相同文件更新了,HTTP200,返回数据,同时通过响应头更新last-Modified的值(以备下次对比)。

ETag/If-None-Match

  而ETag/If-None-Match则是上文大话中说的第二种check服务端文件是否更新的方式,也要配合Cache-Control使用。实际上ETag并不是文件的版本号,而是一串可以代表该文件唯一的字符串(Apache中,ETag的值,默认是对文件的索引节(INode),大小(Size)和最后修改时间(MTime)进行Hash后得到的。),当客户端发现和服务器约定的直接读取缓存的时间过了,就在请求中发送If-None-Match选项,值即为上次请求后响应头的ETag值,该值在服务端和服务端代表该文件唯一的字符串对比(如果服务端该文件改变了,该值就会变),如果相同,则相应HTTP304,客户端直接读取缓存,如果不相同,HTTP200,下载正确的数据,更新ETag值。

图片 9

  看如上截图,与服务器约定的直接读取本地缓存的时间过了,就会向服务器发送新的请求,请求头中带If-None-Match项,该字符串值会在服务端进行匹配,很显然,并没有什么变化(看响应头的ETag值),于是响应HTTP304,直接读取缓存。或许你会发送该请求也有If-Modified-Since项,如果两者同时存在,If-None-Match优先,忽略If-Modified-Since。或许你会问为什么它优先?两者功能相似甚至相同,为什么要同时存在?HTTP1.1中ETag的出现主要是为了解决几个Last-Modified比较难解决的问题:

  1. Last-Modified标注的最后修改只能精确到秒级,如果某些文件在1秒钟以内,被修改多次的话,它将不能准确标注文件的修改时间
  2. 如果某些文件会被定期生成,但有时内容并没有任何变化(仅仅改变了时间),但Last-Modified却改变了,导致文件没法使用缓存
  3. 有可能存在服务器没有准确获取文件修改时间,或者与代理服务器时间不一致等情形

缓存过程

  • 浏览器第一次加载资源,服务器返回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。

网上流传的关于浏览器缓存的两幅图如下:

浏览器第一次请求时:

图片 10

img

浏览器后续再进行请求时:

图片 11

img

ETag/If-None-Match

而ETag/If-None-Match则是上文大话中说的第二种check服务端文件是否更新的方式,也要配合Cache-Control使用。实际上ETag并不是文件的版本号,而是一串可以代表该文件唯一的字符串(Apache中,ETag的值,默认是对文件的索引节(INode),大小(Size)和最后修改时间(MTime)进行Hash后得到的。),当客户端发现和服务器约定的直接读取缓存的时间过了,就在请求中发送If-None-Match选项,值即为上次请求后响应头的ETag值,该值在服务端和服务端代表该文件唯一的字符串对比(如果服务端该文件改变了,该值就会变),如果相同,则相应HTTP304,客户端直接读取缓存,如果不相同,HTTP200,下载正确的数据,更新ETag值。

图片 12

看如上截图,与服务器约定的直接读取本地缓存的时间过了,就会向服务器发送新的请求,请求头中带If-None-Match项,该字符串值会在服务端进行匹配,很显然,并没有什么变化(看响应头的ETag值),于是响应HTTP304,直接读取缓存。或许你会发送该请求也有If-Modified-Since项,如果两者同时存在,If-None-Match优先,忽略If-Modified-Since。或许你会问为什么它优先?两者功能相似甚至相同,为什么要同时存在?HTTP1.1中ETag的出现主要是为了解决几个Last-Modified比较难解决的问题:

  1.  Last-Modified标注的最后修改只能精确到秒级,如果某些文件在1秒钟以内,被修改多次的话,它将不能准确标注文件的修改时间
  2. 如果某些文件会被定期生成,但有时内容并没有任何变化(仅仅改变了时间),但Last-Modified却改变了,导致文件没法使用缓存
  3. 有可能存在服务器没有准确获取文件修改时间,或者与代理服务器时间不一致等情形

不能缓存的请求

  当然并不是所有请求都能被缓存。

  无法被浏览器缓存的请求:

  1. HTTP信息头中包含Cache-Control:no-cache,pragma:no-cache(HTTP1.0),或Cache-Control:max-age=0等告诉浏览器不用缓存的请求
  2. 需要根据Cookie,认证信息等决定输入内容的动态请求是不能被缓存的
  3. 经过HTTPS安全加密的请求(有人也经过测试发现,ie其实在头部加入Cache-Control:max-age信息,firefox在头部加入Cache-Control:Public之后,能够对HTTPS的资源进行缓存,参考《HTTPS的七个误解》)
  4. POST请求无法被缓存
  5. HTTP响应头中不包含Last-Modified/Etag,也不包含Cache-Control/Expires的请求无法被缓存

参考文档

1.
浏览器缓存机制浅析

2.
浏览器的协商缓存与强缓存

3.
http协商缓存VS强缓存

不能缓存的请求

当然并不是所有请求都能被缓存。

无法被浏览器缓存的请求:

  1. HTTP信息头中包含Cache-Control:no-cache,pragma:no-cache(HTTP1.0),或Cache-Control:max-age=0等告诉浏览器不用缓存的请求
  2. 需要根据Cookie,认证信息等决定输入内容的动态请求是不能被缓存的
  3. 经过HTTPS安全加密的请求(有人也经过测试发现,ie其实在头部加入Cache-Control:max-age信息,firefox在头部加入Cache-Control:Public之后,能够对HTTPS的资源进行缓存,参考《HTTPS的七个误解》)
  4. POST请求无法被缓存
  5. HTTP响应头中不包含Last-Modified/Etag,也不包含Cache-Control/Expires的请求无法被缓存

用户行为与缓存

  浏览器缓存过程还和用户行为有关,譬如上面提到的,打开我的主页simplify
the
life,有个jquery的请求,如果直接在地址栏按回车,响应HTTP200(from
cache),因为有效期还没过直接读取的缓存;如果ctrl+r进行刷新,则会相应HTTP304(Not
Modified),虽然还是读取的本地缓存,但是多了一次服务端的请求;而如果是ctrl+shift+r强刷,则会直接从服务器下载新的文件,响应HTTP200。

图片 13

  通过上表我们可以看到,当用户在按F5进行刷新的时候,会忽略Expires/Cache-Control的设置,会再次发送请求去服务器请求,而Last-Modified/Etag还是有效的,服务器会根据情况判断返回304还是200;而当用户使用Ctrl+F5进行强制刷新的时候,只是所有的缓存机制都将失效,重新从服务器拉去资源。

  更多可以参考浏览器缓存机制

用户行为与缓存

浏览器缓存过程还和用户行为有关,譬如上面提到的,打开我的主页simplify
the
life,有个jquery的请求,如果直接在地址栏按回车,响应HTTP200(from
cache),因为有效期还没过直接读取的缓存;如果ctrl+r进行刷新,则会相应HTTP304(Not
Modified),虽然还是读取的本地缓存,但是多了一次服务端的请求;而如果是ctrl+shift+r强刷,则会直接从服务器下载新的文件,响应HTTP200。

图片 14

通过上表我们可以看到,当用户在按F5进行刷新的时候,会忽略Expires/Cache-Control的设置,会再次发送请求去服务器请求,而Last-Modified/Etag还是有效的,服务器会根据情况判断返回304还是200;而当用户使用Ctrl+F5进行强制刷新的时候,只是所有的缓存机制都将失效,重新从服务器拉去资源。

更多可以参考浏览器缓存机制

总结

  盗图浏览器缓存机制,两张图很清晰

图片 15

 

 

图片 16

总结

盗图浏览器缓存机制,两张图很清晰

图片 17

 

 

图片 18

参考

  1. 再记:浏览器缓存200(from
    cache)和304小结
  2. 【Web缓存机制系列】2 –
    Web浏览器的缓存机制
  3. 浏览器缓存机制-吴秦
  4. 浏览器缓存机制
  5. 初探 HTTP 1.1 Cache
    機制

 

 

参考

  1.  再记:浏览器缓存200(from
    cache)和304小结
  2. 【Web缓存机制系列】2 –
    Web浏览器的缓存机制 
  3. 浏览器缓存机制-吴秦
  4. 浏览器缓存机制
  5. 初探 HTTP 1.1 Cache
    機制

打赏支持我写出更多好文章,谢谢!

打赏作者

打赏支持我写出更多好文章,谢谢!

图片 19

2 赞 9 收藏 1
评论

关于作者:韩子迟

图片 20

a JavaScript beginner
个人主页 ·
我的文章 ·
9 ·
   

图片 21

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图