Symfony2架構學習筆記之HTTP Cache用法詳解_php執行個體

本文執行個體講述了Symfony2架構HTTP Cache用法。分享給大家供大家參考，具體如下：

富web應用程式的本質意味著它們的動態。無論你的應用程式多麼有效率，每個請求比起靜態檔案來說總會存在很多的耗費。對於大多數web程式來說，這沒什麼。 Symfony2非常的輕快，無論你做些嚴重超載的請求，每個請求將會得到很快的回複，而不會對你的伺服器造成壓力。但是隨著你網站的成長，負載將成為一個嚴重的問題。對每個請求處理應該只被正常執行一次。這就是緩衝真正要達成的目標。

站在巨人肩膀上的緩衝：

提高一個應用程式執行效率的最有效方法是緩衝一個頁面的所有輸出然後讓後續的請求繞開整個應用程式。當然，這對於高動態性的網站來說並不是總是可能的。Symfony2 緩衝系統是比較特別的，因為它依賴於在HTTP規範中定義的簡單強大的HTTP cache。沒有重新發明新的緩衝方法，Symfony2 擁抱在web上定義基礎交流的標準。一旦你理解了基礎的HTTP校正和到期緩衝模式，你就會完全掌握了Symfony2的緩衝系統。

第一步：一個網關緩衝（gateway cache),或者反向 Proxy。是一個坐在你應用程式前面的對立的層。反向 Proxy緩衝來自於你應用程式的響應並使用這些緩衝響應在某些請求到達你應用程式之前來回複它們。 Symfony2提供了自己的反向 Proxy，也可以使用其它任何的反向 Proxy。

第二步：HTTP緩衝 (HTTP cache)頭用於和網關緩衝以及任何其位於客戶和你的應用程式之間的其它緩衝交流。Symfony2 提供了和緩衝頭互動的預設行為和強大介面。

第三步：HTTP 逾時和校正時用於決定一個緩衝內容是否新鮮和陳舊的兩種模式。

第四步：ESI(Edge Side Includes)允許HTTP緩衝被用於獨立快取頁面面片段（甚至是嵌套片段）。使用ESI，你甚至可以緩衝一個完整的頁面60分鐘。但一個嵌入式側邊欄緩衝只有5分鐘。

使用網關緩衝

當使用HTTP緩衝時，緩衝是跟你的應用程式完全分離的，它位於你的請求用戶端和應用程式之間。該緩衝的工作就是從用戶端接收請求並把它們傳遞迴你的應用程式。同時它也將接收從你的應用程式返回的響應並把它轉給用戶端。可以說它是你的應用程式和請求用戶端之間要求-回應互動的中間人。

按照這個思路，緩衝會儲存被認為是“可快取的”每一個響應回複。當同樣的請求再次傳來時，該緩衝會把自己緩衝的響應直接回複給請求用戶端，而完全忽略你的應用程式。這種類型的緩衝就是HTTP網關緩衝。目前有很多這類緩衝，比如Varnish,Squid in reverse proxy mode和Symfony2 反向 Proxy等。

緩衝類型

一個網關緩衝不是緩衝的唯一類型。事實上，有三種不同類型的緩衝會截獲並使用你的應用程式發出的HTTP緩衝頭。它們是：

瀏覽器緩衝(Browser caches):瀏覽器擁有自己的本機快取，這對你單擊"前一步"或者查看圖片和其它網路資產時起到了主要作用。

代理緩衝（Proxy caches):一個代理緩衝是一個多人位於一人之後的共用的緩衝。它們大多是一些大公司或者ISP安裝用來減少延遲和網路阻塞的。

網關緩衝（Gateway caches):像一個代理，也是一個共用快取但是是位於伺服器端的。一般是網路系統管理員安裝它們，它使得網站更具延展性，可靠性和高效性。網關緩衝有時候被稱為反向 Proxy緩衝，代理緩衝，更或者是HTTP加速器。

Symfony2 反向 Proxy

Symfony2擁有一個用PHP編寫的反向 Proxy（也叫做網關緩衝）。開啟它後，來自你應用程式的可快取的響應回複將會開始被立刻緩衝。安裝它相也當容易。每一個新的Symfony2應用程式都有一個預配置緩衝核心(AppCache)包含了一個預設的AppKernel。該緩衝核心就是個反向 Proxy。要開啟緩衝，修改前端控制器代碼使用緩衝核心：

// web/app.phprequire_once __DIR__.'/../app/bootstrap.php.cache';require_once __DIR__.'/../app/AppKernel.php';require_once __DIR__.'/../app/AppCache.php';use Symfony\Component\HttpFoundation\Request;$kernel = new AppKernel('prod', false);$kernel->loadClassCache();//使用AppCache包裹預設的AppKernel$kernel = new AppCache($kernel);$kernel->handle(Request::createFromGlobale())->send();

