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 origin, seperti Cache-Control atau Expires, hingga TTL maksimum yang dapat dikonfigurasi.
  • Mencadangkan jenis media statis secara otomatis dengan TTL default 3.600 detik, jika tidak ada direktif cache asal.
  • Meng-cache kode status HTTP 200, 204, dan 206 (peng-cache-an negatif tidak diaktifkan).

• Tidak menyimpan dalam 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 direktif cache yang valid tidak 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 yang dikonfigurasi secara eksplisit 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 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 menyimpan jenis media umum dalam cache) meskipun origin tidak menyetel direktif 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 menyimpan respons HTTP tertentu dalam cache. Respons GET dan HEAD harus mematuhi persyaratan ini.

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

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

Persyaratan asal

Untuk mengizinkan Media CDN menyimpan 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 asal 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 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 petunjuk cache yang valid di header responsnya yang di-cache. Respons lainnya di-proxy apa adanya.
• Mode cache FORCE_CACHE_ALL menyimpan semua respons tanpa syarat, tunduk pada persyaratan tidak dapat di-cache yang dinyatakan sebelumnya.
• Mode cache USE_ORIGIN_HEADERS mengharuskan respons untuk menetapkan arahan cache yang valid di header responsnya selain menjadi kode status yang dapat di-cache.

Catatan:

• Respons yang tidak di-cache tidak mengubah arahan 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 direktif cache asal, menyimpan jenis media statis dalam cache, dan menyimpan semua respons dari asal dalam cache, terlepas dari direktif 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_ALL_STATICcache, yang secara otomatis meng-cache jenis media statis umum selama 1 jam (3.600 detik), sekaligus memprioritaskan direktif cache yang ditentukan oleh origin untuk respons yang dapat di-cache.
• Anda dapat menambah atau mengurangi TTL cache yang diterapkan pada respons tanpa TTL cache eksplisit yang ditetapkan (direktif max-age atau s-maxage) dengan menetapkan kolom cdnPolicy.defaultTtl pada rute.
• Untuk mencegah respons yang tidak berhasil di-cache lebih lama dari yang dimaksudkan, 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 dalam cache 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 asal.

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 direktif 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 otomatis menetapkan header Content-Type, termasuk NGINX, Varnish, dan Apache.
• Cloud Storage menetapkan header Content-Type secara otomatis saat upload ketika 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 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 menggantikan nilai yang dikirim oleh Cloud Storage.

Jika respons dapat di-cache berdasarkan jenis MIME-nya, tetapi memiliki arah respons Cache-Control private atau no-store atau header Set-Cookie, respons tersebut tidak 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 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 origin 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 origin 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 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

Penyimpanan dalam cache 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 caching negatif diaktifkan dan negativeCachingPolicy tidak digunakan.

Set default kode penyimpanan cache 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, untuk 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 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 mengaktifkan penyimpanan dalam cache untuk kode status 400 (Permintaan Buruk) atau 403 (Dilarang). Pastikan server asal Anda menampilkan salah satu kode sebagai hasil pemeriksaan hanya pada komponen permintaan yang disertakan dalam kunci cache. Keracunan cache dapat terjadi, misalnya, saat server asal merespons dengan respons error 403 tanpa adanya header Authorization yang benar. Dalam hal ini, meng-cache respons error 403 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 origin dengan direktif 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 secara eksplisit mengabaikan direktif cache asal untuk kode status tertentu, tetapkan cdnPolicy.negativeCachingPolicy[].ttl ke 0 (nol) untuk kode status tersebut.

Catatan:

• Jika negativeCaching diaktifkan pada rute, dan respons menentukan petunjuk cache yang valid, petunjuk 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 asal dengan TTL yang lebih tinggi akan dipatuhi.
• Jika mode cache dikonfigurasi sebagai FORCE_CACHE_ALL, direktif origin diabaikan dalam semua kasus.

Petunjuk kontrol cache

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

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

Jika memungkinkan, Media CDN mematuhi RFC (HTTP RFC 7234), tetapi lebih memilih mengoptimalkan pengalihan 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 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 kedaluwarsa 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 membatalkan 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" akhir.
• Jika permintaan bertanda tangan dikonfigurasi pada rute, atribut bertanda tangan tidak disertakan dalam kunci cache. Permintaan diperlakukan seolah-olah parameter kueri (bertanda tangan) 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 secara unik mengidentifikasi konten, dan mengecualikan parameter yang tidak mengidentifikasi konten secara unik. Misalnya, kecualikan parameter kueri analytics, ID sesi pemutaran, atau parameter lain yang hanya unik untuk klien. Menyertakan lebih banyak parameter kueri daripada yang diperlukan dapat menurunkan rasio hit cache.

Atau, alih-alih menentukan parameter yang akan disertakan dalam kunci cache, Anda dapat memilih parameter yang akan dikecualikan dari kunci cache. Misalnya, untuk mengecualikan informasi stempel waktu dan ID pemutaran 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 ini dengan menyetel 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 diabaikan jika disertakan. Dengan menyertakan parameter bertanda tangan dalam kunci cache, setiap permintaan pengguna akan menjadi unik dan setiap permintaan harus ditayangkan dari origin.

Pengurutan parameter kueri

