全部产品
Search
文档中心

CDN:Konfigurasi waktu kedaluwarsa cache

更新时间:Nov 20, 2025

Waktu hidup (TTL) cache menentukan durasi penyimpanan sumber daya dari server asal dalam cache pada node CDN. Setelah TTL berakhir, node CDN menandai sumber daya tersebut sebagai kedaluwarsa. Jika klien meminta sumber daya yang telah kedaluwarsa dari node CDN, CDN melakukan pengambilan asal untuk mengambil versi terbaru sumber daya tersebut dan menyimpannya dalam cache pada node CDN. Anda dapat mengonfigurasi TTL cache untuk sumber daya statis berdasarkan direktori file atau ekstensi nama file sesuai kebutuhan bisnis Anda.

Perhatian

  • Anda dapat mengubah waktu cache setelah menambahkan nama domain. Durasi cache memengaruhi lalu lintas kembali ke asal dan biaya. Waktu kedaluwarsa cache memengaruhi frekuensi pengambilan asal. Tetapkan durasi cache sumber daya berdasarkan kebutuhan bisnis Anda.

    Jika waktu kedaluwarsa cache terlalu singkat, CDN akan sering mengambil data dari asal, sehingga meningkatkan lalu lintas server asal. Jika waktu kedaluwarsa cache terlalu lama, pembaruan data akan tertunda.

  • Sumber daya yang di-cache pada POP CDN yang jarang diakses (artinya sumber daya pada POP CDN yang sama tidak sering diminta oleh klien) mungkin ditimpa oleh sumber daya lebih populer lainnya pada POP CDN sebelum masa cache-nya berakhir.

  • Secara default, ketika titik kehadiran menerima sumber daya file statis dalam tanggapan dari server asal, sumber daya tersebut di-cache sesuai dengan aturan dan prioritas cache default Alibaba Cloud CDN dan DCDN.

  • Jangan perbarui konten pada server asal menggunakan nama file yang sama. Sebagai gantinya, gunakan nomor versi untuk sinkronisasi.

    Untuk membedakan secara akurat antara konten sebelum dan sesudah pembaruan, sinkronkan konten asal Anda menggunakan nomor versi. Artinya, gunakan nama file yang berbeda saat memperbarui konten. Misalnya, Anda dapat menggunakan nama seperti img-v1.0.jpg dan img-v2.1.jpg.

Prosedur

  1. Masuk ke Konsol CDN.

  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.

    image

    Parameter

    Deskripsi

    Type

    Menentukan cakupan sumber daya berdasarkan Directory atau File Extension.

    • Directory: Menetapkan aturan cache yang sama untuk semua sumber daya dalam path tertentu.

    • File Extension: Menetapkan aturan cache yang sama untuk jenis file tertentu.

    Object

    Menentukan folder atau ekstensi file dari sumber daya yang akan dikonfigurasi.

    • Jika Anda mengatur Type ke Folder, ikuti aturan berikut:

      • Anda hanya dapat menambahkan satu folder dalam satu waktu. Gunakan garis miring (/) untuk mencocokkan semua folder.

      • Masukkan path lengkap folder tersebut. Path harus diawali dengan garis miring (/), misalnya /directory/aaa.

    • Jika Anda memilih File Suffix sebagai tipe, aturan berikut berlaku:

      • Masukkan satu atau beberapa ekstensi file. Pisahkan beberapa ekstensi dengan koma (,), misalnya jpg,txt.

      • Input bersifat case-sensitive.

      • Anda tidak dapat menggunakan tanda bintang (*) untuk mencocokkan semua jenis file.

    Expire In

    Waktu penyimpanan sumber daya dalam cache pada POP CDN. Waktu maksimum adalah 3 tahun. Konfigurasikan parameter ini berdasarkan aturan berikut:

    • Untuk file statis yang jarang diperbarui, seperti citra dan unduhan aplikasi, atur waktu kedaluwarsa lebih dari 1 bulan.

    • Untuk file statis yang sering diperbarui, seperti file JS dan CSS, atur waktu kedaluwarsa sesuai kebutuhan.

    • Untuk file dinamis, seperti file PHP, JSP, dan ASP, atur waktu kedaluwarsa menjadi 0 detik. Hal ini menonaktifkan caching.

    Honor Origin Cache Policy

    Jika diaktifkan dan server asal merespons dengan header kebijakan cache (termasuk Cache-Control dan Pragma), kebijakan cache dari server asal memiliki prioritas lebih tinggi.

    Ignore Origin No-Cache Header

    Jika diaktifkan, POP CDN mengabaikan header kebijakan no-cache berikut dari respons server asal.

    • Cache-Control: no-store

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

    • Pragma: no-cache

    Follows POP Cache Policy

    Jika diaktifkan, POP CDN mengirimkan kebijakan cache efektif akhir dalam respons kepada klien.

    Force Revalidation

    Parameter ini hanya berlaku jika waktu kedaluwarsa cache diatur ke 0. Efeknya sebagai berikut:

    • Nonaktif (default): Jika waktu kedaluwarsa cache untuk CDN diatur ke 0, file tidak di-cache pada POP CDN. Setiap permintaan harus dialihkan ke server asal untuk mengambil konten.

    • Aktif: Jika waktu kedaluwarsa cache untuk CDN diatur ke 0, file dapat di-cache pada POP CDN. Setiap permintaan harus dialihkan ke server asal untuk memvalidasi konten yang di-cache.

    Weight

    Bobot menunjukkan prioritas aturan cache. Nilainya berkisar dari 1 hingga 99. Nilai yang lebih besar menunjukkan prioritas yang lebih tinggi. Aturan dengan prioritas lebih tinggi akan didahulukan.

    Catatan
    • Jika Anda memiliki beberapa aturan cache, tetapkan bobot berbeda untuk setiap aturan guna mengontrol prioritas eksekusinya.

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

    • Jika Anda mengonfigurasi beberapa kebijakan cache, tidak ada kebijakan lain yang dicocokkan setelah satu kebijakan diterapkan.

    Rule Condition

    Kondisi aturan dapat mengidentifikasi parameter dalam permintaan untuk menentukan apakah konfigurasi berlaku untuk permintaan tersebut.

    • Jangan gunakan kondisi

    • Jika ingin menambahkan atau mengedit kondisi aturan, lihat Rules engine.

  6. Klik OK untuk menyelesaikan konfigurasi.

