Wajah menggunakan php force cache refresh

Ini adalah dokumen informasi. Meskipun bersifat teknis, ia berupaya membuat konsep yang terlibat dapat dipahami dan dapat diterapkan dalam situasi dunia nyata. Karena itu, beberapa aspek materi disederhanakan atau dihilangkan, demi kejelasan. Jika Anda tertarik dengan detail subjek, silakan jelajahi bagian akhir

Cache Web berada di antara satu atau lebih server Web (juga dikenal sebagai server asal) dan klien atau banyak klien, dan melihat permintaan datang, menyimpan salinan respons — seperti halaman HTML, gambar, dan file (secara kolektif dikenal sebagai representasi) — untuk dirinya sendiri. Kemudian, jika ada permintaan lain untuk URL yang sama, ia dapat menggunakan respons yang dimilikinya, alih-alih memintanya lagi ke server asal.

Ada dua alasan utama mengapa cache Web digunakan

  • Untuk mengurangi latensi — Karena permintaan dipenuhi dari cache (yang lebih dekat ke klien) alih-alih dari server asal, dibutuhkan lebih sedikit waktu untuk mendapatkan representasi dan menampilkannya. Ini membuat Web tampak lebih responsif
  • Untuk mengurangi lalu lintas jaringan — Karena representasi digunakan kembali, ini mengurangi jumlah bandwidth yang digunakan oleh klien. Ini menghemat uang jika klien membayar lalu lintas, dan menjaga persyaratan bandwidth mereka lebih rendah dan lebih mudah dikelola

Jika Anda memeriksa dialog preferensi browser Web modern apa pun (seperti Internet Explorer, Safari, atau Mozilla), Anda mungkin akan melihat pengaturan "cache". Ini memungkinkan Anda menyisihkan sebagian dari hard disk komputer Anda untuk menyimpan representasi yang telah Anda lihat, hanya untuk Anda. Cache browser berfungsi sesuai dengan aturan yang cukup sederhana. Ini akan memeriksa untuk memastikan bahwa representasinya baru, biasanya sekali sesi (yaitu, sekali dalam permintaan browser saat ini)

Cache ini sangat berguna saat pengguna menekan tombol "kembali" atau mengklik tautan untuk melihat halaman yang baru saja mereka lihat. Selain itu, jika Anda menggunakan gambar navigasi yang sama di seluruh situs Anda, gambar tersebut akan disajikan dari cache browser hampir secara instan

Cache proxy web bekerja dengan prinsip yang sama, tetapi dalam skala yang jauh lebih besar. Proxy melayani ratusan atau ribuan pengguna dengan cara yang sama;

Karena cache proxy bukan bagian dari klien atau server asal, melainkan berada di luar jaringan, permintaan harus diarahkan ke mereka entah bagaimana caranya. Salah satu cara untuk melakukannya adalah dengan menggunakan pengaturan proxy browser Anda untuk menentukan secara manual proxy apa yang akan digunakan; . Proxy intersepsi memiliki permintaan Web yang dialihkan ke mereka oleh jaringan yang mendasarinya sendiri, sehingga klien tidak perlu dikonfigurasi untuk mereka, atau bahkan mengetahuinya

Cache proxy adalah jenis cache bersama; . Itu karena representasi populer digunakan kembali beberapa kali

Juga dikenal sebagai "cache proxy terbalik" atau "cache pengganti," cache gateway juga merupakan perantara, tetapi alih-alih digunakan oleh administrator jaringan untuk menghemat bandwidth, mereka biasanya digunakan oleh Webmaster sendiri, untuk membuat situs mereka lebih terukur, andal, dan berkinerja lebih baik

Permintaan dapat dialihkan ke cache gateway dengan sejumlah metode, tetapi biasanya beberapa bentuk penyeimbang beban digunakan untuk membuat satu atau lebih dari permintaan tersebut terlihat seperti server asal bagi klien

Jaringan pengiriman konten (CDN) mendistribusikan cache gateway di seluruh Internet (atau sebagian darinya) dan menjual caching ke situs Web yang tertarik. Speedera dan Akamai adalah contoh CDN

Tutorial ini sebagian besar berfokus pada cache browser dan proxy, meskipun beberapa informasi juga cocok untuk mereka yang tertarik dengan cache gateway

Caching web adalah salah satu teknologi yang paling disalahpahami di Internet. Webmaster khususnya takut kehilangan kendali atas situs mereka, karena cache proxy dapat "menyembunyikan" pengguna mereka dari mereka, sehingga sulit untuk melihat siapa yang menggunakan situs tersebut

Sayangnya bagi mereka, bahkan jika cache Web tidak ada, ada terlalu banyak variabel di Internet untuk memastikan bahwa mereka bisa mendapatkan gambaran yang akurat tentang bagaimana pengguna melihat situs mereka. Jika ini adalah masalah besar bagi Anda, tutorial ini akan mengajari Anda cara mendapatkan statistik yang Anda perlukan tanpa membuat situs Anda tidak ramah cache

Kekhawatiran lainnya adalah bahwa cache dapat menyajikan konten yang kedaluwarsa, atau basi. Namun, tutorial ini dapat menunjukkan kepada Anda cara mengonfigurasi server Anda untuk mengontrol bagaimana konten Anda di-cache

CDN adalah pengembangan yang menarik, karena tidak seperti banyak cache proxy, cache gateway mereka diselaraskan dengan kepentingan situs Web yang di-cache, sehingga masalah ini tidak terlihat. Namun, meskipun Anda menggunakan CDN, Anda tetap harus mempertimbangkan bahwa akan ada proxy dan cache browser di hilir

