Symfony2Book12：HTTP 缓存

富Web应用程序的特征就是它们是动态的。无论你的应用程序多么有效率，每个请求总是比服务静态文件有着更多的开销。

对于大多数Web应用程序而言，这是好的。Symfony2非常快，除非你做的是很重量级的事，否则每个请求都会很快被返回，这不会给你的服务器太大压力。

但当你的站点增长之后，开销就变成了一个问题。对每个请求的正常处理应该只做一次，这正是缓存的目标所在。

用网关缓存进行缓存

当与HTTP缓存时，缓存完全从你的应用程序中分离出来，并且位于你应用程序和客户端之间发送请求。

缓存的工作是从客户端接受请求，并将其送给应用程序。缓存也从应用程序中接收返回的响应并将其发送给客户端。缓存是客户端和应用程序之间请求-响应通信的中间人。

在这个过程中，缓存将保存每个被认为是“可缓存的“响应（参见HTTP缓存介绍）。如果相同的资源被再次请求，缓存将向客户端发送被缓存的响应，而完全忽视应用程序。

这种类型的缓存被认为是HTTP网关缓存，并且已经有许多的实现，如Varnish、Squid的反向代理模式以及Symfony2反向代理。

This type of cache is knows as an HTTP gateway cache and many exist such as Varnish, Squid in reverse proxy mode, and the Symfony2 reverse proxy.

Symfony2反向代理

Symfony2附带一个用PHP写的反向代理（也被称为网关缓存） 。启动它之后来自你应用程序、可被缓存的响应将马上开始被缓存。安装它非常简单。每个新Symfony2应用程序都有一个被预配置的缓存内核（AppCache），它包含了缺省内核（AppKernel）。缓存内核是个反向代理：

1. // web/app.php 
2.  
3. require_once __DIR__.'/../app/bootstrap_cache.php.cache'; 
4. require_once __DIR__.'/../app/AppCache.php'; 
5.  
6. use Symfony\Component\HttpFoundation\Request; 
7.  
8. // wrap the default AppKernel with the AppCache one 
9. $kernel = new AppCache(new AppKernel('prod', false)); 
10. $kernel->handle(Request::createFromGlobals())->send(); 

缓存内核会立即生效。作为一个反向代理，它缓存来自应用程序的响应并把它们返回给客户端。

缓存内核有一个特殊的getLog()方法，它返回一个缓存层发生了什么的字符串说明。在开发环境中，使用它去调试和验证你的缓存策略：

1. error_log($kernel->getLog()); 

AppCache对象有一个合理的缺省配置，但它也可以通过覆写getOptions方法设置选项的方式进行微调：

1. // app/AppCache.php 
2. class AppCache extends Cache 
3. { 
4.     protected function getOptions() 
5.     { 
6.         return array( 
7.             'debug'                  => false, 
8.             'default_ttl'            => 0, 
9.             'private_headers'        => array('Authorization', 'Cookie'), 
10.             'allow_reload'           => false, 
11.             'allow_revalidate'       => false, 
12.             'stale_while_revalidate' => 2, 
13.             'stale_if_error'         => 60, 
14.         ); 
15.     } 
16. } 

除非覆写getOptions()，否则调试选项将被自动设置为被包含AppKernel的debug值。

这里有一个主要选项的列表：

• default_ttl: 在响应中没有提供明确的刷新信息时一个缓存条目被视为新鲜的秒数。直接覆盖缓存控制或失效头的值（缺省：0）；
• private_headers: 一组请求头。在通过缓存控制指令不能明确公共还是私有状态响应的情况下，触发“私有”缓存控制行为（缺省：授权和Cookie）；
• allow_reload: 通过在请求中包含一个缓存控制的"no-cache"指令来指定用户端是否可以强制进行重载缓存，根据RFC2616将其设置为true（缺省：false）；
• allow_revalidate:通过在请求中包含一个缓存控制的"max-age=0"指令来指定用户端是否可以强制进行缓存重验证。根据RFC2616将其设置为true（缺省：false）；
• stale_while_revalidate: 指定缺省秒数（和响应的TTL精度一样是秒）。在此期间缓存在后台重新验证（缺省：2）时可以返回陈旧响应；这个设置被stale-while-revalidate HTTP 缓存控制扩展覆写（参见RFC 5861）；
• stale_if_error:指定缺省的秒数（精度是秒）。在此期间当发生错误（缺省：60）时，缓存可以成为陈旧响应。该设置可以通过stale-if-error HTTP 缓存控制扩展来覆写（参见RFC 5861）。