Aturan dan prioritas cache default Alibaba Cloud CDN

Untuk respons asal dengan kode status HTTP 200, 203, 206, 300, 301, 308, atau 410, waktu kedaluwarsa cache ditentukan oleh aturan berikut.

Ketika POP CDN menerima sumber daya file dari server asal, aturan cache diterapkan sesuai urutan prioritas berikut. Angka yang lebih kecil menunjukkan prioritas yang lebih tinggi.缓存优先级

  1. Jika server asal merespons dengan pragma:no-cache, cache-control:no-cache (atau no-store, atau max-age=0), CDN tidak menyimpan sumber daya tersebut dalam cache.

  2. Waktu kedaluwarsa cache atau waktu kedaluwarsa kode status yang diatur di Konsol CDN.

    Catatan

    Jika permintaan CDN cocok dengan beberapa aturan, hanya satu aturan yang diterapkan. Prioritas ditentukan pertama berdasarkan bobot, lalu berdasarkan waktu pembuatan.

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

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

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

    1. Jika header cache-control dalam respons dari server asal menentukan nilai max-age atau s-maxage lebih besar dari 0, header cache-control digunakan untuk mengatur waktu hidup. Contoh: cache-control:max-age=3600. Jika max-age dan s-maxage keduanya ada, s-maxage memiliki prioritas lebih tinggi.

    2. Jika respons asal tidak berisi header cache-control tetapi berisi header Expires, waktu kedaluwarsa cache ditentukan oleh header Expires. Contoh: expires:Tue, 25 Nov 2031 17.25.43 GMT.

    3. Jika respons asal tidak berisi cache-control atau Expires tetapi berisi last-modified, waktu cache dihitung menggunakan rumus: (Waktu Saat Ini - last-modified) × 0,1. Jika hasilnya antara 10 detik dan 3600 detik, hasil tersebut digunakan. Jika hasilnya kurang dari 10 detik, waktu cache adalah 10 detik. Jika hasilnya lebih dari 3600 detik, waktu cache adalah 3600 detik.

    4. Jika respons asal tidak berisi cache-control, Expires, atau last-modified tetapi berisi ETag, sumber daya di-cache selama 10 detik.

  4. Jika data yang dikembalikan dari server asal tidak berisi header respons terkait cache apa pun (cache-control, expires, last-modified, atau ETag), sumber daya tersebut tidak di-cache secara default.

Deskripsi informasi respons cache

  • Date:

    • Menunjukkan waktu server asal mengirimkan sumber daya dalam respons kepada POP CDN.

    • Ketika POP CDN melakukan validasi ulang sumber daya dengan server asal dengan menyertakan header If-Modified-Since atau If-None-Match dalam permintaan asal, informasi Date diperbarui jika server asal mengembalikan kode status 304.

    • Formatnya mengikuti Waktu Standar Greenwich (GMT), contohnya: Sat, 19 Apr 2025 08:58:31 GMT.

  • X-Cache:

    Menunjukkan apakah sumber daya yang diminta mengenai cache pada POP CDN. Tabel berikut menjelaskan nilai-nilai yang mungkin.

    Status

    Deskripsi

    HIT

    Sumber daya yang diminta mengenai cache pada POP CDN.

    MISS

    Sumber daya yang diminta tidak mengenai cache pada POP CDN. Sumber daya disediakan oleh server asal.

  • X-Swift-Cachetime:

    • Menunjukkan sisa waktu cache sumber daya pada POP CDN, dalam detik.

    • X-Swift-Cachetime = Ali-Swift-Global-Savetime + Waktu kedaluwarsa cache yang diatur untuk CDN - X-Swift-SaveTime.

    • X-Swift-Cachetime tidak selalu sama dengan waktu kedaluwarsa cache yang diatur untuk CDN. Tiga situasi berikut mungkin terjadi:

      • X-Swift-Cachetime = Waktu kedaluwarsa cache yang diatur untuk CDN, misalnya 3600 detik.

      • X-Swift-Cachetime sedikit lebih kecil daripada waktu kedaluwarsa cache yang diatur untuk CDN. Misalnya, waktu kedaluwarsa cache untuk CDN diatur menjadi 300 detik, tetapi X-Swift-Cachetime adalah 295 detik. Hal ini mungkin disebabkan oleh alasan berikut:

        • Latensi tinggi terjadi ketika POP Layer 1 mengambil data dari POP Layer 2.

        • Jam pada POP Layer 1 dan Layer 2 tidak tersinkronisasi.

      • Nilai X-Swift-Cachetime negatif. Hal ini mungkin terjadi karena waktu kedaluwarsa cache untuk CDN diubah. Ketika klien mengirim permintaan, cache pada POP Layer 1 telah kedaluwarsa, tetapi cache pada POP Layer 2 belum. Misalnya, waktu kedaluwarsa cache untuk CDN awalnya 3600 detik dan kemudian diubah menjadi 300 detik. Jika klien mengirim permintaan 600 detik setelah permintaan pertama, header responsnya adalah X-Swift-Cachetime:-300. Untuk mengatasi masalah ini, Anda dapat menyegarkan cache.

  • X-Swift-SaveTime:

    • Menunjukkan waktu sumber daya pertama kali di-cache pada POP CDN yang diakses langsung oleh klien. Biasanya ini adalah POP Layer 1.

    • Formatnya adalah Greenwich Mean Time (GMT), contohnya: Sat, 19 Apr 2025 08.58.31 GMT.

  • Ali-Swift-Global-Savetime:

    • Menunjukkan waktu sumber daya pertama kali di-cache pada POP CDN. Ini bisa berupa POP Layer 2 atau POP pada lapisan cache lainnya, tergantung pada arsitektur cache situs.

    • Formatnya adalah stempel waktu UNIX, contohnya: 1745053111, yang merepresentasikan 2025-04-19 16.58.31.

Mekanisme kontrol cache HTTP

