cache HTTP


DiffArtikel ini berasal dari BUKU dan berbeza daripada dokumen rasmi sedia ada. Artikel ini menerangkannya dengan lebih mendalam dan terperinci di beberapa tempat. Oleh itu, kami tidak memaksa penyegerakan dengan pegawai itu.

Sifat aplikasi web yang kaya ialah ianya dinamik. Tidak kira betapa cekap program anda, setiap permintaan akan sentiasa menanggung overhed yang jauh lebih besar daripada fail statik.

Dan lebih banyak program web tidak banyak terjejas. Symfony adalah sepantas kilat, dan melainkan anda melakukan sesuatu tugas yang sangat berat, setiap permintaan dipulihkan dengan cepat tanpa meletakkan terlalu banyak tekanan pada pelayan.

Tetapi tapak anda semakin berkembang, dan beban berlebihan mungkin menjadi masalah. Pemprosesan permintaan biasa hendaklah dilakukan sekali sahaja. Dan ini betul-betul matlamat mengunci cache.

Caching on the shoulders of gergasi

Cara paling berkesan untuk meningkatkan prestasi program adalah dengan cache semua output halaman dan kemudian mengabaikannya keseluruhan permintaan susulan. Sudah tentu, untuk tapak web yang sangat dinamik, ini mungkin tidak selalu berlaku. Dalam bab ini, anda akan mempelajari cara sistem caching Symfony berfungsi dan sebab ia merupakan penyelesaian terbaik.

Sistem caching Symfony adalah berbeza kerana ia bergantung pada kesederhanaan dan kuasa cache HTTP yang ditakrifkan oleh spesifikasi HTTP. Daripada mencipta semula pendekatan caching, Symfony menekankan piawaian yang mentakrifkan komunikasi asas di web. Sebaik sahaja anda menguasai asas "pengesahan HTTP" dan "tamat tempoh model cache", anda sudah boleh menguasai sistem caching Symfony.

Proses pembelajaran Symfony cache boleh dibahagikan kepada empat langkah:

  1. gateway cache#🎜🎜 #, atau reverse proksi, ialah lapisan berasingan di hadapan aplikasi anda. Proksi terbalik menyimpan cache respons apabila ia dikembalikan oleh program anda; Symfony menyediakan proksi terbaliknya sendiri, tetapi mana-mana proksi terbalik akan berfungsi.

  2. HTTP cacheHTTP pengepala cache, digunakan antara program anda dan klien, digunakan untuk berkomunikasi dengan cache get laluan atau komunikasi cache lain. Symfony menyediakan konfigurasi lalai yang munasabah dan antara muka yang berkuasa untuk berinteraksi dengan pengepala cache.

  3. HTTP

    Tamat tempoh dan pengesahan (tamat tempoh dan pengesahan) , kedua-dua model ini digunakan untuk menentukan sama ada kandungan cache ialah #🎜🎜 Fresh/fresh (boleh digunakan semula daripada cache), atau sama ada basi/basi (perlu dijana semula oleh program)

    #🎜 🎜#
    4. Edge Side Includes (ESI)
  4. , Edge Side Includes membenarkan cache HTTP digunakan untuk caching bebas bahagian halaman (walaupun serpihan bersarang). Dengan bantuan ESI, anda juga boleh "menyimpan keseluruhan halaman selama 60 minit, tetapi bar sisi selama 5 minit sahaja."

    Oleh kerana cache HTTP bukan eksklusif untuk Symfony, terdapat banyak artikel berkaitan. Jika anda tidak biasa dengan cache HTTP, saya sangat mengesyorkan membaca
    5. Things Caches Do
oleh Ryan Tomayko. Satu lagi artikel yang bagus dan mendalam ialah

Tutorial Cache Mark Nottingham.

Gunakan Cache Gateway

Apabila menggunakan cache HTTP, cache sepenuhnya berasingan daripada program anda, ia berada di Antara program anda dan pelanggan membuat permintaan.