Di sisi lain, jika Anda merencanakan situs dengan baik, cache dapat membantu memuat situs Web Anda lebih cepat, dan menghemat beban di server dan tautan Internet Anda. Perbedaannya bisa dramatis; . Pengguna akan menghargai situs yang memuat cepat, dan akan mengunjungi lebih sering

Pikirkan seperti ini; . Cache melakukan hal yang sama untuk Anda, dan bahkan lebih dekat ke pengguna akhir. Yang terbaik dari semuanya, Anda tidak perlu membayarnya

Faktanya adalah proxy dan cache browser akan digunakan apakah Anda suka atau tidak. Jika Anda tidak mengonfigurasi situs Anda untuk di-cache dengan benar, itu akan di-cache menggunakan default apa pun yang diputuskan oleh administrator cache

Semua cache memiliki seperangkat aturan yang mereka gunakan untuk menentukan kapan menyajikan representasi dari cache, jika tersedia. Beberapa aturan ini diatur dalam protokol (HTTP 1. 0 dan 1. 1), dan beberapa diatur oleh administrator cache (baik pengguna cache browser, atau administrator proxy)

Secara umum, ini adalah aturan paling umum yang diikuti (jangan khawatir jika Anda tidak memahami detailnya, akan dijelaskan di bawah)

  1. Jika header respons memberi tahu cache untuk tidak menyimpannya, itu tidak akan terjadi
  2. Jika permintaan diautentikasi atau aman (mis. e. , HTTPS), itu tidak akan di-cache oleh cache bersama
  3. Representasi yang di-cache dianggap segar (yaitu, dapat dikirim ke klien tanpa memeriksa dengan server asal) jika
    • Ini memiliki waktu kedaluwarsa atau kumpulan tajuk pengontrol usia lainnya, dan masih dalam periode baru, atau
    • Jika cache telah melihat representasi baru-baru ini, dan telah dimodifikasi relatif lama
    Representasi segar disajikan langsung dari cache, tanpa memeriksa dengan server asal
  4. Jika representasi sudah basi, server asal akan diminta untuk memvalidasinya, atau memberi tahu cache apakah salinan yang dimilikinya masih bagus
  5. Dalam keadaan tertentu — misalnya, saat terputus dari jaringan — cache dapat menyajikan respons yang tidak aktif tanpa memeriksa dengan server asal

Jika tidak ada validator (header

Expires: Fri, 30 Oct 1998 14:19:41 GMT
3 atau
Expires: Fri, 30 Oct 1998 14:19:41 GMT
4) yang ada pada respons, dan respons tidak memiliki informasi keaktualan yang eksplisit, biasanya — tetapi tidak selalu — dianggap tidak dapat di-cache

Bersama-sama, kesegaran dan validasi adalah cara terpenting cache bekerja dengan konten. Representasi baru akan tersedia secara instan dari cache, sementara representasi yang divalidasi akan menghindari pengiriman kembali seluruh representasi jika tidak berubah

Ada beberapa alat yang dapat digunakan oleh desainer Web dan Webmaster untuk menyempurnakan cara cache memperlakukan situs mereka. Mungkin Anda perlu sedikit mengotori konfigurasi server Anda, tetapi hasilnya sepadan. Untuk detail tentang cara menggunakan alat ini dengan server Anda, lihat bagian di bawah ini

Penulis HTML dapat menempatkan tag di bagian dokumen yang menjelaskan atributnya. Tag meta ini sering digunakan dengan keyakinan bahwa mereka dapat menandai dokumen sebagai tidak dapat di-cache, atau kedaluwarsa pada waktu tertentu

Tag meta mudah digunakan, tetapi tidak terlalu efektif. Itu karena mereka hanya dihormati oleh beberapa cache browser, bukan cache proxy (yang hampir tidak pernah membaca HTML di dokumen). Meskipun mungkin tergoda untuk memasang Pragma. tag meta tanpa cache ke halaman Web, itu tidak serta merta membuatnya tetap segar

Jika situs Anda dihosting di ISP atau peternakan hosting dan mereka tidak memberi Anda kemampuan untuk menyetel header HTTP arbitrer (seperti

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 dan
Expires: Fri, 30 Oct 1998 14:19:41 GMT
6), komplain dengan keras;

Di sisi lain, header HTTP yang sebenarnya memberi Anda banyak kendali atas cara cache browser dan proxy menangani representasi Anda. Mereka tidak dapat dilihat di HTML, dan biasanya dihasilkan secara otomatis oleh server Web. Namun, Anda dapat mengontrolnya sampai batas tertentu, tergantung pada server yang Anda gunakan. Di bagian berikut, Anda akan melihat header HTTP mana yang menarik, dan cara menerapkannya ke situs Anda

Header HTTP dikirim oleh server sebelum HTML, dan hanya dilihat oleh browser dan semua cache perantara. HTTP biasa 1. 1 tajuk respons mungkin terlihat seperti ini

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html
_

HTML akan mengikuti tajuk ini, dipisahkan oleh baris kosong. Lihat bagian untuk informasi tentang cara menyetel tajuk HTTP

Banyak orang percaya bahwa menetapkan header HTTP

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_7 ke representasi akan membuatnya tidak dapat di-cache. Ini belum tentu benar; . Meskipun beberapa cache dapat menghargai header ini, sebagian besar tidak, dan tidak akan berpengaruh apa pun. Gunakan tajuk di bawah sebagai gantinya

Header HTTP

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 adalah cara dasar untuk mengontrol cache; . Setelah itu, cache akan selalu memeriksa kembali dengan server asal untuk melihat apakah dokumen diubah.
Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 header didukung oleh hampir semua cache