如果debug为true，Symfony2自动向响应添加 X-Symfony-Cache头，该响应包含关于缓存点击和错失的有用信息。

HTTP缓存的介绍

要使用缓存层，你的应用程序必须要能够在可缓存响应和何时／如何缓存变陈旧的规则之间通信。这一切可以通过在响应中设置HTTP缓存头来实现。

记住，"HTTP"无非是一种语言（一个简单文本语言），Web客户端（如浏览器）和Web服务器使用它来相互通信。当我们谈论HTTP缓存时，我们也正在谈论这个语言允许客户端和服务端交换与缓存有关的信息。

• Cache-Control（缓存控制）
• Expires（过程）
• ETag（被请求变量的实体值）
• Last-Modified（最后修改时间）

最重要和最多模式的是Cache-Control头，它其实上是不同缓存信息的集合。

头中每一部分的细节都在HTTP失效和验证一节中进行说明。

The Cache-Control Header¶

Cache-Control头是唯一的，但它所包含的信息部分不是一个，而是多个。信息的每一部分都由冒号分开：

Cache-Control: private, max-age=0, must-revalidate

Cache-Control: max-age=3600, must-revalidate

Symfony2提供一个Cache-Control头的抽象， 使之更易管理：

1. $response = new Response(); 
2.  
3. // mark the response as either public or private 
4. $response->setPublic(); 
5. $response->setPrivate(); 
6.  
7. // set the private or shared max age 
8. $response->setMaxAge(600); 
9. $response->setSharedMaxAge(600); 
10.  
11. // set a custom Cache-Control directive 
12. $response->headers->addCacheControlDirective('must-revalidate', true); 

HTTP失效和验证

HTTP规范定义了两个缓存模型：

• 失效模式中，通过包含Cache-Control和／或失效头，你只需简单指定响应多长时间内会被认为是“新鲜”。缓存理解失效，它将不会生成制造的请求，直到缓存的版本到了它失效的时间，并变得“陈旧”。
• 当页面是真正地动态时（如它们的表现经常改变），验证模型通常是必须的。这种模式中缓存保存响应，但无论缓存的响应是否有效，每次请求都会询问服务器。应用程序使用一个唯一的响应标识（Etage头）和/或一个时间戳（Last-Modified头）去检查在缓存之后页面是否被更改。

两种模式的目标是永远不会两次生成同一个响应，它们依赖缓存去保存和返回“新鲜”的响应。

带Expires头的失效

根据HTTP规范，“Expires头字段给出日期/时间，之后响应被认为陈旧"，Expires头可以通过setExpires()响应方法来设置。它使用DateTime实例作为参数：

1. $date = new DateTime(); 
2. $date->modify('+600 seconds'); 
3.  
4. $response->setExpires($date); 

HTTP头最后看上去象这样：

1. Expires: Thu, 01 Mar 2011 16:00:00 GMT 

正如规范所要求的那样，setExpires()方法会自动将日期转换到GMT时区。

Expires头有两个限制。首先，Web服务器和缓存（如：浏览器）上的时钟必须同步。然后，规范指出"HTTP/1.1服务不能发送超过一年的失效日期。"

带Cache-Control头的失效

因为Expires头的限制，大多数情况下，你应该使用Cache-Control头来代替。回想一下，Cache-Control头被用于指定许多不同缓存指令。对于失效，有两个指令max-age和s-maxage。第一个用于所有缓存，而第二个只考虑共享缓存：

1. // Sets the number of seconds after which the response 
2. // should no longer be considered fresh 
3. $response->setMaxAge(600); 
4.  
5. // Same as above but only for shared caches 
6. $response->setSharedMaxAge(600); 

Cache-Control头将使用以下格式（它也许还有附加指令）：

1. Cache-Control: max-age=600, s-maxage=600 

验证

当底层数据一旦改变时资源就需要更新时，失效模型是不足的。使用失效模型，应用程序不会被要求返回更新的响应，直到缓存最终变成陈旧。

