HTTP快取

富網絡應用程式的天然屬性是，它們是動態的。不管你的程式多有效率，每次請求都一直承受著遠遠大於靜態檔案的開銷。

而更多的web程序，並沒有受大的影響。 Symfony閃電般快，除非你在做一些超級重載，每一次請求都會很快恢復，而沒有把過多壓力留給伺服器。

但你的網站正在成長，過載有可能成為問題。針對通常請求的處理，只應完成一次。而這正是快取鎖定的目標。

緩存於巨人的肩膀 ¶

改善一套程式的效能，最有效的方式是快取頁面的全部輸出，然後無視整個後續請求。當然，對於高動態網站而言，不可能總是這樣。本章，你將了解Symfony的快取系統是如何運作的，以及為何這是最佳方案。

Symfony快取系統與眾不同，因為它依賴的是HTTP specification所定義的HTTP cache之簡單與強大。有別於重新發明一套快取方法，Symfony強調的是定義了web基本通訊的標準。一旦你掌握了“HTTP驗證”，以及“快取models的過期”等基本知識，你已經可以去掌握Symfony的快取系統。

學習Symfony快取的過程，可分為四個步驟：

1. #網關快取（gateway cache），或反向代理（reverse proxy），是位於你程式前面的獨立層。反向代理，快取的是回應，因為它們被你的程式回傳；還能在請求到達你的程式之前，透過快取的回應來回應請求。 Symfony提供了自己的反向代理，但任何反向代理都可以使用。

2. HTTP cacheHTTP快取頭，在你的程式和客戶端之間，被用於同網關快取或其他快取進行通訊。 Symfony提供了合理的預設配置，以及強大的接口，用於與快取頭（cache headers）進行互動。

3. HTTP過期與驗證（expiration and validation），這兩個模型被用來決定快取的內容是否新鮮/fresh（可從cache中復用），或是否陳舊/stale（應被程式重新產生）

4. Edge Side Includes（ESI） ，邊緣端包容允許HTTP cache被用於頁面局部（甚至嵌套片段）的獨立快取。在ESI的幫助下，你甚至可以「快取整個頁面60分鐘，但側邊欄只快取5分鐘」。

由於HTTP cache並非Symfony專用，有許多相關文章。如果你對HTTP快取不太熟，強烈建議閱讀Ryan Tomayko的快取能做什麼（Things Caches Do）。另一個深度好文是Mark Nottingham的快取教學（Cache Tutorial）。

使用Gateway Cache ¶

當使用HTTP快取時，cache是完全與你的程式分開的，它居於你的程式與發動請求的客戶端的之間。

快取的任務，就是接收客戶端請求，然後把它們再傳回你的程序，跟著推送回客戶端。這裡的快取是程式與瀏覽器之間的「請求-回應」通訊過程的「中間人」。

隨著時間推移，這些快取將儲存每一次被認為「可以快取（cacheable）」的回應（參考HTTP快取介紹）。如果相同的資源被再次要求，cache將發送快取了的回應至客戶端，完全無視你的程式。

這種類型的快取即是HTTP gateway cache（網關快取），存在於諸如Varnish、反向代理模式下的Squid以及Symfony的反向代理之中。

快取類型 ¶

但是Gateway快取並非唯一的快取類型。實際上，你的程式發送的HTTP快取頭，被假定於被最多三種方式的快取所解釋：

• 瀏覽器快取（Browser caches） ：每個瀏覽器都內建了自己的本地緩存，用於你點擊「回退」時使用，或用於圖片和其他assets資源。瀏覽器快取是私有（private）緩存，因為快取的資源不能被其他人使用；

• 代理快取（Proxy caches） ：代理，是指共享（shared）緩存，因為很多人可以跟在某個人的後面（來使用）。通常由大公司或ISP所使用，以減少存取延遲和網路流量。

• 網關快取（Gateway caches）：類似代理，它也是共用緩存，但卻在伺服器端。常為網路管理員所用，令網站更易升級、更可靠、效能更高。

程式的每一次回應，將會經歷前兩種快取類型中的一種或兩種。這些快取是在你的（程式）控制之外，卻遵守回應中設定好的HTTP快取的指令。

Symfony反向代理程式（Reverse Proxy） ¶

#Symfony內建了用PHP寫的反向代理（也稱為gateway快取）。 它並非Varnish這種全功能的反向代理快取，但卻是一個很好的開始。

開啟代理程式很容易：Symfony程式都預先建立了一個cache kernel快取核心（AppCache），它把預設的核心（AppKernel）給打包。這個快取核心就是 反向代理。

開啟快取很容易，修改你的前端控制器程式碼。你也可以在app_dev.php中做出這些改變，即可為dev環境添加快取：

// web/app.phpuse Symfony\Component\HttpFoundation\Request;
// ...$kernel = new AppKernel('prod', false);$kernel->loadClassCache(); 
// add (or uncomment) this new line! / 添加下面新行！
// wrap the default AppKernel with the AppCache one
// 用AppCache打包默认的AppKernel$kernel = new AppCache($kernel); $request = Request::createFromGlobals(); $response = $kernel->handle($request);$response->send(); $kernel->terminate($request, $response);

上面的快取核心，將立即作為反向代理來運作－從你的程式快取回應，然後把它們回到客戶端。

1

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,
        );
    }}

以下是一些主要選項：

default_ttl

數值是秒，表示的是當回應中沒有提供明確的新鮮度資訊時，一個快取入口被認為是fresh的長度。明確指定Cache-Control或Expires頭，可以覆寫這個值（預設是0）。

private_headers

