Web Cache Tutorial for Web Authors and Webmasters(译)Part-1
原文标题: Caching Tutorial for Web Authors and Webmasters
原文地址: http://www.mnot.net/cache_docs/;
译文地址: http://www.sunnyu.com/?p=163
本文由 sunny译于 2009.01.15 由于英文水平有限,译文难免有很多不足之处，欢迎指正。
What’s a Web Cache? Why do people use them?
Web cache 存在于客户端和服务器（原始服务器)之间,它监测过来的请求并将对请求的回应做拷贝保存 — 使其就像通常的HTML页面, 图片和文件一样 (collectively known as representations). 然后当有另外一个同样的请求（相同的url地址参数)过来的时候,他就使用前面复制保存的内容做回应而不是再次从原始服务器获取回应内容.
使用 Web caches 主要有以下两个主要原因:
- 降低延时 — 因为用户请求不是从原始服务器返回而是从Cache返回（离客户更近), 所以客户端可以花更少的时间获取并显示它. 这样使网站看起来更快响应.
- 降低网络流 — 因为表现内容被重用, 它大大降低了用户使用的网络带宽，这样也变相节约了金钱（如果客户要为流量付费), 他将低了对网络带宽的要求并且便于管理.
Kinds of Web Caches
Browser Caches
如果你检查网页浏览器的偏好设置对话框，你应该会看到”Cache”设置的项目。这个设置项通过使用你本地机器上的一些硬盘空间来存储你用浏览器看到的内容。浏览器端的Cache使用很简单的机制工作。他通常会在一次浏览期间检查确认要显示的内容是新的。
这种Cache在用户按”back”按钮或这点击一个刚刚看过的链接地址时显得特别有用。同样，如果你在整个网站中使用同样的导航图片,也会从浏览器的Cache中获得巨大好处。
Proxy Caches
Web proxy caches 基于和浏览器Cache类似的规则,但是更具有可伸缩性. Proxies 使用相同的方法为成千上万的用户提供服务;大企业和ISP通常会在他们的防火墙上设置它（或在一些独立的设备上设置)。
因为proxy caches不是客户机或服务器的一部分,但是他们存在于网络上，通常客户的请求会通过一些方式路由到Proxy Cache这儿.一种方式就是在你的浏览器的代理设置中手工告诉你要使用的代理服务器。另外一种方式便是拦截. Interception proxies 将用户的请求通过下层网络进行重定向, 因此客户不需要进行设置，甚至于不知道有它存在。
Proxy caches 是一种共享缓存(shared cache); 和只有一个用户使用的浏览器缓存不同的是，他通常有大量的用户在使用，因此他能大量减少响应延时和网络通讯，因为热门的内容可以被重用n多次。
Gateway Caches
Also known as “反向代理(reverse proxy caches)” or “surrogate caches,” gateway caches 也是一个中介物, 但它不是由网管设置用来节约浏览，通常是由 网站管理员自己设置来时他们的网站具有更好可伸缩性，可用性和更好的性能.
请求可以有多种方法路由到 gateway caches , 但是典型的负载均衡方式会将他们中的一个或多个原始服务器当作客户端看待.
Content delivery networks (CDNs) distribute gateway caches throughout the Internet (or a part of it) and sell caching to interested Web sites. Speedera and Akamai are examples of CDNs.
本篇教程关注点主要在浏览器缓冲和代理缓存，然而一些信息同样适合于gateway cache。
Aren’t Web Caches bad for me? Why should I help them?
Web Caching 是在互联网方面最易被误解的一项技术。网站管理员有点害怕对他们的网站失去控制，因为proxy Cache会对他们”隐藏”他们的用户，使他们很难得到是哪些人访问了他们的网站。
然而对这些人有些不幸的是, 即使 Web caches 不存在, 在互联网上仍然会有很多变化用来保障他们能够精确的获取用户是怎样看他们网站的。如果这是是你关注的大方面，本教程将会教会你在保留缓存的情况下怎样获取这些你需要的这些统计信息。
另一方面，缓存会提供过时（陈旧)的内容，本教程将教会你怎样配置你的服务器来控制被缓存的内容。
CDNs are an interesting development, because unlike many proxy caches, their gateway caches are aligned with the interests of the Web site being cached, so that these problems aren’t seen. However, even when you use a CDN, you still have to consider that there will be proxy and browser caches downstream.
另一方面，如果你很好的对您的网站进行了规划，缓存将能够帮助你提高网站的压力负载响应更多的用户连接。差异是显著的; 一个没有很好缓存处理的网站或许会化好一会时间加载页面, 然而和一个从缓存中获得好处的网站做比较就会显得不怎么样。用户喜欢快速的网站，将会引起更多次的访问.
想象一下，很多大型的互联网公司花费大量的金钱在世界各地建立了很多服务器用来复制他们的内容，目的就是想为他们的用户提供尽可能快的存取速度。缓存可以为你做同样的事情，并且他们更接近于客户。最重要的是，你不必为此额外付费.
其实不管你喜不喜欢，代理缓存和浏览器缓存都被被应用. 如果你不能正确配置你网站的cache，他就会按照采用默认的方式（或缓存管理员决定的的方式)做缓存.
How Web Caches Work
所有的缓存器都有一些规则用来决定什么时候从缓存中提供内容. 其中一些规则由 (HTTP 1.0 and 1.1)协议指定, 还有一些由缓存的管理员设定 (浏览器缓存的使用者或代理的管理员).
一般说来，有如下一些通用规则 (如果你不明白细节，不要担心，后面会有详细说明):
- 如果回应的头信息告诉缓存不要保留他，缓存就不保留它
- 如果被请求的内容是需要验证（安全保护的)，他不应该被缓存
- 如果没有校验器 (
ETag或Last-Modified头信息) 在回应中设置, 并且没有任何显式的关于新鲜度的信息, 将被当作不可缓存的. - 如果满足下列情况，一个被缓存的内容可以被认为是新鲜的（fresh ）(意味这可以直接发送给客户端而不用检查原始服务器) :
- 如果有失效时间（expiry time）或其他关于时间控制的 头信息 被设置，并且仍然在新鲜(fresh)的时间里面.
- 如果浏览器缓存已经看到内容，并且被设置为一次浏览期间只检查一次.
- 如果代理缓存最近看到内容并被修改成相对之前很长的一段时间.
新鲜的内容不用检查原始的服务器，直接从重缓存中提供.
- 如果内容是过时的，原始服务器将被用来验证检查（validate）或告诉缓存该内容的拷贝是否还是好的.
新鲜度(freshness) 和校验器(validation) 对缓存内容很重要.一个新鲜的内容将被立即从缓存中返回，校验过的内容避免失效内容被发送.
How (and how not) to Control Caches
有一些工具可供网站设计人员和网站管理员来对网站的缓存使用情况进行调优。也许在配置服务器的过程中是手脏一点，但显然做这些是值得。 在您服务器上使用这些工具的具体细节可以参照下面的 Implementation 段落.
HTML Meta Tags and HTTP Headers
HTML 作者可以在 <HEAD> 段插入一些Tag. These meta tags are often used in the belief that they can mark a document as uncacheable, or expire it at a certain time.
Meta tags 很容易使用，但不是很有效. 那是因为他们只被一些浏览器缓存使用(他们实际读入 HTML 页面), 不是代理缓存(他们根本不读入HTML信息). 然而可以通过放一个 Pragma: no-cache 的meta标签到Web页面上, it won’t necessarily cause it to be kept fresh.
如果你的网站托管在 ISP 或者主机托管商那里，并且他们没有赋予您任意设置HTTP头信息的能力，(比如 Expires 和 Cache-Control), 要大声抱怨，因为在你的工作中这些是必须的。
另一方面, 真实的 HTTP headers 将给你很多关于浏览器缓存和代理缓存对于你页面内容缓存行为的控制。他们在HTML页面中不可见，通常是由Web服务器自动生成的。然后，你可以在某种程 度上对他们进行控制（具体要看你所使用的服务器)。下面的章节，你经看到哪些HTTP头信息应该被关注，并且怎么在你的网站中应用他们。
服务器在HTML信息前发送HTTP头信息, 他们被浏览器和任意中间缓存看到. 典型的 HTTP 1.1 回应头信息可能如下面这样:
HTTP/1.1 200 OK Date: Fri, 30 Oct 1998 13:19:41 GMT Server: Apache/1.3.3 (Unix) Cache-Control: max-age=3600, must-revalidate Expires: Fri, 30 Oct 1998 14:19:41 GMT Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT ETag: "3e86-410-3596fbbc" Content-Length: 1040 Content-Type: text/html
HTML 信息将有一个空行分隔跟随在这些头信息后面，查看 Implementation 章节看怎么设置 HTTP 头信息.
Pragma HTTP Headers (and why they don’t work)
很多人相信，设置一个Pragma: no-cache 的HTTP 头信息中将使内容不会被缓存。但这个不是总成立； HTTP 规范未对Pragma回应头信息做任何设置指导。 但是有关于 Pragma 的请求头信息 (由浏览器发送给服务器的头信息) 的讨论。虽然有些缓存对此做实现，但是主流的并未实现，使用这个并没有任何效果。要使用下面说明的一些头信息来控制。
Controlling Freshness with the Expires HTTP Header
Expires 是用来控制缓存的基本HTTP 头信息; 它告诉所有的缓存相关的内容将会保持新鲜多长时间. 在那时间后, 缓存将和原始服务器做比较检查看内容是否发生改变. Expires头信息几乎被所有的缓存支持。
多数服务器允许你通过多种方式设置 Expires 回应头信息. 通常，他们允许设置一个失效的绝对时间, a time based on the last time that the client saw the representation (last access time), or a time based on the last time the document changed on your server (last modification time).
Expires 头信息特别适合于使静态图片缓存化(比如导航条和按钮图片). 因为他们通常不会发生变化，你可以给他们设定一个相对长的失效时间，是你的网站更快的回应用户的请求. 他们也适合控制定期改变的页面缓存. 比如, 如果你在每天早晨6点半更新一个新页面，你可以设置为在那个时间失效, 这样缓存器就知道什么时候应该获取一个新的拷贝,不需要用户按 “刷新” 按钮。
在 Expires 头信息中只能使用 HTTP date; 任何其他的内容基本上会被解释为 ‘in the past’, 这样内容将不会被缓存，同样要记住，HTTP date 是格林威治时间(GMT),不是本地时间.
一个例子:
Expires: Fri, 30 Oct 1998 14:19:41 GMT
有一点很重要，如果你使用 Expires 头信息，您应该确保Web服务器的时间是精确的.你可以通过使用 Network Time Protocol (NTP) 协议来做到;和你本地机器的管理员沟通一下。
虽然 Expires 头很有用, 它还是有有些限制. 首先, 由于和时间有关, 服务器的和缓存机器的时间必须同步;如果时间不一致, 可能不会达到期望的效果,缓存机可能错误的将过时的内容当作新鲜的.
另外一个问题是,它很容易忘记一些信息被设置为在某一个具体时间后失效. 如果你不在他失效前更新失效时间，之后的每一次请求都会回到你真实的Web服务器上，增加了负载和延时.
Cache-Control HTTP Headers
HTTP 1.1 阐述了一个新类别的头信息： Cache-Control 回应头信息, 给Web发布者们更多关于他们内容的缓存的控制，由此避免 Expires 的缺点。
有用的 Cache-Control 回应头信息包括:
max-age=[seconds] — 设定最长多长时间内认为该内容是新鲜的，和Expires 有点类似, 该指令是相对于请求的时间。 [seconds] 是相对于请求时间你期望保持新鲜度的时间.s-maxage=[seconds] — 类似max-age, 除了他只对共享的缓存器作用 (比如 proxy).public— 标志验证过的回应是可缓存的;通常，如果需要 HTTP 验证, 回应会自动不可缓存化 (针对共享缓存).no-cache— 每一次在释放一个缓存内容前都强制缓存器将请求提交给原始的服务器来校验. 这个在期望做鉴定保证的时候很有用(通常和 public 做组合), 或用来维护一个严格的新鲜内容，牺牲缓存带来的好处。no-store— 指示缓存器在任何情况下都不要在本地保留拷贝.must-revalidate— tells caches that they must obey any freshness information you give them about a representation. HTTP allows caches to serve stale representations under special conditions; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.proxy-revalidate— 类似must-revalidate, 除了它只对 proxy缓存器作用。
一个例子:
Cache-Control: max-age=3600, must-revalidate
如果你计划使用 Cache-Control 头信息, 你应该好好看一下 HTTP 1.1 文档; see References and Further Information.
Validators and Validation
在 How Web Caches Work, 我们说校验被服务器和缓存器使用来交流什么时候一个内容发生了变化. 通过使用它, 缓存器避免下载本地已经有的但是不确定是否仍然是新鲜的内容.
校验器很重要; 如果对一个内容缓存器中现在没有拷贝，并且这个内容没有关于新鲜度的信息 (Expires 或 Cache-Control) , 缓存器将根本不对其做拷贝保存.
通常 校验器 是文档最后修改的时间, 由Last-Modified 头信息交互. 当缓存器有一个包含 Last-Modified 信息的内容被保存, 他可以使用这个信息去询问服务器这个内容是否发生了改变( 通过一个If-Modified-Since 请求).
HTTP 1.1 引入一个新的叫 ETag 的校验器. ETags 是一个有服务器端生成的唯一标识,并且每一次内容发生变化ETag也会发生变化. 因为服务端控制 ETag 怎样生成, 缓存器可以通过判断 ETag 是否匹配来看本地拷贝的内容是否和服务器端的一样(通过一个If-None-Match 请求).
几乎所有的缓存都使用 Last-Modified 时间来判断一个内容是否是新的; ETag 校验也变得很流行。
目前多数Web服务器会自动为静态内容（比如图片文件）生成 ETag 和 Last-Modified 头信息来当作校验器; 你不需要做任何事情。然而, 对于动态的内容，他们没有足够信息去自动生成这个信息 (比如 CGI, ASP 或 数据库的网站); see Writing Cache-Aware Scripts.
Popularity: 5% [?]
Related
Comments
3 Responses to “Web Cache Tutorial for Web Authors and Webmasters(译)Part-1”
[...] Web Cache Tutorial for Web Authors and Webmasters(译)Part-1 : sunnyu [...]
[...] web制作、开发人员需知的Web缓存知识 发表[ 2015年5月25日2015年5月25日 ]作者[ cgb1021 ] 分类[ html&css ]浏览[ 1 ] 本文原址：http://www.mnot.net/cache_docs/（常年更新） 已有译作：面向站长和网站管理员的Web缓存加速指南(2007-09-06)（开始翻译不错、后面就……）、Web Cache Tutorial (译)Part-1(2009-01-15)和Web Cache Tutorial (译)Part-2(2009-01-16)（从头到尾能够酱油的就酱油，还有1/3缺失~） 朝花夕拾：zhangxinxu [...]
[...] by zhangxinxu from http://www.zhangxinxu.com 本文地址：http://www.zhangxinxu.com/wordpress/?p=3338 .web_cache_index a:visited{color:#cd0000;}sup{color:#666; letter-spacing:-1px;}.right_exp{width:240px; float:right; border-left:1px solid #ccc; padding-left:1em!important; margin-left:1em; color:#666;} 本文原址：http://www.mnot.net/cache_docs/（常年更新） 已有译作：面向站长和网站管理员的Web缓存加速指南(2007-09-06)（开始翻译不错、后面就……）、Web Cache Tutorial (译)Part-1(2009-01-15)和Web Cache Tutorial (译)Part-2(2009-01-16)（从头到尾能够酱油的就酱油，还有1/3缺失~） 朝花夕拾：zhangxinxu [...]