验证模型解决了这个问题。在这种模型下，缓存仍然保存响应。不同在于，对于每个请求，缓存都会询问应用程序被缓存的响应是否有效。如果缓存仍然有效，你的应用程序将返回304状态码，而没有具体内容。这样就告诉缓存它是OK的，以便返回被缓存的内容。

在这种模型下，你主要节省了带宽，因为无须向同一客户端发送两次（用304响应代替）。但如果你应用程序设计仔细的话，你也可以通过发送304响应得到最低限度的数据，也节省CPU（参见下面示例的实现）。

304状态码意味着“不用修改”。这是重要的，因为这个状态码没有包含实际被请求的内容。相反，响应只是简单一组轻量级的指令，告诉缓存它应该使用它保存的版本。

带ETag头的验证

ETag头是一个字符串头（被称为“实体标签”），它完全被应用程序生成和设置，以便你可以看出它是唯一标识代表目的资源的。举个例子，被缓存保存的/about资源是根据应用程序的返回进行更新。ETag就象是一个指纹，并用来快速比较资源的两个不同版本是否相等。象指纹一样，每个ETag必须是唯一代表同一资源的。

让我们看看做为内容的MD5加密来生成ETag的简单实现。

1. public function indexAction() 
2. { 
3.     $response = $this->renderView('MyBundle:Main:index.html.twig'); 
4.     $response->setETag(md5($response->getContent())); 
5.     $response->isNotModified($this->get('request')); 
6.  
7.     return $response; 
8. } 

Response::isNotModified()方法比较请求发送的和在响应上设置的ETag，如果两者匹配，方法将自动设置响应状态码为304。

算法足够简单也非常通用，但你需要在能计算ETag之前创建整个响应。这是次优的，换句话说，它节省带宽，而不是CPU。

在根据验证优化你的代码一节中，我们将展示验证是如何智能地用于决定缓存验证，而无须做大量的工作。

Symfony2也支持通过向setETag()方法的第二个参数发送true来调整ETag。

带Last-Modified头的验证

Last-Modified是第二个验证的方式。根据HTTP规范，“Last-Modified头表示的日期和时间，使源服务器相信它表示最后修改的日期和时间"。换句话说，应用程序决定是否更新缓存内容是基于响应被缓存后，该响应是否被更新。

例如，你可以为所有需要计算资源表现的对象使用最后更新的日期做为Last-Modified头的值：

1. public function showAction($articleSlug) 
2. { 
3.     // ... 
4.  
5.     $articleDate = new \DateTime($article->getUpdatedAt()); 
6.     $authorDate = new \DateTime($author->getUpdatedAt()); 
7.  
8.     $date = $authorDate > $articleDate ? $authorDate : $articleDate; 
9.  
10.     $response->setLastModified($date); 
11.     $response->isNotModified($this->get('request')); 
12.  
13.     return $response; 
14. } 

Response::isNotModified()方法比较请求发送的If-Modified-Since头和在响应上设置的Last-Modified头，如果两者相等，响应将被设置304的状态码。

If-Modified-Since请求头等于为个别资源发送给客户端的最后响应的Last-Modified头。这就是客户端和服务端相互通信并决定资源被缓存后是否被更新。

根据验证优化你的代码

缓存策略的主目标是减轻应用程序的负载。换句话说，在应用程序返回304响应中你做得越少就越好。Response::isNotModified()通过暴露一个简单而有效的模式来实现这一点：

1. public function showAction($articleSlug) 
2. { 
3.     // Get the minimum information to compute 
4.     // the ETag or the Last-Modified value 
5.     // (based on the Request, data are retrieved from 
6.     // a database or a key-value store for instance) 
7.     $article = // ... 
8.  
9.     // create a Response with a ETag and/or a Last-Modified header 
10.     $response = new Response(); 
11.     $response->setETag($article->computeETag()); 
12.     $response->setLastModified($article->getPublishedAt()); 
13.  
14.     // Check that the Response is not modified for the given Request 
15.     if ($response->isNotModified($this->get('request'))) { 
16.         // return the 304 Response immediately 
17.         return $response; 
18.     } else { 
19.         // do more work here - like retrieving more data 
20.         $comments = // ... 
21.  
22.         // or render a template with the $response you've already started 
23.         return $this->render( 
24.             'MyBundle:MyController:article.html.twig', 
25.             array('article' => $article, 'comments' => $comments), 
26.             $response 
27.         ); 
28.     } 
29. } 

