Http页面缓存机制Word格式.docx
《Http页面缓存机制Word格式.docx》由会员分享，可在线阅读，更多相关《Http页面缓存机制Word格式.docx（15页珍藏版）》请在冰点文库上搜索。
但是，这些应用程序的确带来了一种新的Internet使用模式。
现在，Web2.0应用程序拥有许多典型特征，包括拥有富客户端、大页面、包含许多小项目的页面、大量的JavaScript编码等等。
这些特征会导致浏览器端性能问题，特别是在长距离网络中。
这些性能问题会对用户体验造成不利影响，但您甚至不会意识到这些问题的存在。
由于开发人员拥有很好的网络条件，因此这些性能问题很难完全暴露出来。
本文将首先分析典型的Web2.0应用程序的关键方面，解释它们如何影响浏览器端性能。
然后，本文介绍浏览器端性能的一个非常重要的部分——浏览器缓存。
通过使用适当的缓存设置，您可以向用户提供较好的应用程序体验。
如果您没有一个整体缓存策略设计，那么您的缓存策略不仅会导致低劣的性能，还会引发一些功能缺陷。
有许多影响浏览器缓存的规则，其中的部分规则包括Cache-Control、Etag、Expires、Last-Modified和Vary。
所有这些设置拥有不同的含义和最适用的情形。
困难之处在于对于相同的设置，并不是所有流行浏览器都拥有相同的行为。
因此，在您决定使用这些设置之前，您应该准确了解这些浏览器是如何工作的。
本文将检查目前市面上最流行的浏览器的行为：
InternetExplorer、Firefox、Chrome和Safari。
在本文中，我们还使用IBM®
Mashups和开源“RollerWeblogger”来提供一些示例，展示如何应用不同的指令以最好地使用浏览器缓存。
背景
在当今的Internet环境中，Web2.0应用程序正在变得越来越流行。
许多Web站点都使用Web2.0构建，比如Facebook、Youtube等。
IBM也有Web2.0应用程序，比如LotusConnections和LotusMashups。
以下是一种用于计算浏览器响应时间的基本方法：
∙浏览器响应时间=服务器端时间+页面加载时间+浏览器呈现时间
∙页面加载时间=（请求数/并发数）*延迟时间+页面总大小/带宽
在上述等式中：
∙“服务器端时间”是指服务器端处理所花费的时间，比如通过LDAP验证和从数据库检索信息。
∙“浏览器呈现时间”是指浏览器呈现页面所花费的时间，包括执行JavaScript和解析DOM树的时间。
∙“请求数”是指HTTP请求的数量。
∙“并发数”是指浏览器与服务器之间的并行连接的数量。
∙“页面总大小”是指一个页面的完整大小。
∙“延迟时间”和“带宽”是网络状态指标。
在常见的长距离网络环境中，带宽大约为1M，延迟时间大约为100毫秒。
因此，减少到100KB或减少为一个请求能够节约0.1秒响应时间。
请注意一点，鉴于真实环境的复杂性，这个等式可能不能涵盖所有情形。
在一个典型的Web2.0富Internet应用程序（例如LotusMashupMaker）中，浏览器首先发送格式定义请求到服务器。
接收到定义响应数据后，浏览器向服务器发送数据请求。
然后，浏览器对用户呈现页面。
在这种模式中，有大量的小项目请求，比如JavaScript文件、CSS文件等。
在长距离网络环境中，这会导致严重影响用户体验的客户端性能问题。
大多数文件是可以被缓存的静态文件，因此，如果您添加适当的缓存控件、expiry头部以及其他影响浏览器缓存的头部元数据，就可以明显改善用户体验。
浏览器缓存机制
有几个影响浏览器缓存的规则，这个小节将分别讨论它们。
Cache-Control
Cache-Control是最重要的规则。
这个字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令。
这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。
这些指令通常覆盖默认缓存算法。
缓存指令是单向的，即请求中存在一个指令并不意味着响应中将存在同一个指令。
cache-control定义是：
Cache-Control="
Cache-Control"
"
:
"
cache-directive。
表1展示了适用的值。
表1.常用cache-directive值
Cache-directive
说明
public
所有内容都将被缓存
private
内容只缓存到私有缓存中
no-cache
所有内容都不会被缓存
no-store
所有内容都不会被缓存到缓存或Internet临时文件中
must-revalidation/proxy-revalidation
如果缓存的内容失效，请求必须发送到服务器/代理以进行重新验证
max-age=xxx（xxxisnumeric）
缓存的内容将在
xxx
秒后失效
表2表明在不同的情形下，浏览器是将请求重新发送到服务器还是使用缓存的内容。
表2.对cache-directive值的浏览器响应
打开一个新的浏览器窗口
在原窗口中单击Enter按钮
刷新
单击Back按钮
浏览器呈现来自缓存的页面
浏览器重新发送请求到服务器
第一次，浏览器重新发送请求到服务器；
此后，浏览器呈现来自缓存的页面
no-cache/no-store
在
秒后，浏览器重新发送请求到服务器
Cache-Control是关于浏览器缓存的最重要的设置，因为它覆盖其他设置，比如Expires和Last-Modified。
另外，由于浏览器的行为基本相同，这个属性是处理跨浏览器缓存问题的最有效的方法。
失效
Expires头部字段提供一个日期和时间，响应在该日期和时间后被认为失效。
失效的缓存条目通常不会被缓存（无论是代理缓存还是用户代理缓存）返回，除非首先通过原始服务器（或者拥有该实体的最新副本的中介缓存）验证。
（注意：
cache-controlmax-age和s-maxage将覆盖Expires头部。
）
Expires字段接收以下格式的值：
“Expires:
Sun,08Nov200903:
37:
26GMT”。
如果查看内容时的日期在给定的日期之前，则认为该内容没有失效并从缓存中提取出来。
反之，则认为该内容失效，缓存将采取一些措施。
表3-6表明针对不同用户操作的不同浏览器的行为。
表3.当用户打开一个新的浏览器窗口时的失效操作
Firefox3.5
IE8
Chrome3
Safari4
内容没有失效
浏览器重新发送请求到服务器。
返回代码是200
内容失效
表4.当用户在原始浏览器窗口中单击Enter按钮时的失效操作
返回代码是304
表5.当用户按F5键刷新页面时的失效操作
表6.当用户单击Back或Forward按钮时的失效操作
注意：
所有浏览器都假定为使用默认设置运行。
Last-Modified/E-Tag
Last-Modified实体头部字段值通常用作一个缓存验证器。
简单来说，如果实体值在Last-Modified值之后没有被更改，则认为该缓存条目有效。
ETag响应头部字段值是一个实体标记，它提供一个“不透明”的缓存验证器。
这可能在以下几种情况下提供更可靠的验证：
不方便存储修改日期；
HTTP日期值的one-second解决方案不够用；
或者原始服务器希望避免由于使用修改日期而导致的某些冲突。
不同的浏览器有不同的配置行为。
表7-10表明针对不同用户操作的不同浏览器的行为。
表7.当用户打开一个新的浏览器窗口时的Last-ModifiedE-Tag操作
内容自上次访问以来没有被修改
内容自上次访问以来已经被修改
表8.当用户在原始浏览器窗口中单击Enter按钮时的Last-ModifiedE-Tag操作
表9.当用户按F5键刷新页面时的Last-ModifiedE-Tag操作
表10.没有缓存设置且用户单击Back或Forward按钮
所有浏览器都假定使用默认设置运行。
不进行任何缓存相关设置
如果您不定义任何缓存相关设置，则不同的浏览器有不同的行为。
有时，同一个浏览器在相同的情形下每次运行时的行为都是不同的。
情况可能很复杂。
另外，有些不该缓存的内容如果被缓存，将会导致安全问题。
不同的浏览器有不同的行为。
表11展示了不同的浏览器行为。
表11.没有缓存设置且用户打开一个新的浏览器窗口
打开一个新页面
在原始窗口中单击Enter按钮
浏览器呈现来自缓存的页面。
按F5键刷新
单击Back或Forward按钮
应用示例
本小节提供几个Web站点分析示例，展示如何使用IBM商业和开源工具确定正确的缓存行为。
ApacheRollerWeblogger
ApacheRollerWeblogger是一个开源Web2.0Web应用程序，它是驱动、blog.usa.gov、IBMLotusConnections、IBMDeveloperWorks博客等大量博客的开源Java™博客服务器，
在本文中，我们选择IBMMydeveloperWorks博客作为一个示例，详细解释缓存设置。
图1展示了MydeveloperWorks博客页面的一个屏幕截图。
图1.MydeveloperWorks博客页面
这个页面有62个请求，多数是png、gif、js或其他静态文件类型。
当用户首次访问这个页面时，将花费约16秒时间来在浏览器中显示整个页面。
如果您定义正确的缓存设置，多数资源将被缓存到浏览器端。
因此，当用户再次访问这个页面时，这个页面的请求数量将减少到22，只需约6秒钟就可以加载。
用户体验得到极大地改善。
现在，我们将分析一些重要的请求缓存设置。
相关的Weblogger输出如图2所示。
图2.MydeveloperWorks博客主页ResponseHeader1
首先，Cache-Control覆盖Last-Modified设置，因此页面可以在本地缓存5秒钟，但如果内容失效将重新验证。
当用户访问这个页面时，浏览器首先检查本地缓存，以确定本地文件是否已经失效。
如果内容失效，浏览器将发送一个请求到服务器以比较Last-Modified时间戳。
如果响应文件拥有相同的Last-Modified时间戳，则服务器将返回代码304到浏览器，告知浏览器响应文件相同。
图3.MydeveloperWorks博客主页ResponseHeader2
这个Cache-Control设置表明：
这个响应不能被缓存。
从业务角度看，这个请求用于检查用户验证和授权，不应该被缓存。
图4.MydeveloperWorks博客主页ResponseHeader3
这个响应文件是一个很少修改的JavaScript库，因此它的max-age等于1天。
MashupCenter
MashupCenter设计用于提供一个易于使用的mashup解决方案，支持将多个动态情景应用程序集合到一个业务范围中，并提供IT所需的安全和治理功能。
MashupCenter包含LotusMashups和InfoSphereMashupHub。
图5展示了正在运行的LotusMashups的快照。
图5.Mashup主页
图6和图7展示了选中的HTTP头部。
图6.Mashup主页ResponseHeader1
这个请求检索可以从服务器缓存的主题信息。
图7.Mashup主页ResponseHeader2
这是一个个人主页，不应该被缓存。
注意，Expires日期值设置为一个很久以前的日期，以便这个页面总是能够刷新。
结束语
由于不同浏览器的复杂性，适当的缓存设置非常重要。
在本文中，我们介绍了以下最佳实践：
∙尽可能多地缓存文件，以便减少加载次数并改善性能。
∙尽可能使用cache-control定义缓存行为，尤其是对IE。
这降低了不同浏览器之间的差别，是改善性能的最佳方法。
∙不要使用“nosettingsrelatedwithcache”。
∙使用默认设置初次打开IE时，IE浏览器几乎总是发送一个请求到服务器端以检索数据。
∙如果某个页面不应该被缓存，则使用“cache-control:
no-cache,no-store”来确保该页面不会被缓存，尤其是当数据涉及安全或敏感信息时。
∙除非必要，不要使用post请求，因为它不能被缓存。
参考资料
学习
∙查看
HTTPProtocolDefinition，了解基础知识。
∙阅读
IBMdeveloperWorksBlogs
并加入讨论。
∙“N揭秘：
改善Web站点的性能”介绍了Web性能改进。
∙developerWorks
技术活动和网络广播：
随时关注developerWorks技术活动和网络广播。
∙developerWorksWebdevelopment专区：
通过专门关于Web技术的文章和教程，扩展您在网站开发方面的技能。
获得产品和技术
∙开始使用
ApacheRollerWeblogger
构建自己的博客项目。
∙了解关于
IBMMashupCenter
的更多信息并下载免费试用版。
升级会员 