本文实例讲述了Symfony2框架HTTP Cache用法。分享给大家供大家参考，具体如下：
富web应用程序的本质意味着它们的动态。无论你的应用程序多么有效率，每个请求比起静态文件来说总会存在很多的耗费。对于大多数web程序来说，这没什么。 Symfony2非常的轻快，无论你做些严重超载的请求，每个请求将会得到很快的回复，而不会对你的服务器造成压力。但是随着你站点的成长，负载将成为一个严重的问题。对每个请求处理应该只被正常执行一次。这就是缓存真正要达成的目标。
站在巨人肩膀上的缓存：
提高一个应用程序执行效率的最有效方法是缓存一个页面的所有输出然后让后续的请求绕开整个应用程序。当然，这对于高动态性的站点来说并不是总是可能的。Symfony2 缓存系统是比较特别的，因为它依赖于在HTTP规范中定义的简单强大的HTTP cache。没有重新发明新的缓存方法，Symfony2 拥抱在web上定义基础交流的标准。一旦你理解了基础的HTTP校验和过期缓存模式，你就会完全掌握了Symfony2的缓存系统。
第一步：一个网关缓存（gateway cache),或者反向代理。是一个坐在你应用程序前面的对立的层。反向代理缓存来自于你应用程序的响应并使用这些缓存响应在某些请求到达你应用程序之前来回复它们。 Symfony2提供了自己的反向代理，也可以使用其它任何的反向代理。
第二步：HTTP缓存 (HTTP cache)头用于和网关缓存以及任何其位于客户和你的应用程序之间的其它缓存交流。Symfony2 提供了和缓存头交互的预设行为和强大接口。
第三步：HTTP 超时和校验时用于决定一个缓存内容是否新鲜和陈旧的两种模式。
第四步：ESI(Edge Side Includes)允许HTTP缓存被用于独立缓存页面片段（甚至是嵌套片段）。使用ESI，你甚至可以缓存一个完整的页面60分钟。但一个嵌入式边栏缓存只有5分钟。
使用网关缓存
当使用HTTP缓存时，缓存是跟你的应用程序完全分离的，它位于你的请求客户端和应用程序之间。该缓存的工作就是从客户端接收请求并把它们传递回你的应用程序。同时它也将接收从你的应用程序返回的响应并把它转给客户端。可以说它是你的应用程序和请求客户端之间请求-响应交互的中间人。
按照这个思路，缓存会保存被认为是“可缓存的”每一个响应回复。当同样的请求再次传来时，该缓存会把自己缓存的响应直接回复给请求客户端，而完全忽略你的应用程序。这种类型的缓存就是HTTP网关缓存。目前有很多这类缓存，比如Varnish,Squid in reverse proxy mode和Symfony2 反向代理等。
缓存类型
一个网关缓存不是缓存的唯一类型。事实上，有三种不同类型的缓存会截获并使用你的应用程序发出的HTTP缓存头。它们是：
浏览器缓存(Browser caches):浏览器拥有自己的本地缓存，这对你单击"前一步"或者查看图片和其它网络资产时起到了主要作用。
代理缓存（Proxy caches):一个代理缓存是一个多人位于一人之后的共享的缓存。它们大多是一些大公司或者ISP安装用来减少延迟和网络阻塞的。
网关缓存（Gateway caches):像一个代理，也是一个共享缓存但是是位于服务器端的。一般是网络管理员安装它们，它使得网站更具可伸缩性，可靠性和高效性。网关缓存有时候被称为反向代理缓存，代理缓存，更或者是HTTP加速器。
Symfony2 反向代理
Symfony2拥有一个用PHP编写的反向代理（也叫做网关缓存）。开启它后，来自你应用程序的可缓存的响应回复将会开始被立刻缓存。安装它相也当容易。每一个新的Symfony2应用程序都有一个预配置缓存内核(AppCache)包含了一个默认的AppKernel。该缓存内核就是个反向代理。要开启缓存，修改前端控制器代码使用缓存内核：
缓存内核会立刻扮演一个反向代理的角色，缓存来自你应用程序的回复把它们发回给请求客户端。
注意，该缓存内核有一个特别的getLog()方法返回一个能够表示在缓存层发生了什么的字符串。
可以在开发环境中来调试和校验你的缓存策略。
AppCache 对象是一个合理的默认配置，当然你也可以通过重写getOptions()方法来设置可选项对它进行调优。
注意，这里无论怎么重写getOptions()方法，其中debug选项将被包裹的AppKernel的debug值自动设置。
default_ttl: 当没有显式的刷新信息在回复中提供时，一个缓冲实体应该被认为是新鲜的时间秒数。显式的设置Cache-Control 或者 Expires 头会覆盖这个参数值。默认值为0。
private_headers：请求头组，它在回复上触发"private" Cache-Control 行为，无论回复是通过Cache-Control 指令显式的声明是public还是private 。默认为Authorization和Cookie。
allow_reload: 指定是否允许客户端通过在请求中指定Cache-Control的"no-cache"指令来强迫缓存重新加载。设置它为true时符合RFC2616规范。默认值为false。
allow_revalidate:指定是否允许客户端通过在请求中指定Cache-Control的"max-age=0"指令来强迫缓存重新校验。设置它为true时符合RFC2616规范。默认值为false。
stale_while_revalidate:用于指定一个默认秒数（间隔是秒因为回复TTL精度是1秒），在期间缓存还在后台进行重新校验时可以立刻返回一个陈旧的回复（默认是2）；该设置会被stale-while-revalidate HTTP Cache-Control扩展重写（RFC 5861）。
stale_if_error: 指定一个默认秒数（间隔是秒）在这期间缓存可以提供一个陈旧的回复当遇到一个错误时。默认值为60。该设置会被stale-if-error HTTP Cache-Contorl 扩展重写（RFC5861） 如果debug设置为true,Symfony2 会自动添加一个X-Symfony-Cache 头到回复保存着关于缓存点击和丢失的信息。从一个反向代理到另一个的转换：
Symfony2反向代理是一个在开发你的站点或者部署你的站点到一个共享主机而你无法安装任何除PHP代码以外的东西时的非常有用的工具。但是因为使用PHP编写，它不能跟用C写成的反向代理那样快速。这就是为什么我们推荐使用Varnish或者Squid到你的运营服务器上的原因。好消息是从一个代理服务器到另外一个替换很容易，简单的不用你修改任何程序代码。你可以开始时使用Symfony2的反向代理等到了阻塞增加时升级到Varnish。
注意：Symfony2 反向代理执行效率独立于应用程序的复杂性。因为应用程序核心仅仅在请求需要被转发到它时才被启动。
HTTP缓存说明：
为了发挥可用缓存层的优势，你的应用程序必须能传达它的哪个回复可以被缓存，什么时候/怎样 缓存会变成陈旧的规则。这些是通过在回复（response)上设置HTTP 缓存头来实现的。
记住，"HTTP"只不过是一种web客户端和服务器之间交流的简单文本语言。当我们说HTTP 缓存时，我们说的是它允许客户端和服务器交换信息相关的缓存。
HTTP指定了4个Response缓存头，我们需要关注一下：
其中最重要的也是万能的头是Cache-Control头，它其实是一个各种缓存信息的集合。Cache-Control Header
Cache-Control头是唯一的一个其内部包含了各种各样的关于一个response是否可以被缓存的信息。每条信息之间用逗号隔开。
Symfony 提供一个Cache-Control头的抽象，使它的创建更加可控。
公共vs私有 Response
网关缓存和代理缓存都被认为是“共享”缓存，因为它们缓存的内容是被多用户共享的。如果一个特定用户的回复曾被错误的存储到共享缓存中，它以后可能被返回给无数的不用用户。想象一下，如果你的账户信息被缓存然后返回给每一个后来请求他们自己账户页面的用户。要处理这种情况，每个回复可能都要设置时public还是private。
public 说明给回复可能被private和共享的缓存保存。 private 说明所有的或者部分的回复信息时给一个单独用户的，所以不能缓存到共享缓存中。
Symfony 谨慎地默认每个回复为private。 要使用共享缓存的优点（比如Symfony2反向代理），回复必须被显式的设置为public。
安全方法：
HTTP缓存仅仅为安全方法工作（比如GET和HEAD)。要安全意味着当它为某个请求服务时从来不会改变服务器上应用程序的状态。（当然你可以写日志信息，缓存数据等）。这里有两个很合理的后果（consequences):
当你的应用程序回复一个GET或者HEAD请求时，你绝对不会改变你应用程序的状态。即使你不用网关缓存，代理缓存的存在意味着任何GET和HEAD请求可能会或者可能不会真的达到你的服务器。
不要期望PUT，POST或者DELETE方法被缓存。这些方法被使用意味着你应用程序状态的改变。缓存它们将阻止某种请求访问或者改变你的应用程序。
缓存规则和默认设置
HTTP 1.1 默认情况下允许缓存任何事情除非有一个显式的Cache-Control头。实践中，大多数缓存当请求有cookie，一个授权头，使用一个非安全的方法（比如PUT,POST,DELETE)或者当请求有一个重定向代码时，不会进行任何缓存活动。
当开发者没有做任何设置时，Symfony2 会自动按照下面的规则设置一个合理的比较保守的Cache-Control头：
如果没有缓存头被定义（Cache-Control,Expires,ETag 或者Last-Modified),Cache-Control被设置为no-cache，意味着该response将不会被缓存。
如果Cache-Control 为空（但是有另一个缓存头存在），它的值被设置为private，must-revalidate;
如果至少一个Cache-Control指令被设置，并且没有'public'或者‘private'指令被显式的添加，Symfony2 会自动添加一个private指令（除去s-maxage 被设置的情况）。
HTTP过期和校验
HTTP规范定义了两个缓存模型： 过期模型，你只需要通过包含一个Cache-Control和/或者一个Expires头来指定一个Response应该多长时间被考虑“新鲜”问题。缓存理解过期将不再让相同的请求回复，直到缓存的版本达到它过期时间成为“stale"陈旧。
校验模型，当页面时真正的动态页面时（他们的展现经常变化），校验模型就经常需要了。这种模型，缓存存储response，但是要求服务对每个请求是否缓存response依然进行校验。
应用程序使用唯一的response 标示符（ETag 头） 和/或者 时间戳（Last-Modified 头）来检查页面自从被缓存后是否放生了变化。
这两个模型的目标是通过依靠一个缓存存储并返回"新鲜" response，使得应用程序从不生成相同的response两次。
过期：
过期模型是在这两个模型中是更加有效和简单明确的模型，它应该在任何时候都有被使用的可能。当一个response使用一过期方式被缓存，缓存将存储response并为请求直接返回它而不去访问应用程序，直到它过期。
过期模型可以被熟练的使用一两个,几乎相同的,HTTP头:比如 Expires或cache - control。
过期和Expires 头
根据HTTP规范，Expires头字段提供一个日期/时间，过了这个日期或时间后它的response就被认为是陈旧的了。Expires头可以被Response的setExpires()方法设置。它要求一个DateTime实例作为输入参数。
生成的HTTP头的结果如下：
注意，因为规范的需要setExprise()方法会自动把日期转换为GMT时区。
我们注意到在HTTP规范1.1版之前，源服务不需要发送一个Date头。 因此缓存（比如浏览器）可能需要依靠它本地的始终来评估Expires头，造成计算生命周期时时钟偏差。 Expires头的另一个限制是规范规定："HTTP/1.1服务不应该发送Expires日期未来超过一年。"
过期和Cache-Control 头
因为Expires头的限制，大多时候，你应该采用Cache-Control头来替代它。回想一下，Cache-Control头是用来指定多个不同缓存指令的。对于过期来说，有两个指令，max-age 和 s-maxage。第一个被所有的缓存使用，然而第二个仅仅被用于共享缓存。
校验：
一旦底层数据发生变化需要立刻对缓存资源进行更新时，过期模型就显得力不从心了。在过期模型下，应用程序不会被要求返回更新的response直到缓存最后过期变为陈旧内容以后。
校验模型解决了这个问题。在校验模型下，缓存持续保存response。不同的是，对每一个请求request，缓存都询问应用程序缓存的response是否依然有效。如果缓存仍然有效，你的应用程序应该返回一个304状态码和一个空内容。这告诉缓存它可以为请求用户返回它缓存的response。
在这个模型下，你主要节省了带宽因为描述不会发送两次到相同的客户端（而是发送一个304回复代替）。但是，如果你仔细设计你的应用程序，你可能能忍受304 response需要的最小数据并节省CPU。
304状态码意味着没有修改。它很重要因为它没有包含整整的被请求内容，而只是一个轻量级的导向集，它告诉缓存它应该使用它现在保存的版本回复请求。跟过期类似，也有两个不同的HTTP头可以被用来实现校验模型： ETag和Last-Modifed
校验和ETag头
ETag头是一个字符串（也叫"entity-tag")它是目标资源一个表现的唯一标识。它完全由你的应用程序来生成和设置。 比如，如果 /about 资源被缓存保存时取决于日期和你应用程序的返回内容。一个ETag像一个手印，被用来快速的比较一个资源的两个不同版本是否等效。 像手印，同一个资源的所有表示形式中每个ETag必须是唯一的。让我们来简单实现一个生成ETag使用md5加密的回复内容作为内容：
Response::isNotModified()方法把和Request一起发送的ETag与Response上的ETag进行比较。如果两个匹配，方法自动设置Response状态码为304。
这个算法非常简单也非常通用，但是你需要在能计算ETag之前创建一个完整的Response，校验模型是次优选择。换句话说，它节省了带宽，单没有节省CPU利用。
Symfony2还通过向setETag()方法传入true作为第二个参数，来支持弱ETag。
校验和Last-Modified 头
Last-Modified头是校验模型的第二种形式。根据HTTP规范，”Last-Modified 头字段指定日期和时间，在这个时间源服务器相信该表现是最后被修改版。“ 换句话说，应用程序决定基于自动缓存内容被缓存后是否被更新过来判断缓存的内容是否要被更新过。举个例子，你可以使用最新更新日期为所有需要计算资源表现的对象作为Last-Modified头的值：
Response::isNotModified() 方法比较请求Request中的If-Modified-Since头和Response中的Last-Modified 头。如果他们相等，Response会被设置一个304状态码。
注意，If-Modified-since 请求头等于最终发送到客户端特定资源Last-Modified头。这就是如何客户端和服务端相互交流决定资源自从它被缓存后是否被更新。
使用校验优化你的代码：
任何缓存策略的主要目的都是减轻应用程序的加载。换句话说，你的应用程序做的越少来返回304 response，越好。Response::isNotModified()方法通过暴露一个简单有效的模式做到了。
当Response没有被修改后，isNotModified()自动设置response的状态码为304，移除response的内容，移除一些不需要为304存在的头。
不同的回复响应：
到目前为止，我们已经假设了每个URI只有一个目标资源的表示。默认情况下，HTTP缓存通过使用URI的资源作为缓存键被执行。如果两个人请求同一个可缓存资源的URI，第二个用户将获取缓存版本。有时候这些不够，不同版本的用一个URI需要被按照一个或者多个请求头的值来被缓存。举个例子，如果当客户端支持你压缩页面时，任何给定的URI都有两种表示：一个是客户端支持压缩时，一个是不支持时的表示。这时候请求头的Accept-Encoding值将决定使用哪个。
在这种情况下，我们需要回复的特定URI缓存一个压缩版本和一个非压缩版本，基于请求的Accept-Encoding值返回它们。这是通过Vary Response头，Vary是一个不同头用逗号分隔，它的值触发请求资源的不同表示。
注意，这个特别的Vary头，将基于URI和Accept-Encoding和User-Agent 请求头为每个资源的不同版本进行缓存。
Response对象提供一个干净的接口来管理Vary 头：
setVary()方法需要一个头名字或者一个头名字数组对应不同的response。
过期和校验：
你当然可以在同一个Response中同时使用校验和过期。因为过期胜过校验，你可以轻易的从它们两个中根据好处做出选择。换句话说，通过同时使用过期和校验，你可以指示缓存服务于缓存的内容，同时后台间隔检查来调查内容是否依然合法。
更多Response方法：
Response类提供了许多和缓存相关的方法。下面是主要的一些：
另外，跟缓存最相关的HTTP头可以被通过一个单独的方法setCache()设置。
使用ESI（Edge Side Includes)
网关缓存是一个提高你网站执行效率的很好的途径。但是它们有一个限制：只能缓存整个页面。如果你不想缓存整个页面或者页面的某一部分很动态，你就没那么幸运了。
幸运的是，Symfony2为这些情况提供一个解决方案，基于ESI技术。它允许页面指定的部分和主页比起来有一个不同的缓存策略。
ESI规范描述标签你可以嵌入到你的页面来和网关缓存交流。Symfony2中只实现了一个标签，include,因为这是唯一一个能在Akami上下文之外使用的标签。