http协议:Web前端-HTTP Cache-control/浏览器缓存(转)

标签: http web 前端 | 发表时间:2014-05-16 15:45 | 作者:feiyeguohai
分享到:
出处:http://www.iteye.com

HTTP协议分别在 1.0 / 1.1 两个时代推出了 Expires / Cache-control 两种cache策略,这里我们无需了解全部的细节,无需记住整个RFC内容,但是当我们需要使用HTTP cache策略时,我们需要注意以下细节:
Expires 是HTTP 1.0 那个时代的东西了,目前来看,可以不使用了,因为HTTP 1.0 的user agent占有率在 0.1% 以下(我们主要面向的web浏览器均默认使用HTTP 1.1),Cache-control 是 HTTP 1.1 的新特性,也是我们主要做文章使用cache策略的工具.
Cache策略:
#1 保鲜期only
这个是最最基础的一种策略,只需要在响应头中设定:
Cache-control: max-age=[secs]
[secs]是cache在客户端存活的秒数,例如 Cache-control: max-age=1800 表明cache的时间是半小时,只使用这样一个声明就可以使浏览器能够将这个HTTP响应的内容写入临时目录做cache.
这里是简要过程:

I(1)浏览器第一次请求资源http://test.qq.com/test.cgi
(2)查询临时文件目录发现无cache存储,遂发出请求到web server
(3)web server响应资源,并设定Cache-control:max-age=300
(4)浏览器收到响应将资源呈献给用户的同时,在临时文件目录以"http://test.qq.com/test.cgi"为key缓存这个响应

---5分钟内---
II(1)浏览器再一次请求资源http://test.qq.com/test.cgi
(2)查询临时文件目录发现存在cache存储,检查保鲜期max-age,还未过期,则直接读取之,响应给用户

---5分钟后---
III(1)浏览器再一次请求资源http://test.qq.com/test.cgi
(2)查询临时文件目录发现存在cache存储,检查保鲜期max-age,已经过期,则发请求到web server
#2 保鲜期 + 最后修改时间验证
这里的要素是,在给出保鲜期的同时,给出一个资源的验证方式:
Last-Modified: [UTC time]
[UTC time]标示这个响应资源的最后修改时间,例如 Last-Modified: Mon, 06 Jul 2009 09:21:48 GMT
这个响应头只有配合Cache-control的时候才有实际价值,只是声明校验资源的方式,并不能影响资源的保鲜期时长

利用资源的可校验性,我们可以实现在cache的资源超过保鲜期浏览器再次请求时的304响应,令浏览器再次使用之前的cache

这里是简要过程:
I(1)同#1中I (1)
(2)同#1中I (2)
(3)web server响应资源,并设定
Cache-control:max-age=300
Last-Modified: Mon, 06 Jul 2009 09:21:48 GMT
(4)同#1中I (4)

