Mengonfigurasi perilaku caching

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

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

Kemampuan untuk di-cache

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

Perilaku caching default

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

  • Mode cache default CACHE_ALL_STATIC:

    • Mengikuti perintah cache origin, seperti Cache-Control atau Expires, hingga TTL maksimum yang dapat dikonfigurasi.
    • Menyimpan jenis media statis secara otomatis dengan TTL default 3600 detik, jika tidak ada perintah cache origin.
    • Menyimpan kode status HTTP 200 dan 206 dalam cache (caching negatif tidak diaktifkan).

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

Respons yang bukan konten statis atau yang tidak memiliki perintah cache yang valid tidak akan di-cache kecuali jika penyimpanan dalam cache 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 akan 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 Media CDN dan diambil dengan cepat, 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 origin tidak menetapkan perintah kontrol cache dalam respons.

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

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

Atribut HTTP Persyaratan
Kode status Kode status respons harus berupa salah satu dari 200, 203, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503, atau 504.
Metode HTTP GET dan HEAD
Header permintaan Sebagian besar perintah permintaan penyimpanan dalam cache diabaikan. Untuk informasi selengkapnya, lihat Perintah kontrol cache.
Header respons

Berisi perintah cache HTTP yang valid seperti Cache-Control: max-age=3600, public.

Memiliki mode cache yang meng-cache konten tersebut, atau memiliki header Expires dengan tanggal di masa mendatang.
Ukuran respons Hingga 100 GiB.

Header Age HTTP ditetapkan berdasarkan waktu Media CDN pertama kali meng-cache respons, dan biasanya mewakili detik sejak objek di-cache di lokasi pelindung origin. Jika origin 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 cache HTTP, 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 HEAD dan GET, kecuali jika ditentukan lain:

  • Header respons HTTP Last-Modified atau ETag (validator).
  • Header Date HTTP 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.

Atribut HTTP Persyaratan
Kode status

Kode status selain yang ditentukan sebagai dapat di-cache, seperti HTTP 401, HTTP 412, atau HTTP 505.

Kode status ini biasanya mewakili masalah yang dihadapi klien, bukan status asal. Menyimpan respons tersebut dalam cache dapat menyebabkan skenario "cache poisoning" saat respons "buruk" yang dipicu pengguna di-cache untuk semua pengguna.
Header permintaan

Untuk permintaan dengan header permintaan Authorization, respons harus menyertakan perintah Cache-Control public agar di-cache.

Perintah no-store dalam permintaan menyebabkan respons tidak disimpan dalam cache. Untuk informasi selengkapnya, lihat Perintah kontrol cache.
Header respons

Memiliki header Set-Cookie.

Memiliki header Vary selain Accept, Accept-Encoding, Origin, X-Origin, X-Goog-Allowed-Resources, Sec-Fetch-Dest, Sec-Fetch-Mode, atau Sec-Fetch-Site.

Dalam mode CACHE_ALL_STATIC atau USE_ORIGIN_HEADERS, memiliki perintah kontrol cache no-store atau private.
Ukuran respons Lebih dari 100 GiB.

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 perintah cache yang valid di header responsnya yang di-cache. Respons lainnya akan di-proxy apa adanya.
  • Mode cache FORCE_CACHE_ALL meng-cache semua respons tanpa syarat, tunduk pada persyaratan yang tidak dapat di-cache yang dinyatakan sebelumnya.
  • Mode cache USE_ORIGIN_HEADERS mengharuskan respons untuk menetapkan arahan cache yang valid di header responsnya, selain kode status yang dapat di-cache.

Catatan:

  • Respons yang tidak di-cache tidak akan mengubah arahan kontrol cache atau header lainnya dan akan di-proxy apa adanya.
  • Header Cache-Control dan Expires respons dapat diciutkan ke dalam 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 origin, meng-cache jenis media statis, dan meng-cache semua respons dari origin, terlepas dari perintah yang ditetapkan.