Tugas caching adalah untuk menerima permintaan pelanggan, kemudian menghantarnya kembali ke program anda, dan kemudian menolaknya kembali kepada klien. Cache di sini ialah "orang tengah" dalam proses komunikasi "request-response" antara program dan penyemak imbas.

Lama kelamaan, cache ini akan menyimpan setiap respons yang dianggap "boleh cache" (lihat Pengenalan Cache HTTP). Jika sumber yang sama diminta sekali lagi, cache akan menghantar respons cache kepada klien, mengabaikan sepenuhnya aplikasi anda.

Jenis cache ini ialah HTTP gateway cache (gateway cache), yang wujud di tempat seperti Varnish, Squid#🎜🎜 dalam mod proksi terbalik #Dan proksi terbalik Symfony.

Jenis cache

Tetapi cache Gateway bukanlah satu-satunya jenis cache. Malah, pengepala cache HTTP yang dihantar oleh program anda diandaikan ditafsirkan oleh sehingga tiga cara caching: cache)

: Setiap penyemak imbas mempunyai cache setempat terbina dalam sendiri, yang digunakan apabila anda mengklik "Kembali ", atau untuk imej dan aset lain. Cache penyemak imbas ialah cache peribadi (

private
    ) kerana sumber cache tidak boleh digunakan oleh orang lain; (Cache proksi)
  • : Proksi merujuk kepada kongsi (

    shared ) cache, kerana ramai orang boleh mengikuti seseorang (untuk digunakan). Biasanya digunakan oleh syarikat besar atau ISP untuk mengurangkan kependaman akses dan trafik rangkaian.

    • Cache Gerbang
  • : Serupa dengan proksi, ia juga cache kongsi, tetapi di sisi pelayan. Selalunya digunakan oleh pentadbir rangkaian untuk menjadikan tapak web lebih mudah dinaik taraf, lebih dipercayai dan lebih berprestasi.

    Cache Gerbang kadangkala dirujuk secara khusus sebagai cache proksi terbalik, cache pengganti (cache proksi) dan juga pemecut HTTP.

  • Apabila situasi di mana respons cache mengandungi kandungan (seperti maklumat akaun) untuk pengguna tertentu dibincangkan, peribadi ( #🎜 🎜#private
    • ) Caching dan Sharing (
shared
) Kepentingan caching semakin meningkat dari hari ke hari.

Setiap tindak balas program akan mengalami satu atau kedua-dua daripada dua jenis cache pertama. Cache ini berada di luar kawalan (program) anda, tetapi patuhi arahan cache HTTP yang ditetapkan dalam respons.

Symfony Reverse Proxy

Symfony mempunyai proksi songsang terbina dalam (juga dipanggil cache get laluan) yang ditulis dalam PHP. Ia bukan cache proksi terbalik berciri penuh seperti Varnish, tetapi ia adalah permulaan yang baik.

Untuk butiran lanjut tentang persediaan Varnish, rujuk Cara Mempercepatkan Tapak Web Saya dengan Varnish .

Mendayakan proksi adalah mudah: Semua program Symfony mempunyai kernel cache pra-bina (AppCache), yang membungkus teras lalai (AppKernel). Teras cache ini ialah proksi terbalik. 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);

上面的缓存核心，将立即作为反向代理来运作——从你的程序中缓存响应，然后把它们返回到客户端。

如果你正使用framework.http_method_override选项，来从_method参数中读取HTTP方法，参考上面链接来调整到你需要的程度。

缓存核心有一个特殊的getLog()

Mendayakan caching adalah mudah, cuma ubah suai kod pengawal hadapan anda. Anda juga boleh membuat perubahan ini dalam app_dev.php untuk menambah cache bagi persekitaran dev: 
1
Teras cache di atas akan bertindak segera sebagai proksi terbalik Operasi - Cache jawapan daripada permohonan anda dan mengembalikannya kepada pelanggan.
Jika anda menggunakan framework.http_method_override
pilihan untuk membaca kaedah HTTP daripada parameter _method. Rujuk pautan di atas untuk melaraskannya pada tahap yang anda perlukan.
Teras cache mempunyai kaedah getLog() khas yang mengembalikan rentetan untuk menunjukkan perkara yang sebenarnya berlaku dalam lapisan cache. Dalam persekitaran pembangunan, anda boleh menggunakannya untuk nyahpepijat atau mengesahkan strategi caching anda.
🎜🎜🎜🎜
error_log($kernel->getLog());
🎜🎜🎜🎜
// 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,
        );
    }}
🎜🎜🎜🎜🎜

Objek AppCache mempunyai konfigurasi lalai yang sesuai, tetapi dengan mengatasi getOptions() kaedah untuk menetapkan set pilihan, objek boleh diperhalusi. AppCache对象有一个合适的默认配置，但是通过覆写getOptions()方法来设置一组选项，该对象即可被精细调整。

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


除非在getOptions()方法中进行覆写，否则debub选项将被自动设成“被剥离出来的AppKernel

// ... 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)


🎜Melainkan ditindih dalam kaedah getOptions(), pilihan debub akan ditetapkan secara automatik kepada nilai nyahpepijat dalam "dilucutkan AppKernel". 🎜🎜


Berikut ialah beberapa pilihan utama:

default_ttldefault_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

Nilai ialah saat, yang bermaksud apabila tiada maklumat kesegaran yang jelas diberikan dalam respons, cache kemasukan adalah Ia dianggap sebagai tempoh segar. Nilai ini boleh ditindih dengan menyatakan secara eksplisit pengepala Cache-Control atau Expires (lalai ialah 0).

private_headers

Satu set pengepala permintaan yang boleh digunakan tanpa "melepasi arahan Cache-Control (lalai ialah < kod>Kod Kebenaran dan Cookie) mencetuskan Cache-Control "peribadi" dalam respons yang menyatakan secara eksplisit sama ada respons semasa adalah awam atau Status pribadi" Gelagat.

allow_reload🎜🎜Menentukan sama ada klien boleh memasukkan arahan Cache-Control "no-cache" dalam permintaan untuk memaksa Muat Semula cache. Tetapkan kepada true untuk mematuhi RFC2616 (lalai ialah false). 🎜
🎜🎜allow_revalidate🎜🎜Menentukan sama ada pelanggan boleh memasukkan "max-age=0" kepada Cache-Control dalam permintaan untuk paksa pengesahan semula. Tetapkan kepada true untuk mematuhi RFC2616 (lalai ialah false). 🎜
🎜🎜stale_while_revalidate🎜🎜Bilangan lalai saat ditentukan (selang adalah dalam saat kerana ketepatan TTL bagi Respons ialah saat), dalam tempoh ini, walaupun cache berada di latar belakang Respons sedang disahkan semula, tetapi ia boleh mengembalikan respons yang lapuk dengan serta-merta (lalai ialah 2); tetapan ini boleh dilanjutkan dengan HTTPCache-Control stale-while-revalidateOverride (rujuk RFC 5861). 🎜
🎜🎜stale_if_error🎜🎜 Menentukan bilangan saat lalai (selang masa adalah saat) semasa cache boleh menyampaikan respons yang menghadapi ralat (lalai ialah 60< /kod>). Tetapan ini boleh digantikan oleh basi-if-error sambungan HTTP Cache-Control (lihat RFC 5861). 🎜
🎜Jika debug ditetapkan kepada true, Symfony akan secara automatik menambah pengepala X-Symfony-Cache pada respons, di dalam Terdapat maklumat berguna tentang cache hit dan miss. . Tetapi kerana ia ditulis dalam PHP, ia tidak secepat proksi yang ditulis dalam C. Inilah sebabnya mengapa anda amat disyorkan untuk menggunakan Vanish atau Squid pada pelayan pengeluaran apabila boleh. Berita baiknya ialah menukar dari satu pelayan proksi ke pelayan proksi yang lain adalah mudah dan telus kerana tiada kod dalam program anda untuk diubah suai. Anda boleh menggunakan proksi terbalik Symfony dengan tenang dan anda boleh menaik taraf kepada Varnish pada bila-bila masa apabila trafik anda meningkat pada masa hadapan. 🎜🎜🎜

