标题虽然叫HTTP缓存,但叫浏览器缓存也可以,HTTP算是君子,浏览器算是小人,君子动口定下协议,小人动手实现协议。
先看一下缓存的目的,主要还是基于性能的考虑
整个Web应用可不只有HTTP缓存,还有代理服务器缓存、CDN缓存,另外后端有自己的应用逻辑缓存、数据库缓存等,反正就秉持一个原则, 能利用缓存的就尽量利用缓存 ,用空间换时间。
针对缓存同时还有缓存雪崩、缓存穿透、缓存击穿等概念,这里不展开细述。
不过对于一个前端人员来说,可以把精力主要放在HTTP缓存上,该机制和浏览器狼狈为奸[狗头],提高了Web应用的性能。
先从过去讲起,这里介绍已经过时的用法,有个概念即可
在HTTP1.0里使用的是 Expires 头,现在的一些工具、框架里,比如nginx配置 expires 1d 后,也会自动帮你把这个 Expires 头给带上,但其实当有 Cache-Control 头存在的时候, Expires 是不起作用的。
我们看一个 Expires 头的实际例子
expires: Tue, 14 Dec 2021 10:56:15 GMT
注意两个地方,一个是它使用了绝对时间,另一个是时间的精确度是秒级,那么就存在两个问题,一个是绝对时间可能在操作系统时间修改或者跨时区(服务器在一个时区,浏览器在另一个时区)的情况下出现问题,另一个就是万一秒级的精确度还不够,在一秒内发生资源变化呢?
还有一个遗留的缓存有关的HTTP头是 Pragma ,它只能被设置为 no-cache ,效果和 Cache-Control: no-cache 一样
Pragma: no-cache
别看 Pragma 是一个遗老遗少,但它的优先级比较高,也即是 Pragma > Cache-Control > Expires
由于 Expires 存在之前所述的缺陷,在HTTP1.1的时候又提出了一个新的 Cache-Control 头,用下面这张表显示它可以设置的值,内容出自MDN
缓存资源,但在发布缓存副本之前,强制要求缓存把请求提交给原始服务器进行验证(协商缓存验证) | |
no-store | 缓存不应存储有关客户端请求或服务器响应的任何内容,即不使用任何缓存 |
private | 表明响应只能被单个用户缓存,不能作为共享缓存(即代理服务器不能缓存它)。私有缓存可以缓存响应内容,比如:对应用户的本地浏览器 |
public | 表明响应可以被任何对象(包括:发送请求的客户端,代理服务器,等等)缓存,即使是通常不可缓存的内容。(例如:1.该响应没有max-age指令或Expires消息头;2. 该响应对应的请求方法是 POST ) |
max-age=[seconds] | 设置缓存存储的最大周期,超过这个时间缓存被认为过期(单位秒)。与Expires相反,时间是相对于请求的时间 |
s-maxage=[seconds] | 覆盖max-age或者Expires头,但是仅适用于共享缓存(比如各个代理),私有缓存会忽略它,只适用于供多位用户使用的公共缓存服务器(比如CDN缓存) |
s-maxage=[seconds] | 表明客户端愿意接收一个已经过期的资源。可以设置一个可选的秒数,表示响应不能已经过时超过该给定的时间 |
min-fresh=[seconds] | 表示客户端希望获取一个能在指定的秒数内保持其最新状态的响应 |
must-revalidate | 一旦资源过期(比如已经超过max-age),在成功向原始服务器验证之前,缓存不能用该资源响应后续请求 |
proxy-revalidat | 与must-revalidate作用相同,但它仅适用于共享缓存(例如代理),并被私有缓存忽略 |
no-transform | 不得对资源进行转换或转变。Content-Encoding、Content-Range、Content-Type等HTTP头不能由代理修改 |
only-if-cached | 表明客户端只接受已缓存的响应,并且不要向原始服务器检查是否有更新的拷贝 |
Cache-Control 用在请求里可以指定
Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached
Cache-Control 用在响应里可以指定
Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>
以下是几个典型的设置
禁止缓存
Cache-Control: no-store
Cache-Control: max-age=0 # 当服务器关闭或失去连接时,使用了缓存
缓存
Cache-Control: public, max-age=31536000
需要重新验证
Cache-Control: no-cache
需要重新验证
Cache-Control: max-age=0, must-revalidate
注意以下设置当服务器关闭或失去连接时,会使用缓存
Cache-Control: max-age=0
关于如何选择,我画如下的图,逻辑出自于Google自己的文档
除了 no-store ,其他选项都会缓存资源(但是不是直接使用是另一个问题了,要就是存不存看 no-store ,用不用、怎么用还要取决于其他的设置)。一般情况下,都会用 max-age 来指定资源的缓存时长,在该时长范围内,命中缓存,直接使用本地资源。
缓存后的资源有可能在内存里(from memory cache)也有可能在磁盘(from disk cache)上,通过Chrome的开发者工具里的Network页签能够看出来
浏览器肯定先读取内存再读取磁盘,毕竟内存更快。一般来说css文件由于构建StyleSheet之后就不再使用了,会优先放在磁盘,而JS和图片会优先放在内存。不过缓存资源具体放在哪其实不重要也不用过多纠结,因为一旦命中了缓存,最最耗时的网络请求就不需要发送了,另外放在内存还是放在磁盘这也不是你想控制就能控制得了的。
以上 Expires 和 Cache-Control 判断缓存的方式称为 强缓存 ,强缓存是连HTTP请求都不需要发送的,直接本地闭环。
花开花落花落花开,假如现在超过了 max-age 里所设置的时间,那么是否要完全重新下载资源呢,答案当然是否定了,如果资源的大小有1G,并且没有发生变化,难不成也傻傻的重新下载一遍么?
这个时候就有两对HTTP头来辅助服务端识别资源是否修改
Last-Modified / If-Modified-Since
Last-Modified 是服务器响应返回时,返回该资源文件在服务器最后被修改的时间。
If-Modified-Since 则是浏览器再次发起该资源请求时,携带上次请求返回的Last-Modified值,通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。
last-modified: Sat, 09 Oct 2021 06:42:14 GMT
Etag / If-None-Match
Etag 是服务器响应返回时,返回当前资源文件的一个唯一标识,一般会对资源内容进行Hash计算得到一个Hash编码。
If-None-Match 是客户端再次发起该资源请求时,携带上次请求返回的唯一标识 Etag 值,通过此字段值告诉服务器该资源上次请求返回的唯一标识值。
etag: W/"616139c6-dd4"
注意 Etag / If-None-Match 享有更高的优先级,因为
Expires
Last-Modified
Last-Modified
假设服务器现在判断出了资源并没有修改,那么它就可以直接返回状态码304,而304对应的状态描述就是Not Modified,这就是告诉浏览器,资源没有发生变化,你还继续用原来的就成,当然此时浏览器也会根据响应的HTTP头更新相关的缓存设置;如果服务器发现资源已经发生了变化,那么就跟第一次请求一样,返回状态码200,并且把资源放入到body里返回。
以上两对辅助的HTTP头判断缓存的方式称之为 协商缓存 ,与强缓存相比,它还是要发送一次请求的,只是有可能这个请求的响应比较轻,只带了304的状态码而不用带资源内容。
现在用一个请求流程来看一下缓存使用的过程,假设我需要使用到 /abc.css 这个资源
这里盗一张图吧,懒得自己画了
下表来表示缓存在什么操作下会生效或者失效
操作 | Expires/Cache-Control | Last-Modified/Etag |
---|---|---|
地址栏回车 | 有效 | 有效 |
页面链接跳转 | 有效 | 有效 |
新开窗口 | 有效 | 有效 |
前进后退 | 有效 | 有效 |
F5刷新 | 无效 | 有效 |
Ctrl + F5强制刷新 | 无效 | 无效 |
总结一下,一般的正常操作都会使用到缓存,只是以下两种情况例外
现实中觉得这个协商缓存304也是浪费的,白白耗费一次请求,所以搞起了“消灭304”运动。想办法把识别资源的标志放入到URL中,因为URL就相当于是缓存的key,只要URL有一丁点不一样,缓存就不会生效(这也是为什么在不想使用缓存的时候就会带上一个 ?random= 1234567890 查询字符串)。
之前的做法是放入版本号,比如 abc.v1.css ,不过现在主流的做法是放入资源的hash值,比如 abc.7dfkm6.css ,并且资源会设一个很长的缓存失效期,比如一年。但是要记住,对于SPA应用来说,入口的 html 文件千万不能缓存,因为在 HTML 中引用了各资源文件,它一旦被缓存那么整个应用就得不到更新了,而且还会出错,因为很可能在升版后,原来的资源 abc.7dfkm6.css 已经不存在了。
这里刨去过时的技术,比如 manifest 描述文件来进行离线缓存
一方面是可以写自己业务所需逻辑的缓存,比如使用localStorage、IndexDB、cache storage api(注意它不是只能用在Service Worker里)、File API等,不过要留心浏览器兼容性问题
另一方面可以使用新的技术,比如PWA,它的Service Worker就相当于是一个可以自主控制的缓存体系,它更多针对了离线应用场景。从下面这张图(我还没做实验,也没找到该图的出处)来看Service Worker的优先级更高
原文 https://zhuanlan.zhihu.com/p/438789495
到任何有关部署 HTTPS 或 HTTP/2 的问题,都推荐先用 Qualys SSL Labs SSL Server Test 跑个测试,大部分问题都能被诊断出来。
每个HTTP请求和响应都会带有相应的头部信息。默认情况下,在发送XHR请求的同时,还会发送下列头部信息: Accept、Accept-Charset、Accept-Encoding、Connection、Host
HTTP状态码是用以表示网页服务器HTTP响应状态的3位数字代码,其中第一位数字表示响应类别,响应类别从1到5分为五种,分别代表:临时响应、成功、重定向、请求错误、服务器错误。
在客户端与服务器数据传输的过程中,HTTP协议的传输是不安全的,也就是一般情况下HTTP是明文传输的。但HTTPS协议的数据传输是安全的,也就是说HTTPS数据的传输是经过加密的
在最早的时候,第一个定稿的http协议是http/0.9版本,在这个版本里面,http协议,它的内容,非常非常的简单 只有一个命令。http协议的历史,其中当然还有https,https是http的安全版本,它实际使用的内容跟http/1.1没有很大的区别
Axios 是一个基于 promise 的 HTTP 库 ,使用了axios来进行数据的请求,一般都需要我们对它进行封装处理。下面简单介绍下如何对axios的二次封装的实现,以及在vue中的使用。
设置ConnectionPoolTimeout:这定义了从ConnectionManager管理的连接池中取出连接的超时时间,此处设置为1秒。设置ConnectionTimeout:这定义了通过网络与服务器建立连接的超时时间。Httpclient包中通过一个异步线程去创建与服务器的socket连接
X-Forwarded-For一般是每一个非透明代理转发请求时会将上游服务器的IP地址追加到X-Forwarded-For的后面,使用英文逗号分割;X-Real-IP一般是最后一级代理将上游IP地址添加到该头中;X-Forwarded-For是多个IP地址,而X-Real-IP是一个
HTTP协议是基于请求/响应模式的,因此只要服务端给了响应,本次HTTP连接就结束了,根本没有长连接这一说。网络上说HTTP分为长连接和短连接,其实本质上是说的TCP连接。TCP连接是一个双向的通道,它是可以保持一段时间不关闭的,因此TCP连接才有真正的长连接和短连接这一说。
一些常见的状态码为:200 - 服务器成功返回网页;404 - 请求的网页不存在;503 - 服务不可用。1xx(临时响应):表示临时响应并需要请求者继续执行操作的状态代码。2xx (成功):表示成功处理了请求的状态代码。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!