Protokol HTTP mendefinisikan tiga jenis mekanisme kontrol cache:

  1. Mekanisme validasi waktu kedaluwarsa

    Ketika klien meminta sumber daya dari server, waktu kedaluwarsa untuk sumber daya tersebut ditetapkan. Sebelum waktu ini, salinan cache sumber daya dianggap valid. Setelah waktu ini, salinan cache dianggap tidak valid.

    Berikut adalah header HTTP umum yang mengontrol waktu kedaluwarsa cache:

    Nama Header

    Versi Protokol

    Fungsi

    Nilai Contoh

    Tipe

    Pragma

    HTTP/1.0

    Pragma menunjukkan apakah konten tidak boleh di-cache. Nilai tipikalnya adalah no-cache, yang berarti file tidak di-cache. Sering digunakan untuk kompatibilitas dengan server yang hanya mendukung HTTP/1.0.

    Pragma:no-cache

    Permintaan/Respons

    Expires

    HTTP/1.0

    Header respons Expires berisi tanggal/waktu setelah itu konten cache akan kedaluwarsa.

    Jika tanggal tidak valid digunakan, seperti 0, artinya sumber daya telah kedaluwarsa.

    Expires: Wed, 21 Oct 2022 07.28.00 GMT

    Respons

    Cache-Control

    HTTP/1.1

    Header respons Cache-Control dapat diatur dengan instruksi berbeda untuk mencapai kontrol cache yang fleksibel. Ini adalah header utama yang digunakan oleh klien modern, seperti browser, untuk mengontrol caching.

    Tiga contoh berikut menunjukkan bahwa file tidak boleh di-cache:

    • Cache-Control:no-cache

    • Cache-Control:no-store

    • Cache-Control:max-age=0

    Contoh yang menunjukkan periode validitas cache 1 jam: Cache-Control:max-age=3600

    Permintaan/Respons

  2. Mekanisme validasi tag sumber daya

    Ketika klien pertama kali meminta sumber daya dari server, server menyertakan tag sumber daya dalam header respons. Tag ini berfungsi sebagai pengenal validasi untuk permintaan selanjutnya terhadap sumber daya yang sama. Ketika klien meminta sumber daya tersebut lagi, ia menyertakan tag tersebut dalam header permintaan. Jika server memvalidasi tag dan menentukan bahwa sumber daya belum diperbarui, server merespons dengan kode status HTTP 304. Hal ini menunjukkan bahwa klien dapat terus menggunakan salinan cache lokalnya. Jika server menemukan ketidakcocokan, artinya sumber daya telah dimodifikasi, dan klien harus mengambil kembali konten sumber daya tersebut.

    Berikut adalah header HTTP umum yang mengontrol versi cache:

    Nama Header

    Versi Protokol

    Fungsi

    Nilai Contoh

    Tipe

    Last-Modified

    HTTP/1.0

    Last-Modified menunjukkan waktu modifikasi terakhir sumber daya.

    Last-Modified: Wed, 21 Oct 2015 07.28.00 GMT

    Respons

    ETag

    HTTP/1.1

    ETag menyediakan pengenal unik untuk versi tertentu dari sumber daya.

    Membandingkan ETag dapat menentukan apakah sumber daya telah berubah. Jika tidak berubah, server asal tidak perlu mengirim respons penuh.

    ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

    Respons

  3. Mekanisme negosiasi salinan ganda

    Perangkat lunak caching menggunakan kata kunci untuk mengindeks objek yang di-cache pada disk. Dalam HTTP/1.0, URL sumber daya digunakan sebagai kata kunci. Namun, sumber daya berbeda mungkin berbagi URL yang sama. Untuk membedakannya, klien harus memberikan informasi tambahan, seperti header Accept-Language dan Accept-Charset. Untuk mendukung mekanisme negosiasi konten ini, HTTP/1.1 memperkenalkan header Vary dalam pesan respons. Header ini menentukan header mana dari pesan permintaan yang digunakan untuk negosiasi konten.

    Mekanisme negosiasi salinan ganda biasanya menggunakan header HTTP Vary untuk membedakan antara salinan cache yang berbeda. Hal ini memungkinkan klien berbeda yang meminta sumber daya yang sama menerima versi berbeda dari sumber daya tersebut:

    Nama Header

    Versi Protokol

    Deskripsi

    Nilai Contoh

    Tipe

    Vary

    HTTP/1.1

    Contoh umum:

    • Server menentukan Vary: Accept-Encoding untuk memberi tahu penerima (seperti POP CDN) bahwa dua versi sumber daya (terkompresi dan tidak terkompresi) perlu di-cache untuk sumber daya ini. Ketika klien meminta sumber daya yang sama dari CDN, browser lama mendapatkan sumber daya tidak terkompresi (untuk menghindari masalah kompatibilitas), sedangkan browser baru mendapatkan sumber daya terkompresi (untuk mengurangi lalu lintas transmisi data).

    • Server menentukan Vary: User-Agent untuk mengidentifikasi jenis browser yang mengirim permintaan, memberi tahu penerima (seperti POP CDN) untuk menyimpan versi sumber daya yang sesuai berdasarkan jenis browser.

    Vary: Accept-Encoding

    Vary: Accept-Encoding,User-Agent

    Respons

Contoh konfigurasi

Contoh 1: Untuk menyimpan file .txt dalam cache selama 7 hari, Anda dapat menambahkan aturan cache di Konsol CDN untuk ekstensi file "txt" dan mengatur waktu kedaluwarsa cache menjadi "7 Days".

image.png

Contoh 2: Asumsikan Anda mengonfigurasi kebijakan cache berikut untuk nama domain yang dipercepat demo.aliyun.com. Ketika POP CDN mengambil sumber daya http://demo.aliyun.com/image/example.png dari asal, kedua aturan berikut cocok. Karena aturan memiliki bobot yang sama, aturan yang dibuat lebih awal memiliki prioritas lebih tinggi. Dalam kasus ini, aturan untuk folder /image dibuat lebih awal, sehingga sistem menerapkan aturan untuk tipe folder.

image.png

API Terkait

BatchSetCdnDomainConfig

FAQ