---5分钟内---
(同#1中II)

<iframe id="aswift_1" style="margin: 0px; padding: 0px; border-width: 0px; vertical-align: baseline; left: 0px; position: absolute; top: 0px;" name="aswift_1" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" width="468" height="60"></iframe>

---5分钟后---
III(1)浏览器再一次请求资源http://test.qq.com/test.cgi
(2) 查询临时文件目录发现存在cache存储,检查保鲜期max-age,已经过期发现资源具有Last-Modified声明,则为请求带上头 If-Modified-Since: Mon, 06 Jul 2009 09:21:48 GMT 发送请求到web server
(3)web server收到请求后发现有头If-Modified-Since 则与被请求资源的最后修改时间进行比对,若最后修改时间较新,说明资源又被改动过,则响应整片资源内容,HTTP 200 (需要整块内容写为包体).若最后修改时间较旧,说明资源无新修改,则响应HTTP 304 (无需包体),告知浏览器继续使用所保存的cache,(这里当然也可以根据自己的需要决定是200还是304,我们的CGI毕竟是一种原始的实现)

#3 保鲜期 + 自定义标识验证
这里的要素是,在给出保鲜期的同时,给出另一种资源的验证方式:
ETag: [custom flag]
[custom flag]标示这个响应资源的由开发者自己确定的签名验证标识,例如 ETag: "abcdefg",这个响应头只有配合Cache-control的时候才有实际价值,是声明校验资源的方式

ETag的使用为我们实现304响应提供了更多的灵活性,我们可以抛开必须将验证转化成时间格式的限制

这里是简要过程:
I(1)同#1中I (1)
(2)同#1中I (2)
(3)web server响应资源,并设定
Cache-control:max-age=300
ETag: "abcdefg"
(4)同#1中I (4)

---5分钟内---
(同#1中II)

---5分钟后---
III(1)浏览器再一次请求资源http://test.qq.com/test.cgi
(2)查询临时文件目录发现存在cache存储,检查保鲜期max-age,已经过期发现资源具有ETag声明,则为请求带上头 If-None-Match: "abcdefg",发送请求到web server
(3)web server收到请求后发现有头If-None-Match 则与被请求资源的相应校验串进行比对,Etag可以是一个版本号,可以是短时间戳,可以是资源校验和(强烈不推荐使用),或者干脆是一个常量(可以干脆拿来做容错)
If-None-Match发来的串与我们的自有值比对,根据我们自己的任何策略算法,可以自由决定如何返回浏览器,304或200
这里有一个使用ETag来做容错的例子(应用列表目前在使用):
(1)我们的每次正常返回都是200
Cache-control: max-age=1800
ETag: "anything"
这里anything是个常量,我们只用来告诉浏览器,cache过期要发带If-None-Match的请求过来
(2) 这样来自客户端的一大部分请求基本上都会带上If-None-Match头,我们的CGI据此可以知道这个请求的客户端是否有cache,此时如果 CGI联系server失败,那么可以直接返回304,驱使客户端使用上一次cache的正确结果,且更新保鲜期max-age为300秒,这样我们实现 了一个基于HTTP cache的容错,如果我们的资源还能实现一套时间戳存储的话,那么我们可以在正常情况下也实现校验后的304,从而节省流量

这里还有一个比较惨的教训,国内www上都没有文献记载,全球业界也只有一点文献可以找到:
IE6 在资源有gzip压缩同时有ETag头时,cache后再次发请求不会带If-None-Match头!!!



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [http web 前端] 推荐:

http协议:Web前端-HTTP Cache-control/浏览器缓存(转)

- - 互联网 - ITeye博客
HTTP协议分别在 1.0 / 1.1 两个时代推出了 Expires / Cache-control 两种cache策略,这里我们无需了解全部的细节,无需记住整个RFC内容,但是当我们需要使用HTTP cache策略时,我们需要注意以下细节:. Expires 是HTTP 1.0 那个时代的东西了,目前来看,可以不使用了,因为HTTP 1.0 的user agent占有率在 0.1% 以下(我们主要面向的web浏览器均默认使用HTTP 1.1),Cache-control 是 HTTP 1.1 的新特性,也是我们主要做文章使用cache策略的工具.

使用HTTP Headers防御WEB攻击(Part3)

- - FreeBuf.COM | 关注黑客与极客
在FreeBuf之前发布的《. 使用HTTP Headers防御WEB攻击(Part1) 》,《. 使用HTTP Headers防御WEB攻击(Part2) 》中讲述了如何使用HTTP Headers对WEB攻击进行防御,比如使用X-Frame-Options以及X-XSS-Protection.

web基础-web工作原理,http协议,浏览器缓存

- - 浏览器 - 互联网 - ITeye博客
4,cookie和session. 平时用浏览器,输入网址后回车,页面响应我们想要浏览的内容,简单操作的背后蕴涵了什么原理. 当输入url回车后,客户端(浏览器)会去请求DNS服务器,通过DNS获取域名对应的IP地址,然后通过这个地址找到对应的服务器,要求建立TCP连接,建立连接,客户端发送httpRequest(请求包)后,服务器接收并开始处理请求,调用自身服务,返回httpResponse(响应包),客户端收到响应包后开始渲染body主体,等到全部接收,断开与该服务器端的TCP连接.

Web前端优化

- - JavaScript - Web前端 - ITeye博客
优点:直接使用浏览器内存的缓存数据,减少网站后台压力,用户体验(速度)好. 缺点:对于时时变化的动态页面,这种情况就不能容忍了,因为每次访问的都是第一次访问的内容,这样即使所请求的页面已经变化了,用户也不可能知道,所以此场景必须要消除这种缓存的影响. 延迟加载,将资源延迟到需要的时候的加载,例如detail页面,相关产品推荐,当用户浏览更多的信息往下拉动滚动时,才进行加载,异步加载可以大幅减少对后端资源的使用,在需要的时候加载,是资源合理使用常用的方式,但是也带来一个问题,当往下拉才去加载,如果性能不够好,用户的体验其实是不好的,“菊花”转动的时间会比较长,同时异步加载对前端性能的作用也是非常明显的,渲染的节点数量大幅减少.

Web 前端测试

- - Web前端 - ITeye博客
Web 网站测试流程和方法(转载). 进行正式测试之前,应先确定如何开展测试,不可盲目的测试. 一般网站的测试,应按以下流程来进行:. 1)使用HTML Link Validator将网站中的错误链接找出来;. 2)测试的顺序为:自顶向下、从左到右;. 3)查看页面title是否正确. (不只首页,所有页面都要查看);.

