CDN：FAQ tentang cache

• Apa mekanisme purge cache CDN/DCDN?

• Apa aturan cache default CDN/DCDN?

• Bagaimana cara menentukan apakah sebuah resource di-cache pada POP CDN/DCDN?

• Bagaimana cara mengatasi rasio hit cache CDN/DCDN yang rendah akibat parameter variabel dalam URL?

• Bagaimana cara mengonfigurasi file agar diambil langsung dari origin server alih-alih di-cache?

• Mengapa konten tidak terbaru meskipun TTL cache diatur ke 0 di konsol CDN/DCDN?

• Apakah cache pada POP CDN/DCDN diperbarui secara otomatis dan real-time setelah file diperbarui di origin server?

• Faktor apa saja yang dapat menurunkan rasio hit cache CDN/DCDN?

• Bagaimana cara mendiagnosis rasio hit cache yang rendah?

• Bagaimana cara meningkatkan rasio hit cache CDN?

• Bagaimana cara mengonfigurasi pengaturan cache global?

• Atur kebijakan cache HTTP Nginx

• Atur kebijakan cache Apache

• Atur kebijakan cache IIS

• Bagaimana cara mengatur TTL cache sisi server saat menggunakan CDN untuk mempercepat resource statis?

• Mengapa konten yang disajikan oleh CDN berbeda dengan konten di origin server?

• Mengapa konfigurasi cache saya tidak berlaku?

• Konfigurasi Berbagi Sumber Daya Lintas Asal (CORS) untuk CDN

• Mengapa saya tetap menerima error lintas asal dan header respons yang dikonfigurasi tidak muncul setelah mengatur header respons Access-Control-Allow-Origin?

• Apa aturan cache untuk kode status abnormal?

• Apa perbedaan antara header respons keluar dan masuk?

• Bagaimana cara mengonfigurasi seluruh nama domain agar tidak di-cache?

• Apakah CDN mendukung caching multi-replika?

Apa mekanisme pembersihan cache?

Jika sebuah resource yang di-cache pada POP CDN tidak populer—artinya jarang diakses oleh klien pada POP CDN yang sama—resource tersebut kemungkinan besar akan ditimpa oleh resource yang lebih populer pada POP CDN sebelum masa cache-nya berakhir.

Apa aturan cache default?

Saat POP CDN menerima file dari origin server, aturan caching diterapkan berdasarkan prioritas berikut. Angka yang lebih kecil menunjukkan prioritas yang lebih tinggi.

1. Jika origin server merespons dengan pragma:no-cache, cache-control:no-cache (atau no-store, atau max-age=0), CDN mengikuti kebijakan origin server dan tidak menyimpan resource tersebut di cache.

2. TTL cache atau TTL kode status yang dikonfigurasi di konsol CDN.

   Catatan

   Jika suatu permintaan sesuai dengan beberapa aturan, hanya satu aturan yang berlaku. Prioritas ditentukan terlebih dahulu berdasarkan bobot, lalu berdasarkan waktu pembuatan.

   • Jika Anda memiliki beberapa aturan cache, atur bobot yang berbeda untuk setiap aturan guna mengontrol prioritas eksekusinya. Bobot yang lebih tinggi menunjukkan prioritas yang lebih tinggi.

   • Untuk aturan dengan bobot yang sama, aturan yang dibuat lebih awal memiliki prioritas lebih tinggi, terlepas dari jenis aturannya.

3. Aturan cache lain yang dikonfigurasi di origin server. Prioritas dari tinggi ke rendah adalah: cache-control > expires > last-modified > ETag.

   1. Jika respons origin berisi header cache-control, nilainya mencakup max-age atau s-maxage, dan nilai max-age atau s-maxage lebih besar dari 0, header cache-control menentukan waktu kedaluwarsa cache. Contoh: cache-control: max-age=3600. Jika max-age dan s-maxage keduanya ada, s-maxage yang berlaku.

   2. Jika respons origin tidak menyertakan cache-control tetapi menyertakan header Expires, TTL cache ditentukan oleh header Expires. Contoh: expires:Tue, 25 Nov 2031 17:25:43 GMT.

   3. Jika respons origin tidak menyertakan cache-control atau Expires tetapi menyertakan last-modified, durasi cache dihitung menggunakan rumus: (waktu saat ini – last-modified) × 0,1. Durasi dibatasi antara 10 detik hingga 3.600 detik. Jika nilai yang dihitung kurang dari 10 detik, durasi cache menjadi 10 detik. Jika nilainya lebih dari 3.600 detik, durasi cache menjadi 3.600 detik.

   4. Jika respons origin tidak menyertakan cache-control, Expires, atau last-modified tetapi menyertakan ETag, resource tersebut di-cache selama 10 detik.