Sebagian besar server Web memungkinkan Anda menyetel

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_5 header respons dalam beberapa cara. Umumnya, mereka akan mengizinkan pengaturan waktu absolut untuk kedaluwarsa, waktu berdasarkan terakhir kali klien mengambil representasi (waktu akses terakhir), atau waktu berdasarkan terakhir kali dokumen diubah di server Anda (waktu modifikasi terakhir)

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 header sangat bagus untuk membuat gambar statis (seperti bilah navigasi dan tombol) dapat di-cache. Karena mereka tidak banyak berubah, Anda dapat menyetel waktu kedaluwarsa yang sangat lama, membuat situs Anda tampak jauh lebih responsif terhadap pengguna Anda. Mereka juga berguna untuk mengontrol caching halaman yang sering diubah. Misalnya, jika Anda memperbarui halaman berita sekali sehari pada pukul 6 pagi, Anda dapat menyetel perwakilan untuk kedaluwarsa pada waktu itu, sehingga cache akan mengetahui kapan harus mendapatkan salinan baru, tanpa pengguna harus menekan 'muat ulang'

Satu-satunya nilai yang valid dalam header

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 adalah tanggal HTTP; . Ingat juga bahwa waktu dalam tanggal HTTP adalah Greenwich Mean Time (GMT), bukan waktu setempat

Sebagai contoh

Expires: Fri, 30 Oct 1998 14:19:41 GMT

Penting untuk memastikan bahwa jam server Web Anda akurat jika Anda menggunakan header

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5. Salah satu cara untuk melakukannya adalah dengan menggunakan Network Time Protocol (NTP);

Meskipun tajuk

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 berguna, ia memiliki beberapa keterbatasan. Pertama, karena ada tanggal yang terlibat, jam di server Web dan cache harus disinkronkan;

Masalah lain dengan

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_5 adalah mudah lupa bahwa Anda telah menyetel beberapa konten untuk kedaluwarsa pada waktu tertentu. Jika Anda tidak memperbarui
Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 kali sebelum berlalu, setiap permintaan akan kembali ke server Web Anda, meningkatkan beban dan latensi

http1. 1 memperkenalkan kelas header baru,

Expires: Fri, 30 Oct 1998 14:19:41 GMT
6 header respons, untuk memberikan kontrol lebih besar kepada penayang Web atas konten mereka, dan untuk mengatasi batasan
Expires: Fri, 30 Oct 1998 14:19:41 GMT
5

Header respons

Expires: Fri, 30 Oct 1998 14:19:41 GMT
6 yang berguna disertakan

  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    0[detik] — menentukan jumlah maksimum waktu representasi akan dianggap segar. Mirip dengan
    Expires: Fri, 30 Oct 1998 14:19:41 GMT
    _5, direktif ini bersifat relatif terhadap waktu permintaan, bukan absolut. [detik] adalah jumlah detik dari waktu permintaan yang Anda inginkan representasinya segar
  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    2[detik] — mirip dengan
    GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    _3, kecuali bahwa itu hanya berlaku untuk bersama (e. g. , proksi) cache
  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    _4 — menandai respons yang diautentikasi sebagai dapat di-cache;
  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    _5 — memungkinkan cache yang khusus untuk satu pengguna (dan. g. , di browser) untuk menyimpan respons; . g. , dalam proxy) mungkin tidak
  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    6 — memaksa cache untuk mengirimkan permintaan ke server asal untuk validasi sebelum merilis salinan cache, setiap kali. Ini berguna untuk memastikan bahwa autentikasi dihormati (dikombinasikan dengan publik), atau untuk mempertahankan kesegaran yang kaku, tanpa mengorbankan semua manfaat caching
  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    _7 — menginstruksikan cache untuk tidak menyimpan salinan representasi dalam kondisi apa pun
  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    _8 — memberi tahu cache bahwa mereka harus mematuhi setiap informasi kesegaran yang Anda berikan tentang representasi. HTTP mengizinkan cache untuk melayani representasi basi dalam kondisi khusus;
  • GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    _9 — mirip dengan
    GET /foo.html HTTP/1.1 [return]
    Host: www.example.com [return][return]
    8, kecuali bahwa ini hanya berlaku untuk cache proxy

Sebagai contoh

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

Ketika

Expires: Fri, 30 Oct 1998 14:19:41 GMT
6 dan
Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 hadir,
Expires: Fri, 30 Oct 1998 14:19:41 GMT
6 diutamakan. Jika Anda berencana untuk menggunakan header
Expires: Fri, 30 Oct 1998 14:19:41 GMT
6, Anda harus melihat dokumentasi yang sangat baik di HTTP 1. satu;

Di , kami mengatakan bahwa validasi digunakan oleh server dan cache untuk berkomunikasi ketika representasi telah berubah. Dengan menggunakannya, cache menghindari keharusan mengunduh seluruh representasi ketika mereka sudah memiliki salinan secara lokal, tetapi mereka tidak yakin apakah masih segar

Validator sangat penting;

Validator yang paling umum adalah waktu perubahan terakhir dokumen, seperti yang dikomunikasikan dalam header

Expires: Fri, 30 Oct 1998 14:19:41 GMT
4. Ketika cache menyimpan representasi yang menyertakan header
Expires: Fri, 30 Oct 1998 14:19:41 GMT
4, cache dapat menggunakannya untuk menanyakan server apakah representasi telah berubah sejak terakhir kali dilihat, dengan permintaan
Cache-Control: public, no-cache
9

http1. 1 memperkenalkan jenis validator baru yang disebut ETag. ETag adalah pengidentifikasi unik yang dibuat oleh server dan diubah setiap kali representasi melakukannya. Karena server mengontrol bagaimana ETag dibuat, cache dapat memastikan bahwa jika ETag cocok dengan permintaan