緩衝核心會立刻扮演一個反向 Proxy的角色，緩衝來自你應用程式的回複把它們發回給請求用戶端。

注意，該緩衝核心有一個特別的getLog()方法返回一個能夠表示在緩衝層發生了什麼的字串。

可以在開發環境中來調試和校正你的緩衝策略。

error_log($kernel->getLog());

AppCache 對象是一個合理的預設配置，當然你也可以通過重寫getOptions()方法來設定可選項對它進行調優。

// app/AppCache.phpuse Symfony\Bundle\FrameworkBundle\HttpCache\HttpCache;class AppCache extends HttpCache{  protected function getOptions()  {    return array(      'debug'         => false,      'default_ttl'      => 0,      'private_headers'    => array('Authorization', 'Cookie'),      'allow_reload'      => false,      'allow_revalidate'    => false,      'stale_while_revalidate' => 2,      'stale_if_error'     => 60,    );  }}

注意，這裡無論怎麼重寫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 頭到回複儲存著關於緩衝點擊和丟失的資訊。

從一個反向 Proxy到另一個的轉換：

Symfony2反向 Proxy是一個在開發你的網站或者部署你的網站到一個共用主機而你無法安裝任何除PHP代碼以外的東西時的非常有用的工具。但是因為使用PHP編寫，它不能跟用C寫成的反向 Proxy那樣快速。這就是為什麼我們推薦使用Varnish或者Squid到你的運營伺服器上的原因。好訊息是從一個Proxy 伺服器到另外一個替換很容易，簡單的不用你修改任何程式碼。你可以開始時使用Symfony2的反向 Proxy等到了阻塞增加時升級到Varnish。

注意：Symfony2 反向 Proxy執行效率獨立於應用程式的複雜性。因為應用程式核心僅僅在請求需要被轉寄到它時才被啟動。

HTTP緩衝說明：

為了發揮可用緩衝層的優勢，你的應用程式必須能傳達它的哪個回複可以被緩衝，什麼時候/怎樣 緩衝會變成陳舊的規則。這些是通過在回複（response)上設定HTTP 緩衝頭來實現的。

記住，"HTTP"只不過是一種web用戶端和伺服器之間交流的簡單文本語言。當我們說HTTP 緩衝時，我們說的是它允許用戶端和伺服器交換資訊相關的緩衝。

HTTP指定了4個Response緩衝頭，我們需要關注一下：

Cache-Control
Expires
ETag
Last-Modified

其中最重要的也是萬能的頭是Cache-Control頭，它其實是一個各種緩衝資訊的集合。

Cache-Control Header

Cache-Control頭是唯一的一個其內部包含了各種各樣的關於一個response是否可以被緩衝的資訊。每條資訊之間用逗號隔開。

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

Symfony 提供一個Cache-Control頭的抽象，使它的建立更加可控。

$response = new Response();// 標記response為public還是private$response->setPublic();$response->setPrivate();// 設定private或者shared 的最大年齡 age$response->setMaxAge(600);$response->setSharedMaxAge(600);// 設定一個自訂的Cache-Control 指令$response->headers->addCacheControlDirective('must-revalidate', true);

公用vs私人 Response

網關緩衝和代理緩衝都被認為是“共用”緩衝，因為它們緩衝的內容是被多使用者共用的。如果一個特定使用者的回複曾被錯誤的儲存到共用快取中，它以後可能被返回給無數的不用使用者。想象一下，如果你的賬戶資訊被緩衝然後返回給每一個後來請求他們自己賬戶頁面的使用者。要處理這種情況，每個回複可能都要設定時public還是private。

public 說明給回複可能被private和共用的緩衝儲存。
private 說明所有的或者部分的回複資訊時給一個單獨使用者的，所以不能緩衝到共用快取中。

Symfony 謹慎地預設每個回複為private。 要使用共用快取的優點（比如Symfony2反向 Proxy），回複必須被顯式的設定為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執行個體作為輸入參數。

$date = new DateTime();$date->modify('+600 seconds');$response->setExpires($date);

產生的HTTP頭的結果如下：

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

注意，因為規範的需要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->setMaxAge(600);// 同上，但是只用於共用快取。$response->setSharedMaxAge(600);Cache-Control頭將使用如下格式（它可能還有其它指令）：Cache-Control: max-age=600, s-maxage=600

校正：