Prestasi proksi terbalik Symfony adalah bebas daripada kerumitan program. Ini kerana kernel program hanya dimulakan apabila permintaan perlu dihantar kepadanya.

Jadikan cache HTTP respons anda

Untuk memanfaatkan lapisan caching yang tersedia, atur cara anda harus berkomunikasi dengan maklumat berikut: 1. Respons yang manakah boleh dicache. 2. Peraturan yang menentukan bila/bagaimana cache menjadi basi.

Ingat, "HTTP" hanyalah bahasa (teks mudah), digunakan oleh pelanggan dan pelayan untuk berkomunikasi antara satu sama lain. Caching HTTP adalah sebahagian daripada bahasa ini, membenarkan pelanggan dan pelayan bertukar maklumat tentang caching.

HTTP menentukan empat pengepala caching berikut untuk respons:

  • Kawalan CacheCache-Control

  • Expires

  • ETag

  • Last-Modified

其中最为重要和功能最强的当属Cache-Control头，它可说是多种缓存信息的集合。

每种头都在HTTP Expiration,Validation和Invalidation小节中进行了详解。

Cache-Control头 

Cache-Control头是特殊的，它包含不止一条，而是很多条和响应的缓存能力相关的信息。每种信息被以英文逗号分隔开来：

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

Symfony提供了一个关于Cache-Control

Tamat tempoh

ETag

Terakhir Diubah Suai
Yang paling penting dan berkuasa sudah pasti Cache-Control< /code> header, yang boleh dikatakan sebagai koleksi pelbagai maklumat cache. 🎜🎜🎜🎜Setiap pengepala diterangkan secara terperinci dalam bahagian Tamat Tempoh, Pengesahan dan Pembatalan HTTP🎜. 🎜🎜🎜

Pengepala Kawalan-Cache ¶🎜

🎜 PengepalaKawalan-Cache adalah istimewa , yang mengandungi bukan hanya satu maklumat, tetapi banyak maklumat yang berkaitan dengan keupayaan caching respons. Setiap maklumat dipisahkan dengan koma: 🎜
Expires: Thu, 01 Mar 2011 16:00:00 GMT
🎜Symfony menyediakan lapisan abstraksi di atas pengepala Cache-Control untuk menjadikan penciptaannya lebih mudah diurus: 🎜🎜
// 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);
🎜🎜🎜 Jika anda ingin menetapkan pengepala cache untuk tindakan berbeza dalam pengawal anda, anda mungkin ingin melihat 🎜FOSHttpCacheBundle🎜. Ia menyediakan cara untuk menentukan pengepala cache berdasarkan padanan corak URL dan atribut permintaan lain. 🎜🎜🎜

Respons awam dan respons peribadi

Sama ada ia adalah cache get laluan atau proksi, ia dianggap sebagai cache kongsi "kongsi", kerana kandungan cache dikongsi oleh lebih ramai pengguna. Jika respons "khusus pengguna" tersilap diletakkan dalam cache kongsi, ia mungkin dikembalikan kepada berbilang pengguna berbeza pada masa yang akan datang. Bayangkan bagaimana keadaannya jika maklumat akaun anda dicache dan kemudian dihantar kepada semua pengguna seterusnya yang meminta halaman akaun mereka!

Untuk menangani situasi ini, setiap respons hendaklah ditetapkan kepada awam atau peribadi:

awam

menunjukkan bahawa respons harus dicache sebagai cache awam dan peribadi.

private

menunjukkan bahawa semua atau sebahagian daripada maklumat respons hanya untuk pengguna tertentu, jadi caching adalah dilarang untuk caching awam.

