Edge Security Acceleration:Aturan cache default

Kebijakan cache default

Konfigurasi cache hanya berlaku untuk permintaan klien yang dikirim ke komponen cache ESA. Untuk menentukan apakah permintaan klien dikirim ke komponen cache, ESA melakukan langkah-langkah berikut:

1. Memeriksa apakah permintaan bertipe GET atau HEAD.

2. Memeriksa apakah permintaan memenuhi kondisi yang ditentukan dalam aturan cache. Jika ya, aturan cache—bukan pengaturan cache global—yang berlaku. Untuk informasi selengkapnya, lihat Aturan cache untuk respons sukses dan pengalihan.

3. Memeriksa apakah ekstensi file tercantum dalam daftar ekstensi file default yang di-cache. Jika ya, pengaturan cache global berlaku untuk permintaan tersebut.

Aturan cache untuk respons sukses dan pengalihan

Kode status yang berlaku: 200, 203, 206, 300, 301, dan 410.

TTL cache edge memiliki empat opsi, masing-masing diterapkan berdasarkan logika berbeda:

• Honor Origin TTL or Use Default Cache Rule: Jika respons dari server origin berisi header Cache-Control, Expires, Last-Modified, dan ETag untuk menetapkan kebijakan cache, ESA menggunakan kebijakan cache server origin. Jika respons dari server origin tidak berisi salah satu header Cache-Control, Expires, Last-Modified, dan ETag, ESA menyimpan cache sumber daya berdasarkan kebijakan cache default ESA.

  Detail kebijakan cache

  Cache-Control dalam respons

  Header Cache-Control dalam respons origin menentukan salah satu kebijakan berikut:

  1. Jika header Cache-Control memiliki salah satu direktif berikut, sumber daya tidak di-cache:

     • no-cache

     • no-store

     • max-age=0

  2. Jika header Cache-Control berisi direktif max-age atau s-maxage dengan nilai lebih besar dari 0, seperti 3600, TTL yang ditentukan oleh direktif tersebut digunakan. Jika kedua direktif max-age dan s-maxage ada, nilai direktif s-maxage yang berlaku.

  Tidak ada Cache-Control dalam respons

  Jika respons origin tidak berisi header Cache-Control, kebijakan cache default ESA digunakan. Header dalam respons dari server origin memiliki urutan prioritas menurun sebagai berikut: Expires > Last-Modified > ETag.

  1. Jika respons origin berisi header Expires, seperti Expires:Tue, 25 Nov 2031 17:25:43 GMT, ESA menggunakan TTL yang ditetapkan dalam header Expires.

  2. Jika respons origin tidak berisi header Expires tetapi berisi header Last-Modified, TTL dihitung berdasarkan aturan berikut:

     • TTL = (Waktu saat ini - Nilai Last-Modified) × 0,1. Jika nilai hasilnya berkisar antara 10 detik hingga 3.600 detik, nilai aktual digunakan. Jika nilai hasilnya kurang dari 10 detik, TTL adalah 10 detik. Jika nilai hasilnya lebih dari 3.600 detik, TTL adalah 3.600 detik.

  3. Jika respons origin hanya berisi header ETag, TTL adalah 10 detik.

  4. Jika respons origin tidak berisi header Cache-Control, Expires, ETag, atau Last-Modified, sumber daya tidak di-cache.

• Honor Origin TTL or Do Not Cache: Jika respons dari server origin berisi header Cache-Control untuk menetapkan kebijakan cache, ESA menggunakan kebijakan cache server origin. Jika respons dari server origin tidak berisi header Cache-Control, ESA tidak menyimpan cache sumber daya.

  Detail kebijakan cache

  Menentukan kebijakan cache server origin

  Untuk menentukan kebijakan cache server origin, periksa apakah respons origin berisi header Cache-Control. Jika header tidak ada, sumber daya tidak di-cache. Jika header ada, salah satu kebijakan cache berikut berlaku:

  1. Jika header Cache-Control berisi direktif no-cache, no-store, atau max-age=0, sumber daya tidak di-cache.

  2. Jika header Cache-Control berisi direktif max-age atau s-maxage dengan nilai lebih besar dari 0, seperti 3600, TTL yang ditentukan oleh direktif tersebut digunakan. Jika kedua direktif max-age dan s-maxage ada, nilai direktif s-maxage yang berlaku.

• Do Not Cache: Semua sumber daya yang diambil dari server origin tidak di-cache pada POP ESA.

• Use Custom TTL: ESA mengabaikan header Cache-Control, Expires, Last-Modified, dan ETag dari kebijakan cache dalam respons origin dan menggunakan TTL yang ditetapkan pada ESA.

Aturan cache untuk respons dengan kode status error

• Untuk kode status 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503, dan 504, aturan cache adalah sebagai berikut:

  1. Jika server origin mengembalikan header respons set-cookie, respons tidak di-cache.

  2. Jika server origin tidak mengembalikan header respons set-cookie, sistem memeriksa apakah TTL untuk kode status tersebut telah dikonfigurasi di Konsol:

     1. Jika TTL dikonfigurasi, respons di-cache berdasarkan pengaturan di Konsol. Jika beberapa aturan ditetapkan, aturan dengan nomor ordinal terkecil yang berlaku.

     2. Jika TTL tidak dikonfigurasi, respons di-cache berdasarkan header respons Pragma, Cache-Control, atau Expires dari server origin.

  3. Jika server origin tidak mengembalikan header respons Pragma, Cache-Control, atau Expires, respons di-cache selama 1 detik secara default.

• Untuk kode status 302, 307, dan 403, aturan cache adalah sebagai berikut:

  1. Jika server origin mengembalikan header respons set-cookie, respons tidak di-cache.

  2. Jika server origin tidak mengembalikan header respons set-cookie, sistem memeriksa apakah TTL untuk kode status tersebut telah dikonfigurasi di Konsol:

     1. Jika TTL dikonfigurasi, respons di-cache berdasarkan pengaturan di Konsol. Jika beberapa aturan ditetapkan, aturan dengan nomor ordinal terkecil yang berlaku.

     2. Jika TTL tidak dikonfigurasi, respons di-cache berdasarkan header respons Pragma, Cache-Control, atau Expires dari server origin.

  3. Jika server origin tidak mengembalikan header respons Pragma, Cache-Control, atau Expires, respons tidak di-cache.

• Untuk kode status error lainnya, seperti 400, aturan cache adalah sebagai berikut:

  1. Jika server origin mengembalikan header respons set-cookie, respons tidak di-cache.

  2. Jika server origin tidak mengembalikan header respons set-cookie, sistem memeriksa apakah TTL untuk kode status tersebut telah dikonfigurasi di Konsol. Jika beberapa aturan ditetapkan, aturan dengan nomor ordinal terkecil yang berlaku.

  3. Dalam semua kasus lainnya, respons tidak di-cache.

• Untuk permintaan yang menggunakan range origin fetch, jika POP menerima respons dengan kode status selain 206 dari server origin, POP menghapus shard file yang di-cache. Timeout origin fetch tidak menyebabkan file cache dihapus.

  Saat menggunakan range origin fetch, server origin membagi file besar menjadi beberapa shard file yang lebih kecil dan mengirimkannya ke POP. Misalnya, sebuah file dibagi menjadi 10 shard dan POP telah menyimpan cache 5 shard tersebut. Ketika POP meminta shard ke-6 dan server origin mengembalikan kode status 5xx, POP menghapus semua 5 shard yang telah di-cache.

Informasi respons cache

POP ESA memberikan respons standar dan jelas yang memungkinkan Anda menyesuaikan permintaan HTTP secara dinamis. Header respons yang terkait dengan cache berisi informasi berikut:

• Ali-Swift-Global-Savetime: Waktu saat sumber daya pertama kali masuk ke POP ESA (ditentukan oleh arsitektur cache website, yang bisa berupa POP L2 atau POP pada tingkat cache lainnya).

  • Nilainya berupa stempel waktu UNIX. Contoh: 1745053111 menunjukkan 16:58:31 pada 19 April 2025.

• Date: Tanggal saat server origin mengembalikan sumber daya ke POP ESA.

  • Tanggal diperbarui ketika POP ESA menginisiasi permintaan origin yang berisi header If-Modified-Since atau If-None-Match untuk merevalidasi sumber daya dan server origin mengembalikan kode status HTTP 304.

  • Waktunya dalam format GMT. Contoh: Sat, 19 Apr 2025 08:58:31 GMT.

• X-Site-Cache-Status: Status cache sumber daya yang diminta pada POP ESA. Daftar berikut menjelaskan status sumber daya:

  • HIT: Sumber daya ditemukan dalam cache POP ESA.

  • MISS: Sumber daya tidak ditemukan dalam cache POP ESA. POP mengambil sumber daya dari server origin lalu mengembalikannya ke klien.

  • NONE/UNKNOWN: Sumber daya tidak memenuhi syarat untuk di-cache karena alasan berikut:

    • Fungsi edge menghasilkan respons tetapi tidak mengirim subpermintaan apa pun. Dalam hal ini, respons bukan berasal dari cache, dan status cache dicatat sebagai none/unknown.

    • Saat permintaan utama fungsi edge menginisiasi subpermintaan (fetch), status cache dicatat untuk subpermintaan tersebut, sedangkan status cache permintaan utama dicatat sebagai none/unknown. Hal ini terjadi karena modul fungsi edge berjalan sebelum modul cache, sehingga permintaan utama tidak melewati cache.

    • Permintaan klien yang diblokir oleh aturan WAF kustom tidak melewati cache karena WAF dijalankan sebelum modul cache, sehingga status cache dicatat sebagai none/unknown.

    • Permintaan klien mengenai Redirect rules atau HTTPS规则. POP kemudian mengirim respons pengalihan ke URL lain. Karena aturan ini berjalan sebelum modul cache, status cache dicatat sebagai none/unknown.

  • EXPIRED: Sumber daya ditemukan dalam cache POP ESA tetapi telah kedaluwarsa. POP mengambil sumber daya dari server origin lalu mengembalikannya ke klien. Kode status yang dikembalikan oleh server origin adalah 200 atau 206.

  • STALE:

    Sumber daya disajikan dari cache POP ESA tetapi telah kedaluwarsa. Hal ini terjadi dalam kasus berikut:

    • Pengaturan cache adalah Honor Origin TTL dan respons origin berisi Cache-Control:stale-while-revalidate=<seconds>. Dalam periode yang ditentukan, ESA menginisiasi permintaan ke server origin untuk merevalidasi sumber daya dan menyajikan cache yang kedaluwarsa ke klien.

    • Pengaturan cache adalah Honor Origin TTL dan respons origin berisi Cache-Control:stale-if-error=<seconds>. Dalam periode yang ditentukan, ESA menyajikan cache yang kedaluwarsa ke klien ketika ESA tidak dapat terhubung ke server origin untuk mengambil sumber daya terbaru.

    • Fitur Configure response cache expiration diaktifkan. Fitur ini memungkinkan POP ESA menyajikan cache yang kedaluwarsa ke klien ketika respons origin timeout atau server origin tidak dapat dijangkau.

  • BYPASS

    Permintaan ke sumber daya melewati cache ESA. Hal ini terjadi dalam kasus berikut:

    • Pengaturan cache bukan Honor Origin TTL dan ESA menetapkan TTL cache kustom menjadi 0 detik.

    • Pengaturan cache adalah Honor Origin TTL tetapi nilai header Cache-Control yang dikembalikan oleh server origin adalah no-store.

  • REVALIDATED

    Sumber daya disajikan oleh cache ESA, tetapi telah kedaluwarsa. ESA menginisiasi permintaan origin yang berisi header If-Modified-Since atau lf-None-Match ke server origin untuk merevalidasi sumber daya. Server origin mengembalikan kode status HTTP 304.

  • DYNAMIC

    ESA mendeteksi bahwa sumber daya merupakan konten dinamis dan tidak ada aturan cache yang ditentukan berlaku untuk permintaan tersebut. Dalam hal ini, ESA mengambil sumber daya dari server origin lalu mengembalikannya ke klien.

• X-Swift-Cachetime: Menentukan TTL sumber daya pada POP dalam satuan detik. Nilai X-Swift-Cachetime tidak sama dengan TTL yang ditetapkan di ESA. Nilai ini dihitung menggunakan rumus berikut: X-Swift-Cachetime = Ali-Swift-Global-Savetime + TTL yang ditetapkan di ESA - X-Swift-SaveTime. Skenario berikut mungkin terjadi:

  • Nilai X-Swift-Cachetime sama dengan TTL yang ditetapkan di ESA, misalnya 3600 detik.

  • Nilai X-Swift-Cachetime sedikit lebih kecil daripada TTL yang ditetapkan di ESA. Misalnya, jika TTL yang ditetapkan di ESA adalah 300 detik, nilai X-Swift-Cachetime mungkin 295 detik. Perbedaan ini dapat terjadi karena alasan berikut:

    • Latensi tinggi terjadi saat node L1 mengambil konten dari node L2.

    • Jam pada node L1 dan L2 tidak sinkron.

  • Nilai X-Swift-Cachetime negatif. Hal ini dapat terjadi jika Anda mengubah pengaturan TTL di ESA setelah sumber daya di-cache. Ini terjadi ketika permintaan klien tiba setelah cache node L1 kedaluwarsa, tetapi cache node L2 masih valid. Misalnya, TTL awalnya ditetapkan menjadi 3600 detik di ESA dan kemudian diubah menjadi 300 detik. Jika klien mengirim permintaan 600 detik setelah sumber daya di-cache, respons mencakup X-Swift-Cachetime:-300. Untuk mengatasi masalah ini, Anda dapat merefresh cache.

• X-Swift-Cachetime:

  TTL cache sumber daya pada POP ESA. Satuan: detik.

• X-Swift-SaveTime:

  • Waktu saat sumber daya pertama kali masuk ke POP saat ini (POP L1) yang menerima permintaan klien.

  • Waktunya dalam format GMT. Contoh: Sat, 19 Apr 2025 08:58:31 GMT.

Kebijakan Do Not Cache

POP ESA tidak menyimpan cache file dan meneruskan semua permintaan file dalam kondisi berikut:

• Edge Cache TTL pada halaman Settings ESA diatur ke Honor Origin TTL or Do Not Cache dan respons origin adalah Cache-Control: no-store.

• [CONREF:app_site_cache_configuration_node_expiration_title] pada halaman Settings ESA diatur ke Do Not Cache.

• [CONREF:app_site_cache_configuration_node_expiration_title] pada halaman Settings ESA diatur ke Use Custom TTL dan TTL cache diatur menjadi 0 detik.

Revalidasi cache

Setelah file yang di-cache pada POP ESA kedaluwarsa, mekanisme revalidasi cache mulai berlaku saat klien meminta file tersebut untuk pertama kalinya setelah kedaluwarsa. POP ESA mengirim permintaan validasi ke server origin. Jika file belum berubah, server origin mengembalikan pesan 304 not-modified, dan POP ESA terus menyajikan file yang di-cache kepada klien tanpa perlu mengunduh file tersebut lagi. Hal ini secara efektif meningkatkan kecepatan respons permintaan klien dan mengurangi trafik respons dari server origin.

• Konfigurasi kebijakan khusus: File di-cache selama 0 detik, dan POP ESA mengarahkan setiap permintaan ke server origin untuk validasi.

  • Edge Cache TTL pada halaman Settings ESA diatur ke Honor Origin TTL or Use Default Cache Rule, dan respons origin memenuhi kondisi berikut:

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• Konfigurasi kebijakan reguler: Server origin merespons kebijakan terkait validasi cache, dan POP ESA menjalankan kebijakan aktual tersebut.

  • Edge Cache TTL pada halaman Settings ESA diatur ke Honor Origin TTL or Use Default Cache Rule, dan respons origin memenuhi salah satu kebijakan validasi cache berikut:

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• Kebijakan validasi cache

  Daftar berikut menjelaskan kebijakan validasi cache dan memberikan contoh terkait:

  • must-revalidate

    • Deskripsi: Kebijakan ini menunjukkan bahwa jika sumber daya telah kedaluwarsa, sumber daya tersebut harus dikembalikan ke server origin untuk memvalidasi kesegarannya untuk cache apa pun (termasuk cache proxy dan cache browser) sebelum cache mengembalikan respons. Bahkan jika pengguna offline atau jaringan tidak tersedia, cache tidak dapat langsung menggunakan sumber daya yang kedaluwarsa kecuali sumber daya tersebut telah divalidasi tidak berubah.

    • Contoh: Cache-Control: max-age=3600, must-revalidate menunjukkan bahwa sumber daya harus dikembalikan ke server origin untuk memvalidasi kesegarannya setelah sumber daya kedaluwarsa.

  • proxy-revalidate

    • Deskripsi: Mirip dengan kebijakan must-revalidate, kebijakan ini hanya berlaku untuk cache bersama, seperti cache CDN dan server proxy. Kebijakan ini tidak berlaku untuk cache pribadi seperti cache browser. Jika sumber daya telah kedaluwarsa, sumber daya tersebut harus dikembalikan ke server origin untuk validasi sebelum cache bersama menyediakan replika cache. Cache pribadi tidak tunduk pada batasan ini.

    • Contoh: Cache-Control: max-age=3600, proxy-revalidate menunjukkan bahwa sumber daya harus dikembalikan ke server origin untuk memvalidasi kesegarannya setelah sumber daya kedaluwarsa.

  • stale-while-revalidate=seconds

    • Deskripsi: Kebijakan ini menunjukkan bahwa cache dapat terus menyediakan sumber daya cache lama selama periode tertentu (dalam detik) setelah sumber daya kedaluwarsa. Secara bersamaan, POP secara asinkron meminta konten terbaru dari server origin di latar belakang. Kebijakan ini berlaku ketika Anda ingin mengurangi waktu tunggu dan dapat menerima konten yang mungkin tidak paling mutakhir dalam periode waktu singkat.

    • Contoh: Cache-Control: max-age=3600, stale-while-revalidate=60 menunjukkan bahwa sumber daya dianggap segar selama 3.600 detik (1 jam) setelah pertama kali diterbitkan. Setelah kedaluwarsa, sumber daya tersebut masih dapat disediakan untuk pengguna selama 60 detik berikutnya. Secara bersamaan, POP mencoba mendapatkan pembaruan dari server origin.

  • stale-if-error=seconds

    • Deskripsi: Kebijakan ini menunjukkan bahwa ketika POP gagal mengambil konten terbaru dari server origin karena alasan seperti kerusakan server atau kesalahan jaringan, kebijakan ini memungkinkan POP mengembalikan respons yang menunjukkan bahwa sumber daya telah kedaluwarsa tetapi masih di-cache. Periode waktu (dalam detik) ditentukan, selama itu jika terjadi kesalahan, konten cache yang kedaluwarsa dapat digunakan. Hal ini meningkatkan kemampuan toleransi kesalahan sistem dan memastikan Anda dapat mengakses konten yang sebelumnya di-cache meskipun server origin tidak tersedia, sehingga meningkatkan pengalaman pengguna dan mengurangi dampak gangguan layanan.

    • Contoh: Cache-Control: max-age=86400, stale-if-error=604800 menunjukkan bahwa sumber daya dianggap segar selama 86.400 detik (24 jam) setelah pertama kali diterbitkan. Jika revalidasi setelah 86.400 detik gagal, sumber daya yang terakhir berhasil di-cache masih dapat disediakan selama 604.800 detik berikutnya (satu minggu).