一旦底層資料發生變化需要立刻對緩衝資源進行更新時，到期模型就顯得力不從心了。在到期模型下，應用程式不會被要求返回更新的response直到緩衝最後到期變為陳舊內容以後。

校正模型解決了這個問題。在校正模型下，緩衝持續儲存response。不同的是，對每一個請求request，緩衝都詢問應用程式緩衝的response是否依然有效。如果緩衝仍然有效，你的應用程式應該返回一個304狀態代碼和一個空內容。這告訴緩衝它可以為請求使用者返回它緩衝的response。

在這個模型下，你主要節省了頻寬因為描述不會發送兩次到相同的用戶端（而是發送一個304回複代替）。但是，如果你仔細設計你的應用程式，你可能能忍受304 response需要的最小資料並節省CPU。

304狀態代碼意味著沒有修改。它很重要因為它沒有包含整整的被請求內容，而只是一個輕量級的導向集，它告訴緩衝它應該使用它現在儲存的版本回複請求。跟到期類似，也有兩個不同的HTTP頭可以被用來實現校正模型： ETag和Last-Modifed

校正和ETag頭

ETag頭是一個字串（也叫"entity-tag")它是目標資源一個表現的唯一標識。它完全由你的應用程式來產生和設定。 比如，如果 /about 資源被緩衝儲存時取決於日期和你應用程式的返回內容。一個ETag像一個手印，被用來快速的比較一個資源的兩個不同版本是否等效。
像手印，同一個資源的所有表示形式中每個ETag必須是唯一的。讓我們來簡單實現一個產生ETag使用md5加密的回複內容作為內容：

public function indexAction(){  $response = $this->render('MyBundle:Main:index.html.twig');  $response->setETag(md5($response->getContent()));  $response->isNotModified($this->getRequest());  return $response;}

Response::isNotModified()方法把和Request一起發送的ETag與Response上的ETag進行比較。如果兩個匹配，方法自動化佈建Response狀態代碼為304。

這個演算法非常簡單也非常通用，但是你需要在能計算ETag之前建立一個完整的Response，校正模型是次優選擇。換句話說，它節省了頻寬，單沒有節省CPU利用。

Symfony2還通過向setETag()方法傳入true作為第二個參數，來支援弱ETag。

校正和Last-Modified 頭

Last-Modified頭是校正模型的第二種形式。根據HTTP規範，”Last-Modified 頭欄位指定日期和時間，在這個時間原始伺服器相信該表現是最後被修改版。“
換句話說，應用程式決定基於自動緩衝內容被緩衝後是否被更新過來判斷緩衝的內容是否要被更新過。舉個例子，你可以使用最新更新日期為所有需要計算資源表現的對象作為Last-Modified頭的值：

