Http页面缓存机制

《Http页面缓存机制》由会员分享，可在线阅读，更多相关《Http页面缓存机制（10页珍藏版）》请在装配图网上搜索。

1、改善Web 2.0应用程序的性能探秘不同的浏览器端缓存机制Jian Qiao Sun,软件工程师，IBMHua Pin Shen,顾问软件工程师，IBM简介：随着Web 2.0应用程序的出现和流行，人们使用In ter net的方式已经悄然改变。 现在，这些Web 2.0应用程序拥有许多典型的特征，包括拥有富客户端、大页面、包含许 多小项目的页面、大量的JavaScript编码等等。鉴于目前的浏览器技术，大部分这些特征 都会导致浏览器端性能问题，特别是在长距离网络中。本文将分析典型Web 2.0应用程序 的关键方面，并介绍它们如何影响浏览器端性能。本文还将检查浏览器端性能的一个非常重 要的部分

2、一浏览器端缓存。发布日期：2010年2月25日级别：中级其他语言版本：英文杵合件合杵平均分（共2个评分）简介随着Web 2.0应用程序的出现和流行，In ter net的使用方式已经发生改变，出现了一种新 趋势：针对内容管理、信息共享、通信、团队合作等创建一种更加以用户为中心的方法。从 技术角度看，Web 2.0应用程序并没有带来很多新的技术突破。但是，这些应用程序的确 带来了一种新的In ter net使用模式。现在，Web 2.0应用程序拥有许多典型特征，包括拥 有富客户端、大页面、包含许多小项目的页面、大量的JavaScript编码等等。这些特征会 导致浏览器端性能问题，特别是在长距离网

3、络中。这些性能问题会对用户体验造成不利影响， 但您甚至不会意识到这些问题的存在。由于开发人员拥有很好的网络条件，因此这些性能问 题很难完全暴露出来。本文将首先分析典型的Web 2.0应用程序的关键方面，解释它们如何影响浏览器端性能。 然后，本文介绍浏览器端性能的一个非常重要的部分一浏览器缓存。通过使用适当的缓 存设置，您可以向用户提供较好的应用程序体验。如果您没有一个整体缓存策略设计，那么 您的缓存策略不仅会导致低劣的性能，还会引发一些功能缺陷。有许多影响浏览器缓存的规则，其中的部分规则包括Cache-Control、Etag、Expires、 Last-Modified和Vary。所有这些设

4、置拥有不同的含义和最适用的情形。困难之处在于对 于相同的设置，并不是所有流行浏览器都拥有相同的行为。因此，在您决定使用这些设置之 前，您应该准确了解这些浏览器是如何工作的。本文将检查目前市面上最流行的浏览器的行 为：In ter net Explorer、 Firefox、 Chrome 和 Safari 0在本文中，我们还使用IBM Mashups和开源Roller Weblogger”来提供一些示例，展 示如何应用不同的指令以最好地使用浏览器缓存。背景在当今的In ter net环境中，Web 2.0应用程序正在变得越来越流行。许多Web站点都使 用Web 2.0构建，比如Facebook

5、、Youtube等。IBM也有 Web 2.0应用程序，比如 Lotus Connections 和 Lotus Mashups。以下是一种用于计算浏览器响应时间的基本方法： 浏览器响应时间=服务器端时间+页面加载时间+浏览器呈现时间页面加载时间=（请求数/并发数）*延迟时间+页面总大小/带宽在上述等式中： “服务器端时间”是指服务器端处理所花费的时间，比如通过LDAP验证和从数据 库检索信息。 “浏览器呈现时间”是指浏览器呈现页面所花费的时间，包括执行JavaScript和解 析DOM树的时间。 “请求数”是指HTTP请求的数量。 “并发数”是指浏览器与服务器之间的并行连接的数量。页面总大小

6、”是指一个页面的完整大小。 “延迟时间”和“带宽”是网络状态指标。在常见的长距离网络环境中，带宽大约为 1M,延迟时间大约为100毫秒。因此，减少到100KB或减少为一个请求能够节 约0.1秒响应时间。请注意一点，鉴于真实环境的复杂性，这个等式可能不能涵盖所有情形。在一个典型的Web 2.0富In ter net应用程序（例如Lotus Mashup Maker）中，浏览器首 先发送格式定义请求到服务器。接收到定义响应数据后，浏览器向服务器发送数据请求。然 后,浏览器对用户呈现页面。在这种模式中，有大量的小项目请求，比如JavaScript文件、 CSS文件等。在长距离网络环境中，这会导致严重

