Mengonfigurasi perilaku caching

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

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 Anda.

Kemampuan cache

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

Perilaku caching default

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

  • Mode cache default CACHE_ALL_STATIC:

    • Mematuhi perintah cache asal, seperti Cache-Control atau Expires, hingga TTL maksimum yang dapat dikonfigurasi.
    • Meng-cache jenis media statis secara otomatis dengan TTL default 3600, jika tidak ada perintah cache asal.
    • 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 cache dikonfigurasi secara eksplisit. Untuk mempelajari cara mengganti perilaku default, lihat dokumentasi tentang mode cache .

Perilaku default-nya sama dengan cdnPolicy berikut. Rute tanpa cdnPolicy yang dikonfigurasi secara eksplisit 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 disimpan dalam cache

Respons yang dapat di-cache adalah respons HTTP yang dapat disimpan dan diambil oleh Media CDN 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 disimpan dalam cache akan menggantikan kemampuan 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 salah satu dari 200, 203, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503.
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 menyimpan konten tersebut dalam cache, atau memiliki header Expires dengan tanggal di masa mendatang.
Ukuran respons Hingga 100 GiB.

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

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

Persyaratan origin

Agar Media CDN dapat menyimpan respons asal yang lebih besar dari 1 MiB dalam cache, origin harus menyertakan kode 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 hanya mendukung HTTP/1.1, Anda dapat menetapkan kolom protokol secara eksplisit untuk setiap origin.

Respons yang tidak dapat disimpan dalam cache

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

Atribut HTTP Persyaratan
Kode status

Kode status selain yang ditetapkan 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", ketika 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 di-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 dikonfigurasi, hanya respons yang dianggap konten statis atau respons dengan perintah cache yang valid di header responsnya yang akan di-cache. Respons lainnya diberi proxy sebagaimana adanya.
  • Mode cache FORCE_CACHE_ALL meng-cache semua respons tanpa syarat, sesuai dengan persyaratan tidak dapat disimpan dalam cache yang disebutkan sebelumnya.
  • Mode cache USE_ORIGIN_HEADERS memerlukan respons untuk menetapkan perintah cache yang valid di header responsnya selain kode status yang dapat di-cache.

Catatan:

  • Respons yang tidak di-cache tidak memiliki perintah kontrol cache atau header lainnya akan diubah dan diberi proxy sebagaimana adanya.
  • Respons dapat membuat header Cache-Control dan Expires 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 disimpan dalam cache (respons yang tidak akan pernah di-cache) tidak dihitung sebagai Cache Egress dari perspektif penagihan.

Menggunakan mode cache

Dengan mode cache, Anda dapat mengonfigurasi kapan Media CDN harus mematuhi perintah cache asal, meng-cache jenis media statis, dan meng-cache semua respons dari origin, terlepas dari perintah yang ditetapkan.

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

  • 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 yang ditentukan oleh origin sebagai respons yang dapat di-cache.
  • Anda dapat menambah atau mengurangi TTL cache yang diterapkan pada respons tanpa TTL cache yang ditetapkan secara eksplisit (perintah max-age atau s-maxage) dengan menetapkan kolom cdnPolicy.defaultTtl pada rute.
  • Untuk mencegah caching respons non-sukses lebih lama dari yang diinginkan, kode status non-2xx (tidak berhasil) tidak di-cache sesuai dengan Content-Type (jenis MIME) dan TTL default tidak akan 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 penyimpanan dalam cache yang valid. Untuk daftar lengkap persyaratan, lihat Respons yang dapat di-cache.
CACHE_ALL_STATIC

Secara otomatis menyimpan respons yang berhasil dalam cache dengan konten statis, kecuali jika respons tersebut memiliki perintah no-store atau private. Perintah penyimpanan data dalam cache yang valid dari origin akan diprioritaskan.

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

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

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

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

Sebaiknya gunakan opsi ini hanya untuk proses debug karena Media CDN dirancang sebagai infrastruktur cache berskala dunia dan bukan proxy tujuan umum.

Jenis MIME konten statis

Dengan mode cache CACHE_ALL_STATIC, Media CDN dapat secara otomatis meng-cache konten statis umum seperti video, audio, gambar, dan aset web umum berdasarkan jenis MIME yang ditampilkan dalam header respons HTTP Content-Type. Namun, apa pun jenis medianya, Media CDN akan memprioritaskan header Cache-Control atau Expires eksplisit dalam respons asal.

