原文地址：https://www.mnot.net/cache_docs/ #--仅作自己学习所用，不对翻译正误负责。
What’s a Web Cache? Why do people use them?
A Web cache sits between one or more Web servers (also known as origin servers) and a client or many clients,and watches requests come by, saving copies of the responses — like HTML pages, images and files (collectively known as representations) — for itself.
--web缓存处于web服务器(一个或多个,也叫做源服务器)和客户端(一个或多个)，监测获得的请求，为自身保存响应内容的副本，如HTML页面，图片和文件(统称为 representation！！--- 这里实在没找到一个好的词)。
Then, if there is another request for the same URL, it can use the response that it has, instead of asking the origin server for it again.
那么，如果有另一个相同URL的请求，web缓存直接用它已有的响应内容，而不是再次向源服务器请求。
There are two main reasons that Web caches are used:
To reduce latency — Because the request is satisfied from the cache (which is closer to the client) instead of the origin server, it takes less time for it to get the representation and display it. This makes the Web seem more responsive.
--减少延迟--因为请求获得的响应来自离客户较近的缓存而不是源服务器，这样花费较少的时间获得representation并显示。这样看起来Web响应更快速。
To reduce network traffic — Because representations are reused, it reduces the amount of bandwidth used by a client. This saves money if the client is paying for traffic, and keeps their bandwidth requirements lower and more manageable.
--减少网络流量--representations被重用从而减少了用户所用的带宽。这样可以减少用户费用，并保持带宽的低需求量和可控性。
Kinds of Web Caches
Browser Caches
If you examine the preferences dialog of any modern Web browser (like Internet Explorer, Safari or Mozilla), you’ll probably notice a “cache” setting.
--如果你检查任何现代web浏览器(如Internet explorer,Safari or Mozilla)的偏好设置对话框，你可能会注意到“cache”这个设置项。
This lets you set aside a section of your computer’s hard disk to store representations that you’ve seen, just for you.
--该设置项可以在你的电脑硬盘中留出一块来存储你浏览的representations，并且只是为你。
The browser cache works according to fairly simple rules.
--浏览器缓存通过相当简单的规则运作。
It will check to make sure that the representations are fresh, usually once a session (that is, the once in the current invocation of the browser).
--通常它每个会话检测一次(也即是在浏览器当前调用的时候)
This cache is especially useful when users hit the “back” button or click a link to see a page they’ve just looked at.
--这种缓存当用户点击回退按钮或者点击一个链接查看他们看过的内容时时十分有效的。
Also, if you use the same navigation images throughout your site, they’ll be served from browsers’ caches almost instantaneously.
--同样，如果同一个站点使用相同的导航图片，它们会被即时的从浏览器缓存中呈现出来。
Proxy Caches
Web proxy caches work on the same principle, but a much larger scale.
--web代理缓存使用同样的规则，不过规模更大。
Proxies serve hundreds or thousands of users in the same way; large corporations and ISPs often set them up on their firewalls, or as standalone devices (also known as intermediaries).
--代理以同样的方式为成百上千的用户服务，大的公司和ISP通常在他们的防火墙上架设代理缓存或者独立缓存设备(又被称为中介)。
Because proxy caches aren’t part of the client or the origin server, but instead are out on the network, requests have to be routed to them somehow.
--因为代理缓存不是客户端或者源服务器的一部分，它们处于网络之外，请求不得不被以某种方式路由到它们。
One way to do this is to use your browser’s proxy setting to manually tell it what proxy to use; another is using interception.
--一种方式是手动设置浏览器上的代理设置项告诉浏览器使用哪个代理;另一个使用拦截。
Interception proxies have Web requests redirected to them by the underlying network itself, so that clients don’t need to be configured for them, or even know about them.
--拦截代理通过基础网络使请求重定向到自身，这样用户就不需要自己配置它们，设置不知道它们的存在。
Proxy caches are a type of shared cache; rather than just having one person using them, they usually have a large number of users, and because of this they are very good at reducing latency and network traffic.
--代理缓存是一种共享缓存，不单单是使一个人可以使用它们，它们通常有大量的使用者，正因如此代理缓存可以很好地减少延时和网络流量。
That’s because popular representations are reused a number of times.
--进一步因为常用的representations可以被重用很多次。
Gateway Caches
Also known as “reverse proxy caches” or “surrogate caches,” gateway caches are also intermediaries, but instead of being deployed by network administrators to save bandwidth, they’re typically deployed by Webmasters themselves, to make their sites more scalable, reliable and better performing.
--网关缓存又被称作反向代理缓存或者代理缓存(只能照字面意思了= =)网关缓存也是中介，但不是被网络管理员配置来设置带宽，他们通常是由(万维网)站点管理 员来配置，使他们的站点更具扩展性，可靠性和更好的表现。
Requests can be routed to gateway caches by a number of methods, but typically some form of load balancer is used to make one or more of them look like the origin server to clients.
--请求可以通过一系列的方法被重定向到网关缓存，但是典型的一些加载平衡方式是使她们中的一个或多个对于客户端看起来更像源服务器。
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.
This tutorial focuses mostly on browser and proxy caches, although some of the information is suitable for those interested in gateway caches as well.
--这个教程主要针对浏览器和代理缓存，尽管一些内容对于网关缓存也适用。
Aren’t Web Caches bad for me? Why should I help them?
Web caching is one of the most misunderstood technologies on the Internet.
--web缓存是网络技术中最易误解的术语之一。
Webmasters in particular fear losing control of their site, because a proxy cache can “hide” their users from them, making it difficult to see who’s using the site.
--站点管理员特别担心对他们的站点失去控制，因为一个代理缓存可以隐藏他们的用户，使他们很难知道是谁在使用他们的站点。
Unfortunately for them, even if Web caches didn’t exist, there are too many variables on the Internet to assure that they’ll be able to get an accurate picture of how users see their site.
--不幸的是，即使web缓存不存在，网络中也会有很多因素来确保他们能够对用户如何使用他们的站点有一个准确的认识。
If this is a big concern for you, this tutorial will teach you how to get the statistics you need without making your site cache-unfriendly.
--如果这对你来说是一个大的问题，这个教程可以教你如何获得统计数据而不需要令你的站点缓存不友好化。
Another concern is that caches can serve content that is out of date, or stale. However, this tutorial can show you how to configure your server to control how your content is cached.
--另一个担心的问题是缓存可能会给用户提供过时的信息。不过，这个教程能够向你展示如何配置你的服务器来控制如何是你的内容被缓存。
On the other hand, if you plan your site well, caches can help your Web site load faster, and save load on your server and Internet link.
--另一方面，如果你能很好地规划你的网站，缓存可以帮使你的站点加载更快，并节省从你服务器负载和网络链接。
The difference can be dramatic; a site that is difficult to cache may take several seconds to load, while one that takes advantage of caching can seem instantaneous in comparison.
--好的规划和差的规划的差别是很大的，一个不能缓存的站点可能会花费几秒的时间来加载资源，而一个利用了缓存的站点则可以几乎即时显示。
Users will appreciate a fast-loading site, and will visit more often.
-- 用户倾向于浏览加载速度快的网站。
Think of it this way; many large Internet companies are spending millions of dollars setting up farms of servers around the world to replicate their content, in order to make it as fast to access as possible for their users.
--考虑一下这种情形，许多大的网络公司花费上百万美元在全世界建立服务器群来复制他们的内容，用以为用户提供尽可能快的获取速度。
Caches do the same for you, and they’re even closer to the end user. Best of all, you don’t have to pay for them.
-- 缓存可以为你做同样的事情，并且它们更加接近终端用户。最好的是，你不需要支付任何费用。
The fact is that proxy and browser caches will be used whether you like it or not.
--事实上代理和浏览器缓存不管你喜欢不喜欢都会被使用。
If you don’t configure your site to be cached correctly, it will be cached using whatever defaults the cache’s administrator decides upon.
--如果没有正确的配置你的站点缓存，它将会以默认的方式或者缓存管理员决定的方式来进行缓存。
How Web Caches Work
All caches have a set of rules that they use to determine when to serve a representation from the cache, if it’s available.
--所有的缓存都有一个规则集合用来决定什么时候从缓存中提供representation，在可以获得的情况下。
Some of these rules are set in the protocols (HTTP 1.0 and 1.1), and some are set by the administrator of the cache (either the user of the browser cache, or the proxy administrator).
--其中一些规则由(HTTP 1.0 和1.1)协议制定，一些则由缓存管理员(或者是浏览器缓存用户，或者是代理管理员)制定。
Generally speaking, these are the most common rules that are followed (don’t worry if you don’t understand the details, it will be explained below):
--通常来讲，以下这些为最常见的规则(不用担心你不了解这些细节，这些都会在下面作解释的)
1.If the response’s headers tell the cache not to keep it, it won’t.
--如果响应头告诉缓存不需要保留它，则缓存不保留。
2.If the request is authenticated or secure (i.e., HTTPS), it won’t be cached.
-- 如果请求需要验证或者是受保护的(如HTTPS)
3.A cached representation is considered fresh (that is, able to be sent to a client without checking with the origin server)
-- 一个缓存的representation 被认为是“新鲜的”(即是，可以发送给客户端而不需要与源服务器检查)需满足：
if:
•It has an expiry time or other age-controlling header set, and is still within the fresh period, or
--如果它有一个到期时间或者其他的时间控制头信息，并且仍处于“保鲜期”，或者
•If the cache has seen the representation recently, and it was modified relatively long ago.
-- 如果这个缓存已经直接的看到representation，并且它被在一个相对长的时间以前被修改过。
Fresh representations are served directly from the cache, without checking with the origin server.
--新鲜的representations被直接从缓存中提供，而不需要检查源服务器。
4.If a representation is stale, the origin server will be asked to validate it, or tell the cache whether the copy that it has is still good.
-- 如果representation是过时的，源服务器会被要求检查它，并告诉缓存该副本是否是有效的。
5.Under certain circumstances — for example, when it’s disconnected from a network — a cache can serve stale responses without checking with the origin server.
--处于特定的情况下，例如，当断开网络时，一个缓存可以保存过时的响应而不需要向源服务器检查。
If no validator (an ETag or Last-Modified header) is present on a response, and it doesn't have any explicit freshness information, it will usually — but not always — be considered uncacheable.
--如果一个响应中没有验证器(一个ETag 或者 Last-Modified 头)，并且没有任何显式的新鲜度信息，该响应通常(不是总是)会被认为不可缓存的。Together, freshness and validation are the most important ways that a cache works with content.
--总之，新鲜度和验证器对缓存十分重要。
A fresh representation will be available instantly from the cache, while a validated representation will avoid sending the entire representation over again if it hasn’t changed.
-- 一个新鲜的representation可以被即是的从缓存中获得，而一个被验证过的representation将会被避免再次发送全部的representation，如果它没有被改变。
How (and how not) to Control Caches
There are several tools that Web designers and Webmasters can use to fine-tune how caches will treat their sites.
--有多个工具供网站设计者和站点管理员使用对缓存如何处理他们的站点进行调整。It may require getting your hands a little dirty with your server’s configuration, but the results are worth it.
--这需要你亲自动手来处理服务器配置，但结果是值得的。
For details on how to use these tools with your server, see the Implementation sections below.
-- 对于如何使用这些工具，见下面的Implementation部分。
HTML Meta Tags and HTTP Headers
HTML authors can put tags in a document’s <HEAD> section that describe its attributes.
--HTML文件的编写者可以在一个文件的<HEAD>部分加入tags来描述它的属性。
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 are easy to use, but aren’t very effective.
--元标记易于使用，但不是特别有效。
That’s because they’re only honored by a few browser caches, not proxy caches (which almost never read the HTML in the document).
--这是因为它们只被一些浏览器缓存接受，而不是代理缓存(几乎不读文件里的HTML信息).
While it may be tempting to put a Pragma: no-cache meta tag into a Web page, it won’t necessarily cause it to be kept fresh.
-- 也许尝试在一个Web页面加入一个Pragma:no-cache 元标签, 但不一定能保持文件‘新鲜’。
On the other hand, true HTTP headers give you a lot of control over how both browser caches and proxies handle your representations.
--另一方面，真实的HTTP头会给你很多对浏览器缓存和代理如何处理你的representations的控制。
They can’t be seen in the HTML, and are usually automatically generated by the Web server.
--这些控制在HTML中不可见，它们通常是由web服务器自动生成的。
However, you can control them to some degree, depending on the server you use.
-- 然而你可以根据你所用的服务器在某些程度上控制它们。
In the following sections, you’ll see what HTTP headers are interesting, and how to apply them to your site.
--在接下来的部分，你将会看到哪些HTTP头被缓存关注(不好翻译= =)，并如何将它们应用于你的站点。
HTTP headers are sent by the server before the HTML, and only seen by the browser and any intermediate caches.
--HTTP头在HTML前被浏览器发送，并且只可见于浏览器和中间缓存。
Typical HTTP 1.1 response headers might look like this:
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
The HTML would follow these headers, separated by a blank line.
--HTML将会在这些头后面，由一空行隔开。
See the Implementation sections for information about how to set HTTP headers.
Many people believe that assigning a Pragma: no-cache HTTP header to a representation will make it uncacheable.
--许多人认为对一个representation加入Pragma：no-cache HTTP头就会使文件不被缓存。
This is not necessarily true; the HTTP specification does not set any guidelines for Pragma response headers;
--这不一定正确，HTTP规范没有对Pragma响应头做任何准则。
Instead, Pragma request headers (the headers that a browser sends to a server) are discussed.
--相反，对Pragma请求头(……)做了讨论。
Although a few caches may honor this header, the majority won’t, and it won’t have any effect. Use the headers below instead.
--尽管一些缓存接受这种头，但主流的没有，并不起任何作用。
Controlling Freshness with the Expires HTTP Header
The Expires HTTP header is a basic means of controlling caches; it tells all caches how long the associated representation is fresh for.
-- Expires HTTP头是一个基本的缓存控制方式，它告诉所有缓存相关的representation多久是‘新鲜的’。
After that time, caches will always check back with the origin server to see if a document is changed.
--过了那段时间，缓存总是会与源服务器进行核对来确定文件是否改变过。
Expires headers are supported by practically every cache.
-- Expires头几乎被所有的缓存支持。
Most Web servers allow you to set Expires response headers in a number of ways.
--大部分的web服务器允许你以多种方式设置Expires响应头。
Commonly, they will allow setting an absolute time to expire, a time based on the last time that the client retrieved the representation (last access time),
--通常，它们允许设定一个绝对时间使之过期，该时间基于上一次客户端拉去的representation时间(上一次获取时间)。
or a time based on the last time the document changed on your server (last modification time).
--或者是基于上一次服务器上对应文件修改的时间(上一次修改时间)。
Expires headers are especially good for making static images (like navigation bars and buttons) cacheable.
--Expires头特别适合使静态图片(如导航条和按钮)缓存化。
Because they don’t change much, you can set extremely long expiry time on them, making your site appear much more responsive to your users.
-- 因为它们不怎么改变，你可以设置相当长的过期时间，使你的站点响应用户请求更加快速。
They’re also useful for controlling caching of a page that is regularly changed.
--它们对一个定期更改的页面进行缓存控制也很有用。
For instance, if you update a news page once a day at 6am, you can set the representation to expire at that time, so caches will know when to get a fresh copy, without users having to hit ‘reload’.
-- 例如，如果你每天造成6点更新一个新闻页面，你可以设置该representation在那个时间过期，所以缓存就会知道什么时候去获取一个新的副本，而不需要用户点击重新加载。
The only value valid in an Expires header is a HTTP date; anything else will most likely be interpreted as ‘in the past’, so that the representation is uncacheable.
--只有HTTP date在一个Expires头中才有效；其他的都会被解释为‘in the past’,如此一来representation就不能被缓存。
Also, remember that the time in a HTTP date is Greenwich Mean Time (GMT), not local time.
--还有，记住HTTP date里的时间是GMT时间，不是本地时间。
For example:
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Although the Expires header is useful, it has some limitations.
--尽管Expires头很有用，但它由一些限制。
First, because there’s a date involved, the clocks on the Web server and the cache must be synchronised;
--首先，因为涉及日期，浏览器的时钟和缓存时钟必须是同步的。
if they have a different idea of the time, the intended results won’t be achieved, and caches might wrongly consider stale content as fresh.
--如果时间不一致，可能会达不到预定的效果，缓存会错误的认为过时的内容是新鲜的。
Another problem with Expires is that it’s easy to forget that you’ve set some content to expire at a particular time.
--另一个和Expires有关的问题是容易忘记你已经设置了在一个特定时间使过期的信息。
If you don’t update an Expires time before it passes, each and every request will go back to your Web server, increasing load and latency.
--如果在时间过去之前不更新Expires时间，每个请求就会回到的服务器，增加了负载和延时。
Cache-Control HTTP Headers
HTTP 1.1 introduced a new class of headers, Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires.
--HTTP 1.1 引入了一个新的头部类，Cache-Control 响应头，用以给web发布者对自己的内容有更多的控制权，并解决Expires的限制。
Useful Cache-Control response headers include:
•max-age=[seconds] — specifies the maximum amount of time that a representation will be considered fresh.
-- max-age=[seconds] — 指定一个representation被认为是新鲜的最大时间。
Similar to Expires, this directive is relative to the time of the request, rather than absolute.
--与Expires类似，这个指令是相对请求时间而不是绝对时间。
[seconds] is the number of seconds from the time of the request you wish the representation to be fresh for.
--[seconds]是从你请求时间开始的秒数，该请求你希望representation是新鲜的。
•s-maxage=[seconds] — similar to max-age, except that it only applies to shared (e.g., proxy) caches.
-- s-maxage=[seconds] 同max-age相似，除了它只能用于共享缓存(如代理).
•public — marks authenticated responses as cacheable; normally, if HTTP authentication is required, responses are automatically private.
--public 标记被验证过的响应为可缓存，通常，如果HTTP验证时必须的，响应自动为private。
•private — allows caches that are specific to one user (e.g., in a browser) to store the response; shared caches (e.g., in a proxy) may not.
--private 允许缓存特定于一个用户(如在一个浏览器中)用以存储响应。共享缓存(如代理)可能不行。
•no-cache — forces caches to submit the request to the origin server for validation before releasing a cached copy, every time.
-- no-cache 强制缓存每次在释放一个缓存副本之前都想向源服务器提交请求验证。
This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching.
--确保验证被考虑到或者保持严格的新鲜度而不用牺牲全部的缓存优势是十分有用的。
•no-store — instructs caches not to keep a copy of the representation under any conditions.
--no-store 指定缓存在任何情况下都不保留representation的副本。
•must-revalidate — tells caches that they must obey any freshness information you give them about a representation.
--must-revalidate 告诉缓存必须遵守你给定的关于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.
--HTTP允许缓存在特定条件下提供过时的representation；通过设定这个头，你将告诉缓存要严格的执行你指定的规则。
•proxy-revalidate — similar to must-revalidate, except that it only applies to proxy caches.
--proxy-revalidate 与must-revalidate类似，除了它只对代理缓存起作用。
For example:
Cache-Control: max-age=3600, must-revalidate
When both Cache-Control and Expires are present, Cache-Control takes precedence.
--当Cache-Control与Expires同时出现，Cache-Control优先。
If you plan to use the Cache-Control headers, you should have a look at the excellent documentation in HTTP 1.1; see References and Further Information.
--如果你打算用Cache-Control头，你需要看一下查阅一下优秀的HTTP1.1文档。
Validators and Validation
In How Web Caches Work, we said that validation is used by servers and caches to communicate when a representation has changed.
--在How Web Caches Work 部分，我们说过验证是当一个representation改变时服务器和缓存用来通信的。
By using it, caches avoid having to download the entire representation when they already have a copy locally, but they’re not sure if it’s still fresh.
--通过使用它，当缓存已经有了一个本地副本，但不确定是否是新鲜时，避免了下载整个representation。
Validators are very important; if one isn’t present, and there isn’t any freshness information (Expires or Cache-Control) available, caches will not store a representation at all.
--验证器十分重要，如果没有验证器，就没有任何可用的新鲜度信息(Expires 或者 Cache-Control)，缓存将不会存储一个representation。
The most common validator is the time that the document last changed, as communicated in Last-Modified header.
--最常见的验证器是文件的最后更改时间，作为与服务器通信的Last-Modified头。
When a cache has a representation stored that includes a Last-Modified header, it can use it to ask the server if the representation has changed since the last time it was seen, with an If-Modified-Since request.
--当缓存中存在一个拥有Last-Modified头的representation时，缓存可以通过向服务器发送带有If-Modified-Since的请求询问服务器在representation最后一次被'呈现'之后是否被改变过。
HTTP 1.1 introduced a new kind of validator called the ETag.
--HTTP 1.1 引进了一个新的验证器叫做ETag。
ETags are unique identifiers that are generated by the server and changed every time the representation does.
--ETags 是唯一的标识符，由服务器生成，每次representation改变时ETag就会被改变。
Because the server controls how the ETag is generated, caches can be sure that if the ETag matches when they make a If-None-Match request, the representation really is the same.
--因为服务器控制ETag是如何生成的，当缓存发送一个If-None-Match的请求，缓存可以确定如果ETag匹配则representation是相同的<即没法有发生改变>。
Almost all caches use Last-Modified times as validators; ETag validation is also becoming prevalent.
--几乎所有的缓存使用Last-Modified times 作为验证器；ETag验证同样也变得十分流行。
Most modern Web servers will generate both ETag and Last-Modified headers to use as validators for static content (i.e., files) automatically; you won’t have to do anything.
--大部分的现代服务器会自动为静态内容(如文件)生成ETag和Last-Modified头作为验证器；不需要用户做任何事。
However, they don’t know enough about dynamic content (like CGI, ASP or database sites) to generate them; see Writing Cache-Aware Scripts.
--但是，对于动态内容(如CGI，ASP或者数据库站点)服务器没有足够的信息区生成验证器.
Tips for Building a Cache-Aware Site
Besides using freshness information and validation, there are a number of other things you can do to make your site more cache-friendly.
--除了使用新鲜度信息和验证信息，还有很多其他的方式用来使你的站点缓存友好化。
•Use URLs consistently — this is the golden rule of caching. If you serve the same content on different pages, to different users, or from different sites, it should use the same URL.
--使用URLs consistently - 这是缓存的黄金法则。如果你在不同的页面上像不同的用户提供相同的内容，或者从不同的网站，你应该使用相同URL。
This is the easiest and most effective way to make your site cache-friendly.
--这是使你的站点缓存友好化的最简单最有效的方式
For example, if you use “/index.html” in your HTML as a reference once, always use it that way.
--例如，如果你在你的HTML中使用“/index.html”作为一次引用，那后面就会一直作为引用。
•Use a common library of images and other elements and refer back to them from different places.
--使用通用的图像或者其他元素库并从不同的地方引用它们。
•Make caches store images and pages that don’t change often by using a Cache-Control: max-age header with a large value.
--使用Cache-Control:max-age头，max-age的值设一个比较大的值，使缓存存储不经常改变的图片和页面。
•Make caches recognise regularly updated pages by specifying an appropriate max-age or expiration time.
--通过指定适当的max-age和expiration time使缓存能够识别定期更新的页面。
•If a resource (especially a downloadable file) changes, change its name.
如果一个资源(特别是可以下载的文件)改变了，改变它的名字。
That way, you can make it expire far in the future, and still guarantee that the correct version is served; the page that links to it is the only one that will need a short expiry time.
--这种方式，你可以使文件在很久以后过期,并能保证正确的版本得到提供；指向它的页面是唯一需要一个短的过期时间的。
•Don’t change files unnecessarily. If you do, everything will have a falsely young Last-Modified date.
--不要不必要的改变文件。如果你做了，所有东西都会有一个不正确的新的Last-Modified日期。
For instance, when updating your site, don’t copy over the entire site; just move the files that you’ve changed.
--例如，当更新你的站点时，不复制整个站点，只是处理你改变的文件。
•Use cookies only where necessary — cookies are difficult to cache, and aren’t needed in most situations. If you must use a cookie, limit its use to dynamic pages.
--尽在必要的地方使用cookies，对于缓存cookies是不易操作的，并且在大部分情况下是没有必要的。如果你必须使用cookies，那么对动态网页限制cookies的使用。
•Minimize use of SSL — because encrypted pages are not stored by shared caches, use them only when you have to, and use images on SSL pages sparingly.
--尽可能少的使用SSL，因为加密的页面不被共享缓存存储，除非你不得不用的时候才使用它，并尽量少的在SSL页面上使用图片。
•Check your pages with REDbot — it can help you apply many of the concepts in this tutorial.
--用REDbot检查你的页面，它可以帮你应用该教程中的很多概念。
Writing Cache-Aware Scripts
By default, most scripts won’t return a validator (a Last-Modified or ETag response header) or freshness information (Expires or Cache-Control).
--默认地，大部分的脚本不返回验证器(一个Last-Modified 或者 ETag响应头)或者新鲜度信息(Expires或者Cache-Control).
While some scripts really are dynamic (meaning that they return a different response for every request), many (like search engines and database-driven sites) can benefit from being cache-friendly.
--但有些脚本十分智能(不是很恰当= =)(意味着这些脚本对每个请求返回不同的响应)，如搜索引擎和数据库驱动的站点可以从缓存友好化中获的益处。
Generally speaking, if a script produces output that is reproducible with the same request at a later time (whether it be minutes or days later), it should be cacheable.
--通常讲，如果一个脚本产生的输出对于以后的时间(不管是几分钟后还是几天后)的请求是可重复的，则它是可缓存的。
If the content of the script changes only depending on what’s in the URL, it is cacheable; if the output depends on a cookie, authentication information or other external criteria, it probably isn’t.
--如果脚本内容的改变仅依赖于URL的内容，则该脚本是可以缓存的；如果输出依赖于cookie，验证信息或者其他外部准则，则它可能是不可缓存的。
•The best way to make a script cache-friendly (as well as perform better) is to dump its content to a plain file whenever it changes.
--使一个脚本缓存友好化(表现更好)最好的方式是当它发生改变时将它的内容转存到一个普通文件中。
The Web server can then treat it like any other Web page, generating and using validators, which makes your life easier.
--然后web服务器把它当做其他web页面一样，生成和使用验证器，让你用起来更方便<大概是这个意思>.
Remember to only write files that have changed, so the Last-Modified times are preserved.
--记住只有写入文件发生改变，Last-Modified times 才会被保存。
•Another way to make a script cacheable in a limited fashion is to set an age-related header for as far in the future as practical.
--另一个不太主流的方法是给脚本设置一个和时间相关的头<实在翻译不出来= =>.
Although this can be done with Expires, it’s probably easiest to do so with Cache-Control: max-age, which will make the request fresh for an amount of time after the request.
--尽管Expires可以处理这个问题，但用Cache-Control：max-age可能是最容易的，它在该请求以后使这个请求<的内容>在一个很长时间内保鲜。
•If you can’t do that, you’ll need to make the script generate a validator, and then respond to If-Modified-Since and/or If-None-Match requests.
--如果你不能那样做<哪样？？？我觉得是上面两种方式>，你将需要使你的脚本生成一个验证器然后回应If-Modified-Since 和/或者If-None-Match请求。
This can be done by parsing the HTTP headers, and then responding with 304 Not Modified when appropriate. Unfortunately, this is not a trival task.
--这种方式需要解析HTTP头，适当的时候然后以304 Not Modified作为响应。
Some other tips;
•Don’t use POST unless it’s appropriate.
--除非是适当的，否则不是用Post。
Responses to the POST method aren’t kept by most caches; if you send information in the path or query (via GET), caches can store that information for the future.
--大多的缓存不保留POST的响应；如果你都过GET方法发送信息，缓存可以记录这些信息留作后用。
•Don’t embed user-specific information in the URL unless the content generated is completely unique to that user.
--不要在URL中嵌入特定用户的信息，除非产生的内容对那个用户是完全特有的。
•Don’t count on all requests from a user coming from the same host, because caches often work together.
--不要指望用户的所有请求来自相同的主机，因为缓存通常一起工作的。
•Generate Content-Length response headers. It’s easy to do, and it will allow the response of your script to be used in a persistent connection.
--生成Content-Length 响应头。这是容易实现的，并且它将允许你脚本的响应用于一个持续的连接中。
This allows clients to request multiple representations on one TCP/IP connection, instead of setting up a connection for every request.
--这样就允许用户在一个TCP/IP连接上请求多个representation，而不是为每个每个请求都建立一个连接。
It makes your site seem much faster.
--这将会使你的站点看起来十分流畅。
扫一扫
1556
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