7、影响用户体验的客户端性能问题。大多 数文件是可以被缓存的静态文件，因此，如果您添加适当的缓存控件、expiry头部以及其 他影响浏览器缓存的头部元数据，就可以明显改善用户体验。浏览器缓存机制有几个影响浏览器缓存的规则，这个小节将分别讨论它们。Cache-ControlCache-Control是最重要的规则。这个字段用于指定所有缓存机制在整个请求/响应链中必 须服从的指令。这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。这些指令通 常覆盖默认缓存算法。缓存指令是单向的，即请求中存在一个指令并不意味着响应中将存在 同一个指令。cache-control 定义是：Cache-Control

8、 = Cache-Control : cache-directive。表 1 展示 了适用的值。表 1.常用 cache-directive 值Cache-directive说明public所有内容都将被缓存private内容只缓存到私有缓存中no-cache所有内容都不会被缓存no-store所有内容都不会被缓存到缓存或 Internet 临时文件中must-revalidation/proxy-revalidation 如果缓存的内容失效，请求必须发送到服务器/代理以进行重新验证max-age=xxx (xxx is numeric)表2表明在不同的情形下，表 2.对 cache-dire

9、ctiveCache-directive缓存的内容将在 xxx 秒后失效浏览器是将请求重新发送到服务器还是使用缓存的内容。值的浏览器响应打开一个新的 浏览器窗口在原窗口中单击Enter按钮刷新单击Back按钮public浏览器呈现来自缓存的页面浏览器呈现来自缓存的页面浏览器 重新发 送请求 到服务 器浏览器呈现来自缓存的页面private浏览器重新发 送请求到服务 器第一次，浏览器重新发 送请求到服务器；此 后，浏览器呈现来自缓 存的页面浏览器 重新发 送请求 到服务 器浏览器呈现来自缓存的页面no-cache/no-store浏览器重新发 送请求到服务 器浏览器重新发送请求到服务器浏览器 重

10、新发 送请求 到服务 器浏览器重新发 送请求到服务 器must-revalidation/proxy-revalidation 浏览器重新发 送请求到服务 器第一次，浏览器重新发 送请求到服务器；此 后，浏览器呈现来自缓 存的页面浏览器 重新发 送请求 到服务 器浏览器呈现来自缓存的页面max-age=xxx (xxx is numeric)在 xxx 秒后，浏览器重新发送请求到服务器在 xxx 秒后，浏览器重 新发送请求到服务器浏览器重新发送请求在 xxx 秒后，浏览器重新发送请求到服务器到服务器Cache-Control是关于浏览器缓存的最重要的设置，因为它覆盖其他设置，比如Expires

11、和 Last-Modified。另外，由于浏览器的行为基本相同，这个属性是处理跨浏览器缓存问题的最 有效的方法。失效Expires头部字段提供一个日期和时间，响应在该日期和时间后被认为失效。失效的缓存条 目通常不会被缓存（无论是代理缓存还是用户代理缓存）返回，除非首先通过原始服务器（或 者拥有该实体的最新副本的中介缓存）验证。（注意：cache-control max-age和s-maxage 将覆盖Expires头部。）Expires字段接收以下格式的值：“Expires: Sun, 08 Nov 2009 03:37:26 GMT如果查看 内容时的日期在给定的日期之前，则认为该内容没有失效

12、并从缓存中提取出来。反之，贝I认 为该内容失效，缓存将采取一些措施。表3-6表明针对不同用户操作的不同浏览器的行为。表3.当用户打开一个新的浏览器窗口时的失效操作Firefox 3.5IE 8Chrome 3Safari 4内容浏览器呈现来自缓存的浏览器重新发送请求浏览器呈现来自缓存的浏览器呈现来自缓存没有页面到服务器。返回代码页面的页面失效是 200内容浏览器重新发送请求到浏览器重新发送请求浏览器重新发送请求到浏览器重新发送请求失效服务器。返回代码是到服务器。返回代码服务器。返回代码是到服务器。返回代码是200是 200200200表4.当用户在原始浏览器窗口中单击Enter按钮时的失效操作