### activate mod_expires
ExpiresActive On
### Expire .gif's 1 month from when they're accessed
ExpiresByType image/gif A2592000
### Expire everything else 1 day from when it's last modified
### (this uses the Alternative syntax)
ExpiresDefault "modification plus 1 day"
### Apply a Cache-Control header to index.html

Header append Cache-Control "public, must-revalidate"
0, representasinya benar-benar sama

Hampir semua cache menggunakan waktu Last-Modified sebagai validator;

Sebagian besar server Web modern akan menghasilkan header

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_3 dan
Expires: Fri, 30 Oct 1998 14:19:41 GMT
4 untuk digunakan sebagai validator untuk konten statis (i. e. , file) secara otomatis; . Namun, mereka tidak cukup tahu tentang konten dinamis (seperti CGI, ASP, atau situs database) untuk membuatnya;

Selain menggunakan informasi kebaruan dan validasi, ada beberapa hal lain yang dapat Anda lakukan untuk membuat situs Anda lebih ramah cache

  • Gunakan URL secara konsisten — ini adalah aturan emas caching. Jika Anda menayangkan konten yang sama di laman yang berbeda, ke pengguna yang berbeda, atau dari situs yang berbeda, itu harus menggunakan URL yang sama. Ini adalah cara termudah dan paling efektif untuk membuat situs Anda ramah-cache. Misalnya, jika Anda menggunakan “/index. html” di HTML Anda sebagai referensi sekali, selalu gunakan seperti itu
  • Gunakan perpustakaan umum gambar dan elemen lain dan rujuk kembali dari tempat yang berbeda
  • Jadikan cache menyimpan gambar dan halaman yang tidak sering berubah dengan menggunakan header
    ### activate mod_expires
    ExpiresActive On
    ### Expire .gif's 1 month from when they're accessed
    ExpiresByType image/gif A2592000
    ### Expire everything else 1 day from when it's last modified
    ### (this uses the Alternative syntax)
    ExpiresDefault "modification plus 1 day"
    ### Apply a Cache-Control header to index.html
    
    Header append Cache-Control "public, must-revalidate"
    
    3 dengan nilai besar
  • Jadikan cache mengenali halaman yang diperbarui secara berkala dengan menentukan usia maksimum atau waktu kedaluwarsa yang sesuai
  • Jika sumber daya (terutama file yang dapat diunduh) berubah, ubah namanya. Dengan begitu, Anda dapat membuatnya kedaluwarsa jauh di masa mendatang, dan tetap menjamin bahwa versi yang benar disajikan;
  • Jangan mengubah file yang tidak perlu. Jika Anda melakukannya, semuanya akan memiliki tanggal
    Expires: Fri, 30 Oct 1998 14:19:41 GMT
    4 palsu muda. Misalnya, saat memperbarui situs Anda, jangan menyalin seluruh situs;
  • Gunakan kuki hanya jika diperlukan — kuki sulit disimpan dalam cache, dan tidak diperlukan dalam sebagian besar situasi. Jika Anda harus menggunakan cookie, batasi penggunaannya pada halaman dinamis
  • Periksa halaman Anda dengan REDbot — ini dapat membantu Anda menerapkan banyak konsep dalam tutorial ini

Secara default, sebagian besar skrip tidak akan mengembalikan validator (header respons

Expires: Fri, 30 Oct 1998 14:19:41 GMT
4 atau
Expires: Fri, 30 Oct 1998 14:19:41 GMT
3) atau informasi kesegaran (
Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 atau
Expires: Fri, 30 Oct 1998 14:19:41 GMT
6). Sementara beberapa skrip benar-benar dinamis (artinya mereka mengembalikan respons yang berbeda untuk setiap permintaan), banyak (seperti mesin telusur dan situs berbasis basis data) dapat mengambil manfaat dari ramah-cache

Secara umum, jika sebuah skrip menghasilkan output yang dapat direproduksi dengan permintaan yang sama di lain waktu (baik beberapa menit atau beberapa hari kemudian), itu harus dapat di-cache. Jika konten skrip berubah hanya bergantung pada apa yang ada di URL, itu dapat di-cache;

  • Cara terbaik untuk membuat skrip ramah-cache (dan juga berkinerja lebih baik) adalah dengan membuang kontennya ke file biasa setiap kali itu berubah. Server Web kemudian dapat memperlakukannya seperti halaman Web lainnya, menghasilkan dan menggunakan validator, yang membuat hidup Anda lebih mudah. Ingatlah untuk hanya menulis file yang telah diubah, sehingga
    Expires: Fri, 30 Oct 1998 14:19:41 GMT
    4 kali dipertahankan
  • Cara lain untuk membuat skrip dapat di-cache secara terbatas adalah dengan menyetel tajuk terkait usia sejauh mungkin di masa mendatang. Meskipun hal ini dapat dilakukan dengan
    Expires: Fri, 30 Oct 1998 14:19:41 GMT
    _5, mungkin paling mudah melakukannya dengan
    ### activate mod_expires
    ExpiresActive On
    ### Expire .gif's 1 month from when they're accessed
    ExpiresByType image/gif A2592000
    ### Expire everything else 1 day from when it's last modified
    ### (this uses the Alternative syntax)
    ExpiresDefault "modification plus 1 day"
    ### Apply a Cache-Control header to index.html
    
    Header append Cache-Control "public, must-revalidate"
    
    3, yang akan membuat permintaan segar untuk beberapa waktu setelah permintaan
  • Jika Anda tidak dapat melakukannya, Anda harus membuat skrip menghasilkan validator, lalu menanggapi permintaan
    Cache-Control: public, no-cache
    _9 dan/atau
    ### activate mod_expires
    ExpiresActive On
    ### Expire .gif's 1 month from when they're accessed
    ExpiresByType image/gif A2592000
    ### Expire everything else 1 day from when it's last modified
    ### (this uses the Alternative syntax)
    ExpiresDefault "modification plus 1 day"
    ### Apply a Cache-Control header to index.html
    
    Header append Cache-Control "public, must-revalidate"
    
    0. Ini dapat dilakukan dengan mem-parsing header HTTP, lalu merespons dengan
    #!/usr/bin/perl
    print "Content-type: text/html\n";
    print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
    print "\n";
    ### the content body follows...
    4 bila perlu. Sayangnya, ini bukan tugas sepele