当响应没有被修改时，isNotModified()会自动将响应状态码设为304，删除内容和一些304响应不需要递交的头（参见setNotModified()）。

不同响应

到目前为止，我们已经假设每个URI正好表示一个目的资源。缺省状况下，HTTP缓存通过使用资源的URI做为缓存关键词来实现。如果两个用户请求同一可缓存资源的URI，那么第二个用户将得到被缓存的版本。

有时这并不够，相同URI的不同缓存版本需要基于一个或更多请求头的值。例如，当客户端支持压缩页面时，而你又这样做了，那么任何给点URL都有两种形式：一种是客户端支持压缩，一种是客户端不支持压缩。这需要通过Accept-Encoding请求头的值来决定。

在本例中，你需要缓存为特定的URL保存响应的压缩和没压缩的两个版本，并且基于请求的Accept-Encoding值来返回它们。这是通过使用Vary响应头来实现的，该响应头使用逗号分隔的头列表，这些值引发被请求资源的不同表现：

1. Vary: Accept-Encoding, User-Agent 

这个特殊的Vary头将缓存每个基于URL资源的不同版本、Accept-Encoding值和User-Agent请求头。

响应对象提供完整的接口去管理Vary头

1. // set one vary header 
2. $response->setVary('Accept-Encoding'); 
3.  
4. // set multiple vary headers 
5. $response->setVary(array('Accept-Encoding', 'User-Agent')); 

setVary()方法为响应的Vary头提供头名或头名数据。

更多的响应方法

Response类提供了更多关于缓存的方法。这里是最有用的一些：

1. // Marks the Response stale 
2. $response->expire(); 
3.  
4. // Force the response to return a proper 304 response with no content 
5. $response->setNotModified(); 

另外，大多数缓存相关的HTTP头可以通过单个setCache()方法设置：

1. // Set cache settings in one call 
2. $response->setCache(array( 
3.     'etag'          => $etag, 
4.     'last_modified' => $date, 
5.     'max_age'       => 10, 
6.     's_maxage'      => 10, 
7.     'public'        => true, 
8.     // 'private'    => true, 
9. )); 

使用边缘端包含

网关缓存是让你网站性能更高的方式。但它们有一个限制：它们只能缓存整个页面。如果你不需要缓存整个页面或者如果页面的部分拥有“更”动态的内容，你就郁闷了。幸运的是，Symfony2为这些情况提供了解决方案，该方案基于一种ESI或被称为边缘端包含的技术。Akamaï大约在10年前写了该技术的规范，它允许页面的指定部分有着与整个页面不同的缓存策略。

ESI规范描述你可以内嵌到你页面的标签，以便与网关缓存通信。在Symfony2中只实现了一个标签，include，因为这是在Akamaï上下文之外唯一有用的一个：

1. <html> 
2.     <body> 
3.         Some content 
4.  
5.         <!-- Embed the content of another page here --> 
6.         <esi:include src="http://..." /> 
7.  
8.         More content 
9.     </body> 
10. </html> 

注意例子中的每个ESI标签都有一个完全合格的URL。一个ESI标签代表一个页面片段，可以通过给定URL引入。

当请求被处理时，网关缓存引入从缓存或后端应用程序请求的整个页面。如果响应包含一个或多个ESI标记，它们都是以相同的方式处理。换句话说，网关缓存可以从缓存中检索包含的页面片段，也可以从后端应用程序中再次请求页面片段。当所有的ESI标记已经解析，网关缓存合并成整个页面，并将其最终内容发送给客户端。

所有发生在网关缓存层的一切都是透明的（如应用程序无关）。如你所见，如果你选择使用ESI标签，Symfony2可以使包含它们的过程毫不费力。

在Symfony2中使用ESI

首先，要使用ESI，需要确保在你的应用程序配置中启动它：

1. # app/config/config.yml 
2. framework: 
3.     # ... 
4.     esi: { enabled: true } 

现在，假设我们有一个相对静态的页面，除了内容底部的新闻滚动条。通过ESI，我们可以缓存除新闻滚动条之外的页面其它部分。

