All Products
Search
Document Center

Edge Security Acceleration:Konfigurasikan TTL cache

Last Updated:Jun 09, 2026

Dengan mengonfigurasi aturan kedaluwarsa cache, Anda dapat mengontrol durasi penyimpanan resource di titik keberadaan (POPs) DCDN guna menyeimbangkan kesegaran konten, kinerja akses, dan biaya pengambilan asal. Dokumen ini menjelaskan cara mengonfigurasi dan memvalidasi aturan cache, memberikan panduan pemecahan masalah, serta menguraikan praktik terbaik.

Catatan penggunaan

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

    Jika waktu kedaluwarsa cache terlalu singkat, DCDN akan sering mengambil data dari origin, sehingga meningkatkan beban trafik pada server origin. Sebaliknya, jika waktu kedaluwarsa cache terlalu lama, pembaruan data akan tertunda.

  • Resource yang di-cache di POP DCDN yang jarang diakses—yaitu resource yang sama di POP DCDN tersebut tidak sering diminta oleh klien—mungkin ditimpa oleh resource lain yang lebih populer di POP DCDN sebelum masa cache-nya berakhir.

  • Saat POP DCDN menerima file statis dari server origin, resource tersebut di-cache berdasarkan aturan dan prioritas cache default DCDN. Untuk informasi tentang aturan cache untuk file dinamis, lihat Ikhtisar aturan akselerasi untuk konten dinamis dan statis.

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

    Untuk membedakan secara akurat antara konten sebelum dan sesudah pembaruan, sinkronkan konten origin 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 DCDN console.

  2. Di panel navigasi kiri, klik Domain Names.

  3. Pada halaman Domain Names, temukan nama domain yang ingin Anda kelola dan klik Configure.

  4. Di pohon navigasi kiri halaman detail domain, klik Caching.

  5. Pada tab Cache Duration, klik Add.

  6. Pada kotak dialog Cache Duration, konfigurasikan aturan cache.

    image

    Parameter

    Deskripsi

    Type

    Tentukan cakupan resource berdasarkan Directory atau Filename Extension.

    • Directory: Tetapkan aturan cache yang sama untuk semua resource dalam path tertentu.

    • Filename Extension: Tetapkan aturan cache yang sama untuk resource dengan jenis file tertentu.

    Content

    Direktori atau ekstensi file tempat aturan tersebut berlaku.

    • Jika Anda mengatur Type ke Directory, perhatikan hal berikut:

      • Anda hanya dapat menambahkan satu direktori dalam satu waktu. Garis miring (/) cocok dengan semua direktori.

      • Masukkan path lengkap direktori. Path harus dimulai dengan garis miring (/). Contoh: /directory/aaa.

    • Jika Anda mengatur Type ke Filename Extension, perhatikan hal berikut:

      • Anda dapat memasukkan satu atau beberapa ekstensi nama file. Pisahkan beberapa ekstensi dengan koma (,), misalnya, jpg,txt. Input bersifat case-sensitive.

        Jenis file statis yang didukung:

        • Gambar: GIF, PNG, BMP, JPEG, dan JPG.

        • Laman web: HTML, HTM, dan SHTML.

        • File audio dan video: MP3, WMA, FLV, MP4, WMV, OGG, dan AVI.

        • Dokumen: DOC, DOCX, XLS, XLSX, PPT, PPTX, TXT, dan PDF.

        • Lainnya: ZIP, EXE, TAT, ICO, CSS, JS, SWF, APK, M3U8, TS, EJS, SVG, WOFF, dan OTF.

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

    Expire In

    TTL cache untuk resource. Durasi maksimum adalah 3 tahun. Kami merekomendasikan pengaturan berikut:

    • Untuk file statis yang jarang diperbarui, seperti gambar dan paket aplikasi, atur TTL menjadi satu bulan atau lebih lama.

    • Untuk file statis yang sering diperbarui, seperti file JS dan CSS, atur TTL kustom sesuai kebutuhan bisnis Anda.

    • Untuk file dinamis, seperti file PHP, JSP, dan ASP, atur TTL ke 0 detik agar tidak di-cache.

    Honor origin cache policy

    Jika diaktifkan, header kebijakan cache dari server origin, seperti Cache-Control dan Pragma, memiliki prioritas lebih tinggi.

    Ignore origin no-cache header

    Saat fitur ini diaktifkan, POP DCDN akan mengabaikan header kebijakan cache berikut dari respons server origin. Header-header ini menunjukkan bahwa konten tidak boleh di-cache.

    • Cache-Control: no-store

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

    • Pragma: no-cache

    Client follows DCDN cache policy

    Saat fitur ini diaktifkan, POP DCDN akan merespons klien dengan kebijakan cache yang efektif.

    Force revalidation

    Parameter ini hanya berlaku ketika TTL cache diatur ke 0. Efeknya sebagai berikut:

    • Nonaktif (default): Saat TTL cache untuk /DCDN diatur ke 0, POP /DCDN tidak menyimpan file dalam cache, dan setiap permintaan akan melakukan pengambilan asal.

    • Aktif: Saat TTL cache untuk DCDN diatur ke 0, file dapat di-cache di POP DCDN, dan setiap permintaan memerlukan pengambilan asal untuk memvalidasi konten yang di-cache.

    Weight

    Prioritas aturan cache. Nilai yang valid adalah bilangan bulat dari 1 hingga 99. Nilai yang lebih besar menunjukkan prioritas yang lebih tinggi. Aturan dengan prioritas tertinggi diterapkan terlebih dahulu.

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

    • Jika beberapa aturan memiliki weight yang sama, aturan yang dibuat lebih awal memiliki prioritas lebih tinggi, terlepas dari jenis aturannya.

    • Jika beberapa kebijakan cache dikonfigurasi, DCDN berhenti mencocokkan kebijakan cache lain setelah satu kebijakan diterapkan.

    Rule condition

    Kondisi aturan memungkinkan aturan diterapkan hanya jika permintaan memenuhi kriteria tertentu.

    Penting

    Saat suatu fitur merujuk pada kondisi aturan, urutan eksekusi mengikuti prioritas kondisi aturan terkait, bukan urutan konfigurasi fiturnya.

    • Do not use: Menonaktifkan aturan kondisional.

    • Anda dapat menambah atau mengedit aturan kondisional di Rules engine.

  7. Klik OK untuk menyimpan konfigurasi.

    Setelah berhasil mengonfigurasi aturan cache, Anda dapat menemukannya dalam daftar di tab Cache Duration. Anda dapat mengklik Modify atau Delete untuk mengelola aturan tersebut.