Beberapa tip lainnya;

  • Jangan gunakan POST kecuali itu sesuai. Tanggapan terhadap metode POST tidak disimpan oleh sebagian besar cache;
  • Jangan sematkan informasi khusus pengguna di URL kecuali jika konten yang dibuat benar-benar unik untuk pengguna tersebut
  • Jangan mengandalkan semua permintaan dari pengguna yang datang dari host yang sama, karena cache sering kali bekerja sama
  • Hasilkan
    #!/usr/bin/perl
    print "Content-type: text/html\n";
    print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
    print "\n";
    ### the content body follows...
    5 tajuk tanggapan. Ini mudah dilakukan, dan ini akan memungkinkan respons skrip Anda digunakan dalam koneksi tetap. Ini memungkinkan klien untuk meminta banyak representasi pada satu koneksi TCP/IP, alih-alih menyiapkan koneksi untuk setiap permintaan. Itu membuat situs Anda tampak jauh lebih cepat

Lihat untuk informasi yang lebih spesifik

Apa hal terpenting untuk membuat cacheable?

Strategi yang baik adalah mengidentifikasi representasi paling populer dan terbesar (terutama gambar) dan bekerja dengannya terlebih dahulu.

Bagaimana saya bisa membuat halaman saya secepat mungkin dengan cache?

Representasi yang paling dapat di-cache adalah representasi dengan waktu kesegaran yang lama. Validasi memang membantu mengurangi waktu yang diperlukan untuk melihat representasi, tetapi cache masih harus menghubungi server asal untuk melihat apakah masih segar. Jika cache sudah tahu itu segar, itu akan disajikan langsung

Saya mengerti bahwa caching itu bagus, tetapi saya perlu menyimpan statistik tentang berapa banyak orang yang mengunjungi halaman saya

Jika Anda harus tahu setiap kali halaman diakses, pilih SATU item kecil di halaman (atau halaman itu sendiri), dan buat agar tidak dapat di-cache, dengan memberinya header yang sesuai. Misalnya, Anda dapat merujuk ke gambar transparan 1x1 yang tidak dapat di-cache dari setiap halaman. Header

#!/usr/bin/perl
print "Content-type: text/html\n";
print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
print "\n";
### the content body follows...
6 akan berisi informasi tentang apa yang disebut halaman itu

Ketahuilah bahwa bahkan ini tidak akan memberikan statistik yang benar-benar akurat tentang pengguna Anda, dan tidak bersahabat dengan Internet dan pengguna Anda; . Untuk informasi lebih lanjut tentang ini, lihat Menafsirkan Statistik Akses di

Bagaimana saya bisa melihat header HTTP representasi?

Banyak browser Web membiarkan Anda melihat

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 dan
Expires: Fri, 30 Oct 1998 14:19:41 GMT
4 header berada di "info halaman" atau antarmuka serupa. Jika tersedia, ini akan memberi Anda menu halaman dan representasi apa pun (seperti gambar) yang terkait dengannya, beserta detailnya

Untuk melihat header lengkap representasi, Anda dapat menyambungkan ke server Web secara manual menggunakan klien Telnet

Untuk melakukannya, Anda mungkin perlu mengetikkan porta (secara default, 80) ke dalam kolom terpisah, atau Anda mungkin perlu menyambungkan ke

#!/usr/bin/perl
print "Content-type: text/html\n";
print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
print "\n";
### the content body follows...
9 atau
print "Cache-Control: max-age=600\n";
0 (perhatikan spasi). Lihat dokumentasi klien Telnet Anda

Setelah Anda membuka koneksi ke situs, ketikkan permintaan representasi. Misalnya, jika Anda ingin melihat header untuk

print "Cache-Control: max-age=600\n";
1, sambungkan ke
print "Cache-Control: max-age=600\n";
2, port
print "Cache-Control: max-age=600\n";
3, dan ketik

GET /foo.html HTTP/1.1 [return]
Host: www.example.com [return][return]

Tekan tombol Return setiap kali Anda melihat

print "Cache-Control: max-age=600\n";
4; . Ini akan mencetak header, dan kemudian representasi penuh. Untuk melihat header saja, gantikan HEAD dengan GET

Halaman saya dilindungi kata sandi;

Secara default, halaman yang dilindungi dengan autentikasi HTTP dianggap pribadi; . Namun, Anda dapat membuat halaman yang diautentikasi menjadi publik dengan Cache-Control. tajuk publik; . Cache yang sesuai dengan 1 kemudian akan memungkinkannya untuk di-cache

Jika Anda ingin halaman tersebut dapat di-cache, tetapi tetap diautentikasi untuk setiap pengguna, gabungkan header