Mode cache dikonfigurasi di tingkat rute dan, jika digabungkan dengan penggantian TTL, Anda dapat mengonfigurasi perilaku cache menurut host, jalur, parameter kueri, dan header (parameter permintaan apa pun yang cocok).

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

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

Mode cache Perilaku
USE_ORIGIN_HEADERS Memerlukan respons origin untuk menetapkan perintah cache yang valid dan header cache yang valid. Untuk mengetahui daftar lengkap persyaratan, lihat Respons yang dapat di-cache.
CACHE_ALL_STATIC

Otomatis meng-cache respons yang berhasil dengan konten statis, kecuali jika memiliki perintah no-store atau private. Perintah penyimpanan dalam cache yang valid dari origin diprioritaskan.

Konten statis mencakup video, audio, gambar, dan aset web umum seperti yang ditentukan oleh jenis MIME di header respons Content-Type.
FORCE_CACHE_ALL

Menyimpan respons yang berhasil ke dalam cache tanpa syarat, yang akan menggantikan perintah cache apa pun yang ditetapkan oleh origin.

Pastikan untuk tidak menayangkan konten pribadi per pengguna (seperti respons HTML atau API dinamis) dengan mode ini dikonfigurasi.
BYPASS_CACHE

Setiap permintaan yang cocok dengan rute dengan mode cache ini yang dikonfigurasi akan mengabaikan cache, meskipun ada objek yang di-cache yang cocok dengan kunci cache tersebut.

Sebaiknya gunakan ini hanya untuk proses debug karena Media CDN dirancang sebagai infrastruktur cache skala planet, bukan proxy tujuan umum.

Jenis MIME konten statis

Mode cache CACHE_ALL_STATIC memungkinkan Media CDN otomatis menyimpan konten statis umum dalam cache 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 akan memprioritaskan header Cache-Control atau Expires eksplisit dalam respons asal.

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

Respons tidak otomatis di-cache 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.