4. Jika respons dari origin server tidak menyertakan header terkait cache apa pun (cache-control, expires, last-modified, atau ETag), resource tersebut tidak di-cache secara default.

Bagaimana cara mengetahui apakah sebuah resource di-cache?

Anda dapat memeriksa header respons HTTP untuk menentukan apakah CDN menyimpan file di cache.

1. X-Cache: Menunjukkan apakah permintaan mengenai cache CDN. Nilai HIT menunjukkan cache hit. Nilai MISS atau header yang tidak ada menunjukkan cache miss.

2. Age: Waktu dalam detik sejak file di-cache pada POP CDN. Header ini tidak ada untuk file yang telah dipurge atau permintaan pertama kali. Nilai Age sebesar 0 menunjukkan bahwa cache telah kedaluwarsa dan perlu divalidasi ulang dengan origin server.

3. X-Swift-CacheTime: Durasi cache yang dikonfigurasi pada POP CDN. Anda dapat menghitung sisa waktu cache menggunakan rumus: X-Swift-CacheTime – Age.

4. X-Swift-SaveTime: Waktu dalam GMT ketika resource pertama kali di-cache pada POP CDN. Untuk mengonversi ke UTC+8, tambahkan 8 jam.

Untuk melihat header respons HTTP ini, Anda dapat menggunakan salah satu metode berikut untuk memeriksa apakah konten Anda di-cache pada CDN:

curl "http://example.com/path/to/response.html" -v

Bagaimana cara mengatasi masalah rasio hit cache rendah akibat parameter variabel dalam URL?

Hal ini mungkin terjadi karena fitur Ignore Parameters belum diaktifkan. Untuk informasi selengkapnya, lihat Rasio hit cache rendah akibat parameter variabel dalam URL.

Bagaimana cara mengonfigurasi file agar diambil langsung dari origin server alih-alih di-cache?

Untuk mencegah resource tertentu di-cache, Anda dapat mengatur TTL cache-nya ke 0 berdasarkan direktori, path file, atau tipe file.

• Type: Pilih Directory atau File Extension.

• Object: Masukkan path direktori atau ekstensi file yang tidak ingin Anda cache, seperti file dinamis dengan ekstensi .php, .jsp, atau .asp, atau semua file dalam direktori /admin.

• Expire In: Atur nilainya ke 0. Ini menentukan bahwa resource jenis ini tidak di-cache.

• Weight: Sesuaikan nilai bobot sesuai kebutuhan. Bobot yang lebih tinggi menunjukkan prioritas yang lebih tinggi.

Untuk informasi selengkapnya, lihat Konfigurasi waktu kedaluwarsa cache CDN.

Mengapa konten tidak terbaru meskipun TTL cache diatur ke 0 di konsol CDN?

Mengatur TTL cache ke 0 di konsol CDN memastikan setiap permintaan diarahkan ke origin server untuk mengambil konten terbaru. Namun, jika Anda menemukan bahwa resource yang diakses masih bukan versi terbaru, penyebabnya mungkin salah satu dari berikut:

1. Cache browser: Browser mungkin telah menyimpan konten lama di cache. Anda dapat menghapus cache browser atau menggunakan jendela penjelajahan pribadi untuk menguji.

2. Waktu tunda propagasi konfigurasi: Setelah Anda mengatur TTL cache ke 0, konfigurasi tersebut mungkin memerlukan waktu untuk tersebar ke semua POP CDN. Jika POP CDN belum menerima konfigurasi yang diperbarui, konten lama mungkin tetap disajikan.