Symfony secara konservatif menetapkan setiap respons kepada peribadi. Untuk memanfaatkan cache yang dikongsi (seperti proksi terbalik Symfony), respons mesti ditetapkan secara eksplisit kepada awam.

Kaedah Selamat

Caching HTTP hanya berfungsi di bawah kaedah HTTP "selamat" (seperti GET atau HEAD). Apa yang dipanggil keselamatan bermakna anda tidak boleh mengubah keadaan program pada pelayan apabila menyediakan perkhidmatan kepada permintaan (seperti pengelogan, memproses maklumat cache, dll.). Ini membawa kepada dua kesimpulan yang sangat menarik dan penting:

  • Anda tidak boleh menukar keadaan program sebagai tindak balas kepada permintaan GET atau HEAD. Walaupun anda tidak menggunakan cache get laluan, sifat caching proksi ialah sebarang permintaan GET atau HEAD mungkin atau mungkin tidak benar-benar memukul pelayan anda

  • Jangan mengharapkan kaedah PUT, POST atau DELETE cache. Kaedah ini bertujuan untuk digunakan apabila keadaan aplikasi anda berubah (seperti memadamkan catatan blog). Caching mereka akan menghalang permintaan tertentu daripada memukul atau menukar program anda.

Peraturan cache dan tetapan lalai

HTTP1.1 membenarkan sebarang kandungan dicache secara lalai melainkan pengepala Cache-Control dinyatakan dengan jelas. Dalam amalan, kebanyakan cache tidak melakukan apa-apa apabila permintaan mengandungi kuki, apabila pengepala kebenaran disertakan, apabila kaedah tidak selamat digunakan (seperti PUT, POST atau DELETE), atau apabila respons mempunyai kod status ubah hala. Cache-Control头。实践中，多数缓存在请求中包含cookie时、包含authorization头时、使用了一个非安全方法时（比如PUT、POST或DELETE）或当响应有一个重定向状态码时，什么也不做。

当开发者在响应头中什么也没设置时，Symfony依据以下规则，自动设置了有意义的而且是偏保守的Cache-Header头。

  • 如果没有缓存头信息被定义（Cache-Control、Expires、ETag或Last-Modified），Cache-Control将被设为no-cache，代表响应将不被缓存；

  • 如果Cache-Control是空（但是另外一个缓存头有被设置），其值将被设为private, must-revalidate

    Apabila pembangun tidak menetapkan apa-apa dalam pengepala respons, Symfony secara automatik menetapkan pengepala Cache-Header yang bermakna dan konservatif mengikut peraturan berikut. 🎜🎜🎜🎜Jika tiada pengepala cache ditentukan (Kawalan Cache, Tamat tempoh, ETag atau Terakhir Diubahsuai ), Cache-Control akan ditetapkan kepada no-cache, yang bermaksud respons tidak akan dicache 🎜🎜🎜🎜Jika Cache-Control kosong (tetapi pengepala cache lain ditetapkan), nilainya akan ditetapkan kepada peribadi, mesti sahkan semula 🎜

  • Tetapi jika sekurang-kurangnya satu arahan Cache-Control ditetapkan dan tiada arahan awam atau private ditambahkan secara eksplisit, Symfony akan menambah < secara automatik arahan kod>peribadi (kecuali apabila s-maxage ditetapkan) Cache-Control指令被设置，而且没有public或private指令被显式添加的话，Symfony会自动添加private指令（除了当s-maxage被设置时）

HTTP Expiration,Validation和Invalidation 

HTTP协议定义了两种缓存模型：

  • 利用expiration model（过期模型），通过包容Cache-Control头和/或Expires头，即可直接指定一个响应应该被认为“新鲜”的时长。缓存能够理解过期时间，不再制造相同请求，直到该缓存版本抵达过期时间，而且变得“不新鲜（stale）”。

  • 当页面是真动态时（展现层经常改变），则validation model（验证模型）的使用就十分有必要。利用这个模型，缓存把响应存储起来，但会在每次请求时向服务器“提问”——是否缓存了的响应仍然有效？程序使用了一个独立的响应识别器（即Etag头）和/或一个时间戳（即Last-Modified

    • Tamat Tempoh, Pengesahan dan Pembatalan HTTP