Parameter kueri (string kueri) diurutkan secara default untuk meningkatkan rasio cache ditemukan, karena klien dapat 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. Dengan demikian, kedua permintaan dapat dipetakan ke objek yang di-cache yang sama, 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 diurutkan berdasarkan nilai lengkapnya (misalnya, a=hello diurutkan sebelum a=world). Pengurutan tidak dapat dinonaktifkan.

Sertakan 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 dimulai dengan access-control-
• Header apa pun yang dimulai dengan sec-fetch-
• accept-encoding
• accept
• authorization
• 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 dalam kunci cache.

Validasi ulang, pengusiran, dan masa berlaku

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

Penyimpanan Media CDN yang luas, serta perlindungan origin, membatasi kebutuhan untuk mengeluarkan konten yang tidak populer sekalipun. Konten yang diakses beberapa kali per hari pada akhirnya dapat dikeluarkan.

• Respons yang di-cache yang mencapai TTL yang dikonfigurasi mungkin tidak langsung 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.
• Respons yang menetapkan max-age atau s-maxage direktif cache 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 objek jarang diakses.

Jika Anda melihat rasio pengusiran yang tinggi, pastikan Anda telah mengonfigurasi kunci cache untuk mengecualikan parameter yang tidak mengidentifikasi respons secara unik.

Pertimbangan lainnya

Pertimbangan berikut juga mungkin berlaku terkait dengan caching.

Header Vary

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 memberikan hash kamus yang tersedia untuk kompresi
• Origin/X-Origin: biasanya digunakan untuk cross-origin resource sharing
• 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 dalam cache dengan header Vary dalam respons dengan menggunakan nilai header sebagai bagian dari kunci cache. Jika header Vary dalam respons memiliki beberapa nilai, nilai tersebut akan diurutkan secara leksikografis untuk memastikan kunci cache bersifat deterministik.

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

Melewati cache

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

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

Sebaiknya batasi penggunaan ini untuk skenario proses debug secara umum, untuk menghindari pemuatan origin yang tidak disengaja. Traffic keluar saat melewati cache dikenai biaya sesuai tarif traffic keluar internet.

Pembatalan validasi cache

Lihat pembatalan cache.

Permintaan rentang byte

Media CDN mendukung permintaan rentang HTTP seperti yang ditentukan dalam RFC 9110.

Selain itu, Media CDN menggunakan permintaan rentang untuk mengambil respons yang lebih besar dari origin. Hal ini memungkinkan Media CDN meng-cache rentang byte individual, dan tidak memerlukan seluruh objek untuk diambil sekaligus agar dapat di-cache.

• Objek yang lebih besar dari 1 MiB diambil sebagai permintaan rentang byte hingga 2 MiB setiap kali.
• Respons hingga 1 MiB dapat diambil tanpa dukungan untuk rentang byte di origin.
• Respons yang lebih besar dari 1 MiB tidak ditayangkan jika rentang byte tidak didukung di origin.

Dukungan origin untuk permintaan rentang byte ditentukan oleh hal berikut:

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

Setiap permintaan pengisian asal untuk setiap rentang byte dicatat sebagai entri log terpisah dan dikaitkan dengan permintaan klien induknya. Anda dapat mengelompokkan permintaan ini dengan mencocokkan nilai jsonPayload.cacheKeyFingerprint untuk setiap permintaan.

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

Permintaan rentang multibagian

Media CDN mendukung permintaan rentang multibagian, yang memungkinkan pengguna meminta beberapa segmen file yang tidak berdekatan dalam satu permintaan HTTP—misalnya, Range: bytes=0-499, 1000-1499.

Untuk memaksimalkan performa klien dan pelepasan beban origin, Media CDN dapat menayangkan rentang byte individual yang diminta dari cache-nya, menggabungkannya ke dalam satu respons dengan kode status HTTP 206 Partial Response ke klien dengan Content-Type yang ditetapkan ke multipart/byteranges.

Untuk respons yang dapat di-cache, saat klien meminta rentang multipart, Media CDN mengoptimalkan proses dengan mengonversi permintaan menjadi serangkaian permintaan rentang satu bagian. Setiap permintaan berukuran 2 MB untuk mencakup semua bagian rentang byte yang diminta oleh klien. Kemudian, Media CDN menggunakan respons untuk menghasilkan satu respons multipart di edge. Pendekatan ini memungkinkan pemanfaatan cache yang efisien, mengurangi pengambilan asal yang berlebihan, dan mendukung kasus penggunaan bervolume tinggi, seperti download app store dan update OS.

Untuk konten yang tidak dapat di-cache, Media CDN meneruskan permintaan langsung ke origin.

Permintaan rentang terbuka

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

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

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

  #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 Media CDN menunggu di antara pembacaan menggunakan nilai konfigurasi EdgeCacheOrigin.timeouts.readTimeout. Biasanya, nilai ini harus dikonfigurasi ke kelipatan (misalnya, 2x) durasi target Anda.

Langkah berikutnya

• Tinjau pemilihan rute lanjutan.
• Pahami cara terhubung ke berbagai origin.
• Siapkan sertifikat TLS (SSL) untuk layanan Anda.
• Konfigurasi permintaan bertanda tangan untuk mengautentikasi akses ke konten.
• Untuk mengetahui detail selengkapnya tentang cara mengonfigurasi resource EdgeCacheService menggunakan Terraform, lihat dokumentasi Terraform Registry.