Mengonfigurasi perilaku caching

Media CDN menayangkan konten sedekat mungkin dengan pengguna dengan menggunakan infrastruktur edge caching global Google untuk menyimpan konten ke cache dan mengurangi beban pada infrastruktur asal.

Anda dapat mengontrol cara konten di-cache untuk setiap rute. Dengan demikian, Anda dapat mengoptimalkan perilaku berdasarkan jenis konten, atribut permintaan klien, dan persyaratan keaktualan Anda.

Kemampuan penyimpanan dalam cache

Bagian berikut menjelaskan respons yang di-cache Media CDN dan cara meningkatkan pelepasan cache.

Perilaku caching default

Secara default, setelan terkait cache berikut berlaku untuk setiap layanan Edge Cache:

• Mode cache default CACHE_ALL_STATIC:

  • Mematuhi direktif cache server asal, seperti Cache-Control atau Expires, hingga TTL maksimum yang dapat dikonfigurasi.
  • Meng-cache jenis media statis secara otomatis dengan TTL default 3.600 detik, jika tidak ada direktif cache origin.
  • Meng-cache kode status HTTP 200, 204, dan 206 (penyimpanan cache negatif tidak diaktifkan).

• Tidak meng-cache respons yang memiliki direktif cache-control no-store atau private atau yang tidak dapat di-cache.

Respons yang bukan konten statis atau yang tidak memiliki perintah cache yang valid tidak di-cache kecuali jika caching dikonfigurasi secara eksplisit. Untuk mempelajari cara mengganti perilaku default, lihat dokumentasi tentang mode cache .

Perilaku default setara dengan cdnPolicy berikut. Rute tanpa cdnPolicy eksplisit yang dikonfigurasi berperilaku seolah-olah memiliki konfigurasi berikut:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

Respons yang dapat di-cache

Respons yang dapat di-cache adalah respons HTTP yang dapat disimpan dan diambil dengan cepat oleh Media CDN, sehingga memungkinkan waktu pemuatan yang lebih cepat. Tidak semua respons HTTP dapat di-cache.

Anda dapat mengonfigurasi mode cache untuk setiap rute guna mengganti perilaku ini (misalnya, menggunakan mode cache CACHE_ALL_STATIC untuk meng-cache jenis media umum) meskipun server asal tidak menetapkan perintah kontrol cache dalam respons.

Permintaan dan respons yang memenuhi kriteria yang ditentukan dalam respons yang tidak dapat di-cache menggantikan kemampuan di-cache.

Tabel berikut menjelaskan persyaratan untuk meng-cache respons HTTP tertentu. Respons GET dan HEAD harus mematuhi persyaratan ini.

Header HTTP Age ditetapkan berdasarkan waktu Media CDN pertama kali meng-cache respons, dan biasanya menunjukkan detik sejak objek di-cache di lokasi perlindungan origin. Jika server asal Anda menghasilkan header respons Age, gunakan mode cache FORCE_CACHE_ALL untuk mencegah validasi ulang saat Age melebihi TTL cache.

Untuk mengetahui informasi selengkapnya tentang cara Media CDN menafsirkan perintah HTTP caching, lihat Perintah kontrol cache.

Persyaratan asal

Agar Media CDN dapat meng-cache respons origin yang lebih besar dari 1 MiB, origin harus menyertakan hal berikut dalam header respons untuk permintaan GET, kecuali jika ditentukan lain:

• Header respons HTTP Last-Modified atau ETag (validator).
• Header HTTP Date yang valid.
• Header Content-Length yang valid.
• Header respons Content-Range, sebagai respons terhadap permintaan Range GET. Header Content-Range harus memiliki nilai yang valid dalam bentuk bytes x-y/z (dengan z adalah ukuran objek).

Protokol origin default adalah HTTP/2. Jika origin Anda hanya mendukung HTTP/1.1, Anda dapat menetapkan kolom protokol secara eksplisit untuk setiap origin.

Respons yang tidak dapat di-cache

Tabel berikut menjelaskan atribut permintaan dan respons yang mencegah respons di-cache. Respons yang dapat di-cache tetapi cocok dengan kriteria "tidak dapat di-cache" tidak akan di-cache.

Aturan ini berlaku selain mode cache yang dikonfigurasi. Secara khusus:

• Dengan mode cache CACHE_ALL_STATIC yang dikonfigurasi, hanya respons yang dianggap sebagai konten statis atau respons dengan arahan cache yang valid di header responsnya yang di-cache. Respons lainnya di-proxy apa adanya.
• Mode cache FORCE_CACHE_ALL meng-cache semua respons tanpa syarat, tunduk pada persyaratan tidak dapat di-cache yang dinyatakan sebelumnya.
• Mode cache USE_ORIGIN_HEADERS mengharuskan respons untuk menyetel perintah cache yang valid di header responsnya selain menjadi kode status yang dapat di-cache.

Catatan:

• Respons yang tidak di-cache tidak mengubah perintah kontrol cache atau header lainnya dan di-proxy apa adanya.
• Respons dapat memiliki header Cache-Control dan Expires yang diciutkan menjadi satu kolom Cache-Control. Misalnya, respons dengan Cache-Control: public dan Cache-Control: max-age=100 pada baris terpisah akan diciutkan sebagai Cache-Control: public,max-age=100.
• Respons yang tidak dapat di-cache (respons yang tidak akan pernah di-cache) tidak dihitung sebagai Cache Egress dari perspektif penagihan.

Menggunakan mode cache

Mode cache memungkinkan Anda mengonfigurasi kapan Media CDN harus mematuhi perintah cache server asal, meng-cache jenis media statis, dan meng-cache semua respons dari server asal, terlepas dari perintah yang ditetapkan.

Mode cache dikonfigurasi di tingkat rute dan, jika dikombinasikan dengan penggantian TTL, memungkinkan Anda mengonfigurasi perilaku cache menurut host, jalur, parameter kueri, dan header (parameter permintaan yang dapat dicocokkan).

• Secara default, Media CDN menggunakan mode cache CACHE_ALL_STATIC, yang secara otomatis meng-cache jenis media statis umum selama 1 jam (3.600 detik), sekaligus memprioritaskan perintah cache apa pun yang ditentukan oleh server asal untuk respons yang dapat di-cache.
• Anda dapat menambah atau mengurangi TTL cache yang diterapkan pada respons tanpa TTL cache eksplisit yang ditetapkan (perintah max-age atau s-maxage) dengan menetapkan kolom cdnPolicy.defaultTtl pada rute.
• Untuk mencegah respons yang tidak berhasil di-cache lebih lama dari yang diinginkan, kode status non-2xx (tidak berhasil) tidak di-cache sesuai dengan Content-Type (jenis MIME) dan tidak menerapkan TTL default.

Mode cache yang tersedia, yang ditetapkan pada cdnPolicy.cacheMode setiap rute, ditampilkan dalam tabel berikut.

Jenis MIME konten statis

Mode cache CACHE_ALL_STATIC memungkinkan Media CDN untuk secara otomatis menyimpan konten statis umum seperti video, audio, gambar, dan aset web umum berdasarkan jenis MIME yang ditampilkan di header respons HTTP Content-Type. Namun, terlepas dari jenis media, Media CDN memprioritaskan header Cache-Control atau Expires eksplisit dalam respons origin.

Tabel berikut mencantumkan jenis MIME yang dapat di-cache secara otomatis dengan mode cache CACHE_ALL_STATIC.

Respons tidak di-cache secara otomatis jika tidak memiliki header respons Content-Type dengan nilai yang cocok dengan nilai berikut. Anda harus memastikan bahwa respons menetapkan perintah cache yang valid, atau Anda harus menggunakan mode cache FORCE_CACHE_ALL untuk meng-cache respons tanpa syarat.

Perhatikan hal berikut:

• Software server web asal Anda harus menetapkan Content-Type untuk setiap respons. Banyak server web yang otomatis menetapkan header Content-Type, termasuk NGINX, Varnish, dan Apache.
• Cloud Storage akan menyetel header Content-Type secara otomatis saat upload saat Anda menggunakan konsol Google Cloud atau gcloud CLI untuk mengupload konten.
• Cloud Storage akan selalu menyediakan header Cache-Control ke Media CDN. Jika tidak ada nilai yang dipilih secara eksplisit, nilai default akan dikirim. Akibatnya, semua respons Cloud Storage yang berhasil akan di-cache sesuai dengan nilai default Cloud Storage, kecuali jika Anda secara eksplisit menyesuaikan metadata kontrol cache untuk objek di Cloud Storage atau menggunakan mode FORCE_CACHE_ALL untuk mengganti nilai yang dikirim oleh Cloud Storage.

Jika suatu respons dapat di-cache berdasarkan jenis MIME-nya, tetapi memiliki perintah respons Cache-Control dari private atau no-store atau header Set-Cookie, respons tersebut tidak akan di-cache.

Jenis media lainnya, seperti HTML (text/html) dan JSON (application/json), tidak di-cache secara default. Jenis respons ini biasanya bersifat dinamis (per pengguna), dan juga tidak cocok untuk arsitektur Media CDN. Sebaiknya gunakan Cloud CDN untuk menayangkan aset web dan untuk menyimpan respons API dalam cache.

Mengonfigurasi TTL cache