Protokol HTTP mentakrifkan dua model caching:
Tetapi terdapat 🎜HTTP Bis🎜 berterusan untuk menulis ganti RFC 2616. Ia tidak menerangkan versi baharu HTTP, tetapi lebih kepada pembersihan protokol HTTP asal. Organisasi dokumen juga telah bertambah baik dengan protokol HTTP dibahagikan kepada tujuh bahagian; setiap bahagian mengenai cache HTTP boleh didapati dalam dua bab berasingan (🎜P4 - Permintaan Bersyarat🎜 dan 🎜P6 - Caching: Pelayar dan cache perantara🎜). 🎜🎜Sebagai pembangun web, anda 🎜sangat digesa oleh pasukan Symfony rasmi kami🎜 untuk membaca tentang protokol HTTP. Ia sangat jelas dan berkuasa sehingga - walaupun 10 tahun selepas ia dicipta - Spesifikasi HTTP tidak ternilai. Kami ingin mengingatkan anda supaya tidak mengambil mudah tentang perjanjian ini - kandungannya ratusan ribu kali lebih cantik daripada kulitnya. 🎜🎜🎜

Tamat tempoh (expired)

model tamat tempoh adalah salah satu daripada dua model caching yang lebih cekap dan langsung, jadi ia harus digunakan sebaik mungkin. Apabila respons dicache melalui tamat tempoh, cache akan menyimpan respons dan mengembalikannya terus sebelum tamat tempoh tanpa memukul program.

Model tamat tempoh boleh dilaksanakan melalui salah satu daripada dua pengepala HTTP yang hampir serupa berikut: Tamat tempoh atau Cache-Control. Expires或Cache-Control。

使用Expires头控制过期 

根据HTTP specification，“Expires头字段将在response被认为是stale之后给出date/time。”。这里的Expires头可以被设为Response方法：setExpires()。它使用DateTime实例作为参数：

1

该响应的HTTP头信息类似这种：

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

setExpires()方法将自动转换日期为GMT时区，因为这是HTTP specification的要求。

注意，在HTTP 1.1版之前，并不需要原始服务器来发送Date头。因此，缓存（比如浏览器的）就需要本地时钟来评估Expires头，进而令缓存周期的计算因时间倾斜而变得脆弱不堪。另外一个Expires头限制是，正如HTTP协议中所描述的，“HTTP/1.1 不得发送Expires的日期超过一年。”

使用Cache-Control头控制过期 

因为Expires头的限制，多数情况下，你应该使用Cache-Control头来替代。记得，Cache-Control头被用于多种不同的缓存指令。例如，max-age和s-maxage。第一个用于全部缓存，而第二个仅在共享缓存时用到。

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

Cache-Control

Gunakan pengepala Tamat Tempoh untuk mengawal tamat tempoh
Mengikut spesifikasi HTTP, medan pengepala "Tamat tempoh akan dipertimbangkan dalam jawapan Tarikh/masa diberikan selepas basi." Pengepala Expires di sini boleh ditetapkan kepada kaedah Respons: setExpires(). Ia menggunakan contoh DateTime sebagai parameter: 
// Set cache settings in one call$response->setCache(array(
    'etag'          => $etag,
    'last_modified' => $date,
    'max_age'       => 10,
    's_maxage'      => 10,
    'public'        => true,
    // 'private'    => true,
    ));
