Mengonfigurasi perilaku caching

Media CDN menayangkan konten sedekat mungkin dengan pengguna menggunakan Infrastruktur edge caching global Google untuk meng-cache konten dan mengurangi beban pada infrastruktur origin Anda.

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 cache

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

Perilaku caching default

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

• 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 origin.
  • Menyimpan kode status HTTP 200 dan 206 dalam cache (caching negatif tidak diaktifkan).

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

Respons yang bukan konten statis atau tidak memiliki perintah cache yang valid tidak di-cache kecuali jika penyimpanan di 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 eksplisit yang dikonfigurasi berperilaku seolah-olah memiliki hal berikut konfigurasi:

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 oleh Media CDN dan mengambil data dengan cepat, sehingga waktu muat menjadi lebih cepat. Tidak semua HTTP dapat disimpan dalam cache.

Anda dapat mengonfigurasi mode cache untuk setiap rute untuk menggantinya perilaku Anda (misalnya, menggunakan mode cache CACHE_ALL_STATIC untuk menyimpan cache yang umum jenis media) meskipun origin tidak disetel 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 HTTP tertentu yang dihasilkan. Respons GET dan HEAD harus mematuhi persyaratan ini.

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

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

Persyaratan origin

Untuk memungkinkan Media CDN meng-cache respons asal yang lebih besar dari 1 MiB, origin harus menyertakan baris berikut di header respons untuk permintaan HEAD dan GET, kecuali jika ditentukan sebaliknya:

• 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 mengatur isian protokol secara eksplisit untuk setiap asal.

Respons yang tidak dapat disimpan dalam cache

Tabel berikut menjelaskan atribut permintaan dan respons yang mencegah respons jika di-cache. Respons yang dapat di-cache tetapi cocok "tidak dapat disimpan dalam cache" kriteria 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 atau respons statis dengan perintah cache yang valid di header responsnya di-cache. Respons lainnya diberi proxy sebagaimana adanya.
• Mode cache FORCE_CACHE_ALL menyimpan semua respons ke dalam cache tanpa syarat, tunduk pada persyaratan {i>uncacheability<i} yang disebutkan sebelumnya.
• Mode cache USE_ORIGIN_HEADERS memerlukan respons untuk disetel perintah cache yang valid di header responsnya pada selain kode status yang dapat di-cache.

Catatan:

• Respons yang tidak di-cache tidak memiliki direktif kontrol cache atau {i>header<i} lain diubah dan diberi {i>proxy<i} apa 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 di 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 origin, cache jenis media statis, dan cache semua respons dari asalnya, apa pun direktif yang ditetapkan.

Mode {i>cache<i} dikonfigurasi pada tingkat rute dan, dikombinasikan dengan penggantian TTL, memungkinkan Anda untuk mengonfigurasi perilaku {i>cache<i} berdasarkan {i>host<i}, jalur, parameter kueri, dan header (parameter permintaan apa pun yang cocok).

• Secara default, Media CDN menggunakan mode cache CACHE_ALL_STATIC, yang secara otomatis melakukan {i>cache<i} jenis media statis umum selama 1 jam (3600 detik), dengan memprioritaskan perintah cache apa pun yang ditentukan oleh origin untuk respons yang dapat disimpan dalam cache.
• Anda dapat menambah atau mengurangi TTL cache yang diterapkan pada respons tanpa disetel TTL cache eksplisit (perintah max-age atau s-maxage) dengan menyetel Kolom cdnPolicy.defaultTtl pada rute.
• Agar respons yang tidak berhasil di-cache lebih lama dari yang diinginkan, kode status non-2xx (tidak berhasil) tidak di-{i>cache<i} sesuai dengan Content-Type (jenis MIME) dan tidak memiliki TTL default diterapkan.

Mode cache yang tersedia, yang ditetapkan pada cdnPolicy.cacheMode masing-masing , ditampilkan dalam tabel berikut.

Jenis MIME konten statis

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

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 Content-Type header respons dengan nilai yang cocok dengan nilai berikut. Anda harus memastikan respons menetapkan perintah cache yang valid, atau Anda harus menggunakan mode cache FORCE_CACHE_ALL untuk meng-cache tanpa syarat yang dihasilkan.

Perhatikan hal berikut:

• Software server web asal Anda harus menyetel Content-Type untuk setiap respons. Banyak server web secara otomatis menyetel Header Content-Type, termasuk NGINX, Varnish, dan Apache.
• Cloud Storage menetapkan header Content-Type otomatis pada upload saat Anda menggunakan Konsol Google Cloud atau gcloud CLI untuk mengupload konten.
• Jika respons dapat di-cache berdasarkan jenis MIME-nya tetapi memiliki Perintah respons Cache-Control dari private atau Header no-store atau Set-Cookie, tidak di-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 disetel dalam kontrol cache max-age dan s-maxage perintah (atau header Expires) yang disetel oleh origin.

TTL, baik yang disetel dengan penggantian maupun dengan menggunakan perintah cache, optimis. Konten yang jarang diakses atau tidak populer mungkin akan dikeluarkan dari {i>cache<i} sebelum mencapai TTL.

Tabel berikut ini menampilkan tiga setelan TTL.

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

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

Catatan:

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

Cache negatif

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

Hal ini memungkinkan Anda menyimpan respons error seperti pengalihan (HTTP 301 dan 308) ke dalam cache dan tidak ditemukan (HTTP 404) yang lebih dekat dengan pengguna, serta mengurangi origin memuat lebih luas jika respons cenderung tidak berubah dan dapat di-cache.

Secara default, caching negatif dinonaktifkan. Tabel berikut menampilkan metode untuk setiap kode status saat {i>caching<i} negatif diaktifkan dan negativeCachingPolicy tidak digunakan.

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

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

Jika Anda perlu mengkonfigurasi TTL kode per status Anda sendiri, dan mengganti ini, Anda dapat mengonfigurasi cdnPolicy.negativeCachingPolicy. Hal ini memungkinkan Anda tetapkan TTL untuk setiap 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 5 detik untuk respons HTTP 404 (Not Found), serta TTL selama 10 detik untuk respons HTTP 405 (Metode Tidak Diizinkan), gunakan mengikuti definisi YAML di setiap rute yang berlaku:

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

Untuk mencegah {i>cache poisoning<i}, kami tidak menyarankan untuk mengaktifkan {i>cache<i} baik untuk kode status 400 (Permintaan Buruk) atau 403 (Dilarang). Pastikan server origin Anda mengembalikan salah satu kode sebagai hasil dari pemeriksaan hanya komponen permintaan yang disertakan dalam kunci cache. Cache poisoning dapat terjadi, misalnya, ketika server asal merespons dengan respons {i>error<i} 403 jika tidak ada Header Authorization. Dalam hal ini, meng-cache respons {i>error<i} akan menghasilkan Media CDN yang menyajikan respons error 403 ke semua permintaan hingga TTL kedaluwarsa, meskipun permintaan memiliki Header Authorization.

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 status dapat di-cache kode akan di-cache.
• Untuk mencegah penyimpanan cache negatif untuk kode status tertentu, tetapi tetap mematuhinya perintah cache origin, hilangkan kode status (cdnPolicy.negativeCachingPolicy[].code) di negativeCachingPolicy Anda definisi.
• Untuk secara eksplisit mengabaikan perintah cache origin untuk status tertentu kode, tetapkan cdnPolicy.negativeCachingPolicy[].ttl ke 0 (nol) untuk nilai tersebut kode status.

Catatan:

• Jika negativeCaching diaktifkan pada rute, dan respons menentukan perintah cache yang valid, perintah cache di respons akan lebih diutamakan.
• Jika Anda mengonfigurasi negativeCachingPolicy eksplisit, dan ada TTL untuk kode status yang diberikan, TTL yang ditentukan dalam kebijakan selalu data
• 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, origin akan diabaikan dalam semua kasus.

Perintah kontrol cache

Perilaku Media CDN sehubungan dengan Perintah Cache-Control didefinisikan di sini.

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

Jika memungkinkan, Media CDN sesuai dengan RFC (HTTP RFC 7234), tetapi lebih memilih mengoptimalkan pengurangan beban cache dan meminimalkan dampak yang dapat ditimbulkan klien dan beban asal secara keseluruhan.

Untuk respons yang menggunakan header Expires HTTP/1.1:

• Nilai header Expires harus berupa tanggal HTTP yang valid karena ditentukan dalam RFC 7231
• Nilai tanggal di masa lalu, tanggal tidak valid, atau nilai 0 menunjukkan bahwa konten telah kedaluwarsa dan memerlukan validasi ulang.
• Media CDN mengabaikan header Expires jika Cache-Control {i>header <i}ada dalam respons.

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

Kunci cache

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

Bagian berikut menjelaskan cara mengonfigurasi kunci cache.

Komponen kunci cache

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

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

Perhatikan hal berikut:

• Kunci cache tidak dikaitkan ke origin yang dikonfigurasi, sehingga Anda dapat mengupdate konfigurasi origin (atau mengganti origin sepenuhnya) tanpa risiko "flushing" cache (misalnya, saat memigrasikan penyimpanan asal antar-penyedia).
• Kunci cache dibatasi pada EdgeCacheService. EdgeCacheServices yang berbeda memiliki namespace cache yang berbeda, yang mencegah Anda meng-{i>cache<i} secara tidak sengaja objek di antara produksi, staging, dan lingkungan pengujian lainnya, meskipun {i>host<i}, jalur, atau komponen kunci cache lainnya akan cocok. Menghapus EdgeCacheService secara efektif membatalkan semua objek yang di-cache untuk layanan tersebut.
• Kunci cache tidak mencakup rute individual. Beberapa rute mungkin merujuk pada kunci cache, terutama jika rute tersebut cocok dengan komponen yang disertakan dalam kunci cache, seperti header permintaan atau parameter yang dikecualikan. Ini dapat berguna jika Anda ingin beberapa rute berbagi cache yang sama tetapi menampilkan header respons atau konfigurasi CORS yang berbeda.
• Kunci cache tidak mencakup konfigurasi penulisan ulang URL—misalnya, kunci cache didasarkan pada permintaan yang ditampilkan kepada pengguna, dan bukan permintaan akhir permintaan.
• Ketika permintaan bertanda tangan dikonfigurasi pada sebuah rute, atribut yang ditandatangani tidak disertakan dalam kunci cache. Permintaan diperlakukan seolah-olah (ditandatangani) parameter kueri atau komponen jalur, dimulai dengan edge-cache-token dan yang diakhiri di pemisah jalur berikutnya ("/"), bukan merupakan bagian dari URL.

Menyertakan atau mengecualikan parameter kueri

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

Misalnya, untuk menyertakan parameter kueri contentID dan country, serta abaikan yang 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 mereka yang tidak. Misalnya, mengecualikan parameter kueri Analytics, ID sesi pemutaran, atau parameter lain yang hanya unik untuk klien. Menyertakan parameter kueri lebih banyak daripada yang diperlukan dapat mengurangi rasio cache ditemukan.

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

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 {i>cache<i} untuk sebuah rute. Lakukan 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 disertakan dalam string kueri, dan diabaikan jika dimasukkan. Menyertakan parameter yang ditandatangani dalam kunci cache secara efektif membuat setiap permintaan pengguna menjadi unik, dan mengharuskan setiap dilayani dari origin.

Pengurutan parameter kueri

Parameter kueri (string kueri) diurutkan secara default untuk meningkatkan hasil cache karena klien mungkin memesan ulang atau meminta 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 kelompok objek yang di-cache, menghindari permintaan yang tidak perlu ke (dan merespons dari) tempat asal.

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

Sertakan header

Nama {i>header<i} tidak peka huruf besar/kecil dan dikonversi menjadi huruf kecil oleh dan 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 huruf besar tidak dapat digunakan dalam kunci {i>cache<i}.

Validasi ulang, penghapusan, dan masa berlaku

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

Penyimpanan Media CDN yang luas, serta perlindungan origin, membatasi kebutuhan untuk mengeluarkan, bahkan yang tidak populer saat ini. Konten yang diakses beberapa kali per hari mungkin pada akhirnya akan 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 telah tidak berubah. Dalam beberapa situasi, Media CDN mengirim permintaan ke origin dengan salah satu atau kedua header permintaan berikut: If-None-Match dan If-Modified-Since. Dalam kasus ini, origin yang dikonfigurasi dengan benar akan menampilkan HTTP 304 (Not Modified) tanpa byte body, jika cache memiliki "terbaru" salinan dari respons tersebut.
• Respons yang menetapkan cache max-age atau s-maxage atau yang menggunakan TTL untuk menetapkan nilai TTL yang tinggi (misalnya, 30 hari) mungkin tidak disimpan di cache untuk TTL penuh. Tidak ada jaminan bahwa sebuah objek disimpan dalam cache selama durasi penuh, terutama jika jarang diakses.