public function showAction($articleSlug){  //...  $articleDate = new \DateTime($article->getUdateAt());  $authorDate = new \DateTime($author->getUpdateAt());\  $date = $authorDate>$articleDate ? $authorDate : $articleDate;  $response->setLastModified($date);  $response->isNotModified($this->getRequest());  return $response;}

Response::isNotModified() 方法比較請求Request中的If-Modified-Since頭和Response中的Last-Modified 頭。如果他們相等，Response會被設定一個304狀態代碼。

注意，If-Modified-since 要求標頭等於最終發送到用戶端特定資源Last-Modified頭。這就是如何用戶端和服務端相互交流決定資源自從它被緩衝後是否被更新。

使用校正最佳化你的代碼：

任何緩衝策略的主要目的都是減輕應用程式的載入。換句話說，你的應用程式做的越少來返回304 response，越好。Response::isNotModified()方法通過暴露一個簡單有效模式做到了。

public funcation showAction($articleSlug){  //擷取最小資訊來計算ETag或者Last-Modified值（基於Request，資料是從資料庫或者一個索引值對儲存執行個體中擷取。  $article = //...  //建立一個Response帶有一個ETag 和/或者 一個Last-Modified 頭  $response = new Response();  $response->setETag($article->computeETag());  $response->setLastModified($article->getPublishedAt());  //為給定的Request檢查Response沒有被修改  if($response->isNotModified($this->getRequest())){    //立刻返回304 Response    return $response;  }else{    //做一些更多的工作-比如擷取更多的資料    $comment=//...    //或者用你已經開啟的$response渲染一個模版    return $this->render('MyBundle:MyController:article.html.twig',        array('article'=>$article, 'comments' =>$comments),        $response    );  }}

當Response沒有被修改後，isNotModified()自動化佈建response的狀態代碼為304，移除response的內容，移除一些不需要為304存在的頭。

不同的回複響應：

到目前為止，我們已經假設了每個URI只有一個目標資源的表示。預設情況下，HTTP緩衝通過使用URI的資源作為緩衝鍵被執行。如果兩個人請求同一個可緩衝資源的URI，第二個使用者將擷取緩衝版本。有時候這些不夠，不同版本的用一個URI需要被按照一個或者多個要求標頭的值來被緩衝。舉個例子，如果當用戶端支援你壓縮頁面時，任何給定的URI都有兩種表示：一個是用戶端支援壓縮時，一個是不支援時的表示。這時候要求標頭的Accept-Encoding值將決定使用哪個。

在這種情況下，我們需要回複的特定URI緩衝一個壓縮版本和一個非壓縮版本，基於請求的Accept-Encoding值返回它們。這是通過Vary Response頭，Vary是一個不同頭用逗號分隔，它的值觸發請求資源的不同表示。

Vary:Accept-Encoding,User-Agent

注意，這個特別的Vary頭，將基於URI和Accept-Encoding和User-Agent 要求標頭為每個資源的不同版本進行緩衝。

Response對象提供一個乾淨的介面來管理Vary 頭：

// 設定一個vary 頭$response->setVary('Accept-Encoding');// 設定多個vary頭$response->setVary(array('Accept-Encoding', 'User-Agent'));

setVary()方法需要一個頭名字或者一個頭名字數組對應不同的response。

到期和校正：

你當然可以在同一個Response中同時使用校正和到期。因為到期勝過校正，你可以輕易的從它們兩個中根據好處做出選擇。換句話說，通過同時使用到期和校正，你可以指示快取服務於緩衝的內容，同時後台間隔檢查來調查內容是否依然合法。

更多Response方法：

Response類提供了許多和緩衝相關的方法。下面是主要的一些：

// 標誌Response到期陳舊$response->expire();// 強迫response返回一個適合 304 的沒有內容的response$response->setNotModified();

另外，跟緩衝最相關的HTTP頭可以被通過一個單獨的方法setCache()設定。

// 通過一個調用設定緩衝參數$response->setCache(array(  'etag'     => $etag,  'last_modified' => $date,  'max_age'    => 10,  's_maxage'   => 10,  'public'    => true,  // 'private'  => true,));

使用ESI（Edge Side Includes)

網關緩衝是一個提高你網站執行效率的很好的途徑。但是它們有一個限制：只能緩衝整個頁面。如果你不想緩衝整個頁面或者頁面的某一部分很動態，你就沒那麼幸運了。

幸運的是，Symfony2為這些情況提供一個解決方案，基於ESI技術。它允許頁面指定的部分和首頁比起來有一個不同的緩衝策略。

ESI規範描述標籤你可以嵌入到你的頁面來和網關緩衝交流。Symfony2中只實現了一個標籤，include, 因為這是唯一一個能在Akami上下文之外使用的標籤。

      Some content            More content  

從這個例子中注意到每個ESI標籤有一個全限定URL。一個ESI標籤表示可以通過一個給定的URL擷取的一個頁面片段。

當請求被處理時，網關緩衝從它的緩衝或者從背後的應用程式中請求回複擷取整個頁面。換句話說，網關緩衝既從緩衝中擷取包含的頁面片段也會再次從背後的應用程式中擷取回複請求的頁面片段。當所有的ESI標籤被解析後，網關緩衝合并每一個ESI內容到一個首頁並返回最後的內容到用戶端。所有的這一切都透明的發生在網關緩衝級（在你的程式外）。你將看到，如果你選擇ESI標籤，Symfony2讓這包含它們的這一過程幾乎不費勁。

在Symfony2中使用ESI

首先，使用ESI需要確認在你的應用程式配置中已經開啟。

YAML格式：

# app/config/config.ymlframework:  # ...  esi: { enabled: true }

XML格式：

PHP代碼格式：

// app/config/config.php$container->loadFromExtension('framework', array(  // ...  'esi'  => array('enabled' => true),));

現在假設我們有一個頁面時相對靜態，除了一個新聞自動收報機在內容的底部。使用ESI，我們可以緩衝新聞自動收報機獨立於頁面其它部分。

public function indexAction(){  $response = $this->render('MyBundle:MyController:index.html.twig');  $response->setSharedMaxAge(600);  return $response;}

在該樣本中，我們給全頁面緩衝周期為10分鐘。接下來，通過嵌入一個action讓新聞ticker包含到模板中。這是通過render協助來實現的。因為嵌入的內容來自其它頁面，Symfony2使用一個標準的render協助來配置ESI標籤：

Twig格式：

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

PHP格式：

<?php echo $view['actions']->render('...:news', array(), array('standalone' => true)) ?>

通過把standalone設定為true，告訴Symfony2這個action應該被渲染為一個ESI標籤。

你可能想知道為什麼要使用一個helper方法來代替直接寫ESI標籤。這是因為使用helper讓你的應用程式工作即使沒有網關緩衝被安裝。讓我們來看看它是怎樣工作的。

當standalone為false時（也是預設值），Symfony2在發送response到用戶端之前合并包含的頁面內容到一個首頁。

但是當standalone為true時，並且如果Symfony2發現它跟支援ESI的網關緩衝對話時，它產生一個ESI include標籤。

如果沒有網關緩衝或者網關緩衝不支援ESI，Symfony2將只合并包含的標籤頁面內容到一個主要的像它在standalone為false時所做的一樣。

嵌入的action現在可以指定自己的緩衝規則了，完全獨立於首頁。

public function newsAction(){  //...  $response->setShareMaxAge(60);}

使用ESI，整個頁面緩衝將被保持600秒有效，但是新聞群組建緩衝將只持續60秒。

ESI的一個必備條件是嵌入的action可以通過一個URL被訪問，這樣網關緩衝才可以獨立於頁面其它部分擷取它。當然，一個action不能被通過一個URL訪問除非有一個路由指向它。Symfony2 通過一個通用的路由和controller負責這個。

為了ESI包含標籤能正常的工作，你必須定義_internal 路由：

YAML格式：

# app/config/routing.yml_internal:  resource: "@FrameworkBundle/Resources/config/routing/internal.xml"  prefix:  /_internal

XML格式：

<?xml version="1.0" encoding="UTF-8" ?>  

PHP代碼格式：

// app/config/routing.phpuse Symfony\Component\Routing\RouteCollection;use Symfony\Component\Routing\Route;$collection->addCollection($loader->import('@FrameworkBundle/Resources/config/routing/internal.xml', '/_internal'));return $collection;

因為路由允許所有的action通過一個URL被訪問，你可以通過使用Symfony2防火牆（允許訪問你的反向 Proxy的IP範圍）內容保護它。

緩衝策略的一大優勢是你可以讓你的應用程式根據動態需要同時又盡量的減少觸及應用程式。

一旦你開始使用ESI，請記住一定使用s-maxage指令代替max-age。因為瀏覽器只接受彙總的資源，它不知道子組件，所以它會按照max-age指令緩衝整個頁面。這是你不希望它做的。

render helper支援的兩外兩個有用選項：
alt:用作ESI標籤的alt屬性，當src找不到時，它允許你指定一個替代URL。
ignore_errors:如果設定為true,一個onerror屬性將被添加到ESI，並且屬性值設定為continue，在一個失敗事件中，網關緩衝將只默默的移除ESI標籤。

緩衝失效：

“電腦科學中有兩大難題：緩衝失效和命名事物”---Phil Karlton

你永遠都不需要失效快取資料，因為失效早已在HTTP緩衝模型中被考慮到了。如果你使用校正，你永遠都不需要通過定義校正任何事情；如果你使用到期並失效某個資源，它意味著你設定一個未來的到期日期。因為在任何類型的反向 Proxy中失效都是一個頂級規範，如果你不擔心失效，你可以在不改變任何應用程式代碼的情況下在反向 Proxy間切換。

其實，所有的反向 Proxy都提供了清除快取資料的方式，但是你需要盡量的避免使用它們。最標準的清除給定URL的緩衝的方式是通過指定請求的HTTP方法為PURGE 來進行。

下面是如何配置Symfony2的反向 Proxy支援PURGE HTTP方法：

// app/AppCache.phpuse Symfony\Bundle\FrameworkBundle\HttpCache\HttpCache;class AppCache extends HttpCache{  protected function invalidate(Request $request)  {    if ('PURGE' !== $request->getMethod()) {      return parent::invalidate($request);    }    $response = new Response();    if (!$this->getStore()->purge($request->getUri())) {      $response->setStatusCode(404, 'Not purged');    } else {      $response->setStatusCode(200, 'Purged');    }    return $response;  }}

注意，你必須保護你的PURGE HTTP方法以避免隨便一個人使用某些方法清除你的快取資料。

總結：

Symfony2旨在遵循一條被證明了的道路規則：HTTP。 緩衝也不例外。掌握Symfony2緩衝系統意味著熟悉HTTP緩衝模式和有效使用它們。

這就意味著，你不能只依賴於symfony2文檔和程式碼範例，你必須瞭解有關HTTP緩衝和網關緩衝的更寬闊的知識，比如Varnish。

希望本文所述對大家基於Symfony架構的PHP程式設計有所協助。