1. public function indexAction() 
2. { 
3.     $response = $this->renderView('MyBundle:MyController:index.html.twig'); 
4.     $response->setSharedMaxAge(600); 
5.  
6.     return $response; 
7. } 

在本例中，我们全页面缓存十分钟的生命周期。接下来，让我们在模板中通过内嵌一个动作包含新闻滚动条。它可以通过render助手函数实现（参见templating-embedding-controller 以得到更多细节）。

因为内嵌内容来自其它页（或控制器），Symfony2使用标准的render助手函数来配置ESI标签：

1. {% render '...:news' with {}, {'standalone': true} %} 

通过将standalone设置为true，你告诉Symfony2动作应该作为ESI标签渲染。你也许疑惑为什么你想使用助手函数代替ESI标签？那是因为使用助手函数可以使你的应用程序即使在没安装网关缓存的情况下正常运行。让我们看看它是如何工作的。

当standalone为false时（缺省值），Symfony2在发送响应到客户端之前合并被包含的页面内容到主页面。但当standalone为真是，如果Symfony2检测到它正在与一个支持ESI的网关缓存会话时，它会生成一个ESI的include标签。如果没有网关缓存或该缓存不支持ESI时，Symfony2将只是把被包含的页面内容合并到主页面中，就象standalone被设置成false一样。

Symfony2检测网关缓存是否通过另一个Akamaï规范支持ESI，该规范通过Symfony2反向代理的开箱支持。

被内嵌的动作现在可以指定它自己的缓存规则，完全独立于主页面。

1. public function newsAction() 
2. { 
3.   // ... 
4.  
5.   $response->setSharedMaxAge(60); 
6. } 

通过ESI，整个页面缓存的有效时间是600秒，而新闻组件缓存仅为60秒。

然而，ESI的要求是内嵌动作可以通过URL访问，因此网关代理可以将它从页面的其它部分中独立出来。当然一个动作不能通过URL来访问，除非有路由指向它。Symfony2通过路由和控制器可以实现。为了要让ESI的include标签正确工作，你必须定义_internal路由：

1. # app/config/routing.yml 
2. _internal: 
3.     resource: "@FrameworkBundle/Resources/config/routing/internal.xml" 
4.     prefix:   /_internal 

因为这条路由允许所有动作可以通过URL访问，所以你也许想要通过使用Symfony2防火墙功能（通过允许访问你反向代理的IP地址范围）来保护它。

这种缓存策略最大的好处在于你可以使你的应用程序根据需要在同一时间里尽可能的动态，命中最可能的少。

• alt: 作为ESI标签中的alt属性，允许你指定另一个URL，在src没有找到时替代；
• ignore_errors: 如果设为真，带着表明继续值的onerror属性会被添加到ESI中。当发生故障时，网关缓存将默默地将ESI标签删除。

缓存无效¶

"在计算机学科只有两个难题：缓存无效和命名事物" --菲尔 卡尔顿

你永远不需要去处理无效的缓存数据，因为无效已经被考虑到HTTP缓存模型中。如果你使用验证模型，你永远不需要任何被定义无效的事物；如果你使用失效模型，资源无效，这就意味着你设置的失效时间太长了。

又因为没有无效机制，你可以使用任何反向代理，而无须改动你的应用程序代码。

实际上，所有反向代理都提供删除缓存数据的方式，但你应该尽可能地避免使用它们。最标准的做法是通过请求指定的URL来删除缓存，该请求带有特殊PURGE的HTTP方法。

这里是如何配置Symfony2反向代理支持PURGE的HTTP方法：

1. // app/AppCache.php 
2. class AppCache extends Cache 
3. { 
4.     protected function invalidate(Request $request) 
5.     { 
6.         if ('PURGE' !== $request->getMethod()) { 
7.             return parent::invalidate($request); 
8.         } 
9.  
10.         $response = new Response(); 
11.         if (!$this->store->purge($request->getUri())) { 
12.             $response->setStatusCode(404, 'Not purged'); 
13.         } else { 
14.             $response->setStatusCode(200, 'Purged'); 
15.         } 
16.  
17.         return $response; 
18.     } 
19. } 

无论如何你都必须保护PURGE的HTTP方法，以避免随机用户删除你的缓存数据。