Jika Anda melihat tingkat penghapusan yang tinggi, Anda harus memastikan bahwa Anda memiliki mengonfigurasi kunci cache untuk mengecualikan parameter yang tidak mengidentifikasi sebuah yang dihasilkan.

Pertimbangan lainnya

Pertimbangan berikut juga mungkin berlaku terkait caching.

Vary header

Header Vary menunjukkan bahwa respons bervariasi bergantung pada header permintaan. Jika ada header Vary dalam respons, Media CDN tidak menyimpannya dalam cache, kecuali jika header menentukan salah satu {i>header<i} 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 klien menerima
• Available-Dictionary: digunakan untuk memberikan hash dari bahasa yang tersedia kamus untuk kompresi
• Origin/X-Origin: biasanya digunakan untuk berbagi resource lintas origin
• X-Goog-Allowed-Resources: mendukung organisasi Google Cloud batasan
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: digunakan untuk mengambil permintaan metadata header

Media CDN menyimpan respons dengan header Vary ke dalam cache dalam respons dengan menggunakan nilai {i>header<i} sebagai bagian dari kunci {i>cache<i}. Jika header Vary di respons memiliki beberapa nilai, mereka diurutkan secara leksikografis untuk memastikan bahwa kunci cache bersifat determenistik.

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

Abaikan cache

Anda dapat mengonfigurasi mode cache BYPASS_CACHE pada rute yang sengaja mengabaikan cache pada permintaan yang sesuai. Hal ini dapat berguna jika Anda perlu mengabaikan cache untuk sebagian kecil traffic tidak kritis, atau asal debug konektivitas pribadi.

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

Disarankan agar Anda secara umum membatasi penggunaan layanan ini untuk skenario {i>debugging<i}, untuk menghindari pemuatan origin yang tidak disengaja. Traffic yang keluar saat mengabaikan cache dengan tarif traffic keluar internet.

Pembatalan validasi cache

Lihat pembatalan validasi cache.

Permintaan dengan rentang byte

Media CDN mendukung permintaan rentang HTTP satu bagian sebagaimana didefinisikan dalam RFC 7233.

Selain itu, Media CDN juga menggunakan permintaan rentang untuk mengambil respons yang lebih besar dari origin. Hal ini memungkinkan Media CDN untuk cache potongan terpisah, dan tidak memerlukan seluruh objek untuk 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 byte rentang di tempat asal.
• Respons yang lebih besar dari ini tidak disajikan jika rentang byte tidak didukung pada tempat 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).

Permintaan pengisian origin individual untuk setiap "bagian" (rentang byte) dicatat sebagai entri log diskrit dan terkait dengan permintaan klien induknya. Anda dapat mengelompokkan permintaan ini dengan permintaan yang sesuai pada jsonPayload.cacheKeyFingerprint.

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

Permintaan rentang terbuka

Media CDN mendukung "open-ended" Permintaan Range (misalnya, dengan Range: bytes=0-) yang membuat permintaan tetap terbuka terhadap origin hingga respons ditutup oleh origin (misalnya, origin akan menulis semua {i>byte<i} ke kabel) atau kehabisan waktu.

Rentang byte terbuka biasanya digunakan oleh klien yang meminta HLS Latensi Rendah segmen: karena setiap potongan CMAF ditulis ke kabel, CDN dapat meng-cache dan memberikan potongan itu kepada klien.

Dalam kasus lain, seperti ketika interoperabilitas dengan DASH tidak diperlukan, {i>playlist<i} media menunjukkan kepada pemutar {i>byte<i} 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 berapa lama Media CDN menunggu di antara pembacaan dengan menggunakan nilai konfigurasi EdgeCacheOrigin.timeouts.readTimeout. Seharusnya biasanya dikonfigurasi ke beberapa (misalnya, 2x) dari durasi target.

Langkah selanjutnya

• Tinjau pemilihan rute lanjutan.
• Memahami cara terhubung ke origin yang berbeda.
• Menyiapkan sertifikat TLS (SSL) untuk akun layanan.
• Mengonfigurasi permintaan bertanda tangan untuk mengautentikasi akses ke konten.