-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
缓存(二)——浏览器缓存机制:强缓存、协商缓存 #41
Comments
看过这么多篇关于缓存的文章,还是博主的文章最为全面,各个方面都说到了。 |
谢谢你的认真阅读,这会让我更有动力的 |
很齐全 |
感谢总结! |
协商缓存本身是有意义的,比如取一个 1G 的大文件,通过协商缓存,下次不一定要重新下载 |
最近了解到一个heuristic cache(启发式缓存)的概念,我觉得可以补充一下
|
在vue-cli2项目中使用了协商缓存,但是版本更新之后,打开浏览器有时候并不会去请求新资源,而是需要 CTRL + F5强刷,更有甚者需要清理浏览器缓存,不然会报 js 加载错误, |
请问 强缓存 和 协商缓存 的英文分别是什么呢? 完全找不到对应的英文资料啊 |
|
"但是如果在本地打开缓存文件,就会造成 Last-Modified 被修改,所以在 HTTP / 1.1 出现了 ETag" |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching 感觉 原文里写的 中文社区里面造词强缓存,是不是能让人联想到弱缓存呢,然而并没有 |
写得很好,看完 《HTTP 权威指南》里关于缓存的章节,配合你这篇文章食用更佳~ |
蟹博主, 学习了 ~ |
@ficapy @ethan-cao 下面的引用有删减,详见 RFC 7234 中文翻译。
实际上,强缓存指的是新鲜的响应,而协商缓存指的是陈旧的响应(已过期)。而要复用陈旧的响应就得使用条件请求(If-xxx)进行缓存验证。 判断已缓存的响应是否过期的机制见 RFC 7234 4.2. 新鲜度 / Freshness。(与 Expires 和 Cache-Control 的 max-age 指令等值相关) |
from mermory cache是页面刷新的时候内存取的 |
你好,想问下,浏览器强缓存与协商缓存如何配置呢 |
一篇好文章就是让人读懂,要是早点看到这篇文章就好了,那我大概就可以在百度二面时回答上这个问题了 |
有个错误,在下面这段
在第一条,判断是否命中强缓存时校验的应该是资源的响应头里的 |
MemoryCache 是指该文件内容仍在内存中,可以直接从内存取,速度更快。 |
协商缓存需要配合强缓存使用,如果不启用强缓存的话,协商缓存根本没有意义 这句话是什么理解呢?没有强缓存,协商缓存就用不了吗 |
别被绕糊涂了,强缓存和协商缓存二词非常有误导性,上面已经有人提及,建议直接查看文档。如果一定要借用这两个词的话,个人认为可以这样理解:
读取缓存是验证缓存可用后的最后一步,不读取,前面的验证自然也没了意义。 两个词都是对流程的概括,但是听起来像管理缓存的手段,强缓存容易产生“弱缓存”的联想,协商也和“验证”挂不上边。 如有错误,烦请指出 |
这样说来,协商缓存读的还是强缓存,协商缓存就不能单独存在,只开协商缓存,可能还更慢?因为你多了一部校验的动作,结果还是要返回新资源 |
其实我认为与其说 |
|
我是这样理解的,max-age=0表示本地缓存一直处于过期的状态,不代表不会缓存,must-revalidate表示本地缓存过期之后都会向服务器发送请求进行缓存校验。如果具有缓存校验(etag、last-modified)会向服务器发送请求检查资源是否发生变化,如果服务器资源未变化,请求状态码为304使用本地缓存,否则请求为200并刷新本地缓存资源。 |
受教了,感谢分享~ |
https://juejin.cn/post/7044519783366131748 这哥们还和面试官怼了起来 |
您好,我已经收到信件,我会尽快处理的……祝快乐每一天。
|
有经验的同学可以直接去看第四部分的流程图,如果你能完全理解那个图,那这篇文章你可以不看了,当然,看看当复习也好
一、概述
良好的缓存策略可以降低资源的重复加载提高网页的整体加载速度
通常浏览器缓存策略分为两种:强缓存和协商缓存
1、基本原理
expires
和cache-control
判断是否命中强缓存,是则直接从缓存读取资源,不会发请求到服务器。last-modified
和etag
验证资源是否命中协商缓存,如果命中,服务器会将这个请求返回,但是不会返回这个资源的数据,依然是从缓存中读取资源2、相同点
如果命中,都是从客户端缓存中加载资源,而不是从服务器加载资源数据;
3、不同点
强缓存不发请求到服务器,协商缓存会发请求到服务器。
二、强缓存
强缓存通过
Expires
和Cache-Control
两种响应头实现1、Expires
Expires是http1.0提出的一个表示资源过期时间的header,它描述的是一个绝对时间,由服务器返回。
Expires 受限于本地时间,如果修改了本地时间,可能会造成缓存失效
2、Cache-Control
Cache-Control 出现于 HTTP / 1.1,优先级高于 Expires ,表示的是相对时间
题外tips
Cache-Control: no-cache
不会缓存数据到本地的说法是错误的,详情《HTTP权威指南》P182Cache-Control: no-store
才是真正的不缓存数据到本地Cache-Control: public
可以被所有用户缓存(多用户共享),包括终端和CDN等中间代理服务器Cache-Control: private
只能被终端浏览器缓存(而且是私有缓存),不允许中继缓存服务器进行缓存三、协商缓存
当浏览器对某个资源的请求没有命中强缓存,就会发一个请求到服务器,验证协商缓存是否命中,如果协商缓存命中,请求响应返回的http状态为304并且会显示一个Not Modified的字符串
协商缓存是利用的是
【Last-Modified,If-Modified-Since】
和【ETag、If-None-Match】
这两对Header来管理的1、Last-Modified,If-Modified-Since
Last-Modified
表示本地文件最后修改日期,浏览器会在request header加上If-Modified-Since
(上次返回的Last-Modified
的值),询问服务器在该日期后资源是否有更新,有更新的话就会将新的资源发送回来但是如果在本地打开缓存文件,就会造成 Last-Modified 被修改,所以在 HTTP / 1.1 出现了 ETag
2、ETag、If-None-Match
Etag
就像一个指纹,资源变化都会导致ETag变化,跟最后修改时间没有关系,ETag
可以保证每一个资源是唯一的If-None-Match
的header会将上次返回的Etag
发送给服务器,询问该资源的Etag
是否有更新,有变动就会发送新的资源回来ETag
的优先级比Last-Modified
更高具体为什么要用
ETag
,主要出于下面几种情况考虑:四、整体流程图
五、几种状态码的区别
200
:强缓Expires/Cache-Control存失效时,返回新的资源文件200(from cache)
: 强缓Expires/Cache-Control两者都存在,未过期,Cache-Control优先Expires时,浏览器从本地获取资源成功304(Not Modified )
:协商缓存Last-modified/Etag没有过期时,服务端返回状态码304但是!但是!
现在的
200(from cache)
已经变成了from disk cache(磁盘缓存)
和from memory cache(内存缓存)
两种打开chrome控制台看一下网络请求就知道了
具体两者的区别,暂时没有去深究,有兴趣的同学可以自己去研究
六、如何选择合适的缓存
大致的顺序
协商缓存需要配合强缓存使用,如果不启用强缓存的话,协商缓存根本没有意义
大部分web服务器都默认开启协商缓存,而且是同时启用【Last-Modified,If-Modified-Since】和【ETag、If-None-Match】
但是下面的场景需要注意:
七、后记
感谢您耐心看到这里,希望有所收获!
如果不是很忙的话,麻烦右上角点个star⭐【Github博客传送门】,举手之劳,却是对作者莫大的鼓励。
我在学习过程中喜欢做记录,分享的是自己在前端之路上的一些积累和思考,希望能跟大家一起交流与进步,更多文章请看【amandakelake的Github博客】
参考
浅谈Web缓存 | AlloyTeam
浏览器缓存知识小结及应用 - 流云诸葛 - 博客园
HTTP 缓存 | Web | Google Developers
大公司里怎样开发和部署前端代码? - 知乎
HTTP强缓存和协商缓存 - JavaScript学习笔记 - SegmentFault 思否
The text was updated successfully, but these errors were encountered: