Edge Security Acceleration:Aturan cache default

Kebijakan cache default

Konfigurasi cache hanya berlaku untuk permintaan yang diarahkan ke komponen cache ESA. ESA menggunakan langkah-langkah berikut untuk menentukan apakah suatu permintaan masuk ke cache:

1. Periksa apakah permintaan bertipe GET atau HEAD.

2. Periksa apakah permintaan memenuhi kondisi yang ditentukan dalam aturan cache. Jika permintaan memenuhi kondisi tersebut, aturan cache—bukan pengaturan cache global—yang berlaku untuk permintaan tersebut. Untuk informasi lebih lanjut, lihat Aturan cache untuk respons sukses dan pengalihan.

3. Periksa apakah ekstensi file tercantum dalam daftar ekstensi file cache default. Jika iya, 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:

• Honor Origin TTL or Use Default Cache Rule: Jika respons yang dikembalikan dari origin server berisi header Cache-Control, Expires, Last-Modified, dan ETag untuk menetapkan kebijakan cache, ESA menggunakan kebijakan cache dari origin server. Jika respons yang dikembalikan dari origin server tidak berisi salah satu header Cache-Control, Expires, Last-Modified, dan ETag, ESA menyimpan cache resource 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, resource tidak disimpan dalam 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 dari direktif s-maxage yang berlaku.

  Tidak ada Cache-Control dalam respons

  Jika respons origin tidak berisi header Cache-Control, kebijakan cache default ESA digunakan. Prioritas header (tertinggi ke terendah): 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, resource tidak disimpan dalam cache.

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

  Detail kebijakan cache

  Menentukan kebijakan cache origin server

  Periksa apakah respons origin berisi header Cache-Control. Jika tidak ada, resource tidak disimpan dalam cache. Jika ada, salah satu kebijakan berikut berlaku:

  1. Jika header Cache-Control berisi direktif no-cache, no-store, atau max-age=0, resource tidak disimpan dalam 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 dari direktif s-maxage yang berlaku.

• Do Not Cache: Semua resource yang diambil dari origin server tidak disimpan dalam cache di 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 origin server mengembalikan header respons set-cookie, respons tidak disimpan dalam cache.

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

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

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

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

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

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

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

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

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

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

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

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

  2. Jika origin server 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 disimpan dalam cache.

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

  Saat menggunakan range origin fetch, origin server 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 origin server mengembalikan kode status 5xx, POP akan menghapus semua 5 shard yang telah disimpan dalam cache.

Informasi respons cache

POP ESA mengembalikan header respons terkait cache dengan informasi berikut:

• Ali-Swift-Global-Savetime: Waktu saat resource 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 origin server mengembalikan resource ke POP ESA.

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

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

• X-Site-Cache-Status: Status cache resource yang diminta di POP ESA. Daftar berikut menjelaskan status resource:

  • HIT: Resource ditemukan dalam cache POP ESA.

  • MISS: Resource tidak ditemukan dalam cache POP ESA. POP mengambil resource dari origin server lalu mengembalikannya ke klien.

  • NONE/UNKNOWN: Resource tidak memenuhi syarat untuk disimpan dalam cache karena alasan berikut:

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

    • Saat permintaan utama fungsi edge menginisiasi subrequest (fetch), status cache dicatat untuk subrequest 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 berjalan sebelum modul cache, sehingga status cache dicatat sebagai none/unknown.

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

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

  • STALE:

    Resource 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 waktu yang ditentukan, ESA menginisiasi permintaan ke origin server untuk merevalidasi resource dan menyajikan cache yang kedaluwarsa ke klien.

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

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

  • BYPASS

    Permintaan ke resource 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 origin server adalah no-store.

  • REVALIDATED

    Resource disajikan oleh cache ESA, tetapi telah kedaluwarsa. ESA menginisiasi permintaan origin yang berisi header If-Modified-Since atau If-None-Match ke origin server untuk merevalidasi resource. Origin server mengembalikan kode status HTTP 304.

  • DYNAMIC

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

• X-Swift-Cachetime: Menentukan TTL resource di 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 resource disimpan dalam 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 resource disimpan dalam cache, respons mencakup X-Swift-Cachetime:-300. Untuk mengatasi masalah ini, Anda dapat merefresh cache.

• X-Swift-Cachetime:

  TTL cache resource di POP ESA. Satuan: detik.

• X-Swift-SaveTime:

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

  • Waktu 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.

• Edge Cache TTL pada halaman Settings ESA diatur ke Do Not Cache.

• Edge Cache TTL pada halaman Settings ESA diatur ke Use Custom TTL dan TTL cache diatur menjadi 0 detik.

Revalidasi cache

Setelah file yang disimpan dalam cache di POP ESA kedaluwarsa, POP ESA mengirim permintaan validasi ke origin server pada permintaan klien berikutnya. Jika file belum berubah, origin server mengembalikan 304 not-modified, dan POP ESA menyajikan file yang tersimpan dalam cache tanpa mengunduh ulang. Hal ini mengurangi lalu lintas origin dan meningkatkan kecepatan respons.

• Konfigurasi kebijakan khusus: File disimpan dalam cache selama 0 detik, dan POP ESA mengarahkan setiap permintaan ke origin server 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: Origin server merespons kebijakan terkait validasi cache, dan POP ESA menjalankan kebijakan aktual.

  • 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

  Kebijakan validasi cache:

  • must-revalidate

    • Deskripsi: Setelah kedaluwarsa, cache apa pun (proxy atau browser) harus merevalidasi resource dengan origin server sebelum menyajikannya. Cache tidak boleh menyajikan konten kedaluwarsa meskipun jaringan tidak tersedia, kecuali resource telah divalidasi tidak berubah.

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

  • proxy-revalidate

    • Deskripsi: Mirip dengan must-revalidate, tetapi hanya berlaku untuk cache bersama (CDN, server proxy). Cache pribadi seperti browser tidak terikat oleh batasan ini.

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

  • stale-while-revalidate=seconds

    • Deskripsi: Setelah kedaluwarsa, cache menyajikan konten kedaluwarsa selama durasi yang ditentukan sambil secara asinkron merevalidasi dengan origin di latar belakang. Gunakan ini ketika pengurangan latensi lebih penting daripada menyajikan konten kedaluwarsa untuk waktu singkat.

    • Contoh: Cache-Control: max-age=3600, stale-while-revalidate=60 menunjukkan bahwa resource dianggap segar selama 3.600 detik (1 jam) setelah pertama kali diterbitkan. Setelah kedaluwarsa, resource masih dapat disediakan untuk pengguna selama 60 detik berikutnya. Pada saat yang sama, POP berusaha mendapatkan pembaruan dari origin server.

  • stale-if-error=seconds

    • Deskripsi: Saat origin tidak dapat dijangkau (server rusak, error jaringan), POP menyajikan konten cache yang kedaluwarsa selama durasi yang ditentukan. Hal ini meningkatkan toleransi kesalahan dan menjaga ketersediaan selama gangguan origin.

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