#一組請求頭，在沒有「透過Cache-Control指令（預設為Authorization和Cookie）明確聲明目前回應是public還是private狀態」的回應中，觸發「private」Cache -Control行為。

allow_reload

#指定客戶端是否可以在請求中包容一個Cache-Control的「no -cache”指令來強制重新載入快取。設為true即可遵守RFC2616（預設為false）。

allow_revalidate

#指定客戶端是否可以在請求中包容一個來Cache-Control的“ max-age=0”來強制重新驗證。設為true即可遵守RFC2616（預設為false）。

stale_while_revalidate

指定的預設秒數（以秒為間隔是因為Response的TTL精確度是秒），在此期間，儘管快取在後台對回應正進行重新驗證，但它能夠立即傳回一個不新鮮的回應（預設值是2）；本設定可被HTTPCache-Control擴充的stale-while-revalidate覆蓋（參考RFC 5861）。

stale_if_error

#指定的預設秒數（間隔為秒），在此期間，快取可以對遇到錯誤的回應提供服務（預設值是60）。本設定可被HTTPCache-Control擴充的stale-if-error覆寫（參考RFC 5861）。

如果debug被設為true，Symfony將自動添加一個X-Symfony-Cache頭到回應中，在裡面有關於緩存命中和丟失的有用資訊。

令你的回應成為HTTP快取 ¶

#為了利用可用的快取層，你的程式應該與以下資訊進行通訊：1 、哪些響應可被緩存。 2、能夠決定快取「何時/如何變成不新鮮」的規則。

HTTP指定了以下四個用於回應的快取頭：

• Cache-Control

• #Expires

• #ETag

• Last -Modified

其中最重要且功能最強的當屬Cache-Control頭，它可說是多種快取資訊的集合。

Cache-Control頭 ¶

#Cache-Control頭是特殊的，它包含不只一條，而是很多條和響應的快取能力相關的資訊。每個資訊被以英文逗號分隔開來：

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

Symfony提供了一個關於Cache-Control頭的抽象層，以便令它的創建更加易於管理：

// ... use Symfony\Component\HttpFoundation\Response; $response = new Response();
// mark the response as either public or private 标记响应是公有还是私有$response->setPublic();$response->setPrivate();
// set the private or shared max age 设置私有或公有的最大周期$response->setMaxAge(600);$response->setSharedMaxAge(600); 
// set a custom Cache-Control directive 设置一个自定义Cache-Control命令$response->headers->addCacheControlDirective('must-revalidate', true)

Public回應和Private回應 ¶

不管是gateway還是proxy緩存，都被認為是「shared」共享緩存，因為快取內容被更多用戶分享。如果一個「特定用戶專有」回應被錯誤地置於共享快取中，它可能在後面的時間裡被傳回給多位不同用戶。試想你的帳號資訊被緩存，然後發送給所有後續請求了自己帳號頁面的用戶是個什麼場面！

為應對這種情形，每一個回應應設為public或private：

public

private

¶

• 你永遠不應該在GET或HEAD請求的回應中改變程式狀態。就算你不使用gateway cache，然而代理快取的本質是，任何GET或HEAD請求，可能或並沒有真正hit到你的伺服器；

• 不要預期對PUT、POST或DELETE方法進行快取。這些方法意味著被用於你的程式狀態改變時（例如刪除一篇部落格）。快取它們將阻止特定的請求命中或改變你的程式。

¶

Cache-Control 頭。實務中，多數快取在請求中包含cookie時、包含authorization頭時、使用了一個非安全方法時（例如PUT、POST或DELETE）或當回應有一個重定向狀態碼時，什麼也不做。

Cache-Header頭。

• 如果沒有快取頭資訊被定義（

  Cache-Control、Expires、ETag或Last -Modified），Cache-Control將設為no-cache，代表回應將不被快取；

##如果
• Cache-Control

  是空（但是另一個快取頭有被設定），其值將設為private, must-revalidate;

• 但是如果至少有一個Cache-Control指令被設置，而且沒有public或private指令被明確添加的話，Symfony會自動加入private指令（除了當s-maxage被設定時）

HTTP Expiration,Validation和Invalidation # ¶

HTTP協定定義了兩個快取模型：

• #利用expiration model（過期模型），透過包容 Cache-Control頭和/或Expires頭，即可直接指定一個回應應該被認為「新鮮」的時長。快取能夠理解過期時間，不再製造相同請求，直到該快取版本抵達過期時間，而且變得「不新鮮（stale）」。

• 當頁面是真動態時（展現層經常改變），則validation model（驗證模型）的使用就十分有必要。利用這個模型，快取把回應儲存起來，但會在每次請求時向伺服器「提問」——是否快取了的回應仍然有效？程式使用了一個獨立的回應辨識器（即Etag頭）和/或一個時間戳記（即Last-Modified頭），來檢查目前頁面自被快取之後，是否發生了改變。

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

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

// Sets the number of seconds after which the response
// should no longer be considered fresh// 设置“响应过期”的秒数$response->setMaxAge(600);
 // Same as above but only for shared caches
// 同上，但仅用于共享缓存$response->setSharedMaxAge(600);

1

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

// Marks the Response stale 标记响应过期$response->expire(); 
// Force the response to return a proper 304 response with no content
// 强制响应返回一个没有内容的恰当的304响应$response->setNotModified();

// Set cache settings in one call$response->setCache(array(
    'etag'          => $etag,
    'last_modified' => $date,
    'max_age'       => 10,
    's_maxage'      => 10,
    'public'        => true,
    // 'private'    => true,
    ));