Penggantian time to live (TTL) memungkinkan Anda menetapkan nilai TTL default untuk konten yang di-cache dan mengganti nilai TTL yang ditetapkan dalam direktif kontrol cache max-age dan s-maxage (atau header Expires) yang ditetapkan oleh server asal Anda.

TTL, baik yang ditetapkan oleh penggantian maupun dengan menggunakan direktif cache, bersifat optimis. Konten yang jarang diakses atau tidak populer dapat dikeluarkan dari cache sebelum TTL tercapai.

Tabel berikut menunjukkan tiga setelan TTL.

Menetapkan nilai TTL ke nol (0 detik) menyebabkan setiap permintaan divalidasi ulang dengan asal sebelum respons ditayangkan dan meningkatkan beban ke asal jika ditetapkan terlalu luas.

Jika mode cache disetel ke Use Origin Headers, setelan TTL tidak dapat dikonfigurasi karena Media CDN mengandalkan server asal untuk menentukan perilaku.

Catatan:

• Nilai TTL maks harus selalu lebih besar daripada (atau sama dengan) nilai TTL default.
• Nilai TTL klien harus selalu lebih kecil dari (atau sama dengan) nilai TTL maks.
• Saat Media CDN mengganti nilai TTL server asal, header Cache-Control ke klien juga mencerminkan nilai tersebut.
• Jika origin menetapkan header Expires dan Media CDN mengganti TTL efektif (berdasarkan stempel waktu), header Expires akan diganti dengan header Cache-Control dalam respons downstream ke klien.

Caching negatif

Caching negatif menentukan cara kode status HTTP yang tidak berhasil (selain 2xx) di-cache oleh Media CDN.

Dengan demikian, Anda dapat menyimpan respons error seperti pengalihan (HTTP 301 dan 308) dan respons tidak ditemukan (HTTP 404) lebih dekat dengan pengguna, serta mengurangi beban origin secara lebih luas jika respons tidak mungkin berubah dan dapat di-cache.

Secara default, caching negatif dinonaktifkan. Tabel berikut menunjukkan nilai default untuk setiap kode status saat cache negatif diaktifkan dan negativeCachingPolicy tidak digunakan.

Set default kode caching negatif cocok dengan kode status yang dapat di-cache secara heuristik yang dijelaskan dalam HTTP RFC 9110, dengan pengecualian berikut:

• Kode HTTP 414 (URI Terlalu Panjang) tidak didukung untuk penyimpanan ke cache, guna menghindari keracunan cache.
• Kode HTTP 451 (Tidak Tersedia karena Alasan Hukum) didukung untuk penyimpanan cache, seperti yang dijelaskan dalam HTTP RFC 7725.

Jika perlu mengonfigurasi TTL per kode status sendiri, dan mengganti perilaku default, Anda dapat mengonfigurasi cdnPolicy.negativeCachingPolicy. Dengan demikian, Anda dapat menetapkan TTL untuk kode status yang diizinkan oleh Media CDN: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503, dan 504.

Misalnya, untuk menetapkan TTL singkat selama 5 detik untuk respons HTTP 404 (Not Found), dan TTL 10 detik untuk respons HTTP 405 (Method Not Allowed), gunakan definisi YAML berikut di setiap rute yang berlaku:

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

Untuk mencegah keracunan cache, sebaiknya jangan aktifkan caching untuk kode status 400 (Permintaan Buruk) atau 403 (Dilarang). Pastikan server asal Anda menampilkan salah satu kode sebagai hasil dari pemeriksaan hanya komponen permintaan yang disertakan dalam kunci cache. Keracunan cache dapat terjadi, misalnya, saat server asal merespons dengan respons error 403 tanpa header Authorization yang benar. Dalam hal ini, menyimpan respons error 403 dalam cache akan menyebabkan Media CDN menayangkan respons error 403 untuk semua permintaan berikutnya hingga TTL berakhir, meskipun permintaan memiliki header Authorization yang benar.

Untuk menonaktifkan caching negatif:

• Untuk menonaktifkan perilaku caching negatif default, tetapkan cdnPolicy.negativeCaching: false pada rute. Perhatikan bahwa respons server asal dengan perintah cache yang valid dan kode status yang dapat di-cache masih di-cache.
• Untuk mencegah caching negatif untuk kode status tertentu, tetapi tetap mematuhi petunjuk cache asal, hapus kode status (cdnPolicy.negativeCachingPolicy[].code) dalam definisi negativeCachingPolicy Anda.
• Untuk mengabaikan secara eksplisit perintah cache origin untuk kode status tertentu, tetapkan cdnPolicy.negativeCachingPolicy[].ttl ke 0 (nol) untuk kode status tersebut.

Catatan:

• Jika negativeCaching diaktifkan pada rute, dan respons menentukan perintah cache yang valid, perintah cache dalam respons akan diprioritaskan.
• Jika Anda mengonfigurasi negativeCachingPolicy eksplisit, dan ada TTL yang ditentukan untuk kode status tertentu, TTL yang ditentukan dalam kebijakan akan selalu digunakan.
• Nilai maksimum untuk TTL yang ditetapkan oleh negativeCachingPolicy adalah 1.800 detik (30 menit), tetapi direktif cache server asal dengan TTL yang lebih tinggi akan dipatuhi.
• Jika mode cache dikonfigurasi sebagai FORCE_CACHE_ALL, direktif server asal akan diabaikan dalam semua kasus.

Perintah kontrol cache

Perilaku Media CDN terkait direktif Cache-Control dijelaskan di sini.

Jika perintah tidak berlaku untuk permintaan atau respons, seperti only-if-cached (perintah khusus klien), maka "T/A" akan ditandai di kolom tersebut.

Jika memungkinkan, Media CDN akan mematuhi RFC (HTTP RFC 7234), tetapi lebih memilih mengoptimalkan pengurangan beban cache dan meminimalkan dampak yang dapat ditimbulkan klien terhadap rasio cache ditemukan dan beban server asal secara keseluruhan.

Untuk respons yang menggunakan header Expires HTTP/1.1:

• Nilai header Expires harus berupa HTTP-date yang valid seperti yang ditentukan dalam RFC 7231.
• Nilai tanggal di masa lalu, tanggal yang tidak valid, atau nilai 0 menunjukkan bahwa konten telah habis masa berlakunya dan memerlukan validasi ulang.
• Media CDN mengabaikan header Expires jika header Cache-Control ada dalam respons.

Header Pragma HTTP/1.0, jika ada dalam respons, akan diabaikan dan diteruskan apa adanya ke klien.

Kunci cache

Anda dapat mengurangi frekuensi Media CDN perlu menghubungi origin Anda dengan mempertimbangkan apa yang secara unik mengidentifikasi permintaan, dan menghapus komponen yang mungkin sering berubah di antara permintaan. Kumpulan komponen permintaan sering disebut sebagai 'kunci cache'.

Bagian berikut menjelaskan cara mengonfigurasi kunci cache.

Komponen kunci cache

Kunci cache adalah kumpulan parameter permintaan (seperti host, jalur, dan parameter kueri) yang dirujuk oleh objek yang di-cache.

Secara default, kunci cache untuk layanan Edge Cache mencakup host permintaan, jalur dan parameter kueri dari permintaan, serta dicakup ke EdgeCacheService tertentu.

Perhatikan hal berikut:

• Kunci cache tidak dilampirkan ke asal yang dikonfigurasi, sehingga Anda dapat memperbarui konfigurasi asal (atau mengganti asal sepenuhnya) tanpa risiko "mengosongkan" cache (misalnya, saat memigrasikan penyimpanan asal antar-penyedia).
• Kunci cache dibatasi ke EdgeCacheService. EdgeCacheService yang berbeda memiliki namespace cache yang berbeda, yang mencegah Anda secara tidak sengaja menyimpan objek dalam cache antara lingkungan produksi, staging, dan pengujian lainnya, meskipun host, jalur, atau komponen kunci cache lainnya cocok. Menghapus EdgeCacheService secara efektif akan menginvalidasi semua objek yang di-cache untuk layanan tersebut.
• Kunci cache tidak dicakup ke rute individual. Beberapa rute dapat merujuk ke kunci cache yang sama, terutama jika rute tersebut cocok dengan komponen yang tidak disertakan dalam kunci cache, seperti header permintaan atau parameter yang dikecualikan. Hal ini dapat berguna jika Anda ingin beberapa rute berbagi cache yang sama, tetapi menampilkan header respons atau konfigurasi CORS yang berbeda.
• Kunci cache tidak menyertakan konfigurasi penulisan ulang URL—misalnya, kunci cache didasarkan pada permintaan yang terlihat oleh pengguna, bukan permintaan "ditulis ulang" terakhir.
• Jika permintaan bertanda tangan dikonfigurasi pada rute, atribut bertanda tangan tidak disertakan dalam kunci cache. Permintaan diperlakukan seolah-olah parameter kueri atau komponen jalur (yang ditandatangani), yang dimulai dengan edge-cache-token dan berakhir di pemisah jalur berikutnya ("/"), bukan bagian dari URL.

Menyertakan atau mengecualikan parameter kueri

Anda dapat menyertakan atau mengecualikan parameter kueri tertentu dari kunci cache dengan menambahkan nama parameter ke konfigurasi kunci cache includedQueryParameters atau excludedQueryParameters pada rute tertentu.

Misalnya, untuk menyertakan parameter kueri contentID dan country serta mengabaikan semua parameter lainnya dari kunci cache: