新闻型网站建设,找网络公司建网站每年收维护费,连锁店进销存软件,网站项目报价缓存的基本原理
对于前端来说#xff0c;缓存主要分为浏览器缓存#xff08;比如 localStorage、sessionStorage、cookie等等#xff09;以及http缓存#xff0c;也是本文主要讲述的。
当然叫法也不一样#xff0c;比如客户端缓存大概包括浏览器缓存和http缓存
所谓htt…缓存的基本原理
对于前端来说缓存主要分为浏览器缓存比如 localStorage、sessionStorage、cookie等等以及http缓存也是本文主要讲述的。
当然叫法也不一样比如客户端缓存大概包括浏览器缓存和http缓存
所谓http缓存顾名思义是将某一次的响应结果保存在客户端比如浏览器中而后续的请求仅需要从缓存中读取即可极大的降低了服务器的处理压力。
http缓存的原理如下 这只是一个简易的原理图实际情况可能有差异 这里就设计到一个缓存策略的问题这些问题包括
哪些资源需要加入到缓存哪些不需要缓存的时间是多久呢如果服务器的资源有改动客户端如何更新缓存呢如果缓存过期了可是服务器上的资源并没有发生变动又该如何处理呢…
要回答这些问题就必须要清楚http中关于缓存的协议
理解了http的缓存协议自然就能回答上面的问题了。
来自服务器的缓存指令
当客户端发出一个get请求到服务器服务器可能有以下的内心活动「你请求的这个资源我很少会改动它干脆你把它缓存起来吧以后就不要来烦我了」
为了表达这个美好的愿望服务器在响应头中加入了以下内容
Cache-Control: max-age3600
ETag: W/121-171ca289ebf
Date: Thu, 30 Apr 2020 12:39:56 GMT
Last-Modified: Thu, 30 Apr 2020 08:16:31 GMT这个响应头表达了下面的信息
Cache-Control: max-age3600我希望你把这个资源缓存起来缓存时间是3600秒1小时ETag: W/121-171ca289ebf这个资源的编号是W/121-171ca289ebfDate: Thu, 30 Apr 2020 12:39:56 GMT我给你响应这个资源的服务器时间是格林威治时间2020-04-30 12:39:56Last-Modified: Thu, 30 Apr 2020 08:16:31 GMT这个资源的上一次修改时间是格林威治时间2020-04-30 08:16:31
这个美好的缓存愿望就这样通过响应头传递给客户端了
如果客户端是其他应用程序可能并不会理会服务器的愿望也就是说可能根本不会缓存任何东西。
但是凑巧客户端是一个浏览器它和服务器一直以来都是相亲相爱的小伙伴当它看到服务器的这个响应头表达的美好愿望后立即忙起来
浏览器把这次请求得到的响应体缓存到本地文件中浏览器标记这次请求的请求方法和请求路径浏览器标记这次缓存的时间是3600秒浏览器记录服务器的响应时间是格林威治时间2020-04-30 12:39:56浏览器记录服务器给予的资源编号W/121-171ca289ebf浏览器记录资源的上一次修改时间是格林威治时间2020-04-30 08:16:31
这一次的记录非常重要它为以后浏览器要不要去请求服务器提供了各种依据。 来自客户端的缓存指令
当客户端收拾好行李准备再次请求GET /index.js时它突然想起了一件事我需要的东西在不在缓存里呢
此时客户端会到缓存中去寻找是否有缓存的资源
寻找的过程如下
缓存中是否有匹配的请求方法和路径如果有该缓存资源是否还有效呢
以上两个验证会导致浏览器产生不同的行为 要验证是否有匹配的缓存非常简单只需要验证当前的请求方法GET和当前的请求路径/index.js是否有对应的缓存存在即可
如果没有就直接请求服务器就和第一次请求服务器时一样这种情况没有什么好讨论的
关键在于验证缓存是否有效
如何验证呢
非常简单就是把max-age Date得到一个过期时间看看这个过期时间是否大于当前时间如果是则表示缓存还没有过期仍然有效如果不是则表示缓存失效。
缓存有效
当浏览器发现缓存有效时完全不会请求服务器直接使用缓存即可得到结果
此时如果你断开网络会发现资源仍然可用
这种情况会极大的降低服务器压力但当服务器更改了资源后浏览器是不知道的只要缓存有效它就会直接使用缓存
缓存无效
当浏览器发现缓存已经过期它并不会简单的把缓存删除而是抱着一丝希望想问问服务器我这个缓存还能继续使用吗
于是浏览器向服务器发出了一个带缓存的请求
所谓带缓存的请求无非就是加入了以下的请求头
If-Modified-Since: Thu, 30 Apr 2020 08:16:31 GMT
If-None-Match: W/121-171ca289ebf它们表达了下面的信息
If-Modified-Since: Thu, 30 Apr 2020 08:16:31 GMT亲你曾经告诉我这个资源的上一次修改时间是格林威治时间2020-04-30 08:16:31请问这个资源在这个时间之后有发生变动吗If-None-Match: W/121-171ca289ebf亲你曾经告诉我这个资源的编号是W/121-171ca289ebf请问这个资源的编号发生变动了吗
其实这两个问题可以合并为一个问题快说资源到底变了没有
之所以要发两个信息是为了兼容不同的服务器因为有些服务器只认If-Modified-Since有些服务器只认If-None-Match有些服务器两个都认 目前的很多服务器只要发现If-None-Match存在就不会去看If-Modified-Since If-Modified-Since是http1.0版本的规范If-None-Match是http1.1的规范 此时问题又抛给了服务器接下来就是服务器的表演时间了
服务器可能会产生两个情况
缓存已经失效缓存仍然有效
如果是第一种情况——缓存已经失效那么非常简单服务器再次给予一个正常的响应响应码200 带响应体同时可以附带上新的缓存指令这就回到了上一节——来自服务器的缓存指令
这样一来客户端就会重新缓存新的内容
但如果服务器觉得缓存仍然有效它可以通过一种极其简单的方式告诉客户端
响应码为304 Not Modified无响应体响应头带上新的缓存指令见上一节——来自服务器的缓存指令
这样一来就相当于告诉客户端「你的缓存资源仍然可用我给你一个新的缓存时间你那边更新一下就可以了」
于是客户端就继续happy的使用缓存了
这样一来可以最大程度的减少网络传输因为如果资源还有效服务器就不会传输消息体
它们完整的交互过程如下 细节
上面描述了客户端缓存的基本概念和过程
但其中仍然有不少细节值得我们注意
Cache-Control
在上述的讲解中Cache-Control是服务器向客户端响应的一个消息头它提供了一个max-age用于指定缓存时间。
实际上Cache-Control还可以设置下面一个或多个值
public指示服务器资源是公开的。比如有一个页面资源所有人看到的都是一样的。这个值对于浏览器而言没有什么意义但可能在某些场景可能有用。本着「我告知你随意」的原则http协议中很多时候都是客户端或服务器告诉另一端详细的信息至于另一端用不用完全看它自己。private指示服务器资源是私有的。比如有一个页面资源每个用户看到的都不一样。这个值对于浏览器而言没有什么意义但可能在某些场景可能有用。本着「我告知你随意」的原则http协议中很多时候都是客户端或服务器告诉另一端详细的信息至于另一端用不用完全看它自己。no-cache告知客户端你可以缓存这个资源但是不要直接使用它。当你缓存之后后续的每一次请求都需要附带缓存指令让服务器告诉你这个资源有没有过期。见「来自客户端的缓存指令 - 缓存无效」no-store告知客户端不要对这个资源做任何的缓存之后的每一次请求都按照正常的普通请求进行。若设置了这个值浏览器将不会对该资源做出任何的缓存处理。max-age不再赘述
比如Cache-Control: public, max-age3600表示这是一个公开资源请缓存1个小时。
Expire
在http1.0版本中是通过Expire响应头来指定过期时间点的例如
Expire: Thu, 30 Apr 2020 23:38:38 GMT到了http1.1版本已更改为通过Cache-Control的max-age来记录了。
记录缓存时的有效期
浏览器会按照服务器响应头的要求自动记录缓存到本地文件并设置各种相关信息
在这些信息中有效期尤为关键它决定了这个缓存可以使用多久
浏览器会根据服务器不同的响应情况设置不同的有效期
具体的有效期设置按照下面的流程进行 例如当max-age设置为0时缓存立即过期
虽然立即过期但缓存仍然被记录下来后续的请求通过缓存指令发送到服务器来确认资源是否被更改。
因此Cache-Control: max-age0类似于Cache-Control: no-cache
Pragma
这是http1.0版本的消息头
当该消息头出现在请求中时是向服务器表达不要考虑任何缓存给我一个正常的结果。
在http1.1版本中可以在请求头中加入Cache-Control: no-cache实现同样的含义。 是的Cache-Control可以出现在请求头中 在Chrome浏览器中调试时如果勾选了Disable cache则发送的请求中会附带该信息 Vary
有的时候是否有缓存不仅仅是判断请求方法和请求路径是否匹配可能还要判断头部信息是否匹配。
此时就可以使用Vary字段来指定要区分的消息头
比如当使用GET /personal.html请求服务器时请求头中cookie的值不一样得到的页面也不一样
如果还按照之前的做法仅仅匹配请求方法和请求路径如果cookie变动你可能得到的仍然是之前的页面。
正确的做法如下 使用版本号或hash
如果你是一个前端工程师使用过vue或其他基于webpack搭建的工程
你会发现打包的结果中很多文件名类似于这样
app.68297cd8.css文件的中间部分使用了hash值
这样做的好处是可以让客户端大胆的、长时间的缓存该文件减轻服务器的压力
当文件改动后它的文件hash值也会随之而变比如变成了app.446fccb8.css
这样一来客户端要请求新的文件时就会发现路径从/app.68297cd8.css变成了app.446fccb8.css由于之前的缓存路径无法匹配到因此就会发送新的请求来获取新资源了。
以上是现代流行的做法。
而在古老的年代还没有构建工具出现时人们使用的办法是在资源路径后面加入版本号来获取新版本的文件
比如页面中引入了一个css资源app.css它可能的引入方式是
link href/app.css?v1.0.0这样一来缓存的路径是/app.css?v1.0.0
当服务器的版本发生变化时可以给予新的版本号让html中的路径发生变动
link href/app.css?v1.0.1由于新的路径无法命中缓存于是浏览器就会发送新的普通请求来获取这个资源
总结
最后通过客户端和服务器两位大佬的视角来总结一下以上内容
服务器视角
服务器无法知道客户端到底有没有像浏览器那样缓存文件它只管根据请求的情况来决定如何响应 很多后端语言搭建的服务器都会自带自己的默认缓存规则当然也支持不同程度的修改
浏览器视角
浏览器在发出请求时会判断要不要使用缓存 当收到服务器响应时会自动根据缓存指令进行处理