13、Firefox 3.5IE 8Chrome 3Safari 4内容没有失效浏览器呈现来自缓存的页面浏览器呈现 来自缓存的 页面浏览器重新发送请求到服务器。返回代码是 304浏览器重新发送请求到服务器。返回代码是 304内容失效浏览器重新发送请求到服务器。返回代码是 200浏览器呈现来自缓存的浏览器重新发送请求到服务器。返回代码是 200浏览器重新发送请求到服务器。返回代码是 200页面表5.当用户按F5键刷新页面时的失效操作Firefox 35IE 8Chrome 3Safari 4内容没浏览器重新发送请求到服务器。浏览器重新发送请求到服务浏览器重新发送请求到服务器。浏览器重新发送请求到服务器

14、。有失效返回代码是 304器。返回代码是 304返回代码是 304返回代码是 304内容失浏览器重新发送请求到服务器。浏览器重新发送请求到服务浏览器重新发送请求到服务器。浏览器重新发送请求到服务器。效返回代码是 200器。返回代码是 200返回代码是 200返回代码是 200表6.当用户单击Back或Forward按钮时的失效操作Firefox 35IE 8Chrome 3Safari 4内容没有失浏览器呈现来自缓存的页浏览器呈现来自缓存的页浏览器呈现来自缓存的页浏览器呈现来自缓存的页面效面面面内容失效浏览器呈现来自缓存的页浏览器呈现来自缓存的页浏览器呈现来自缓存的页浏览器重新发送请求到服务器

15、。返回代码是面面面200注意：所有浏览器都假定为使用默认设置运行。Last-Modified/E-TagLast-Modified实体头部字段值通常用作一个缓存验证器。简单来说，如果实体值在 Last-Modified值之后没有被更改，则认为该缓存条目有效。ETag响应头部字段值是一个 实体标记，它提供一个“不透明”的缓存验证器。这可能在以下几种情况下提供更可靠的验 证：不方便存储修改日期；HTTP日期值的one-second解决方案不够用；或者原始服务 器希望避免由于使用修改日期而导致的某些冲突。不同的浏览器有不同的配置行为。表7-10表明针对不同用户操作的不同浏览器的行为。表7.当用户打开

16、一个新的浏览器窗口时的Last-Modified E-Tag操作Firefox 3.5IE 8Chrome 3Safari 4内容自上次访问以浏览器重新发送请求到服务浏览器重新发送请求到服务浏览器重新发送请求到服务浏览器重新发送请求到服务来没有被修改器。返回代码是 304器。返回代码是 200器。返回代码是 304器。返回代码是 304内容自上次访问以浏览器重新发送请求到服务浏览器重新发送请求到服务浏览器重新发送请求到服务浏览器重新发送请求到服务来已经被修改器。返回代码是 200器。返回代码是 200器。返回代码是 200器。返回代码是 200表8.当用户在原始浏览器窗口中单击Enter按钮时

17、的Last-Modified E-Tag操作Firefox 35IE 8Chrome 3Safari 4内容自上次访问以浏览器呈现来自缓存的页面浏览器呈现来自浏览器重新发送请求到服务器。浏览器重新发送请求到服务器。来没有被修改缓存的页面返回代码是 304返回代码是 304内容自上次访问以浏览器重新发送请求到服务器。浏览器呈现来自浏览器重新发送请求到服务器。浏览器重新发送请求到服务器。来已经被修改返回代码是 200缓存的页面返回代码是 200返回代码是 200表9.当用户按F5键刷新页面时的Last-Modified E-Tag操作内容自上次访问以 浏览器重新发送请求到服务浏览器重新发送请求到服

18、务 浏览器重新发送请求到服务浏览器重新发送请求到服务来没有被修改器。返回代码是 304器。返回代码是 304器。返回代码是 304器。返回代码是 304内容自上次访问以 浏览器重新发送请求到服务 浏览器重新发送请求到服务 浏览器重新发送请求到服务浏览器重新发送请求到服务来已经被修改器。返回代码是 200器。返回代码是 200器。返回代码是 200器。返回代码是 200表10.没有缓存设置且用户单击Back或Forward按钮Firefox 3.5IE 8Chrome 3Safari 4内容自上次访问以来没有浏览器呈现来自缓存的浏览器呈现来自缓存浏览器呈现来自缓存的浏览器呈现来自缓存的页面被修改