Tabel berikut mencantumkan jenis MIME yang dapat otomatis di-cache 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 Semua Jenis Konten yang cocok dengan font/*
Gambar Semua Jenis Konten yang cocok dengan image/*
Video Semua Jenis Konten yang cocok dengan video/*
Audio Semua Jenis Konten yang cocok dengan audio/*
Jenis dokumen terformat application/pdf and application/postscript

Perhatikan hal-hal berikut:

  • Software server web asal Anda harus menetapkan Content-Type untuk setiap respons. Banyak server web menetapkan header Content-Type secara otomatis, termasuk NGINX, Varnish, dan Apache.
  • Cloud Storage menetapkan header Content-Type secara otomatis saat diupload saat Anda menggunakan Konsol Google Cloud atau alat gsutil untuk mengupload konten.
  • Jika 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.

Mengonfigurasi TTL cache

Dengan penggantian time to live (TTL), Anda dapat 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 dengan penggantian maupun menggunakan perintah cache, bersifat optimis. Konten yang jarang diakses atau tidak populer mungkin akan dikeluarkan dari cache sebelum TTL tercapai.

Tabel berikut ini menampilkan 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 jika origin belum menentukan header max-age atau s-maxage.

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

Saat menggunakan FORCE_CACHE_ALL untuk meng-cache semua respons tanpa syarat, TTL default digunakan untuk menetapkan TTL cache. Semua nilai dan perintah lain 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 Tidak ditetapkan secara default. 0 detik 1 hari
(86.400 detik)		 Untuk respons yang dapat di-cache, TTL maksimum yang diizinkan dalam respons downstream (dihadap klien) jika harus 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 bergantung pada 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 maksimum.
  • Saat Media CDN mengganti nilai TTL 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 klien.

Cache negatif

Cache negatif menentukan bagaimana kode status HTTP yang gagal (selain 2xx) di-cache oleh Media CDN.

Dengan begitu, Anda dapat menyimpan respons error seperti pengalihan (HTTP 301 dan 308) dan respons tidak ditemukan (HTTP 404) lebih dekat ke pengguna, serta mengurangi beban asal secara lebih luas jika respons tersebut kemungkinan tidak berubah dan dapat di-cache.

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

Kode status Frasa alasan 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 caching negatif default cocok dengan kode status yang dapat di-cache secara heuristis seperti yang dijelaskan dalam HTTP RFC 9110, dengan pengecualian berikut:

  • Kode HTTP 414 (URI Terlalu Panjang) tidak didukung untuk penyimpanan 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. Dengan demikian, Anda dapat menetapkan TTL untuk setiap kode status yang diizinkan oleh Media CDN: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 504, dan 504.

Misalnya, untuk menetapkan TTL singkat 5 detik untuk respons HTTP 404 (Not Found), dan TTL 10 detik untuk respons HTTP 405 (Metode Tidak Diizinkan), gunakan definisi YAML berikut pada setiap rute yang berlaku:

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

Untuk mencegah cache poisoning, sebaiknya jangan aktifkan cache 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. Cache poisoning dapat terjadi, misalnya, saat server asal merespons dengan respons error 403 jika tidak ada header Authorization yang benar. Dalam hal ini, meng-cache respons error 403 akan menghasilkan Media CDN yang menayangkan respons error 403 untuk semua permintaan berikutnya hingga TTL habis masa berlakunya, meskipun permintaan tersebut memiliki header Authorization yang benar.

Untuk menonaktifkan caching negatif:

  • Untuk menonaktifkan perilaku caching negatif default, tetapkan cdnPolicy.negativeCaching: false pada rute. Perlu diperhatikan bahwa respons origin dengan perintah cache yang valid dan kode status yang dapat di-cache akan tetap di-cache.
  • Guna mencegah caching negatif untuk kode status tertentu, tetapi masih mematuhi perintah cache origin, hapus kode status (cdnPolicy.negativeCachingPolicy[].code) dalam definisi negativeCachingPolicy Anda.
  • Untuk mengabaikan perintah cache asal secara eksplisit 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 yang diberikan, TTL yang ditetapkan dalam kebijakan akan selalu digunakan.
  • Nilai maksimum untuk TTL yang ditetapkan oleh negativeCachingPolicy adalah 1800 detik (30 menit), tetapi perintah cache asal dengan TTL yang lebih tinggi akan dipatuhi.
  • Jika mode cache dikonfigurasi sebagai FORCE_CACHE_ALL, perintah asal akan diabaikan dalam semua kasus.

Perintah kontrol cache

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

Jika perintah tersebut 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 asal.

Respons dengan no-cache akan 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 atas 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 akan di-cache jika respons dianggap dapat di-cache secara keseluruhan dan respons juga memiliki perintah max-age atau s-maxage.

Hal ini tidak diperlukan saat menggunakan cache CACHE_ALL_STATIC atau mode FORCE_CACHE_ALL.
private T/A

Respons dengan perintah private tidak di-cache oleh Media CDN, meskipun respons 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 respons yang disimpan dalam cache.
max-age=SECONDS Perintah permintaan usia maksimum akan diabaikan. Respons yang di-cache akan ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. Respons dengan perintah max-age akan di-cache hingga SECONDS yang ditentukan.
s-maxage=SECONDS T/A

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

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

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

Perintah permintaan max-stale akan diabaikan.

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

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

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

Respons dengan proxy-revalidate divalidasi ulang dengan server asal setelah masa berlakunya habis.
immutable T/A Tidak berpengaruh. 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 akan ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A

Jika memungkinkan, Media CDN sesuai dengan RFC (HTTP RFC 7234), tetapi lebih memilih pengoptimalan untuk memindahkan cache dan meminimalkan dampak yang dapat ditimbulkan klien terhadap rasio hit dan pemuatan origin secara keseluruhan.

Untuk respons yang menggunakan header Expires HTTP/1.1:

  • Nilai header Expires harus berupa tanggal HTTP yang valid seperti yang ditetapkan dalam RFC 7231
  • Nilai tanggal di masa lalu, tanggal tidak valid, atau nilai 0 menunjukkan bahwa konten sudah tidak berlaku dan memerlukan validasi ulang.
  • Media CDN mengabaikan header Expires jika ada header Cache-Control 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 asal Anda dengan mempertimbangkan apa yang mengidentifikasi permintaan secara unik, dan menghapus komponen yang mungkin sering berubah di antara permintaan. Kumpulan komponen permintaan sering kali 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 direferensikan dengan objek yang di-cache.

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

Komponen Disertakan secara default? Detail
Protokol Tidak

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

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

Host yang berbeda tidak merujuk pada objek cache yang sama.

Jika Anda memiliki beberapa nama host yang diarahkan ke EdgeCacheService yang sama, dan menampilkan konten yang sama, tetapkan cdnPolicy.excludeHost ke true.
Jalur Ya Selalu disertakan di kunci cache dan tidak dapat dihapus. Jalurnya adalah representasi minimum dari suatu objek dalam cache.
Parameter kueri Ya

Jika parameter kueri tidak membedakan berbagai respons, tetapkan cacheKeyPolicy.excludeQueryString ke true.

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 agar memiliki rentang nilai yang besar (misalnya, nilai header gabungan mengidentifikasi satu pengguna) akan secara signifikan menurunkan tingkat kecocokan cache dan dapat menyebabkan tingkat penghapusan yang lebih tinggi serta performa yang lebih rendah.
Cookie Tidak

Setel 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 secara signifikan menurunkan tingkat kecocokan cache dan dapat menyebabkan tingkat penghapusan yang lebih tinggi serta performa yang lebih rendah.

Perhatikan hal-hal berikut:

  • Kunci cache tidak dikaitkan ke origin yang dikonfigurasi, sehingga Anda dapat mengupdate konfigurasi origin (atau mengganti origin sepenuhnya) tanpa risiko "membersihkan" cache (misalnya, saat memigrasikan penyimpanan origin antar-penyedia).
  • Kunci cache dibatasi pada EdgeCacheService. EdgeCacheServices yang berbeda memiliki namespace cache yang berbeda, yang mencegah Anda meng-cache objek secara tidak sengaja antara prod, staging, dan lingkungan 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 mencakup rute individual. Beberapa rute mungkin merujuk pada 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 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 dilihat pengguna, bukan permintaan akhir yang "ditulis ulang".
  • Saat permintaan yang ditandatangani dikonfigurasi pada rute, atribut yang ditandatangani tidak disertakan dalam kunci cache. Permintaan diperlakukan seolah-olah parameter kueri (bertanda tangan) atau komponen jalur, yang dimulai dengan edge-cache-token dan diakhiri 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:

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

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

Atau, daripada menentukan parameter yang akan disertakan dalam kunci cache, Anda dapat memilih parameter yang akan dikecualikan dari kunci cache. Misalnya, untuk mengecualikan ID pemutaran khusus klien dan informasi stempel waktu 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 yang ditandatangani diaktifkan di rute, parameter kueri yang digunakan untuk penandatanganan tidak akan disertakan dalam string kueri, dan akan diabaikan jika disertakan. Menyertakan parameter yang ditandatangani dalam kunci cache secara efektif membuat setiap permintaan pengguna menjadi unik, dan mengharuskan setiap permintaan disajikan dari origin.

Pengurutan parameter kueri

Parameter kueri (string kueri) diurutkan secara default untuk meningkatkan rasio cache ditemukan, 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 diperoleh. Hal ini memungkinkan kedua permintaan dipetakan ke objek dalam cache yang sama, sehingga menghindari permintaan yang tidak perlu ke (dan respons dari) tempat asal.

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

Sertakan header

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

Header berikut tidak dapat disertakan dalam kunci cache:

  • Header apa pun yang dimulai dengan access-control-
  • Header apa pun yang dimulai dengan sec-fetch-
  • Header apa pun yang dimulai dengan x-amz-
  • Header apa pun yang dimulai dengan x-goog-
  • Header apa pun yang dimulai 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.

Sertakan cookie

Nama cookie peka huruf besar/kecil.

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

Validasi ulang, penghapusan, dan masa berlaku

Jaringan penayangan konten (CDN), termasuk Media CDN, beroperasi dengan menyimpan konten yang paling populer ke dalam cache sedekat mungkin dengan pengguna.

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

  • Respons yang di-cache dan mencapai TTL yang dikonfigurasi mungkin tidak akan segera dikeluarkan. Untuk konten populer, Media CDN 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 asal dengan salah satu atau kedua header permintaan berikut: If-None-Match dan If-Modified-Since. Dalam hal ini, asal yang dikonfigurasi dengan benar akan menampilkan respons HTTP 304 (Tidak Diubah), tanpa byte isi, jika cache memiliki salinan respons tersebut "terbaru".
  • 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 tingkat penghapusan yang tinggi, sebaiknya pastikan Anda telah mengonfigurasi kunci cache untuk mengecualikan parameter yang tidak mengidentifikasi respons secara unik.

Pertimbangan lainnya

Pertimbangan berikut juga mungkin berlaku terkait caching.

Vary header

Header Vary menunjukkan bahwa respons bervariasi bergantung pada header permintaan klien. Jika header Vary ada dalam respons, Media CDN tidak akan meng-cache-nya, 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 menyediakan hash kamus yang tersedia untuk kompresi
  • Origin/X-Origin: biasanya digunakan untuk berbagi resource lintas origin
  • X-Goog-Allowed-Resources: mendukung pembatasan organisasi Google Cloud
  • Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: digunakan untuk mengambil header permintaan metadata

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

Media CDN menyimpan hingga 100 varian untuk kunci cache tertentu dan secara acak mengeluarkan varian dari cache di luar batas tersebut. Saat secara eksplisit membatalkan validasi cache untuk URL atau tag cache tertentu, semua varian menjadi tidak valid.

Abaikan cache

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

Jika Anda perlu menyajikan respons dinamis, seperti backend API, sebaiknya konfigurasi Load Balancer Aplikasi eksternal.

Sebaiknya batasi penggunaan metode ini untuk skenario proses debug, untuk menghindari pemuatan origin yang tidak disengaja. Traffic yang keluar saat mengabaikan cache dikenakan harga sesuai tarif keluar internet.

Pembatalan validasi cache

Lihat pembatalan validasi cache.

Permintaan dengan rentang byte

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

Selain itu, Media CDN juga menggunakan permintaan rentang untuk mengambil respons yang lebih besar dari asal. Cara ini memungkinkan Media CDN untuk menyimpan potongan ke dalam cache satu per satu, dan tidak mengharuskan seluruh objek diambil pada satu waktu untuk di-cache.

  • Objek yang lebih besar dari 1 MiB akan diambil sebagai permintaan rentang byte ("bagian") dengan ukuran maksimal 2 MiB.
  • Respons hingga 1 MiB dapat diambil tanpa dukungan untuk rentang byte di asal.
  • Respons yang lebih besar dari ini tidak akan ditampilkan 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 Parsial).
  • Header respons Content-Length atau Content-Range yang valid.
  • Validator respons (ETag atau Last-Modified).

Masing-masing permintaan pengisian origin untuk setiap "bagian" (rentang byte) dicatat dalam log sebagai entri log diskret dan dikaitkan dengan permintaan klien induk mereka. Anda dapat mengelompokkan permintaan ini dengan mencocokkan permintaan pada jsonPayload.cacheKeyFingerprint.

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

Permintaan rentang terbuka

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

Rentang byte terbuka biasanya digunakan oleh klien yang meminta segmen Low-Latensi dari Apple: karena setiap potongan CMAF ditulis ke kabel, CDN dapat menyimpan dalam cache dan mengirimkan potongan tersebut ke klien.

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

  #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 durasi tunggu Media CDN di antara pembacaan dengan menggunakan nilai konfigurasi EdgeCacheOrigin.timeouts.readTimeout. Batas ini biasanya harus dikonfigurasi ke beberapa (misalnya, 2x) dari durasi target Anda.

Langkah selanjutnya