压力测试工具集合【ab,webbench,Siege,http_load,Web Application Stress】

- - 小彰
-------------------------------------------------- 1 Apache附带的工具ab. ab的全称是ApacheBench,是Apache附带的一个小工具,专门用于HTTP Server的benchmark testing,可以同时模拟多个并发请求.

Web 前端攻防(2014版)

- - 博客 - 伯乐在线
外链会产生站外请求,因此可以被利用实施 CSRF 攻击. 目前国内有大量路由器存在 CSRF 漏洞,其中相当部分用户使用默认的管理账号. 通过外链图片,即可发起对路由器 DNS 配置的修改,这将成为国内互联网最大的安全隐患. 百度旅游在富文本过滤时,未考虑标签的 style 属性,导致允许用户自定义的 CSS.

WEB已死? HTTP将死?还是Browser会死?—— 一篇迟来的脚注

- cgeek - It Talks--上海魏武挥的博客
网易科技《数字与人》专栏供稿,得到网易科技的许可,在此同步发出. 《连线》的这篇东西,不无商业目的. 文章很明显带有站在苹果(以及facebook)这一边向google叫板的味道,毕竟google是web的最大玩家(昨儿还传言说要推出google的平板电脑以及web应用商店). 巨头们的竞争,不是市场这个层面上的,更不是什么应用层面上的,而是标准、规则、接入方式等.

Web前端优化最佳实践

- Jimmy - 中文热文榜|最新
还有 Jason, Bixuan, 曦, 推荐,查看全部 8 个推荐. 博评 - Sting的网经发表于2010-08-08 08:41:10. Google的前端优化最佳实践 Yahoo的前端优化最佳实践. Web前端优化最佳实践之Content篇. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests).

web前端性能优化进阶路

- - 阿里巴巴(中国站)用户体验设计部博客
Web前端性能优化WPO,相信大多数前端同学都不会陌生,在各自所负责的站点页面中,也都会或多或少的有过一定的技术实践. 可以说,这个领域并不缺乏成熟技术理论和技术牛人:例如Yahoo的web站点性能优化 黄金法则,以及大名鼎鼎的优化大师 Steve Souders. 本文并非一篇讨论性能优化技术方法的文章,而更多的是对中文站 搜索List页面持续两年多的前端性能优化实践的 思路总结.