19、页面的页面页面内容自上次访问以来已经 浏览器呈现来自缓存的 浏览器呈现来自缓存 浏览器呈现来自缓存的 浏览器重新发送请求到服务器。返回代 被修改页面的页面页面码是 200注意：所有浏览器都假定使用默认设置运行。不进行任何缓存相关设置如果您不定义任何缓存相关设置，则不同的浏览器有不同的行为。有时，同一个浏览器在相 同的情形下每次运行时的行为都是不同的。情况可能很复杂。另外，有些不该缓存的内容如 果被缓存，将会导致安全问题。不同的浏览器有不同的行为。表11展示了不同的浏览器行为。表11.没有缓存设置且用户打开一个新的浏览器窗口Firefox 3.5IE 8Chrome 3Safari 4打开一个新

20、页面浏览器重新发送请求到服务浏览器重新发送请求到服务浏览器重新发送请求到服务浏览器重新发送请求到服务器。返回代码是 200器。返回代码是 200器。返回代码是 200器。返回代码是 200在原始窗口中单击浏览器重新发送请求到服务浏览器呈现来自缓存的页浏览器重新发送请求到服务浏览器重新发送请求到服务Enter 按钮器。返回代码是 200面。器。返回代码是 200器。返回代码是 200按 F5 键刷新浏览器重新发送请求到服务 浏览器重新发送请求到服务 浏览器重新发送请求到服务 浏览器重新发送请求到服务器。返回代码是 200器。返回代码是 200器。返回代码是 200器。返回代码是 200单击 Ba

21、ck 或浏览器呈现来自缓存的页面。 浏览器呈现来自缓存的页浏览器重新发送请求到服务浏览器重新发送请求到服务Forward 按钮器。返回代码是 200器。返回代码是 200注意：所有浏览器都假定使用默认设置运行。应用示例本小节提供几个Web站点分析示例，展示如何使用IBM商业和开源工具确定正确的缓存 行为。Apache Roller WebloggerApache Roller Weblogger是一个开源 Web 2.0 Web应用程序，它是驱动、blog.usa.gov、IBM Lotus Connections、IBM Developer Works 博客等大 量博客的开源Java博客服务

22、器，在本文中，我们选择IBM My developerWorks博客作为一个示例，详细解释缓存设置。图 1展示了 My developerWorks博客页面的一个屏幕截图。图 1. My developerWorks 博客页面这个页面有62个请求，多数是png、gif、js或其他静态文件类型。当用户首次访问这个 页面时，将花费约16秒时间来在浏览器中显示整个页面。如果您定义正确的缓存设置， 多数资源将被缓存到浏览器端。因此，当用户再次访问这个页面时，这个页面的请求数量将 减少到22,只需约6秒钟就可以加载。用户体验得到极大地改善。现在，我们将分析一些重要的请求缓存设置。相关的Weblogger

23、输出如图2所示。图 2. My developerWorks 博客主页 Response Header 1HeadersHTML）廿U Oct舅加 轉：乩：MVia HTTP/1 1 wwsrdw. southi&ury-Ewt. lbm 20a (IBM-PRD5i 1 -P?TE)Last-Modiiieck13 Oct 200 O5：4：uu bATh ccepl-Enco di nj,t tx/htm 1; cht 1141 f- 6 en-US1TU4T匚日th巳一匸oritrol 計JiSEi muzt-上勻】t 矗 i 臼VaryEnVnNFnwHno Cwitnr-Tyrv C

24、 tint ent-lnguge -Length首先，Cache-Control覆盖Last-Modified设置，因此页面可以在本地缓存5秒钟，但如 果内容失效将重新验证。当用户访问这个页面时，浏览器首先检查本地缓存，以确定本地文 件是否已经失效。如果内容失效，浏览器将发送一个请求到服务器以比较Last-Modified时 间戳。如果响应文件拥有相同的Last-Modified时间戳，则服务器将返回代码304到浏览 器，告知浏览器响应文件相同。图 3. My developerWorks 博客主页 Response Header 2Headers ResponseResponse Hcade

25、tsDate 附也 13 Oct 辿2 W：51: 07 &KIServertnTP 壯i 山】q 好8曲=it 4r (UrJ*) tnwfContent-Type Dnt pnt-L anquage Var/ Content-Encodi ng Content-LengthWkTP/i wwm rj：ti -jHiihiti u r 7 i - ib* n* I Id肝PROXY Wrkjtr&ljtion/ene tnt. M亡亡电p* Enm di heEiip448这个Cache-Control设置表明：这个响应不能被缓存。从业务角度看，这个请求用于检查 用户验证和授权，不应该被缓存