Kategori Jenis MIME
Aset web text/css text/ecmascript text/javascript application/javascript
Font Content-Type apa pun yang cocok dengan font/*
Gambar Content-Type apa pun yang cocok dengan image/*
Video Content-Type apa pun yang cocok dengan video/*
Audio Content-Type apa pun yang cocok dengan audio/*
Jenis dokumen berformat application/pdf and application/postscript

Perhatikan hal berikut:

  • Software server web origin Anda harus menetapkan Content-Type untuk setiap respons. Banyak server web yang otomatis menetapkan header Content-Type, termasuk NGINX, Varnish, dan Apache.
  • Cloud Storage menetapkan header Content-Type secara otomatis saat diupload saat Anda menggunakan konsol Google Cloud atau gcloud CLI untuk mengupload konten.
  • Cloud Storage 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 disimpan dalam 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 respons dapat di-cache berdasarkan jenis MIME-nya, tetapi memiliki direktif 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 dinamis (per pengguna), dan juga tidak cocok untuk arsitektur Media CDN. Sebaiknya gunakan Cloud CDN untuk menayangkan aset web dan meng-cache respons API.

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 perintah kontrol cache max-age dan s-maxage (atau header Expires) yang ditetapkan oleh origin Anda.

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

Tabel berikut menunjukkan tiga setelan TTL.

Setelan Default Minimum Maksimum Deskripsi Mode cache yang berlaku
Default TTL 1 jam
(3.600 detik)		 0 detik 1 tahun
(31.536.000 detik)

TTL yang akan ditetapkan saat origin belum menentukan header max-age atau s-maxage.

Jika origin menentukan header s-maxage, header tersebut akan digunakan, bukan nilai TTL default di sini.

Saat menggunakan FORCE_CACHE_ALL untuk meng-cache semua respons tanpa syarat, TTL default akan digunakan untuk menetapkan TTL cache. Semua nilai dan perintah lainnya akan diabaikan.

CACHE_ALL_STATIC

FORCE_CACHE_ALL
Max TTL 1 hari
(86.400 detik)		 0 detik 1 tahun
(31.536.000 detik)		 Untuk respons yang dapat di-cache, TTL maksimum yang diizinkan. Nilai yang lebih besar dari ini dibatasi pada nilai maxTtl. CACHE_ALL_STATIC
Client TTL Secara default tidak ditetapkan. 0 detik 1 hari
(86.400 detik)		 Untuk respons yang dapat di-cache, TTL maksimum yang diizinkan dalam respons downstream (yang ditampilkan klien) jika perlu berbeda dengan nilai TTL lainnya.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

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

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

Catatan:

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

Caching negatif

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

Hal ini memungkinkan Anda meng-cache respons error seperti pengalihan (HTTP 301 dan 308) dan respons tidak ditemukan (HTTP 404) yang 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 penyimpanan dalam cache negatif diaktifkan dan negativeCachingPolicy tidak digunakan.

Kode status Reason-phrase TTL
HTTP 300 Multiple Choices 10 menit
HTTP 301 dan HTTP 308 Permanent Redirect 10 menit
HTTP 404 Tidak Ditemukan 120 detik
HTTP 405 Metode Tidak Ditemukan 60 detik
HTTP 410 Gone 120 detik
HTTP 451 Tidak Tersedia karena Alasan Hukum 120 detik
HTTP 501 Not Implemented 60 detik

Kumpulan kode penyimpanan dalam cache negatif default 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 dalam cache, seperti yang dijelaskan dalam HTTP RFC 7725.

Jika perlu mengonfigurasi TTL kode per status Anda sendiri, dan mengganti perilaku default, Anda dapat mengonfigurasi cdnPolicy.negativeCachingPolicy. Hal ini memungkinkan Anda menetapkan TTL untuk kode status apa pun 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 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 penyimpanan dalam cache untuk kode status 400 (Permintaan Tidak Valid) atau 403 (Dilarang). Pastikan server origin Anda menampilkan salah satu kode sebagai hasil dari pemeriksaan komponen permintaan saja yang disertakan dalam kunci cache. Keracunan cache dapat terjadi, misalnya, saat server origin merespons dengan respons error 403 tanpa header Authorization yang benar. Dalam hal ini, meng-cache respons error 403 akan menyebabkan Media CDN menayangkan respons error 403 ke 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 di rute. Perhatikan bahwa respons origin 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 perintah cache origin, hapus kode status (cdnPolicy.negativeCachingPolicy[].code) dalam definisi negativeCachingPolicy Anda.
  • Untuk secara eksplisit mengabaikan perintah cache origin untuk kode status tertentu, tetapkan cdnPolicy.negativeCachingPolicy[].ttl ke 0 (nol) untuk kode status tersebut.

Catatan:

  • Jika negativeCaching diaktifkan di 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 perintah cache origin dengan TTL yang lebih tinggi akan dipatuhi.
  • Jika mode cache dikonfigurasi sebagai FORCE_CACHE_ALL, perintah origin akan diabaikan dalam semua kasus.

Perintah kontrol cache

Perilaku CDN Media sehubungan dengan perintah Cache-Control ditentukan di sini.

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

Perintah Permintaan Respons
no-cache Perintah permintaan no-cache diabaikan untuk mencegah klien berpotensi memulai atau memaksa validasi ulang ke origin.

Respons dengan no-cache di-cache, tetapi memerlukan validasi dengan origin sebelum dapat ditayangkan.

Hal ini dapat diganti per rute dengan mode cache FORCE_CACHE_ALL.
no-store Respons terhadap permintaan dengan no-store tidak di-cache.

Respons dengan no-store tidak di-cache.

Hal ini dapat diganti per rute dengan mode cache FORCE_CACHE_ALL.
public T/A

Respons dengan perintah public di-cache jika respons dianggap dapat di-cache secara keseluruhan dan respons tersebut juga memiliki perintah max-age atau s-maxage.

Saat menggunakan cache CACHE_ALL_STATIC atau mode FORCE_CACHE_ALL, hal ini tidak diperlukan.
private T/A

Respons dengan perintah private tidak di-cache oleh Media CDN, meskipun respons tersebut dianggap dapat di-cache. Klien (seperti browser) mungkin masih menyimpan hasil dalam cache.

Hal ini dapat diganti per rute dengan mode cache FORCE_CACHE_ALL.

Gunakan no-store untuk mencegah semua penyimpanan ke cache respons.
max-age=SECONDS Perintah permintaan max-age diabaikan. Respons yang di-cache akan ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. Respons dengan perintah max-age di-cache hingga SECONDS yang ditentukan.
s-maxage=SECONDS T/A

Respons dengan perintah s-maxage di-cache hingga SECONDS yang ditentukan.

Jika max-age dan s-maxage ada, s-maxage akan digunakan oleh server.

Perhatikan bahwa s-max-age (dua tanda hubung) tidak valid untuk tujuan penyimpanan dalam cache.
min-fresh=SECONDS Perintah permintaan min-fresh akan diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A
max-stale=SECONDS

Perintah permintaan max-stale akan diabaikan.

Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan.

 T/A
stale-while-revalidate=SECONDS T/A Tidak ada efek. Nilai ini diteruskan ke klien dalam respons.
stale-if-error=SECONDS Perintah permintaan stale-if-error akan diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. Tidak ada efek. Nilai ini diteruskan ke klien dalam respons.
must-revalidate T/A

Respons dengan must-revalidate divalidasi ulang dengan server asal setelah masa berlakunya habis.
proxy-revalidate T/A

Respons dengan proxy-revalidate divalidasi ulang dengan server origin setelah masa berlakunya habis.
immutable T/A Tidak ada efek. Nilai ini diteruskan ke klien dalam respons.
no-transform T/A Tidak ada transformasi yang diterapkan oleh Media CDN.
only-if-cached Perintah permintaan only-if-cached akan diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A

Jika memungkinkan, Media CDN mematuhi RFC (HTTP RFC 7234), tetapi lebih memilih mengoptimalkan offload cache dan meminimalkan dampak yang dapat ditimbulkan klien terhadap rasio hit dan beban origin secara keseluruhan.

Untuk respons yang menggunakan header Expires HTTP/1.1:

  • Nilai header Expires harus berupa tanggal HTTP 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.
  • CDN Media mengabaikan header Expires jika header Cache-Control ada dalam respons.

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

Kunci cache

Anda dapat mengurangi frekuensi Media CDN perlu menghubungi origin 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 parameter host, jalur, dan kueri) yang digunakan untuk mereferensikan objek yang di-cache.

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

Komponen Disertakan secara default? Detail
Protokol Tidak

Permintaan melalui HTTP dan HTTPS mereferensikan objek yang di-cache yang sama.

Jika Anda ingin menampilkan respons yang berbeda untuk permintaan http: dan https:, tetapkan cacheKeyPolicy.includeProtocol ke benar di rute terkait.
Host Ya

Host yang berbeda tidak mereferensikan objek yang di-cache yang sama.

Jika Anda memiliki beberapa nama host yang diarahkan ke EdgeCacheService yang sama, dan nama host tersebut menayangkan konten yang sama, tetapkan cdnPolicy.excludeHost ke benar.
Jalur Ya Selalu disertakan dalam kunci cache dan tidak dapat dihapus. Jalur adalah representasi minimum objek dalam cache.
Parameter kueri Ya

Jika parameter kueri tidak membedakan antara respons yang berbeda, tetapkan cacheKeyPolicy.excludeQueryString ke benar.

Jika hanya beberapa parameter kueri yang harus disertakan dalam kunci cache, tetapkan includedQueryParameters atau excludedQueryParameters, sebagaimana mestinya.
Header Tidak

Tetapkan cacheKeyPolicy.includedHeaderNames dengan nama header yang akan disertakan dalam kunci cache.

Menentukan beberapa header yang digabungkan untuk memiliki rentang nilai yang besar (misalnya, nilai header gabungan mengidentifikasi satu pengguna) secara drastis menurunkan rasio hit cache dan dapat mengakibatkan rasio penghapusan yang lebih tinggi serta performa yang menurun.
Cookie Tidak

Tetapkan cacheKeyPolicy.includedCookieNames dengan nama cookie yang akan disertakan dalam kunci cache.

Menentukan beberapa cookie yang digabungkan untuk memiliki rentang nilai yang besar (misalnya, nilai cookie gabungan mengidentifikasi satu pengguna) akan menurunkan rasio hit cache secara drastis dan dapat mengakibatkan rasio penghapusan yang lebih tinggi serta performa yang menurun.

Perhatikan hal berikut:

  • Kunci cache tidak dilampirkan ke origin yang dikonfigurasi, sehingga Anda dapat memperbarui konfigurasi origin (atau mengganti origin sepenuhnya) tanpa risiko "menghapus" cache (misalnya, saat memigrasikan penyimpanan origin antar-penyedia).
  • Kunci cache dibatasi untuk EdgeCacheService. EdgeCacheServices yang berbeda memiliki namespace cache yang berbeda, yang mencegah Anda menyimpan cache objek secara tidak sengaja di antara lingkungan produksi, staging, dan pengujian lainnya, meskipun host, jalur, atau komponen kunci cache lainnya akan cocok. Menghapus EdgeCacheService secara efektif akan membatalkan semua objek yang di-cache untuk layanan tersebut.
  • Kunci cache tidak dicakup untuk setiap rute. Beberapa rute mungkin merujuk ke kunci cache yang sama, terutama jika rute tersebut cocok pada 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 ditampilkan kepada pengguna, bukan permintaan "ditulis ulang" akhir.
  • Saat permintaan yang ditandatangani dikonfigurasi di rute, atribut yang ditandatangani tidak disertakan dalam kunci cache. Permintaan diperlakukan seolah-olah parameter kueri (ditandatangani) atau komponen jalur, 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 di rute tertentu.

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

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

Pastikan untuk menyertakan parameter kueri yang mengidentifikasi konten secara unik, dan mengecualikan parameter yang tidak. Misalnya, kecualikan parameter kueri analisis, ID sesi pemutaran, atau parameter lainnya yang hanya unik untuk klien. Menyertakan lebih banyak parameter kueri daripada yang diperlukan dapat menurunkan rasio hit cache.

Atau, Anda dapat memilih parameter yang akan dikecualikan dari kunci cache, bukan menentukan parameter yang akan disertakan dalam kunci cache. Misalnya, untuk mengecualikan informasi ID pemutaran dan stempel waktu khusus klien dari kunci cache, konfigurasikan hal berikut:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

Untuk rute tertentu, Anda dapat menentukan salah satu dari includedQueryParameters atau excludedQueryParameters.

Jika parameter kueri tidak pernah digunakan untuk mengidentifikasi konten secara unik di seluruh permintaan, Anda dapat menghapus semua parameter kueri dari kunci cache untuk rute. Lakukan hal ini dengan menetapkan excludeQueryString ke true, seperti berikut:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

Jika Permintaan bertanda tangan diaktifkan di rute, parameter kueri yang digunakan untuk penandatanganan tidak disertakan dalam string kueri, dan akan diabaikan jika disertakan. Menyertakan parameter yang ditandatangani dalam kunci cache secara efektif membuat setiap permintaan pengguna unik, dan mengharuskan setiap permintaan dilayani dari origin.

Pengurutan parameter kueri

Parameter kueri (string kueri) diurutkan secara default untuk meningkatkan rasio hit cache, karena klien mungkin mengurutkan ulang atau meminta objek yang sama yang di-cache dengan urutan parameter kueri yang berbeda.

Misalnya, parameter kueri b=world&a=hello&z=zulu&p=paris dan p=paris&a=hello&z=zulu&b=world diurutkan sebagai a=hello&b=world&p=paris&z=zulu sebelum kunci cache diturunkan. Hal ini memungkinkan kedua permintaan dipetakan ke objek yang sama yang di-cache, sehingga menghindari permintaan yang tidak perlu ke (dan respons dari) origin.

Jika ada beberapa instance kunci parameter kueri, masing-masing dengan nilai yang berbeda, parameter akan diurutkan berdasarkan nilai lengkapnya (misalnya, a=hello diurutkan sebelum a=world). Pengurutan tidak dapat dinonaktifkan.

Menyertakan header

Nama header tidak peka huruf besar/kecil dan dikonversi menjadi huruf kecil oleh Media CDN.

Header berikut tidak dapat disertakan dalam kunci cache:

  • Header apa pun yang diawali dengan access-control-
  • Header apa pun yang diawali dengan sec-fetch-
  • Header apa pun yang diawali dengan x-amz-
  • Header apa pun yang diawali dengan x-goog-
  • Header apa pun yang diawali dengan x-media-cdn-
  • accept-encoding
  • accept
  • authorization
  • cdn-loop
  • connection
  • content-md5
  • content-type
  • cookie
  • date
  • forwarded
  • from
  • host
  • if-match
  • if-modified-since
  • if-none-match
  • origin
  • proxy-authorization
  • range
  • referer
  • referrer
  • user-agent
  • want-digest
  • x-csrf-token
  • x-csrftoken
  • x-forwarded-for

Untuk menyertakan metode HTTP dalam kunci cache, gunakan nama header khusus :method.

Menyertakan cookie

Nama cookie peka huruf besar/kecil.

Cookie yang dimulai dengan edge-cache- dalam variasi huruf besar atau huruf kecil tidak dapat digunakan dalam kunci cache.

Validasi ulang, pengusiran, dan habis masa berlaku

Jaringan penayangan konten, termasuk Media CDN, beroperasi dengan meng-cache konten yang paling populer sedekat mungkin dengan pengguna.

Penyimpanan Media CDN yang luas, serta perlindungan origin, membatasi kebutuhan untuk menghapus konten yang tidak populer sekalipun. Konten yang diakses beberapa kali per hari pada akhirnya mungkin akan dihapus.

  • Respons yang di-cache yang mencapai TTL yang dikonfigurasi mungkin tidak langsung dikeluarkan. Untuk konten populer, Media CDN akan memvalidasi ulang bahwa respons yang di-cache adalah versi terbaru dengan mengeluarkan permintaan HEAD ke origin untuk mengonfirmasi bahwa header tidak berubah. Dalam beberapa situasi, Media CDN akan mengirim permintaan ke origin dengan salah satu atau kedua header permintaan ini: If-None-Match dan If-Modified-Since. Dalam hal ini, origin yang dikonfigurasi dengan benar akan menampilkan respons HTTP 304 (Tidak Diubah), tanpa byte isi, jika cache memiliki salinan "terbaru" respons tersebut.
  • Respons yang menetapkan perintah cache max-age atau s-maxage atau yang menggunakan penggantian TTL untuk menentukan nilai TTL yang tinggi (misalnya, 30 hari) mungkin tidak disimpan dalam cache untuk TTL penuh. Tidak ada jaminan bahwa objek disimpan dalam cache selama durasi penuh, terutama jika jarang diakses.

Jika Anda melihat rasio penghapusan yang tinggi, Anda harus memastikan bahwa Anda telah mengonfigurasi kunci cache untuk mengecualikan parameter yang tidak mengidentifikasi respons secara unik.

Pertimbangan lainnya

Pertimbangan berikut mungkin juga berlaku sehubungan dengan penyimpanan dalam cache.

Header Vary

Header Vary menunjukkan bahwa respons bervariasi bergantung pada header permintaan klien. Jika header Vary ada dalam respons, Media CDN tidak akan menyimpannya dalam cache, kecuali jika header menentukan salah satu header yang dikonfigurasi sebagai setelan kunci cache atau salah satu nilai berikut:

  • Accept: digunakan untuk menunjukkan jenis media yang diterima klien
  • Accept-Encoding: digunakan untuk menunjukkan jenis kompresi yang diterima klien
  • Available-Dictionary: digunakan untuk memberikan hash kamus yang tersedia untuk kompresi
  • Origin/X-Origin: biasanya digunakan untuk cross-origin resource sharing
  • X-Goog-Allowed-Resources: mendukung batasan organisasi Google Cloud
  • Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: digunakan untuk mengambil header permintaan metadata

Media CDN menyimpan respons dalam cache dengan header Vary dalam respons dengan menggunakan nilai header sebagai bagian dari kunci cache. Jika header Vary dalam respons memiliki beberapa nilai, header tersebut akan diurutkan secara leksikografis untuk memastikan bahwa kunci cache bersifat deterministik.

Media CDN meng-cache hingga 100 varian untuk kunci cache tertentu dan secara acak menghapus varian dari cache di luar batas tersebut. Saat cache untuk URL atau tag cache tertentu secara eksplisit dinonaktifkan, semua varian akan dinonaktifkan.

Mengabaikan cache

Anda dapat mengonfigurasi mode cache BYPASS_CACHE di rute untuk sengaja mengabaikan cache pada permintaan yang cocok. Hal ini dapat berguna jika Anda perlu mengabaikan cache untuk sebagian kecil traffic non-kritis, atau men-debug konektivitas origin.

Jika Anda perlu menayangkan respons dinamis, seperti backend API, sebaiknya konfigurasikan Load Balancer Aplikasi eksternal.

Sebaiknya Anda membatasi penggunaan ini untuk skenario proses debug, untuk menghindari pemuatan origin yang tidak disengaja. Traffic yang keluar saat mengabaikan cache harganya sesuai dengan tarif traffic keluar internet.

Pembatalan validasi cache

Lihat pembatalan cache.

Permintaan rentang byte

Media CDN mendukung permintaan rentang HTTP satu bagian seperti yang ditentukan dalam RFC 7233.

Selain itu, Media CDN juga menggunakan permintaan rentang untuk mengambil respons yang lebih besar dari origin. Hal ini memungkinkan Media CDN menyimpan cache potongan satu per satu, dan tidak mengharuskan seluruh objek diambil sekaligus untuk disimpan dalam cache.

  • Objek yang lebih besar dari 1 MiB diambil sebagai permintaan rentang byte ("potongan") yang masing-masing berukuran hingga 2 MiB.
  • Respons hingga 1 MiB dapat diambil tanpa dukungan untuk rentang byte di origin.
  • Respons yang lebih besar dari ini tidak ditayangkan jika rentang byte tidak didukung di asal.

Dukungan origin untuk permintaan rentang byte ditentukan oleh hal berikut:

  • Kode status HTTP 200 (OK) atau 206 (Konten Sebagian).
  • Header respons Content-Length atau Content-Range yang valid.
  • Validator respons (ETag atau Last-Modified).

Setiap permintaan pengisian asal untuk setiap "chunk" (rentang byte) dicatat ke dalam log sebagai entri log terpisah dan dikaitkan dengan permintaan klien induknya. Anda dapat mengelompokkan permintaan ini dengan mencocokkan permintaan di jsonPayload.cacheKeyFingerprint.

Untuk mengetahui detail selengkapnya tentang apa yang dicatat ke dalam log, lihat dokumentasi Cloud Logging.

Permintaan rentang terbuka

Media CDN mendukung permintaan Range "terbuka" (misalnya, permintaan dengan Range: bytes=0-) yang membuat permintaan tetap terbuka terhadap origin hingga respons ditutup oleh origin (misalnya, origin menulis semua byte ke kabel) atau waktu tunggu habis.

Rentang byte terbuka biasanya digunakan oleh klien yang meminta segmen HLS Latency Rendah Apple: saat setiap bagian CMAF ditulis ke kabel, CDN dapat meng-cache dan mengirimkan bagian tersebut ke klien.

Dalam kasus lain, seperti saat interoperabilitas dengan DASH tidak diperlukan, playlist media akan menunjukkan kepada pemutar byte mana yang mewakili setiap bagian:

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

Anda dapat mengonfigurasi berapa lama Media CDN menunggu di antara pembacaan menggunakan nilai konfigurasi EdgeCacheOrigin.timeouts.readTimeout. Hal ini biasanya dikonfigurasi ke kelipatan (misalnya, 2x) durasi target Anda.

Langkah selanjutnya