3. Cache origin server: Origin server mungkin memiliki mekanisme caching sendiri. Jika cache di origin server belum diperbarui, POP CDN mungkin mengambil konten lama saat melakukan origin fetch.

4. Penundaan pembersihan cache POP: Sumber daya yang di-cache sebelum perubahan konfigurasi mungkin memerlukan waktu untuk dibersihkan. Anda dapat membersihkan cache secara manual guna segera mengambil konten terbaru. Untuk informasi selengkapnya, lihat Panduan Pengguna.

Apakah cache pada POP diperbarui secara otomatis dan real-time setelah file diubah di origin server?

Setelah file diperbarui di origin server, cache pada POP CDN tidak diperbarui secara otomatis atau real-time. Pembaruan cache ditentukan oleh kebijakan cache yang dikonfigurasi.

• POP CDN memperbarui cache berdasarkan TTL cache yang dikonfigurasi. Jika cache belum kedaluwarsa, perubahan pada file di origin server tidak langsung tercermin di cache CDN. Untuk informasi selengkapnya, lihat Konfigurasi waktu kedaluwarsa cache CDN.

• Anda dapat melakukan purge cache secara manual agar permintaan berikutnya mengambil konten terbaru dari origin server.

  • Untuk purge melalui konsol, lihat Panduan Pengguna.

  • Untuk purge melalui pemanggilan operasi API, lihat Perbarui Cache.

Faktor apa saja yang dapat menurunkan rasio hit cache?

Faktor-faktor berikut dapat menurunkan rasio hit cache Alibaba Cloud CDN:

1. Purge cache: Purge cache manual atau otomatis dapat menyebabkan penurunan sementara pada rasio hit cache.

2. Lonjakan bandwidth: Peningkatan tajam bandwidth dalam periode singkat dapat menyebabkan lebih banyak Permintaan asal dari POP CDN dan DCDN, sehingga menurunkan Rasio hit cache.

3. Permintaan konten baru: Jika POP CDN/DCDN sering menerima permintaan pertama kali untuk konten baru, lebih banyak origin fetch diperlukan. Hal ini mengakibatkan rasio hit cache yang lebih rendah.

4. Perubahan aturan cache: Mengubah kebijakan cache dapat memengaruhi rasio hit cache. Contohnya termasuk TTL cache atau kebijakan cache yang dikonfigurasi secara tidak tepat.

5. Parameter variabel dalam URL: Jika URL berisi parameter variabel setelah tanda tanya (?), setiap URL unik dianggap sebagai resource berbeda, meskipun kontennya sama. Hal ini meningkatkan jumlah origin fetch dan menurunkan rasio hit cache.

6. TTL cache yang dikonfigurasi secara tidak tepat: Jika Anda tidak mengatur TTL cache yang sesuai untuk file statis berdasarkan frekuensi pembaruannya, resource yang di-cache mungkin kedaluwarsa terlalu cepat. Hal ini meningkatkan origin fetch dan menurunkan rasio hit cache.

Untuk informasi selengkapnya tentang faktor yang memengaruhi rasio hit cache, lihat Tingkatkan rasio hit cache CDN. Untuk informasi selengkapnya, lihat Perbarui dan pra-ambil resource, Abaikan parameter, dan Konfigurasi waktu kedaluwarsa cache CDN.

Bagaimana cara mendiagnosis rasio hit cache yang rendah?

Rasio hit cache yang rendah dapat memperlambat pemuatan konten dan meningkatkan beban pada origin server Anda. Untuk informasi selengkapnya, lihat Diagnosis rasio hit cache CDN yang rendah.

Bagaimana cara mengonfigurasi pengaturan cache global?

Untuk mengonfigurasi pengaturan cache global dengan Time to Live (TTL) cache, atur Type ke Directory dan masukkan garis miring (/) di bidang Content untuk mencocokkan semua direktori. Untuk informasi selengkapnya, lihat Konfigurasi waktu kedaluwarsa cache CDN.

Mengapa konfigurasi cache saya tidak berlaku?

Jika Anda mengonfigurasi aturan cache yang tidak berlaku, penyebabnya mungkin salah satu dari berikut:

1. Waktu tunda propagasi: Aturan cache baru atau yang dimodifikasi mungkin memerlukan waktu untuk tersebar. Anda dapat memverifikasi aturan tersebut setelah propagasi selesai.

2. Mekanisme pembaruan cache: Aturan baru tidak langsung diterapkan pada konten yang sudah di-cache. Aturan baru hanya berlaku setelah cache yang ada kedaluwarsa.

3. Cache belum dipurge: Setelah Anda mengubah pengaturan cache, konten yang sudah di-cache akan terus disajikan kepada pengguna hingga kedaluwarsa atau dipurge secara manual. Untuk informasi selengkapnya, lihat Perbarui dan pra-ambil resource.

4. Header respons cache yang tidak tepat: Periksa apakah header Cache-Control dan Expires dalam respons HTTP dari origin server diatur dengan benar.

5. Prioritas aturan cache: Jika permintaan CDN sesuai dengan beberapa aturan, prioritas ditentukan terlebih dahulu berdasarkan bobot, lalu berdasarkan waktu pembuatan.

   • Jika Anda memiliki beberapa aturan cache, Anda dapat mengatur bobot yang berbeda untuk setiap aturan guna mengontrol prioritas eksekusinya. Bobot yang lebih tinggi menunjukkan prioritas yang lebih tinggi.

   • Untuk aturan dengan bobot yang sama, aturan yang dibuat lebih awal memiliki prioritas lebih tinggi, terlepas dari jenis aturannya.

   Contoh konfigurasi: Kebijakan cache berikut dikonfigurasi untuk nama domain yang dipercepat demo.aliyun.com. POP CDN mengambil resource http://demo.aliyun.com/image/example.png dari origin server. Meskipun permintaan sesuai dengan kedua aturan dan bobotnya sama, aturan dengan waktu pembuatan lebih awal memiliki prioritas lebih tinggi. Dalam kasus ini, aturan untuk direktori /image dibuat lebih awal dan karenanya berlaku.

Konfigurasi Berbagi Sumber Daya Lintas Asal (CORS) CDN menggunakan header respons HTTP dan catatan penting

Anda dapat mengatur header respons HTTP yang sesuai untuk mengizinkan permintaan dari asal berbeda mengakses resource Anda. Untuk informasi selengkapnya, lihat Konfigurasi berbagi sumber daya lintas asal.

Mengapa saya tetap mendapatkan error lintas asal dan header respons yang dikonfigurasi tidak muncul, meskipun saya telah mengonfigurasi header respons Access-Control-Allow-Origin?

Jika Anda mengonfigurasi header respons origin fetch seperti Access-Control-Allow-Origin di Alibaba Cloud CDN, tetapi klien tetap mengalami masalah lintas asal dan header respons tidak muncul, penyebabnya mungkin salah satu dari berikut:

Apa aturan cache untuk kode status abnormal?

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

  

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

  2. Jika origin server tidak mengembalikan header respons Set-Cookie, respons di-cache berdasarkan waktu kedaluwarsa kode status yang Anda konfigurasi di konsol CDN. Untuk informasi tentang bagaimana beberapa aturan berlaku, lihat bagian Prioritas beberapa aturan.

  3. Jika origin server tidak mengembalikan header respons Set-Cookie dan Anda tidak mengonfigurasi waktu kedaluwarsa untuk kode status di konsol CDN, respons di-cache berdasarkan header respons Pragma, Cache-Control, atau Expires dari origin server.

  4. Jika origin server tidak mengembalikan header respons Set-Cookie, Pragma, Cache-Control, atau Expires dan Anda tidak mengonfigurasi waktu kedaluwarsa untuk kode status di konsol CDN, respons di-cache selama 1 detik secara default.

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

  

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

  2. Jika origin server tidak mengembalikan header respons Set-Cookie, respons di-cache berdasarkan waktu kedaluwarsa kode status yang Anda konfigurasi di konsol CDN. Untuk informasi tentang bagaimana beberapa aturan berlaku, lihat bagian Prioritas beberapa aturan.

  3. Jika origin server tidak mengembalikan header respons Set-Cookie dan Anda tidak mengonfigurasi waktu kedaluwarsa untuk kode status di konsol CDN, respons di-cache berdasarkan header respons Pragma, Cache-Control, atau Expires dari origin server.

  4. Jika origin server tidak mengembalikan header respons Set-Cookie, Pragma, Cache-Control, atau Expires dan Anda tidak mengonfigurasi waktu kedaluwarsa untuk kode status di konsol CDN, respons tidak di-cache.