26、。图 4. My developerWorks 博客主页 Response Header 3Ddte 皿灯 1? 0bA e* (rsH-PWDiT-ffrr)C ache -C ontk(4 publ i cr *!- e*=E6400 Lt-McdifiEd $qjl 站 Fit 烈训门戢棉 GJTTL*tt tfcAt-1*b& l ie iLitCotitent-lnguaqe *IK_USViSTy Ust-rJfcAkContent-Encodmq ezipCqh t&nt-Length 13HS这个响应文件是一个很少修改的JavaScript库，因此它的max-age等于1天。M

27、ashup CenterMashup Center设计用于提供一个易于使用的mashup解决方案，支持将多个动态情景应 用程序集合到一个业务范围中，并提供IT所需的安全和治理功能。Mashup Center包含Lotus Mashups 和 InfoSphere MashupHub。图 5 展示了正在运行的 Lotus Mashups 的 快照。图5. Mashup主页肿他 I Svflinp G Hfftp |MFlUWtjHrTM kA#*fcl 4-U*l C HbiJftAot?l 0 RH 13Ww mhi4wenwIih dlljil1 iA Li Higroup00100D_0r

28、i T#4*1. *WX* -*f4WW nmgfifttffi iTiMMtf* p却軋 0 D#h hl LfiMbfuiaMfl WOMi hd IIME，!1 fNI Ufit Dd 仙 a-Ell MW ClI Te 也沖札riU越 rnfeFn4 fifej*. ftCHKTW Cirtkkjfi rMMW *H 青 * URL CtVV 4Mi!悔声叭皿松古叭討计申 iftWWI wwl Oft bw ffiir|ilW &*M. 4T 4ftrt eoHlfiirktoaH vwaow uh 沖机衍 Hi* UfyF-tfihe dWa iow图6和图7展示了选中的HTTP头部

29、。图 6. Mashup 主页 Response Header 1Pdrbtn 召 HeedersAciponseOe Server X-R已呻卜敗ftVary 匚 ont ent-Encoding Keep-Alive Connecbon Trans fek-Encodtrig Content-Type Content-l anguAgeRcspuiibfr HecidorsTu& L3 Oel ?015 0? 56 St CKTtHplresVtA, 14 &eIFOO* 厂56 总 ICT匚a匚h亡-CoiltfoI ”iibEi“ m%M-gE*=8&4*Jlee-ep-eout =

30、lGr *kx = %XetD-ll ivt亡 trunk 4这个请求检索可以从服务器缓存的主题信息。图 7. Mashup 主页 Response Header 2Headers Response HTMLRc5panse HeddersDe Tm. 1? Ocl 沙曲 07: 5& W QKTSet-Coohie J se s s I on 1 D-OOfl of u f- st?i 1 mi od-MvO_ r - i ；Expim Th* Ql Dc 1994 16; QO:QO tKT匚Tchei-Cijjrtrol 加-爼曲三-工十100曲也 “eMlaQvary Acctot-E

31、nndinKfantent-EnEDdinq tzipKeep-Alive timtout=10, bb.i=1 00ConnectHHi Kep-ilivTransfer -E nc odirbg chunkedContent-7ype t. elu tntsiSG-#454-iCantentLanguage enUS这是一个个人主页，不应该被缓存。注意Expires日期值设置为一个很久以前的日期，以 便这个页面总是能够刷新。结束语由于不同浏览器的复杂性，适当的缓存设置非常重要。在本文中，我们介绍了以下最佳实践: 尽可能多地缓存文件，以便减少加载次数并改善性能。 尽可能使用cache-con

32、trol定义缓存行为，尤其是对IE。这降低了不同浏览器之间 的差别，是改善性能的最佳方法。 不要使用no settings related with cache。 使用默认设置初次打开IE时，IE浏览器几乎总是发送一个请求到服务器端以检索 数据。 如果某个页面不应该被缓存，则使用cache-co ntrol: no-cache, no -store来确保该 页面不会被缓存，尤其是当数据涉及安全或敏感信息时。除非必要，不要使用post请求，因为它不能被缓存。参考资料学习 查看 HTTP Protocol Def in itio n, 了 解基础知识。 阅读 IBM developerWorks Blogs 并加入讨论。 “N揭秘：改善 Web站点的性能”介绍了 Web性能改进。 developerWorks技术活动和网络广播：随时关注developerWorks技术活动和网 络广播。 developerWorks Web development专区:通过专门关于 Web 技术的文章和教程, 扩展您在网站开发方面的技能。获得产品和技术 开始使用Apache Roller Weblogger构建自己的博客项目。 了解关于IBM Mashup Center的更多信息并下载免费试用版。