免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1476 | 回复: 0

如何利用HTTP缓存提高网页性能 [复制链接]

论坛徽章:
0
发表于 2011-12-20 09:48 |显示全部楼层

网站的性能(Performance)要考虑两方面,一方面是在Server端的运行效率,另一方面是在Client端感受到的效率。不要以为Server端效率高这个网站或者服务给用户的体验就是高效的,如果不考虑影响Client Performance的因素,Server端跑得再快用户也可能感觉慢得和牛一样。

Yahoo的哥们做的研究真不是盖,他们还写了本书《High Performance Web Sites》详细介绍如果提高Client Performance。公司内部也有一个Team做这方面的事情,听过他们的培训,和Yahoo说的差不多,所谓英雄所见略同。

给静态资源(HTML文件,图片文件等)的Repsone加上Expires/Cache-Control Header是很有效的一招。如果HTTP Response中有Expires这样的Header的话,浏览器会Cache这个资源,理想状况下(注意,只是理想状况),在Expire Date之前,不会再发HTTP请求给Server要这个资源,不过Expires的值只能是一个固定日期,比如“Thu 27 Nov 2008 07:00:00 GMT”,不能是一个类似从现在开始之后10这样一个随机浮动的值,如果要这样的效果,可以用Cache-Control这样的Header,如果HTTP Resposne中有这样的Header:“Cache-Control: max-age = 100”,表示这个资源在cache中的最大寿命是100秒。一般说来这种静态文件永远不应该过期,如果真的要给这个Cache加上一个期限,那我希望是——一万年,“Cache-Control: max-age = 315360000000”;

其实就应该给Expires设一个永远不会过期的时间,比如你现在有一个文件叫logo.gif,需要用一个新的logo的时候,你不要去覆盖原来的文件,而把新的logo存成logo_v2.gif,让相关网页引用新的logo_v2.gif,这样可以让新老网页同时工作,实在犯不上为了节省存储空间覆盖原有文件。

Apache服务器,使用mod_expires,在httpd.conf或者.htaccess中加上

<FilesMatch "\\.(ico|gif|jpg|html)$">
ExpiresDefault "access plus 10 years"
</FileMatch>

还有,同一个HTTP Response中可以同时有ExpiresCache-Control,但是Cache-Control权限比Expires大,会override它的。

HTTPResponse中还会有另外一个HeaderLast-Modified,比如“Last-Modified: Thu, 06 Apr 2006 21:17:12 GMT”,浏览器访问一个URI得到这样的Resposne之后,就知道这个资源最后一次的修改时间,下次需要再次获得这个资源的时候,会发一个RequestServer,不过这个Request中有一条“If-Unmodified-Since: Thu, 06 Apr 2006 21:17:12 GMT”,如果在Server端在这个日期之后对这个资源进行了修改,就会照常返回这个资源给Client端,但是如果没有修改,就会返回一个304 (Not Modified) Response而不返回资源,告诉Client端:这个资源从上次给你之来从来没改过,你放心用你Cache中的好了。一个304 Response比一个静态资源通常小多了,这样就节省了网络带宽。

让我们回过头来比较一下ExpiresLast-Modified这两个东西,似乎Last-Modified比不上Expires,因为虽然它能够节省一点带宽,但是还是逃不掉发一个HTTP请求出去,而Expires却使得浏览器干脆连HTTP请求都不用发,岂不痛快!那还要Last-Modified这个物体干什么?理想状况的确是这样,不过当用户在IE或者Firefox里面按F5或者点击Refresh按钮的时候(不是在URL栏里重新输入一遍URL然后回车),就算对于有ExpiresURI,一样也会发一个HTTP请求出去,所以,Last-Modified还是要用的,而且要和Expires一起用。

除了Last-ModifiedHTTP Response中还可能有另外一个Header: ETag,使得Server上的静态资源有点版本控制的味道;假如HTTP Response中包含“ETag: "abcdefg1234:0001"”,等于告诉Client端,你拿到的这个版本的资源有个ID,叫做abcdefg1234:0001,下次需要发Request索要同一个URI的时候,在Request里面加一条“If-None-Match: "abcdefg1234:0001"”,好,Server端做了一些修改,下次这个Client再来了一个请求,但是这时候资源已经改了,所以返回这个新资源,还有新的tag “ETag: "abcdefg4567:0001"”(这个etag我是胡写的),这样,Client端等于Cache了两份,在需要索要这个资源的时候,可以包含这样的Header: “If-None-Match: "abcdefg1234:0001" "abcdefg4567:0001"”,这样,即使Server端头脑发热,把这个资源Roll back回原来的版本,依然会返回304 (Not Modified) Response,因为它知道ClientCache着以前的版本呢,这点功能是Last-Modifed/If-Not-Modified没法做到的。

不过ETag/If-None-Match这点功能实在是个鸡肋,首先,Server端的资源不大可能Roll Back,更重要的是,有可能造成Client Performance下降。对于只有一个Server的网站,没什么问题,但是现在稍微上点规模的网站都需要Scale Out,也就是说需要前端一个Load Balancer,后面接多台Server来处理请求,俗称Cluster,既然是Cluster,那么每个请求到底返回什么结果应该和分配到哪个Server无关,不过这个ETag可能就坏事了。假如用户的第一次请求分配给Server A,返回“ETag: "abcdefg1234:0001"”,但是第二次请求分配给了Server BServer B上这个资源和Server A上的一模一样,但是计算出这个资源的ETag"abcdefg1234:0002",这下麻烦了,虽然内容一样,但是ETag不匹配,还是浪费了带宽把资源发送了一遍,冤枉啊!而事实上,不同Server上的ETag很有可能不同,对于ApacheETag的计算考虑了inode,对于IIS,ETag考虑了metabase的修改版本,要保证不同server上的这些信息一致,有点小难。不过不是有Last-Modified/If-Not-Modified吗?Server端看到If-Modified-Since,对照一下时间对得上,不管If-None-Match,可以直接发回304(Not Modified)呀,很不幸,RFC2616对这种情况做了规,如果既有If-None-Match又有If-Modified-Since,除非两者不冲突,不然不会返回304

所以说ETag就是一个害人精,按照Yahoo的建议,别费劲想办法同步不同Server上的ETag了,干脆就把ETag删除得了(缺省,ApacheIIS都是有ETag),我Sniff了一下Yahoo的若干网页返回HTTP Response,的确没有ETag,人家的确是知行合;

对于Apache,在httpd.conf或者.htaccess中加一行就搞定了:

FileETag none

对于IIS 6,可就有点费劲了,首先,似乎没有办法通过Config来把ETag去掉,查了很多资料,问了很多人,似乎能够去掉ETag的办法只有写一个ISAPI FilterSniff了一下Microsoft的几个网页的结果显示ETag都稳当当的存在,估计目前真的没有什么好方法。

只好退而取其次,保证不同Server上的ETag一致了。 IISEtag的计算算法是ETag = {Filetimestamp:ChangeNumber}, Filetimestamp保持一致没什么问题,ChangeNumbermetabasechange number,就有点难保证Cluster中每个Server都一样了,所以,干脆就把它设成固定值好了,这个连告诉我们该怎么办,很可惜,没有找到彻底删除ETags的配置。

 

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP