Web Cache Tutorial for Web Authors and Webmasters(译)Part-2
原文标题: Caching Tutorial for Web Authors and Webmasters
原文地址: http://www.mnot.net/cache_docs/;
译文地址: http://www.sunnyu.com/?p=164
前段地址: Caching Tutorial for Web Authors and Webmasters(译)Part-1
本文由 sunny译于 2009.01.16 由于英文水平有限,译文难免有很多不足之处,欢迎指正。
Tips for Building a Cache-Aware Site
在使用 新鲜度信息 和 校验器 之前,你还可以做很多事情来使你的网站对缓存处理是友好的。
- Use URLs consistently — 这是做缓存处理的黄金准则. 如果你为不同页面,不同用户或不同网站提供相同的内容,他们应该使用相同的URL. 这很简单并且是一个很有效的方法使你的网站是cache-friendly. 比如,如果你使用“/index.html” 在你的HTML做为你网站的参考,那就总是这么使用.
- Use a common library of images 其他在不同地方的元素来引用他们.
- Make caches store images and pages that don’t change often 通过使用
Cache-Control: max-age
头信息设置一个很大的值. - Make caches recognize regularly updated pages 通过设置一个适当的 max-age 或 expiration 时间.
- If a resource (especially a downloadable file) changes, change its name. 这种办法,你可以设置他在未来很长时间后才失效并保障正确的文件版本被提供; 引用的页面文件则需要一个小的失效时间。
- Don’t change files unnecessarily. 如果你这么做了,新的Last-Modified日期将会使所有相关信息的验证失败. 比如, 在更新网站的时候,不要覆盖整网站,只对变化的文件做处理.
- Use cookies only where necessary — cookies很难被缓存,并且在多数时候并不是必须的.如果你必须使用Cookie,在动态页面中要有节制的使用。
- Minimize use of SSL — 因为加密的页面不会在共享缓存中保存, 只有在你必须用的时候采用, 在SSL页面中谨慎使用图片。
- use the Cacheability Engine — 可以帮助你应用本教程所阐述的很多观念。
Writing Cache-Aware Scripts
默认情况下, 很多脚本不会返回校验器 ( Last-Modified
或 ETag
回应头) 或新鲜度信息 (Expires
或 Cache-Control 头信息
).有一些脚本确实是动态的 (意味着每一次请求都返回不同的内容), 但更多 (像搜索引擎和基于数据库的网站) 的是可以从缓存中获得好处的。
一般说来,如果一个请求的内容在一段时间后(一些分钟后或一些天后)可以使用同样的请求重现, 它应该是可缓存化的。如果返回内容只和请求的URL地址有关,那么它是可缓存的;如果输出内容和Cookie,验证信息或其他外部标准有关,那么它们一般是不可缓存的。
- 将脚本缓存化的最好的办法是将将变化后的内容导出保存到一个文件中, 然后Web服务器可以将他们和其他Web页面一样看待,生成和使用校验器, 这样可以使你的工作容易些。记住:只要写那些发生了变化的文件, 这样
Last-Modified
的时间就是实际期望的。 - 另外一种方法就是给内容设置一个时间相关的头信息(适合使用的足够长时间)。 可以通过
Expires
头信息设置,不过更简单的是通过Cache-Control: max-age
头信息来做,他使内容在请求发生后的一个足够长时间内保持鲜活的。 - 如果你不能那么做,那么你需要通过脚本生成一个校验器, 然后回应
If-Modified-Since
和/或If-None-Match
请求. 这个可以通过分析HTTP头信息, 然后在适合的时候回应一个304 Not Modified
。 不幸的是,这是个不简单的任务。
其他一些技巧;
- Don’t use POST 除非是适合的. 大多数缓存器对POST方法的回应是不做缓存的; 如果你使用GET方法获取信息,缓存器可以保存信息为将来使用.
- Don’t embed user-specific information in the URL 除非生成的内容完全和那个用户相关。
- Don’t count on all requests from a user coming from the same host, 因为缓存器通常是一起工作的。
- Generate
Content-Length
response headers. 这个很容易做, 它将使你脚本的回应使用一个 持久连接(persistent connection)。 他允许客户端通过一个 TCP/IP 连接请求很多内容, 而不是对每个请求都建立一次连接. 他使你的网站看上去比较快.
查看 Implementation Notes 获取更多信息。
Frequently Asked Questions
What are the most important things to make cacheable?
一个很好的策略就是先鉴别出最热门,使用量最大的内容(特别是图片),拿它们先开刀.
How can I make my pages as fast as possible with caches?
最适合缓存化的内容要给他设置一个长的用来保持新鲜度的时间。校验器会来计算减少这个鲜活时间,但是缓存器仍然会和原始服务器做交互来检查看它是否是新鲜的。如果缓存器知道它是新鲜的,就直接从缓存器中提供给客户端显示用。
I understand that caching is good, but I need to keep statistics on how many people visit my page!
如果你必须知道每一次页面被访问的情况, 在页面上选中一个小元素 (或页面信息), 通过设置一个适当的头信息使它是不可缓存的. 比如, 你可以在每一个页面上引用一个 1×1 的不可缓存透明图片. Referer
头信息将会包含调用它的页面信息.
请注意,即使这样也不能给出关于你用户的精确统计, 并且对通过互联网访问的用户也不是很友好,他产生不必要的流量, 并强迫用户等待未被缓存的内容从网络上下载回来, see On Interpreting Access Statistics in the references.
How can I see a representation’s HTTP headers?
很多浏览器使你能够在”page info”或类似的界面中看到 Expires
和 Last-Modified
头信息。如果有的化,会给你一个关于页面和其上相关内容的细节内容菜单.
为了看到内容的完整头信息,你可以使用Telnet客户端手工连接到Web服务器.
要注意的是,你必须指定连接的端口(一般是80),比如你可以连接到 www.example.com:80
或 www.example.com 80
(注意空格). 具体查看你telnet客户端的文档.
当你连接到一个网站后,输入请求内容。比如, 如果你想看到 http://www.example.com/foo.html 的头信息
, 首先连接到 www.example.com
, 80
端口,并输入:
GET /foo.html HTTP/1.1 [return] Host: www.example.com [return][return]
[return]等同
敲回车键; 确认最后输入两次.这样将输出头信息,然后跟着实际内容. 如果只想看到头信息, 使用HEAD 来替换 GET.
My pages are password-protected; how do proxy caches deal with them?
默认情况下, 被HTTP验证保护的页面被当作是私有的; 他们不会在共享缓存中保留. 然而你可以使用Cache-Control: public 头信息将被验证保护地页面标志为公共的; 这样HTTP 1.1-compliant 的缓存器将允许他们被缓存。
如果你期望这些文件被缓存, 但仍然要多每一个用户做验证, 将 Cache-Control: public
和 no-cache
头信息组合起来。这告诉缓存器它在从缓存中送出内容前必须递交客户端的验证给原始的服务器。这个头信息如下所示:
Cache-Control: public, no-cache
不用管它是怎么做的, 它最小化了验证过程; 比如:如果你的图片是不敏感的, 将他们放到一个单独的目录并配置你的服务对他们不做强制验证。这样,那些图片就会很自然的被缓存了。
Should I worry about security if people access my site through a cache?
SSL 页面不会被代理缓存, 因此你不需要担心会通过缓存获取敏感信息。 However, because caches store non-SSL requests and URLs fetched through them, 你必须对不安全的网站有所认识; 一个不道德的管理员可能会通过缓存搜集用户的信息(特别是在URL信息中)。
实际上,任何在网络上介于你服务器和客户机之间的管理员都可以收集这类信息. 个别情况如在CGI脚本在URL地址中传递用户名和密码信息时;这很容易让其他人发现用户的登陆信息。
不过如果你关注关于网站安全的一般性问题, 你就不会对代理缓存的这个情况感到惊奇。
I’m looking for an integrated Web publishing solution. Which ones are cache-aware?
这个是不确定的. 一般来说,越复杂的系统越难缓存. 最差的情况就是所有的内容都是动态生成,并且不提供校验器; 他们根本不可能被缓存. 和你的供应商的技术人员沟通获取更多信息, 然后看下面的 Implementation notes.
My images expire a month from now, but I need to change them in the caches now!
Expires头信息设置的时间不会被中断破坏; 除非缓存器 (浏览器或代理) 主动删除内容, 否则缓存的内容会被保留使用直到设定的时间。
最有小的解决方法就是修改任何指向他们的连接; 这样, 就会从原始服务器中完整的获得新内容。记住被页面引用的内容用也会被缓存. 因为这个原因,最好使HTML页面指向的那些静态图片或类似内容也是很好缓存的。
如果你想让指定的缓存器重新加载一个内容, 你可以在浏览器中强制重新加载一个被缓存的内容(在Firefox中, 在点 重新加载 按钮的时候按住 shift 键,将处理一个 Pragma: no-cache
请求头)。 或, 你可以让缓存管理员通过他们可以使用的接口界面删除缓存内容。
I run a Web Hosting service. How can I let my users publish cache-friendly pages?
如果你使用的是Apache, 考虑允许他们使用.htaccess 文件并提供适合的文档。
否则你需要在每一个虚拟主机上为各种缓存属性建立预定的区域。比如:你可以指定一个叫 /cache-1m 的目录用来放读取后要缓存一个月的内容,然后再建一个/no-cache的目录在头信息中指定这么目录中的内容不要被缓存。
不管你能够怎么做,最好先给最大量的用户内容做缓存处理。在大型网站上这会给网络流量和机器负载上节约很多。
I’ve marked my pages as cacheable, but my browser keeps requesting them on every request. How do I force the cache to keep representations of them?
通常缓存器会对一个标志缓存的内容做本地备份并重用它,但是在某些条件下一些内容不会被缓存重新使用。 缓存器基本上是基于内容的大小,类型(图片或html文件)或如果保留它们需要占用多少本地空间等来决定一个内容是否被缓存重用。
一些缓存器允许管理员设置对不同类别内容的保留优先级,另外一些则允许一些内容驻留(“pinned”)在缓存中,这样他们总是可用的。
Popularity: 6% [?]
Related
Comments
2 Responses to “Web Cache Tutorial for Web Authors and Webmasters(译)Part-2”
[...] Cache Tutorial (译)Part-1(2009-01-15)和Web Cache Tutorial (译)Part-2(2009-01-16)(从头到尾能够酱油的就酱油,还有1/3缺失~) [...]
[...] Cache Tutorial (译)Part-1(2009-01-15)和Web Cache Tutorial (译)Part-2(2009-01-16)(从头到尾能够酱油的就酱油,还有1/3缺失~) [...]