Aturan dan prioritas cache default Alibaba Cloud DCDN

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

Saat POP DCDN menerima file sumber daya dari server origin, aturan cache diterapkan berdasarkan urutan prioritas berikut. Angka yang lebih kecil menunjukkan prioritas yang lebih tinggi.缓存优先级

  1. Jika server origin merespons dengan pragma:no-cache, cache-control:no-cache (atau no-store atau max-age=0), DCDN tidak menyimpan resource tersebut dalam cache.

  2. Waktu kedaluwarsa cache atau waktu kedaluwarsa kode status yang diatur di konsol DCDN.

    Catatan

    Jika permintaan DCDN cocok dengan beberapa aturan, hanya satu aturan yang diterapkan. Prioritas ditentukan berdasarkan weight terlebih dahulu, kemudian berdasarkan waktu pembuatan.

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

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

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

    1. Jika header cache-control dalam respons dari server origin menentukan nilai max-age atau s-maxage lebih besar dari 0, header cache-control digunakan untuk menetapkan time-to-live. Contoh: cache-control:max-age=3600. Jika max-age dan s-maxage keduanya ada, s-maxage memiliki prioritas lebih tinggi.

    2. Jika respons origin 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 origin 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 origin tidak berisi cache-control, Expires, atau last-modified tetapi berisi ETag, resource di-cache selama 10 detik.

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

Deskripsi informasi respons cache

  • Date:

    • Menunjukkan waktu saat server origin mengirimkan resource dalam respons ke POP DCDN.

    • Saat POP DCDN memvalidasi ulang resource dengan server origin dengan menyertakan header If-Modified-Since atau If-None-Match dalam permintaan asal, informasi tanggal diperbarui jika server origin mengembalikan kode status 304.

    • Formatnya adalah Greenwich Mean Time (GMT), contoh: Sat, 19 Apr 2025 08:58:31 GMT.

  • X-Cache:

    Menunjukkan apakah resource yang diminta terdapat di cache pada POP DCDN. Tabel berikut menjelaskan nilai-nilai yang mungkin.

    Status

    Deskripsi

    HIT

    Sumber daya yang diminta ditemukan di cache pada POP DCDN.

    MISS

    Resource yang diminta tidak mengenai cache di POP DCDN. Resource disediakan oleh server origin.

  • X-Swift-Cachetime:

    • Menunjukkan sisa waktu cache resource di POP DCDN, dalam satuan 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 dikonfigurasi untuk DCDN. Tiga situasi berikut dapat terjadi:

      • X-Swift-Cachetime = Waktu kedaluwarsa cache yang ditetapkan untuk DCDN, misalnya, 3.600 detik.

      • X-Swift-Cachetime sedikit lebih kecil daripada waktu kedaluwarsa cache yang diatur untuk DCDN. Misalnya, jika waktu kedaluwarsa cache untuk DCDN diatur ke 300 detik, nilai X-Swift-Cachetime akan menjadi 295 detik. Hal ini mungkin disebabkan oleh alasan berikut:

        • Latensi tinggi terjadi saat 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 dapat terjadi jika waktu kedaluwarsa cache untuk DCDN diubah. Saat klien mengirim permintaan, cache di POP Layer 1 telah kedaluwarsa, sedangkan cache di POP Layer 2 belum. Misalnya, waktu kedaluwarsa cache untuk DCDN awalnya 3.600 detik, lalu 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 merefresh cache.

  • X-Swift-SaveTime:

    • Menunjukkan waktu saat resource pertama kali di-cache di POP DCDN yang diakses langsung oleh klien, biasanya POP Layer 1.

    • Formatnya adalah Greenwich Mean Time (GMT), contoh: Sat, 19 Apr 2025 08:58:31 GMT.

  • Ali-Swift-Global-Savetime:

    • Menunjukkan waktu saat resource pertama kali di-cache di POP DCDN. POP tersebut dapat berupa POP Layer 2 atau POP pada lapisan cache lainnya, tergantung pada arsitektur cache situs.

    • Formatnya adalah stempel waktu UNIX, contoh: 1745053111, yang merepresentasikan 2025-04-19 16:58:31.

Verifikasi status cache resource

Setelah mengonfigurasi TTL cache, gunakan metode berikut untuk memverifikasi apakah resource disajikan dari cache DCDN.

  • Metode 1: Gunakan perintah curl

    Di terminal, jalankan perintah berikut untuk meminta URL target menggunakan curl -I, lalu periksa bidang X-Cache di header respons untuk menentukan apakah cache terkena.

    curl -I http://<accelerated_domain_name>/<resource_path>

    Di header respons, periksa bidang X-Cache:

    • X-Cache: HIT menunjukkan bahwa resource disajikan dari cache DCDN.

    • X-Cache: MISS menunjukkan bahwa resource tidak ditemukan di cache DCDN dan disajikan langsung dari server origin.

  • Metode 2: Gunakan alat developer browser

    Gunakan alat developer browser Anda (F12). Di tab Network, akses URL resource tersebut. Pilih permintaan dan periksa header X-Cache dalam respons.

Mekanisme kontrol cache HTTP

Protokol HTTP mendefinisikan tiga jenis mekanisme kontrol cache:

  1. Mekanisme validasi waktu kedaluwarsa

    Saat klien meminta resource dari server, waktu kedaluwarsa untuk resource tersebut ditetapkan. Sebelum waktu ini, salinan cache resource 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

    Jenis

    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 mana konten yang di-cache akan kedaluwarsa.

    Jika tanggal tidak valid digunakan, seperti 0, artinya resource 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 resource

    Saat klien pertama kali meminta resource dari server, server menyertakan tag resource dalam header respons. Tag ini berfungsi sebagai pengenal validasi untuk permintaan berikutnya terhadap resource yang sama. Saat klien meminta resource tersebut lagi, tag tersebut disertakan dalam header permintaan. Jika server memvalidasi tag dan menentukan bahwa resource 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 resource telah dimodifikasi, dan klien harus mengambil kembali konten resource tersebut.

    Berikut adalah header HTTP umum yang mengontrol versi cache:

    Nama Header

    Versi Protokol

    Fungsi

    Nilai Contoh

    Jenis

    Last-Modified

    HTTP/1.0

    Last-Modified menunjukkan waktu modifikasi terakhir resource.

    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT

    Respons

    ETag

    HTTP/1.1

    ETag menyediakan pengenal unik untuk versi spesifik resource.

    Membandingkan ETag dapat menentukan apakah resource telah berubah. Jika tidak berubah, server origin tidak perlu mengirim respons lengkap.

    ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

    Respons

  3. Mekanisme negosiasi multi-salinan

    Perangkat lunak caching menggunakan kata kunci untuk mengindeks objek yang di-cache di disk. Dalam HTTP/1.0, URL resource digunakan sebagai kata kunci. Namun, resource 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 multi-salinan biasanya menggunakan header HTTP Vary untuk membedakan antara salinan cache yang berbeda. Hal ini memungkinkan klien berbeda yang meminta resource yang sama menerima versi berbeda dari resource tersebut:

    Nama Header

    Versi Protokol

    Deskripsi

    Nilai Contoh

    Jenis

    Vary

    HTTP/1.1

    Contoh umum:

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

    • Server menentukan Vary: User-Agent untuk mengidentifikasi jenis browser yang mengirim permintaan, memberi tahu penerima (seperti POP DCDN) untuk menyimpan versi resource 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, tambahkan aturan cache di DCDN console untuk ekstensi nama file .txt dan atur TTL cache menjadi 7 hari.

image.png

Contoh 2: Kebijakan caching berikut dikonfigurasi untuk nama domain yang dipercepat demo.aliyun.com. Saat POP DCDN mengambil resource http://demo.aliyun.com/image/example.png dari origin, dua aturan cocok. Karena kedua aturan memiliki weight yang sama, sistem memprioritaskan aturan yang dibuat lebih awal. Aturan untuk direktori /image dibuat lebih awal. Oleh karena itu, aturan berbasis direktori yang diterapkan.image.png

Referensi API

BatchSetDcdnDomainConfigs