print "Cache-Control: max-age=600\n";
_5 dan
GET /foo.html HTTP/1.1 [return]
Host: www.example.com [return][return]
6. Ini memberi tahu cache bahwa ia harus mengirimkan informasi autentikasi klien baru ke server asal sebelum melepaskan representasi dari cache. Ini akan terlihat seperti

Cache-Control: public, no-cache

Apakah ini dilakukan atau tidak, sebaiknya minimalkan penggunaan autentikasi; . Dengan begitu, gambar-gambar itu secara alami dapat di-cache

Haruskah saya mengkhawatirkan keamanan jika orang mengakses situs saya melalui cache?

print "Cache-Control: max-age=600\n";
_7 halaman tidak di-cache (atau didekripsi) oleh cache proxy, jadi Anda tidak perlu khawatir tentang itu. Namun, karena cache menyimpan
print "Cache-Control: max-age=600\n";
_8 respons dan URL yang diambil melaluinya, Anda harus mengetahui tentang situs yang tidak aman;

Faktanya, setiap administrator di jaringan antara server Anda dan klien Anda dapat mengumpulkan jenis informasi ini. Satu masalah khusus adalah ketika skrip CGI memasukkan nama pengguna dan kata sandi di URL itu sendiri;

Jika Anda mengetahui masalah seputar keamanan Web secara umum, Anda seharusnya tidak terkejut dengan cache proxy

Saya mencari solusi penerbitan Web terintegrasi. Mana yang sadar-cache?

Ini bervariasi. Secara umum, semakin kompleks solusinya, semakin sulit untuk di-cache. Yang terburuk adalah yang menghasilkan semua konten secara dinamis dan tidak menyediakan validator; . Bicaralah dengan staf teknis vendor Anda untuk informasi lebih lanjut, dan lihat Catatan Implementasi di bawah ini

Gambar saya kedaluwarsa sebulan dari sekarang, tetapi saya perlu mengubahnya di cache sekarang

Header Kedaluwarsa tidak dapat dielakkan;

Solusi paling efektif adalah mengubah tautan apa pun ke sana; . Ingatlah bahwa setiap halaman yang mengacu pada representasi ini juga akan di-cache. Karena itu, yang terbaik adalah membuat gambar statis dan representasi serupa sangat dapat di-cache, sekaligus menjaga agar halaman HTML yang merujuknya tetap ketat.

Jika Anda ingin memuat ulang representasi dari cache tertentu, Anda dapat memaksa memuat ulang (di Firefox, menahan shift sambil menekan 'muat ulang' akan melakukan ini dengan mengeluarkan header permintaan

Expires: Fri, 30 Oct 1998 14:19:41 GMT
7) saat menggunakan cache. Atau, Anda dapat meminta administrator cache menghapus representasi melalui antarmuka mereka

Saya menjalankan layanan Web Hosting. Bagaimana saya bisa membiarkan pengguna saya menerbitkan halaman ramah-cache?

Jika Anda menggunakan Apache, pertimbangkan untuk mengizinkan mereka menggunakannya. htaccess dan menyediakan dokumentasi yang sesuai

Jika tidak, Anda dapat menetapkan area yang telah ditentukan sebelumnya untuk berbagai atribut caching di setiap server virtual. Misalnya, Anda dapat menentukan direktori /cache-1m yang akan di-cache selama satu bulan setelah akses, dan area /no-cache yang akan disajikan dengan header yang menginstruksikan cache untuk tidak menyimpan representasi darinya

Apa pun yang dapat Anda lakukan, yang terbaik adalah bekerja dengan pelanggan terbesar Anda terlebih dahulu dalam melakukan caching. Sebagian besar penghematan (dalam bandwidth dan beban di server Anda) akan diwujudkan dari situs bervolume tinggi

Saya telah menandai halaman saya sebagai dapat di-cache, tetapi browser saya terus memintanya di setiap permintaan. Bagaimana cara memaksa cache untuk menyimpan representasinya?

Cache tidak diperlukan untuk menyimpan representasi dan menggunakannya kembali; . Semua cache membuat keputusan tentang representasi mana yang akan disimpan berdasarkan ukuran, jenisnya (mis. g. , gambar vs. html), atau berapa banyak ruang yang tersisa untuk menyimpan salinan lokal. Milik Anda mungkin tidak dianggap layak disimpan, dibandingkan dengan representasi yang lebih populer atau lebih besar.

Beberapa cache mengizinkan administrator mereka untuk memprioritaskan jenis representasi apa yang disimpan, dan beberapa memungkinkan representasi untuk "disematkan" dalam cache, sehingga selalu tersedia

Secara umum, yang terbaik adalah menggunakan versi terbaru dari server Web apa pun yang Anda pilih untuk digunakan. Tidak hanya akan berisi lebih banyak fitur ramah-cache, versi baru juga biasanya memiliki peningkatan keamanan dan kinerja yang penting

Server HTTP Apache

Apache menggunakan modul opsional untuk menyertakan header, termasuk Expires dan Cache-Control. Kedua modul tersedia di 1. distribusi 2 atau lebih

Modul perlu dibangun ke dalam Apache; . Untuk mengetahui apakah modul diaktifkan di server Anda, temukan biner httpd dan jalankan

0; . Modul yang kami cari adalah expired_module dan headers_module

  • Jika tidak tersedia, dan Anda memiliki akses administratif, Anda dapat mengkompilasi ulang Apache untuk menyertakannya. Ini dapat dilakukan dengan menghapus komentar pada baris yang sesuai di file Konfigurasi, atau menggunakan argumen
    2 dan 
    3 untuk mengonfigurasi (1. 3 atau lebih). Lihat file INSTALL yang ditemukan dengan distribusi Apache

Setelah Anda memiliki Apache dengan modul yang sesuai, Anda dapat menggunakan mod_expires untuk menentukan kapan representasi harus kedaluwarsa, baik di. htaccess atau di akses server. file conf. Anda dapat menentukan kedaluwarsa dari akses atau waktu modifikasi, dan menerapkannya ke jenis file atau sebagai default. Lihat dokumentasi modul untuk informasi lebih lanjut, dan bicarakan dengan guru Apache lokal Anda jika Anda mengalami masalah

Untuk menerapkan

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_6 header, Anda harus menggunakan modul mod_headers, yang memungkinkan Anda menentukan header HTTP arbitrer untuk sumber daya. Lihat dokumentasi mod_headers

Ini sebuah contoh. htaccess yang mendemonstrasikan penggunaan beberapa header

  • htaccess memungkinkan penerbit web untuk menggunakan perintah yang biasanya hanya ditemukan di file konfigurasi. Mereka memengaruhi konten direktori tempat mereka berada dan subdirektori mereka. Bicaralah dengan administrator server Anda untuk mengetahui apakah mereka diaktifkan
### activate mod_expires
ExpiresActive On
### Expire .gif's 1 month from when they're accessed
ExpiresByType image/gif A2592000
### Expire everything else 1 day from when it's last modified
### (this uses the Alternative syntax)
ExpiresDefault "modification plus 1 day"
### Apply a Cache-Control header to index.html

Header append Cache-Control "public, must-revalidate"
  • Perhatikan bahwa mod_expires secara otomatis menghitung dan menyisipkan
    5 header yang sesuai

Konfigurasi Apache 2 sangat mirip dengan 1. 3; . 2 dokumentasi mod_expires dan mod_headers untuk informasi lebih lanjut

microsoft IIS

Server Informasi Internet Microsoft membuatnya sangat mudah untuk mengatur header dengan cara yang agak fleksibel. Perhatikan bahwa ini hanya mungkin di server versi 4, yang hanya akan berjalan di Server NT

Untuk menentukan tajuk untuk area situs, pilih di antarmuka

6, dan tampilkan propertinya. Setelah memilih tab 
_7, Anda akan melihat dua area menarik; . Yang pertama harus cukup jelas, dan yang kedua dapat digunakan untuk menerapkan header Cache-Control

Lihat bagian ASP di bawah ini untuk informasi tentang pengaturan header di Active Server Pages. Dimungkinkan juga untuk mengatur header dari modul ISAPI;

Server Perusahaan Netscape/iPlanet

Mulai dari versi 3. 6, Enterprise Server tidak menyediakan cara yang jelas untuk mengatur header Kedaluwarsa. Namun, itu telah mendukung HTTP 1. 1 fitur sejak versi 3. 0. Ini berarti bahwa HTTP 1. 1 cache (proxy dan browser) akan dapat memanfaatkan pengaturan Cache-Control yang Anda buat

Untuk menggunakan header Cache-Control, pilih

0 di server administrasi. Kemudian, dengan menggunakan Resource Picker, pilih direktori tempat Anda ingin mengatur header. Setelah mengatur header, klik 'OK'. Untuk informasi lebih lanjut, lihat manual NES.

Satu hal yang perlu diingat adalah mungkin akan lebih mudah untuk menyetel tajuk HTTP dengan server Web Anda daripada dengan bahasa scripting. coba keduanya

Karena penekanan pada skrip sisi server adalah pada konten dinamis, itu tidak membuat halaman yang sangat dapat di-cache, bahkan ketika konten dapat di-cache. Jika konten Anda sering berubah, tetapi tidak pada setiap klik halaman, pertimbangkan untuk menyetel Cache-Control. tajuk usia maksimal; . Misalnya, saat pengguna menekan tombol 'kembali', jika tidak ada informasi validator atau pembaruan yang tersedia, mereka harus menunggu hingga halaman diunduh ulang dari server untuk melihatnya.

CGI

Skrip CGI adalah salah satu cara paling populer untuk menghasilkan konten. Anda dapat dengan mudah menambahkan tajuk respons HTTP dengan menambahkannya sebelum mengirim badan; . Misalnya, di Perl;

#!/usr/bin/perl
print "Content-type: text/html\n";
print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n";
print "\n";
### the content body follows...

Karena semuanya berupa teks, Anda dapat dengan mudah membuat

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_5 dan header terkait tanggal lainnya dengan fungsi bawaan. Akan lebih mudah jika Anda menggunakan
### activate mod_expires
ExpiresActive On
### Expire .gif's 1 month from when they're accessed
ExpiresByType image/gif A2592000
### Expire everything else 1 day from when it's last modified
### (this uses the Alternative syntax)
ExpiresDefault "modification plus 1 day"
### Apply a Cache-Control header to index.html

Header append Cache-Control "public, must-revalidate"
3;

print "Cache-Control: max-age=600\n";

Ini akan membuat skrip dapat di-cache selama 10 menit setelah permintaan, sehingga jika pengguna menekan tombol 'kembali', mereka tidak akan mengirim ulang permintaan

Spesifikasi CGI juga membuat header permintaan yang dikirimkan klien tersedia di lingkungan skrip; . Jadi, jika klien membuat permintaan

Cache-Control: public, no-cache
_9, itu akan muncul sebagai
5

Sisi Server Termasuk

SSI (sering digunakan dengan ekstensi. shtml) adalah salah satu cara pertama penerbit Web dapat memasukkan konten dinamis ke dalam halaman. Dengan menggunakan tag khusus pada halaman, bentuk skrip dalam-HTML terbatas tersedia