• Untuk kode status 304, CDN tidak menyimpan respons tersebut di cache. Anda tidak dapat mengatur durasi cache untuk kode status ini.

Apa perbedaan antara header respons keluar dan masuk?

Header respons keluar dan header respons masuk merepresentasikan informasi header HTTP pada tahap berbeda dalam arsitektur cache.

• Header respons keluar: Header ini dikirim dari POP CDN ke klien, seperti browser. Jika POP CDN memiliki konten yang diminta di cache-nya, konten tersebut langsung dikembalikan ke klien tanpa menghubungi origin server.

• Header respons masuk: Header ini dikirim dari origin server ke POP CDN. Saat cache pada POP CDN kedaluwarsa atau permintaan menghasilkan cache miss, POP CDN meminta konten terbaru dari origin server. Respons dari origin server, termasuk header HTTP-nya, merupakan respons masuk.

Perbedaan antara header respons keluar dan masuk terletak pada skenario penerapan dan interaksi yang dikontrolnya. Header respons keluar mengontrol perilaku caching antara klien dan POP CDN/DCDN. Header respons masuk mengontrol perilaku caching antara origin server dan POP CDN/DCDN. Keduanya sering digunakan bersama untuk mencapai kontrol cache yang efisien dan tepat. Untuk informasi selengkapnya tentang header respons masuk, lihat Modifikasi header respons masuk.

Bagaimana cara mengonfigurasi seluruh nama domain agar tidak di-cache?

Untuk mencegah seluruh nama domain di Alibaba Cloud CDN di-cache, Anda dapat mengatur TTL cache untuk semua path ke 0. Ikuti langkah-langkah berikut:

1. Login ke CDN console.

2. Di panel navigasi kiri, klik Domain Names.

3. Pada halaman Domain Names, temukan nama domain target dan klik Manage di kolom Actions.

4. Di panel navigasi domain, klik Cache.

5. Pada tab Cache Expiration, klik Create Rule.

   • Type: Pilih Directory.

   • Object: Masukkan /. Ini merepresentasikan semua path.

   • Expire In: Masukkan 0 seconds.

   • Pertahankan pengaturan default untuk parameter lainnya.

6. Klik OK untuk menyelesaikan konfigurasi.

Apakah CDN mendukung caching multi-replika?

Ya. CDN mendukung caching multi-replika secara default. Origin server harus menyertakan header Vary untuk menginstruksikan POP CDN/DCDN membuat replika berbeda berdasarkan header permintaan tertentu.

Sebagai contoh, untuk mendukung jenis kompresi berbeda, klien mungkin mengirim permintaan dengan Accept-Encoding: gzip, dan origin server mengembalikan konten yang dikompresi gzip. Jika klien mengirim Accept-Encoding: br, origin server mengembalikan konten yang dikompresi Brotli. Untuk menyimpan versi respons yang berbeda ini di cache, origin server harus menambahkan header Vary pada responsnya. Header ini memberi tahu sistem caching header permintaan mana yang digunakan untuk membedakan replika. Dalam contoh ini, origin server harus mengatur Vary: Accept-Encoding. Ini menunjukkan bahwa replika cache yang berbeda disimpan dan disajikan berdasarkan nilai header Accept-Encoding.

Bagaimana cara mengonfigurasi CDN untuk mengakses halaman utama subdirektori?

Praktik umum untuk situs web adalah mengembalikan halaman utama default saat pengguna mengakses subdirektori. Anda dapat mengonfigurasi ini di CDN, sehingga tidak perlu melakukan perubahan pada origin server Anda.

Sebagai contoh, jika file halaman utama adalah https://www.example.com/cdn/index.html, metode ini memastikan bahwa mengakses subdirektori https://www.example.com/cdn atau https://www.example.com/cdn/ juga mengembalikan file halaman utama tersebut.