Maklumat pengepala HTTP respons adalah serupa dengan ini: Perhatikan bahawa sebelum HTTP versi 1.1, pelayan asal tidak diperlukan untuk menghantar pengepala Tarikh. Oleh itu, cache (seperti penyemak imbas) memerlukan jam tempatan untuk menilai pengepala Tamat, menjadikan pengiraan tempoh cache terdedah kepada pencongan masa. Satu lagi sekatan pengepala Tamat tempoh ialah, seperti yang diterangkan dalam protokol HTTP, "HTTP/1.1 TIDAK MESTI menghantar Tamat tempoh dengan tarikh yang lebih lama daripada satu tahun Disebabkan pengehadan Tamat tempoh, dalam kebanyakan kes, anda harus gunakan pengepala Cache- Control sebaliknya. Ingat, pengepala Cache-Control digunakan untuk pelbagai arahan caching yang berbeza. Contohnya, umur maks dan s-maxage. Yang pertama digunakan untuk semua cache, manakala yang kedua hanya digunakan apabila cache dikongsi. rrreee
rrreee
Kaedah setExpires() akan menukar secara automatik tarikh ke zon waktu GMT, kerana Ini adalah keperluan spesifikasi HTTP.
Gunakan Cache -Pengepala kawalan Kawalan tamat tempoh
Kawalan CachePengepala biasanya dalam format berikut (tetapi kadangkala terdapat arahan lain):🎜🎜🎜🎜🎜🎜🎜🎜rrreee🎜🎜🎜🎜rrreee🎜🎜rrreee

Tamat Tempoh dan Pengesahan

Anda sudah tentu boleh membalas ResponsGunakan kedua-duanya pengesahan dan tamat tempoh. Kerana kelebihan tamat tempoh melebihi pengesahan, anda boleh mendapat manfaat daripada yang terbaik dari kedua-dua dunia dengan mudah. Iaitu, menggunakan tamat tempoh dan pengesahan bersama-sama, anda boleh mengarahkan cache untuk menyampaikan kandungan yang telah dicache, sambil juga menyemak ke belakang pada selang masa tertentu (tamat tempoh) untuk mengesahkan bahawa kandungan cache masih sah. Response同时使用validation和expiration。因为expiration的优势大过validation，你能很容易地从两个世界中好的一面受益。也就是说，同时使用过期和验证，你可以命令缓存来服务于已缓存的内容，同时还能在某些区间（expiration）向后检查以确认缓存内容仍然有效。

你也可以通过annotation来为expiration和validation去定义HTTP缓存头。参考FrameworkExtraBundle文档。

更多Response方法 

Response类提供了很多方法以应对缓存。下面是几个特别有用的：

rrreee

另外，多数与缓存相关的HTTP头可以单独使用setCache()

Anda juga boleh menentukan pengepala cache HTTP untuk tamat tempoh dan pengesahan melalui anotasi. Rujuk kepada dokumen FrameworkExtraBundle

.

Lagi kaedah Respons

#🎜 🎜 #Kelas Response menyediakan banyak kaedah untuk menangani caching. Berikut adalah beberapa yang amat berguna:
rrreee#🎜🎜# Selain itu, kebanyakan pengepala HTTP berkaitan cache boleh digunakan secara individu setCache()#🎜🎜# kaedah untuk melengkapkan tetapan: #🎜🎜#rrreee#🎜🎜# Ringkasan # 🎜🎜#¶#🎜🎜##🎜🎜##🎜🎜##🎜🎜#Falsafah reka bentuk Symfony adalah mengikut piawaian yang diiktiraf industri: HTTP. Fungsi caching tidak terkecuali. Menguasai sistem caching Symfony bermakna anda sudah biasa dengan model cache HTTP dan boleh menggunakannya dengan cekap. Dengan kata lain, anda boleh meneroka dunia cache HTTP dan cache get laluan yang diwakili oleh Varnish tanpa bergantung pada dokumentasi dan rutin Symfony. #🎜🎜##🎜🎜#
←
→

Laman web PHP Cina

RumahRumahKursusKursusArtikelArtikelSoal JawabSoal JawabKamusKamusManualManualMuat turunMuat turuncaricariAPPMuat turun APPMuat turun