Sebagian besar implementasi SSI tidak menetapkan validator, dan karena itu tidak dapat di-cache. Namun, implementasi Apache mengizinkan pengguna untuk menentukan file SSI mana yang dapat di-cache, dengan mengatur izin eksekusi grup pada file yang sesuai, digabungkan dengan direktif

6. Untuk informasi lebih lanjut, lihat dokumentasi mod_include

PHP

PHP adalah bahasa skrip sisi server yang, ketika dibangun ke dalam server, dapat digunakan untuk menyematkan skrip di dalam HTML halaman, seperti SSI, tetapi dengan jumlah opsi yang jauh lebih besar. PHP dapat digunakan sebagai skrip CGI di server Web apa pun (Unix atau Windows), atau sebagai modul Apache

Secara default, representasi yang diproses oleh PHP tidak ditetapkan sebagai validator, dan karenanya tidak dapat di-cache. Namun, pengembang dapat menyetel tajuk HTTP dengan menggunakan fungsi

7

Misalnya, ini akan membuat header Cache-Control, serta header Expires tiga hari ke depan

Ingatlah bahwa fungsi

_7 HARUS muncul sebelum output lainnya

Seperti yang Anda lihat, Anda harus membuat tanggal HTTP untuk header

Expires: Fri, 30 Oct 1998 14:19:41 GMT
5 secara manual; . Tentu saja, mudah untuk menetapkan
Expires: Fri, 30 Oct 1998 14:19:41 GMT
00, yang sama baiknya untuk sebagian besar situasi

Untuk informasi lebih lanjut, lihat entri manual untuk header

fusi dingin

Cold Fusion, oleh Macromedia adalah mesin skrip sisi server komersial, dengan dukungan untuk beberapa server Web di Windows, Linux, dan beberapa varian Unix

Cold Fusion membuat pengaturan header HTTP arbitrer menjadi relatif mudah, dengan tag

Expires: Fri, 30 Oct 1998 14:19:41 GMT
01. Sayangnya, contoh mereka untuk menyetel tajuk _
Expires: Fri, 30 Oct 1998 14:19:41 GMT
5, seperti di bawah ini, agak menyesatkan

Ini tidak berfungsi seperti yang Anda pikirkan, karena waktu (dalam hal ini, ketika permintaan dibuat) tidak dapat dikonversi ke tanggal yang valid HTTP; . Sebagian besar klien akan mengabaikan nilai tersebut, atau mengubahnya menjadi default, seperti 1 Januari 1970

Namun, Cold Fusion memang menyediakan fungsi pemformatan tanggal yang akan melakukan pekerjaan itu; . Dikombinasikan dengan

Expires: Fri, 30 Oct 1998 14:19:41 GMT
04, mudah untuk mengatur tanggal Kedaluwarsa;

Anda juga dapat menggunakan tag

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_05 untuk mengatur
### activate mod_expires
ExpiresActive On
### Expire .gif's 1 month from when they're accessed
ExpiresByType image/gif A2592000
### Expire everything else 1 day from when it's last modified
### (this uses the Alternative syntax)
ExpiresDefault "modification plus 1 day"
### Apply a Cache-Control header to index.html

Header append Cache-Control "public, must-revalidate"
3 dan header lainnya

Ingatlah bahwa header server Web dilewatkan dalam beberapa penerapan Cold Fusion (seperti CGI);

ASP dan ASP. bersih

Saat menyetel header HTTP dari ASP, pastikan Anda menempatkan panggilan metode Respons sebelum pembuatan HTML apa pun, atau gunakan

Expires: Fri, 30 Oct 1998 14:19:41 GMT
07 untuk menyangga output. Juga, perhatikan bahwa beberapa versi IIS menyetel header
Expires: Fri, 30 Oct 1998 14:19:41 GMT
08 pada ASP secara default, dan harus dinyatakan publik agar dapat di-cache oleh cache bersama

Halaman Server Aktif, dibangun ke dalam IIS dan juga tersedia untuk server Web lain, juga memungkinkan Anda menyetel header HTTP. Misalnya, untuk mengatur waktu kedaluwarsa, Anda dapat menggunakan properti dari objek

Expires: Fri, 30 Oct 1998 14:19:41 GMT
09;

Expires: Fri, 30 Oct 1998 14:19:41 GMT
0

menentukan jumlah menit dari permintaan untuk kedaluwarsa representasi.

Expires: Fri, 30 Oct 1998 14:19:41 GMT
6 header dapat ditambahkan seperti ini

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_1

Di ASP. NET,

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_11 sudah tidak digunakan lagi;

Expires: Fri, 30 Oct 1998 14:19:41 GMT
_2

HTTP 1. 1 spec memiliki banyak ekstensi untuk membuat halaman dapat di-cache, dan merupakan panduan otoritatif untuk mengimplementasikan protokol. Lihat bagian 13, 14. 9, 14. 21 dan 14. 25

Pengantar yang bagus untuk konsep caching, dengan tautan ke sumber online lainnya

Kata-kata kasar Jeff Goldberg yang informatif tentang mengapa Anda tidak boleh mengandalkan statistik akses dan penghitung hit

Memeriksa sumber daya HTTP untuk menentukan bagaimana mereka akan berinteraksi dengan cache Web, dan secara umum seberapa baik mereka menggunakan protokol

This document is Copyright © 1998-2013 Mark Nottingham . This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

Semua merek dagang di dalamnya adalah milik dari pemiliknya masing-masing

Meskipun penulis percaya bahwa isinya akurat pada saat publikasi, tidak ada tanggung jawab yang ditanggung untuk mereka, penerapannya atau konsekuensi apa pun darinya. Jika ditemukan kekeliruan, kesalahan, atau kebutuhan klarifikasi lainnya, harap segera hubungi penulis