Http页面缓存机制Word格式.docx

1、但是，这些应用程序的确带来了一种新的 Internet 使用模式。现在，Web 2.0 应用程序拥有许多典型特征，包括拥有富客户端、大页面、包含许多小项目的页面、大量的 JavaScript 编码等等。这些特征会导致浏览器端性能问题，特别是在长距离网络中。这些性能问题会对用户体验造成不利影响，但您甚至不会意识到这些问题的存在。由于开发人员拥有很好的网络条件，因此这些性能问题很难完全暴露出来。本文将首先分析典型的 Web 2.0 应用程序的关键方面，解释它们如何影响浏览器端性能。然后，本文介绍浏览器端性能的一个非常重要的部分 浏览器缓存。通过使用适当的缓存设置，您可以向用户提供较好的应用程序体验

2、。如果您没有一个整体缓存策略设计，那么您的缓存策略不仅会导致低劣的性能，还会引发一些功能缺陷。有许多影响浏览器缓存的规则，其中的部分规则包括 Cache-Control、Etag、Expires、Last-Modified 和 Vary。所有这些设置拥有不同的含义和最适用的情形。困难之处在于对于相同的设置，并不是所有流行浏览器都拥有相同的行为。因此，在您决定使用这些设置之前，您应该准确了解这些浏览器是如何工作的。本文将检查目前市面上最流行的浏览器的行为：Internet Explorer、Firefox、Chrome 和 Safari。在本文中，我们还使用 IBM Mashups 和开源 “R

3、oller Weblogger” 来提供一些示例，展示如何应用不同的指令以最好地使用浏览器缓存。背景在当今的 Internet 环境中，Web 2.0 应用程序正在变得越来越流行。许多 Web 站点都使用 Web 2.0 构建，比如 Facebook、Youtube 等。IBM 也有 Web 2.0 应用程序，比如 Lotus Connections 和 Lotus Mashups。以下是一种用于计算浏览器响应时间的基本方法： 浏览器响应时间 = 服务器端时间 + 页面加载时间 + 浏览器呈现时间 页面加载时间 = （请求数 / 并发数）* 延迟时间 + 页面总大小 / 带宽在上述等式中： “

4、服务器端时间” 是指服务器端处理所花费的时间，比如通过 LDAP 验证和从数据库检索信息。 “浏览器呈现时间” 是指浏览器呈现页面所花费的时间，包括执行 JavaScript 和解析 DOM 树的时间。 “请求数” 是指 HTTP 请求的数量。 “并发数” 是指浏览器与服务器之间的并行连接的数量。 “页面总大小” 是指一个页面的完整大小。 “延迟时间” 和 “带宽” 是网络状态指标。在常见的长距离网络环境中，带宽大约为 1M，延迟时间大约为 100 毫秒。因此，减少到 100KB 或减少为一个请求能够节约 0.1 秒响应时间。请注意一点，鉴于真实环境的复杂性，这个等式可能不能涵盖所有情形。在一

5、个典型的 Web 2.0 富 Internet 应用程序（例如 Lotus Mashup Maker）中，浏览器首先发送格式定义请求到服务器。接收到定义响应数据后，浏览器向服务器发送数据请求。然后，浏览器对用户呈现页面。在这种模式中，有大量的小项目请求，比如 JavaScript 文件、CSS 文件等。在长距离网络环境中，这会导致严重影响用户体验的客户端性能问题。大多数文件是可以被缓存的静态文件，因此，如果您添加适当的缓存控件、expiry 头部以及其他影响浏览器缓存的头部元数据，就可以明显改善用户体验。浏览器缓存机制有几个影响浏览器缓存的规则，这个小节将分别讨论它们。Cache-Contro

6、lCache-Control 是最重要的规则。这个字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令。这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。这些指令通常覆盖默认缓存算法。缓存指令是单向的，即请求中存在一个指令并不意味着响应中将存在同一个指令。cache-control 定义是：Cache-Control = Cache-Control : cache-directive。表 1 展示了适用的值。表 1. 常用 cache-directive 值Cache-directive说明public所有内容都将被缓存private内容只缓存到私有缓存中no-cache所有内容都

7、不会被缓存no-store所有内容都不会被缓存到缓存或 Internet 临时文件中must-revalidation/proxy-revalidation如果缓存的内容失效，请求必须发送到服务器/代理以进行重新验证max-age=xxx （xxx is numeric）缓存的内容将在xxx秒后失效表 2 表明在不同的情形下，浏览器是将请求重新发送到服务器还是使用缓存的内容。表 2. 对 cache-directive 值的浏览器响应打开一个新的浏览器窗口在原窗口中单击 Enter 按钮刷新单击 Back 按钮浏览器呈现来自缓存的页面浏览器重新发送请求到服务器第一次，浏览器重新发送请求到服务器

8、；此后，浏览器呈现来自缓存的页面no-cache/no-store在秒后，浏览器重新发送请求到服务器Cache-Control 是关于浏览器缓存的最重要的设置，因为它覆盖其他设置，比如 Expires 和 Last-Modified。另外，由于浏览器的行为基本相同，这个属性是处理跨浏览器缓存问题的最有效的方法。失效Expires 头部字段提供一个日期和时间，响应在该日期和时间后被认为失效。失效的缓存条目通常不会被缓存（无论是代理缓存还是用户代理缓存）返回，除非首先通过原始服务器（或者拥有该实体的最新副本的中介缓存）验证。（注意：cache-control max-age 和 s-maxage

9、将覆盖 Expires 头部。）Expires 字段接收以下格式的值：“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。如果查看内容时的日期在给定的日期之前，则认为该内容没有失效并从缓存中提取出来。反之，则认为该内容失效，缓存将采取一些措施。表 3-6 表明针对不同用户操作的不同浏览器的行为。表 3. 当用户打开一个新的浏览器窗口时的失效操作Firefox 3.5IE 8Chrome 3Safari 4内容没有失效浏览器重新发送请求到服务器。返回代码是 200内容失效表 4. 当用户在原始浏览器窗口中单击 Enter 按钮时的失效操作返回代码是 304表 5.

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

11、的浏览器有不同的配置行为。表 7-10 表明针对不同用户操作的不同浏览器的行为。表 7. 当用户打开一个新的浏览器窗口时的 Last-Modified E-Tag 操作内容自上次访问以来没有被修改内容自上次访问以来已经被修改表 8. 当用户在原始浏览器窗口中单击 Enter 按钮时的 Last-Modified E-Tag 操作表 9. 当用户按 F5 键刷新页面时的 Last-Modified E-Tag 操作表 10. 没有缓存设置且用户单击 Back 或 Forward 按钮所有浏览器都假定使用默认设置运行。不进行任何缓存相关设置如果您不定义任何缓存相关设置，则不同的浏览器有不同的行为。

12、有时，同一个浏览器在相同的情形下每次运行时的行为都是不同的。情况可能很复杂。另外，有些不该缓存的内容如果被缓存，将会导致安全问题。不同的浏览器有不同的行为。表 11 展示了不同的浏览器行为。表 11. 没有缓存设置且用户打开一个新的浏览器窗口打开一个新页面在原始窗口中单击 Enter 按钮浏览器呈现来自缓存的页面。按 F5 键刷新单击 Back 或 Forward 按钮应用示例本小节提供几个 Web 站点分析示例，展示如何使用 IBM 商业和开源工具确定正确的缓存行为。Apache Roller WebloggerApache Roller Weblogger 是一个开源 Web 2.0 We

13、b 应用程序，它是驱动 、blog.usa.gov、IBM Lotus Connections、IBM Developer Works 博客等大量博客的开源 Java 博客服务器，在本文中，我们选择 IBM My developerWorks 博客作为一个示例，详细解释缓存设置。图 1 展示了 My developerWorks 博客页面的一个屏幕截图。图 1. My developerWorks 博客页面这个页面有 62 个请求，多数是 png、gif、js 或其他静态文件类型。当用户首次访问这个页面时，将花费约 16 秒时间来在浏览器中显示整个页面。如果您定义正确的缓存设置，多数资源将被缓

14、存到浏览器端。因此，当用户再次访问这个页面时，这个页面的请求数量将减少到 22，只需约 6 秒钟就可以加载。用户体验得到极大地改善。现在，我们将分析一些重要的请求缓存设置。相关的 Weblogger 输出如图 2 所示。图 2. My developerWorks 博客主页 Response Header 1首先，Cache-Control 覆盖 Last-Modified 设置，因此页面可以在本地缓存 5 秒钟，但如果内容失效将重新验证。当用户访问这个页面时，浏览器首先检查本地缓存，以确定本地文件是否已经失效。如果内容失效，浏览器将发送一个请求到服务器以比较 Last-Modified 时间

15、戳。如果响应文件拥有相同的 Last-Modified 时间戳，则服务器将返回代码 304 到浏览器，告知浏览器响应文件相同。图 3. My developerWorks 博客主页 Response Header 2这个 Cache-Control 设置表明：这个响应不能被缓存。从业务角度看，这个请求用于检查用户验证和授权，不应该被缓存。图 4. My developerWorks 博客主页 Response Header 3这个响应文件是一个很少修改的 JavaScript 库，因此它的 max-age 等于 1 天。Mashup CenterMashup Center 设计用于提供一个易于

16、使用的 mashup 解决方案，支持将多个动态情景应用程序集合到一个业务范围中，并提供 IT 所需的安全和治理功能。Mashup Center 包含 Lotus Mashups 和 InfoSphere MashupHub。图 5 展示了正在运行的 Lotus Mashups 的快照。图 5. Mashup 主页图 6 和图 7 展示了选中的 HTTP 头部。图 6. Mashup 主页 Response Header 1这个请求检索可以从服务器缓存的主题信息。图 7. Mashup 主页 Response Header 2这是一个个人主页，不应该被缓存。注意，Expires 日期值设置为一个

17、很久以前的日期，以便这个页面总是能够刷新。结束语由于不同浏览器的复杂性，适当的缓存设置非常重要。在本文中，我们介绍了以下最佳实践： 尽可能多地缓存文件，以便减少加载次数并改善性能。 尽可能使用 cache-control 定义缓存行为，尤其是对 IE。这降低了不同浏览器之间的差别，是改善性能的最佳方法。 不要使用 “no settings related with cache”。 使用默认设置初次打开 IE 时，IE 浏览器几乎总是发送一个请求到服务器端以检索数据。 如果某个页面不应该被缓存，则使用 “cache-control: no-cache, no-store” 来确保该页面不会被缓存

18、，尤其是当数据涉及安全或敏感信息时。 除非必要，不要使用 post 请求，因为它不能被缓存。参考资料学习 查看HTTP Protocol Definition，了解基础知识。 阅读IBM developerWorks Blogs并加入讨论。 “N 揭秘：改善 Web 站点的性能”介绍了 Web 性能改进。 developerWorks技术活动和网络广播：随时关注 developerWorks 技术活动和网络广播。 developerWorks Web development 专区：通过专门关于 Web 技术的文章和教程，扩展您在网站开发方面的技能。获得产品和技术 开始使用Apache Roller Weblogger构建自己的博客项目。 了解关于IBM Mashup Center的更多信息并下载免费试用版。