这是一篇知识性的文档，主要目的是为了让Web缓存相关概念更容易被开发者理解并应用于实际的应用环境中。为了简要起见，某些实现方面的细节被简化或省略了。如果你更关心细节实现则完全不必耐心看完本文，后面参考文档和更多深入阅读部分可能是你更需要的内容。
什么是Web缓存，为什么要使用它?
http://blog.csdn.net/shoyer/article/details/8457952
缓存的类型：
浏览器缓存;
代理服务器缓存;
Web缓存无害吗?为什么要鼓励缓存?
Web缓存如何工作：
如何控制(控制不)缓存：
HTML Meta标签 vs. HTTP头信息;
Pragma HTTP头信息(为什么不起作用);
使用Expires(过期时间)HTTP头信息控制保鲜期;
Cache-Control(缓存控制) HTTP头信息;
校验参数和校验;
创建利于缓存网站的窍门;
编写利于缓存的脚本;
常见问题解答;
缓存机制的实现：Web服务器端配置;
缓存机制的实现：服务器端脚本;
参考文档和深入阅读;
关于本文档;
什么是Web缓存，为什么要使用它?
Web缓存位于Web服务器之间(1个或多个，内容源服务器)和客户端之间(1个或多个)：缓存会根据进来的请求保存输出内容的副本，例如html页面， 图片，文件(统称为副本)，然后，当下一个请求来到的时候：如果是相同的URL，缓存直接使用副本响应访问请求，而不是向源服务器再次发送请求。
使用缓存主要有2大理由：
减少相应延迟：因为请求从缓存服务器(离客户端更近)而不是源服务器被相应，这个过程耗时更少，让web服务器看上去相应更快;
减少网络带宽消耗：当副本被重用时会减低客户端的带宽消耗;客户可以节省带宽费用，控制带宽的需求的增长并更易于管理。
缓存的类型
浏览器缓存
对于新一代的Web浏览器来说(例如：IE，Firefox)：一般都能在设置对话框中发现关于缓存的设置，通过在你的电脑上僻处一块硬盘空间用于存储你已经看过的网站的副本。浏览器缓存根据非常简单的规则进行工作：在同一个会话过程中(在当前浏览器没有被关闭之前)会检查一次并确定缓存的副本足够新。这个缓存对于用户点击“后退”或者点击刚访问过的链接特别有用，如果你浏览过程中访问到同一个图片，这些图片可以从浏览器缓存中调出而即时显现。
代理服务器缓存
Web代理服务器使用同样的缓存原理，只是规模更大。代理服务器群为成百上千用户服务使用同样的机制;大公司和ISP经常在他们的防火墙上架设代理缓存或者单独的缓存设备;
由于带路服务器缓存并非客户端或者源服务器的一部分，而是位于原网络之外，请求必须路由到他们才能起作用。一个方法是手工设置你的浏览器：告诉浏览器使用 那个代理，另外一个是通过中间服务器：这个中间服务器处理所有的web请求，并将请求转发到后台网络，而用户不必配置代理，甚至不必知道代理的存在;
代理服务器缓存：是一个共享缓存，不只为一个用户服务，经常为大量用户使用，因此在减少相应时间和带宽使用方面很有效：因为同一个副本会被重用多次。
网关缓存
也被称为反向代理缓存或间接代理缓存，网关缓存也是一个中间服务器，和内网管理员部署缓存用于节省带宽不同：网关缓存一般是网站管理员自己部署：让他们的网站更容易扩展并获得更好的性能;
请求有几种方法被路由到网关缓存服务器上：其中典型的是让用一台或多台负载均衡服务器从客户端看上去是源服务器;
网络内容发布商 (Content delivery networks CDNs)分布网关缓存到整个(或部分)互联网上，并出售缓存服务给需要的网站，Speedera和Akamai就是典型的网络内容发布商(下文简称CDN)。
本问主要关注于浏览器和代理缓存，当然，有些信息对于网关缓存也同样有效;
Web缓存无害吗?为什么要鼓励缓存?
Web缓存在互联网上最容易被误解的技术之一：网站管理员经常怕对网站失去控制，由于代理缓存会“隐藏”他们的用户，让他们感觉难以监控谁在使用他们的网站。
不幸的是：就算不考虑Web缓存，互联网上也有很多网站使用非常多的参数以便管理员精确地跟踪用户如何使用他们的网站;如果这类问题也是你关心的，本文将告诉你如何获得精确的统计而不必将网站设计的非常缓存不友好。
另外一个抱怨是缓存会给用户过期或失效的数据;无论如何：本文可以告诉你怎样配置你的服务器来控制你的内容将被如何缓存。
CDN是另外一个有趣的方向，和其他代理缓存不同：CDN的网关缓存为希望被缓存的网站服务，没有以上顾虑。即使你使用了CDN，你也要考虑后续的代理服务器缓存和浏览器缓存问题。
另外一方面：如果良好地规划了你的网站，缓存会有助于网站服务更快，并节省服务器负载和互联网的链接请求。这个改善是显著的：一个难以缓存的网站可能需要几秒去载入页面，而对比有缓存的网站页面几乎是即时显现：用户更喜欢速度快的网站并更经常的访问;
这样想：很多大型互联网公司为全世界服务器群投入上百万资金，为的就是让用户访问尽可能快，客户端缓存也是这个目的，只不过更靠近用户一端，而且最好的一点是你甚至根本不用为此付费。
事实上，无论你是否喜欢，代理服务器和浏览器都回启用缓存。如果你没有配置网站正确的缓存，他们会按照缺省或者缓存管理员的策略进行缓存。
缓存如何工作
所有的缓存都用一套规则来帮助他们决定什么时候使用缓存中的副本提供服务(假设有副本可用的情况下);一些规则在协议中有定义(HTTP协议1.0和1.1)，一些规则由缓存的管理员设置(浏览器的用户或者代理服务器的管理员);
一般说来：遵循以下基本的规则(不必担心，你不必知道所有的细节，细节将随后说明)
如果响应头信息：告诉缓存器不要保留缓存，缓存器就不会缓存相应内容;
如果请求信息是需要认证或者安全加密的，相应内容也不会被缓存;
如果在回应中不存在校验器(ETag或者Last-Modified头信息)，缓存服务器会认为缺乏直接的更新度信息，内容将会被认为不可缓存。
一个缓存的副本如果含有以下信息：内容将会被认为是足够新的
含有完整的过期时间和寿命控制头信息，并且内容仍在保鲜期内;
浏览器已经使用过缓存副本，并且在一个会话中已经检查过内容的新鲜度;
缓存代理服务器近期内已经使用过缓存副本，并且内容的最后更新时间在上次使用期之前;
够新的副本将直接从缓存中送出，而不会向源服务器发送请求;
如果缓存的副本已经太旧了，缓存服务器将向源服务器发出请求校验请求，用于确定是否可以继续使用当前拷贝继续服务;
总之：新鲜度和校验是确定内容是否可用的最重要途径：
如果副本足够新，从缓存中提取就立刻能用了;
而经缓存器校验后发现副本的原件没有变化，系统也会避免将副本内容从源服务器整个重新传输一遍。
如何控制(控制不)缓存
有很多工具可以帮助设计师和网站管理员调整缓存服务器对待网站的方式，这也许需要你亲自下手对服务器的配置进行一些调整，但绝对值得;了解如何使用这些工具请参考后面的实现章节;
HTML meta标签和HTTP 头信息
HTML的编写者会在文档的区域中加入描述文档的各种属性，这些META标签常常被用于标记文档不可以被缓存或者标记多长时间后过期;
META标签使用很简单：但是效率并不高，因为只有几种浏览器会遵循这个标记(那些真正会“读懂”HTML的浏览器)，没有一种缓存代理服务器能遵循这个 规则(因为它们几乎完全不解析文档中HTML内容);有事会在Web页面中增加：Pragma: no-cache这个META标记，如果要让页面保持刷新，这个标签其实完全没有必要。
如果你的网站托管在ISP机房中，并且机房可能不给你权限去控制HTTP的头信息(如：Expires和Cache-Control)，大声控诉：这些机制对于你的工作来说是必须的;
另外一方面： HTTP头信息可以让你对浏览器和代理服务器如何处理你的副本进行更多的控制。他们在HTML代码中是看不见的，一般由Web服务器自动生成。但是，根据 你使用的服务，你可以在某种程度上进行控制。在下文中：你将看到一些有趣的HTTP头信息，和如何在你的站点上应用部署这些特性。
HTTP头信息发送在HTML代码之前，只有被浏览器和一些中间缓存能看到，一个典型的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代码的输出，关于如何设置HTTP头信息请参考实现章节;
Pragma HTTP头信息 (为什么它不起作用)
很多人认为在HTTP头信息中设置了Pragma: no-cache后会让内容无法被缓存。但事实并非如此：HTTP的规范中，响应型头信息没有任何关于Pragma属性的说明，而讨论了的是请求型头信息 Pragma属性(头信息也由浏览器发送给服务器)，虽然少数集中缓存服务器会遵循这个头信息，但大部分不会。用了Pragma也不起什么作用，要用就使 用下列头信息：
使用Expires(过期时间)HTTP头信息来控制保鲜期
Expires(过期时间) 属性是HTTP控制缓存的基本手段，这个属性告诉缓存器：相关副本在多长时间内是新鲜的。过了这个时间，缓存器就会向源服务器发送请求，检查文档是否被修改。几乎所有的缓存服务器都支持Expires(过期时间)属性;
大部分Web服务器支持你用几种方式设置Expires属性;一般的：可以设计一个绝对时间间隔：基于客户最后查看副本的时间(最后访问时间)或者根据服务器上文档最后被修改的时间;
Expires头信息：对于设置静态图片文件(例如导航栏和图片按钮)可缓存特别有用;因为这些图片修改很少，你可以给它们设置一个特别长的过期时间，这会使你的网站对用户变得相应非常快;他们对于控制有规律改变的网页也很有用，例如：你每天早上6点更新新闻页，你可以设置副本的过期时间也是这个时间，这样缓存 服务器就知道什么时候去取一个更新版本，而不必让用户去按浏览器的“刷新”按钮。
过期时间头信息属性值只能是HTTP格式的日期时间，其他的都会被解析成当前时间“之前”，副本会过期，记住：HTTP的日期时间必须是格林威治时间(GMT)，而不是本地时间。举例：
Expires: Fri, 30 Oct 1998 14:19:41 GMT
所以使用过期时间属性一定要确认你的Web服务器时间设置正确，一个途径是通过网络时间同步协议(Network Time Protocol NTP)，和你的系统管理员那里你可以了解更多细节。
虽然过期时间属性非常有用，但是它还是有些局限，首先：是牵扯到了日期，这样Web服务器的时间和缓存服务器的时间必须是同步的，如果有些不同步，要么是应该缓存的内容提前过期了，要么是过期结果没及时更新。
还有一个过期时间设置的问题也不容忽视：如果你设置的过期时间是一个固定的时间，如果你返回内容的时候又没有连带更新下次过期的时间，那么之后所有访问请求都会被发送给源Web服务器，反而增加了负载和响应时间;
Cache-Control(缓存控制) HTTP头信息
HTTP 1.1介绍了另外一组头信息属性：Cache-Control响应头信息，让网站的发布者可以更全面的控制他们的内容，并定位过期时间的限制。
有用的 Cache-Control响应头信息包括：
max-age=[秒] ― 执行缓存被认为是最新的最长时间。类似于过期时间，这个参数是基于请求时间的相对时间间隔，而不是绝对过期时间，[秒]是一个数字，单位是秒：从请求时间开始到过期时间之间的秒数。
s-maxage=[秒] ― 类似于max-age属性，除了他应用于共享(如：代理服务器)缓存
public ― 标记认证内容也可以被缓存，一般来说： 经过HTTP认证才能访问的内容，输出是自动不可以缓存的;
no-cache ― 强制每次请求直接发送给源服务器，而不经过本地缓存版本的校验。这对于需要确认认证应用很有用(可以和public结合使用)，或者严格要求使用最新数据的应用(不惜牺牲使用缓存的所有好处);
no-store ― 强制缓存在任何情况下都不要保留任何副本
must-revalidate ― 告诉缓存必须遵循所有你给予副本的新鲜度的，HTTP允许缓存在某些特定情况下返回过期数据，指定了这个属性，你高速缓存，你希望严格的遵循你的规则。
proxy-revalidate ― 和 must-revalidate类似，除了他只对缓存代理服务器起作用
举例:
Cache-Control: max-age=3600, must-revalidate
如果你计划试用Cache-Control属性，你应该看一下这篇HTTP文档，详见参考和深入阅读;
校验参数和校验
在Web缓存如何工作： 我们说过：校验是当副本已经修改后，服务器和缓存之间的通讯机制;使用这个机制：缓存服务器可以避免副本实际上仍然足够新的情况下重复下载整个原件。
校验参数非常重要，如果1个不存在，并且没有任何信息说明保鲜期(Expires或Cache-Control)的情况下，缓存将不会存储任何副本;
最常见的校验参数是文档的最后修改时间，通过最后Last-Modified头信息可以，当一份缓存包含Last-Modified信息，他基于此信息，通过添加一个If-Modified-Since请求参数，向服务器查询：这个副本从上次查看后是否被修改了。
HTTP 1.1介绍了另外一个校验参数： ETag，服务器是服务器生成的唯一标识符ETag，每次副本的标签都会变化。由于服务器控制了ETag如何生成，缓存服务器可以通过If-None-Match请求的返回没变则当前副本和原件完全一致。
所有的缓存服务器都使用Last-Modified时间来确定副本是否够新，而ETag校验正变得越来越流行;
所有新一代的Web服务器都对静态内容(如：文件)自动生成ETag和Last-Modified头信息，而你不必做任何设置。但是，服务器对于动态内容(例如：CGI,ASP或数据库生成的网站)并不知道如何生成这些信息，参考一下编写利于缓存的脚本章节;
创建利于缓存网站的窍门
除了使用新鲜度信息和校验，你还有很多方法使你的网站缓存友好。
保持URL稳定： 这是缓存的金科玉律，如果你给在不同的页面上，给不同用户或者从不同的站点上提供相同的内容，应该使用相同的URL，这是使你的网站缓存友好最简单，也是 最高效的方法。例如：如果你在页面上使用 "/index.html" 做为引用，那么就一直用这个地址;
使用一个共用的库存放每页都引用的图片和其他页面元素;
对于不经常改变的图片/页面启用缓存，并使用Cache-Control: max-age属性设置一个较长的过期时间;
对于定期更新的内容设置一个缓存服务器可识别的max-age属性或过期时间;
如果数据源(特别是下载文件)变更，修改名称，这样：你可以让其很长时间不过期，并且保证服务的是正确的版本;而链接到下载文件的页面是一个需要设置较短过期时间的页面。
万不得已不要改变文件，否则你会提供一个非常新的Last-Modified日期;例如：当你更新了网站，不要复制整个网站的所有文件，只上传你修改的文件。
只在必要的时候使用Cookie，cookie是非常难被缓存的，而且在大多数情况下是不必要的，如果使用cookie，控制在动态网页上;
减少试用SSL，加密的页面不会被任何共享缓存服务器缓存，只在必要的时候使用，并且在SSL页面上减少图片的使用;
使用可缓存性评估引擎，这对于你实践本文的很多概念都很有帮助;
编写利于缓存的脚本
脚本缺省不会返回校验参数(返回Last-Modified或ETag头信息)或其他新鲜度信息(Expires或Cache-Control)，有些动态脚本的确是动态内容(每次相应内容都不一样)，但是更多(搜索引擎，数据库引擎网站)网站还是能从缓存友好中获益的。
一般说来，如果脚本生成的输出在未来一段时间(几分钟或者几天)都是可重复复制的，那么就是可缓存的。如果脚本输出内容只随URL变化而变化，也是可缓存的;但如果输出会根据cookie，认证信息或者其他外部条件变化，则还是不可缓存的。
最利于缓存的脚本就是将内容改变时导出成静态文件，Web服务器可以将其当作另外一个网页并生成和试用校验参数，让一些都变得更简单，只需要写入文件即可，这样最后修改时间也有了;
另外一个让脚本可缓存的方法是对一段时间内能保持较新的内容设置一个相对寿命的头信息，虽然通过Expires头信息也可以实现，但更容易的是用Cache-Control: max-age属性，它会让首次请求后一段时间内缓存保持新鲜;
如果以上做法你都做不到，你可以让脚本生成一个校验属性，并对 If-Modified-Since 和/或If-None-Match请求作出反应，这些属性可以从解析HTTP头信息得到，并对符合条件的内容返回304 Not Modified(内容未改变)，可惜的是，这种做法比不上前2种高效;
其他窍门：
尽量避免使用POST，除非万不得已，POST模式的返回内容不会被大部分缓存服务器保存，如果你发送内容通过URL和查询(通过GET模式)的内容可以缓存下来供以后使用;
不要在URL中加入针对每个用户的识别信息：除非内容是针对每个用户不同的;
不要统计一个用户来自一个地址的所有请求，因为缓存常常是一起工作的;
生成并返回Content-Length头信息，如果方便的话，这个属性让你的脚本在可持续链接模式时：客户端可以通过一个TCP/IP链接同时请求多个副本，而不是为每次请求单独建立链接，这样你的网站相应会快很多;
具体定义请参考实现章节。
常见问题解答
让网站变得可缓存的要点是什么?
好的策略是确定那些内容最热门，大量的复制(特别是图片)并针对这些内容先部署缓存。
