Ringkasan cache

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

Mode cache

Dengan mode cache, Anda dapat mengontrol faktor yang menentukan apakah Cloud CDN menyimpan konten Anda dalam cache.

Cloud CDN menawarkan tiga mode cache yang menentukan cara meng-cache respons, apakah Cloud CDN mematuhi perintah cache yang dikirim oleh origin, dan cara menerapkan TTL cache.

Mode cache yang tersedia ditampilkan dalam tabel berikut:

Mode cache Perilaku
CACHE_ALL_STATIC Secara otomatis meng-cache respons yang berhasil dengan konten statis yang tidak tidak dapat disimpan dalam cache. Respons asal yang menetapkan perintah caching yang valid juga akan di-cache.

Ini adalah perilaku default untuk backend berkemampuan Cloud CDN yang dibuat menggunakan Google Cloud CLI atau REST API.

USE_ORIGIN_HEADERS Memerlukan respons origin yang berhasil untuk menetapkan perintah cache yang valid dan header caching yang valid. Respons yang berhasil tanpa perintah ini akan diteruskan dari asalnya.
FORCE_CACHE_ALL Meng-cache respons yang berhasil tanpa syarat, menggantikan perintah cache apa pun yang ditetapkan oleh sumber. Mode ini tidak sesuai jika backend menayangkan konten pribadi per pengguna, seperti respons API atau HTML dinamis.

Respons error dapat di-cache meskipun tidak ada perintah cache yang valid.

Sebelum menyetel mode cache ke FORCE_CACHE_ALL, pertimbangkan perilaku berikut:

  • Untuk URL bertanda tangan atau cookie yang ditandatangani, FORCE_CACHE_ALL menggantikan usia maksimum yang ditentukan melalui setelan Usia maksimum entri cache di Konsol Google Cloud atau opsi gcloud --signed-url-cache-max-age.

  • FORCE_CACHE_ALL mengubah time to live (TTL) konten yang di-cache sebelumnya. Perubahan ini dapat menyebabkan beberapa entri yang sebelumnya dianggap baru (karena TTL lebih panjang dari header origin) dianggap tidak berlaku, dan dapat menyebabkan beberapa entri yang sebelumnya dianggap tidak berlaku akan dianggap baru.

  • FORCE_CACHE_ALL menggantikan perintah cache (Cache-Control dan Expires), tetapi tidak menggantikan header respons origin lainnya. Secara khusus, header Vary masih diterapkan, dan dapat menyembunyikan penyimpanan dalam cache bahkan jika ada FORCE_CACHE_ALL. Untuk informasi selengkapnya, lihat header misc.

Untuk petunjuk penyiapan, lihat Menyetel mode cache.

Konten statis

Konten statis adalah konten yang selalu sama, bahkan saat diakses oleh pengguna yang berbeda. CSS yang digunakan untuk menata gaya situs, JavaScript guna menyediakan konten interaktivitas, video, dan gambar biasanya tidak berubah bagi setiap pengguna untuk URL tertentu (kunci cache), sehingga bisa di-cache di seluruh jaringan edge global Cloud CDN.

Saat Anda menetapkan mode cache ke CACHE_ALL_STATIC, dan respons tidak memiliki perintah caching eksplisit di header Cache-Control atau Expires, Cloud CDN otomatis menyimpan respons tersebut untuk hal berikut:

  • Aset Web, termasuk CSS (text/css), JavaScript (application/javascript), dan semua font web, termasuk WOFF2 (font/woff2)
  • Gambar, termasuk JPEG (image/jpg) dan PNG (image/png)
  • Video, termasuk H.264, H.265, dan MP4 (video/mp4) +. File audio, termasuk MP3 (audio/mpeg) dan MP4 (audio/mp4)
  • Dokumen terformat, termasuk PDF (application/pdf)

Tabel berikut memberikan ringkasan.

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 dan application/postscript

Cloud CDN memeriksa header respons HTTP Content-Type, yang menunjukkan jenis MIME dari konten yang ditayangkan.

Perhatikan hal-hal berikut:

  • Software server web origin 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 diupload saat Anda menggunakan Konsol Google Cloud atau alat gsutil untuk mengupload konten.

  • Jika respons dapat di-cache berdasarkan jenis MIME, tetapi memiliki header respons Cache-Control dari private atau no-store, atau header Set-Cookie (lihat daftar lengkap aturan), respons tersebut tidak akan di-cache.

Cloud CDN tidak menggunakan ekstensi file di jalur URL untuk menentukan apakah suatu respons dapat disimpan dalam cache karena banyak respons valid yang dapat di-cache tidak tercermin dalam URL.

Jika ingin meng-cache jenis konten text/html dan application/json, Anda harus menetapkan header Cache-Control eksplisit dalam respons, berhati-hatilah agar tidak meng-cache satu data pengguna secara tidak sengaja dan menayangkannya ke semua pengguna.

Konten yang dapat di-cache

Cloud CDN menyimpan respons yang memenuhi semua persyaratan di bagian ini ke dalam cache. Beberapa persyaratan ini ditentukan oleh RFC 7234, dan persyaratan lainnya khusus untuk Cloud CDN.

Cloud CDN dapat secara berkala mengubah serangkaian kondisi yang diperlukan untuk menyimpan konten dalam cache. Jika Anda ingin secara eksplisit mencegah Cloud CDN menyimpan konten ke dalam cache, ikuti panduan di RFC 7234 untuk menentukan cara menentukan respons dijamin tidak dapat disimpan dalam cache. Lihat juga bagian konten yang tidak dapat di-cache berdasarkan header origin.

Cloud CDN menyimpan respons dalam cache jika semua hal berikut berlaku.

Atribut Persyaratan
Dilayani oleh Layanan backend, bucket backend, atau backend eksternal dengan Cloud CDN diaktifkan
Menanggapi Permintaan GET
Kode status

200, 203, 204, 206, 300, 301, 302, 307, 308, 404, 405, 410, 421, 451, atau 501.
Keaktualan

Responsnya memiliki header Cache-Control dengan perintah max-age atau s-maxage, atau header Expires dengan stempel waktu di masa mendatang.

Untuk respons yang dapat di-cache tanpa usia (misalnya, dengan no-cache), perintah public harus diberikan secara eksplisit.

Dengan mode cache CACHE_ALL_STATIC, jika tidak ada perintah keaktualan, respons yang berhasil dengan jenis konten statis masih memenuhi syarat untuk disimpan dalam cache.

Dengan mode cache FORCE_CACHE_ALL, setiap respons yang berhasil akan memenuhi syarat untuk disimpan dalam cache. Hal ini dapat menyebabkan konten pribadi per pengguna (dapat diidentifikasi pengguna) disimpan dalam cache. Anda hanya boleh menetapkan FORCE_CACHE_ALL di backend yang tidak menyajikan konten pribadi atau dinamis, seperti bucket Cloud Storage.

Jika cache negatif diaktifkan dan kode statusnya cocok dengan yang mana cache negatif menentukan TTL, respons akan memenuhi syarat untuk disimpan dalam cache, meskipun tanpa perintah keaktualan yang eksplisit.
Konten

Untuk origin HTTP/1, respons harus berisi header Content-Length, Content-Range, atau Transfer-Encoding: chunked yang valid.

Untuk origin yang menggunakan versi protokol HTTP lebih canggih (HTTP/2 dan yang lebih baru), respons tidak perlu memiliki header tersebut.
Ukuran Kurang dari atau sama dengan ukuran maksimum.

Untuk respons dengan ukuran antara 10 MB dan 100 GB, lihat batasan kemampuan cache tambahan yang dijelaskan dalam permintaan rentang byte.

Untuk bucket backend Cloud Storage, berikut adalah beberapa cara untuk memenuhi persyaratan ini:

  • Buat bucket Anda dapat dibaca secara publik. Ini adalah pendekatan yang kami rekomendasikan untuk konten publik. Dengan setelan ini, siapa pun di internet dapat melihat dan mencantumkan objek Anda beserta metadatanya, tidak termasuk ACL. Praktik yang direkomendasikan adalah mendedikasikan bucket tertentu untuk objek publik.

  • Gunakan folder terkelola agar sebagian bucket dapat dibaca oleh publik.

  • Buat masing-masing objek dapat dibaca oleh publik. Kami tidak merekomendasikan pendekatan ini karena menggunakan sistem pemberian izin khusus Cloud Storage lama.

Secara default, jika objek bersifat publik dan tidak menentukan metadata Cache-Control, Cloud Storage akan menetapkan header Cache-Control: public, max-age=3600 ke objek tersebut. Anda dapat menetapkan nilai yang berbeda menggunakan metadata Cache-Control.

Untuk mengetahui contoh yang menunjukkan cara mengonfigurasi Load Balancer Aplikasi eksternal dengan bucket backend, lihat Menyiapkan Cloud CDN dengan bucket backend.

Ukuran maksimum

Cloud CDN menerapkan ukuran maksimum untuk setiap respons. Respons apa pun dengan isi yang lebih besar dari ukuran maksimum tidak akan disimpan dalam cache, tetapi tetap dikirim ke klien.

Ukuran maksimum bervariasi bergantung pada apakah server asal mendukung permintaan rentang byte.

Server asal mendukung permintaan rentang byte Server asal tidak mendukung permintaan rentang byte
100 GB (107.374.182.400 byte) 10 MB (10.485.760 byte)

Hampir semua server web modern (termasuk NGINX, Apache, dan Varnish) mendukung permintaan rentang byte.

Konten yang tidak dapat di-cache berdasarkan header asal

Ada pemeriksaan yang memblokir cache respons. Cloud CDN dapat secara berkala mengubah serangkaian kondisi yang menyebabkan konten di-cache. Jadi, jika Anda ingin secara eksplisit mencegah Cloud CDN menyimpan konten dalam cache, ikuti panduan dalam standar (RFC 7234) untuk menentukan cara menentukan respons yang dijamin dan tidak dapat disimpan dalam cache.

Cloud CDN tidak akan menyimpan respons dalam cache jika tidak memenuhi persyaratan untuk Konten yang dapat di-cache, atau jika salah satu hal berikut benar.

Atribut Persyaratan
Dilayani oleh Layanan backend atau backend eksternal yang tidak mengaktifkan Cloud CDN
Cookie Memiliki header Set-Cookie
Vary header Memiliki nilai selain Accept, Accept-Encoding, Access-Control-Request-Headers, Access-Control-Request-Method, Origin, Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, X-Goog-Allowed-Resources, X-Origin, atau salah satu header yang dikonfigurasi untuk menjadi bagian dari setelan kunci cache.
Perintah respons Respons memiliki header Cache-Control dengan perintah no-store atau private (kecuali jika menggunakan mode cache FORCE_CACHE_ALL, dalam hal ini header Cache-Control akan diabaikan)
Perintah permintaan Permintaan memiliki perintah Cache-Control: no-store
Minta otorisasi Permintaan memiliki header Authorization, kecuali jika diganti oleh Cache-Control respons.
Ukuran Lebih besar dari ukuran maksimum

Jika Cache-Control: no-store atau private ada, tetapi konten masih di-cache, hal ini disebabkan oleh salah satu hal berikut:

  • Penandatanganan URL dikonfigurasi.
  • Mode cache Cloud CDN disetel untuk memaksa penyimpanan semua respons ke dalam cache.

Mencegah penyimpanan dalam cache

Agar informasi pribadi tidak di-cache dalam cache Cloud CDN, lakukan langkah berikut:

  1. Pastikan mode cache Cloud CDN tidak disetel ke mode FORCE_CACHE_ALL, yang meng-cache semua respons yang berhasil tanpa syarat.
  2. Sertakan header Cache-Control: private dalam respons yang tidak boleh disimpan di cache Cloud CDN, atau header Cache-Control: no-store dalam respons yang tidak boleh disimpan di cache mana pun, bahkan di cache browser web.
  3. Jangan tanda tangani URL yang memberikan akses ke informasi pribadi. Saat diakses menggunakan URL yang ditandatangani, konten berpotensi memenuhi syarat untuk disimpan dalam cache, terlepas dari perintah Cache-Control dalam respons.
  4. Untuk permintaan origin (pengisian cache) yang menyertakan header permintaan Authorization, Cloud CDN hanya akan meng-cache respons yang menyertakan perintah kontrol cache public, must-revalidate, atau s-maxage saat mode cache disetel ke USE_ORIGIN_HEADERS atau CACHE_ALL_STATIC. Tindakan ini mencegah penyimpanan konten per pengguna dan/atau konten yang memerlukan autentikasi ke dalam cache secara tidak sengaja. Mode cache FORCE_CACHE_ALL tidak memiliki pembatasan ini.

Menambahkan header respons kustom

Dengan header respons kustom, Anda dapat menentukan header yang ditambahkan oleh Load Balancer Aplikasi klasik ke respons melalui proxy. Header respons kustom memungkinkan Anda mencerminkan status cache ke klien, data geografis klien, dan header respons statis Anda sendiri.

Untuk daftar header, lihat Variabel yang dapat muncul di nilai header.

Untuk mengetahui petunjuknya, lihat Bekerja dengan header respons kustom.

Header respons kustom tidak didukung untuk deployment Cloud CDN di Load Balancer Aplikasi eksternal global.

Kunci cache

Setiap entri cache di cache Cloud CDN diidentifikasi oleh kunci cache. Saat permintaan masuk ke cache, cache akan mengonversi URI permintaan menjadi kunci cache, lalu membandingkannya dengan kunci entri yang di-cache. Jika menemukan kecocokan, cache akan mengembalikan objek yang terkait dengan kunci tersebut.

Untuk layanan backend, Cloud CDN secara default menggunakan URI permintaan lengkap sebagai kunci cache. Misalnya, https://example.com/images/cat.jpg adalah URI lengkap untuk permintaan tertentu bagi objek cat.jpg. String ini digunakan sebagai kunci cache default. Hanya permintaan dengan pencocokan string yang sama persis. Permintaan untuk http://example.com/images/cat.jpg atau https://example.com/images/cat.jpg?user=user1 tidak cocok.

Untuk bucket backend, setelan defaultnya adalah kunci cache terdiri dari URI tanpa protokol atau host. Secara default, hanya parameter kueri yang diketahui oleh Cloud Storage yang akan disertakan sebagai bagian dari kunci cache (misalnya, "pembuatan").

Jadi, untuk bucket backend tertentu, URI berikut me-resolve objek yang sama di cache:

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

Anda dapat mengubah bagian URI yang digunakan di kunci cache. Meskipun nama file dan jalur harus selalu menjadi bagian dari kunci, Anda dapat menyertakan atau menghilangkan kombinasi protokol, host, atau string kueri saat menyesuaikan kunci cache. Penggunaan kunci cache menjelaskan cara menyesuaikan kunci cache.

Bagian URI Penyesuaian Contoh URL yang memiliki kunci cache yang sama
Protocol Menghapus protokol dari kunci cache.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Host Menghapus host dari kunci cache.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
String kueri

Hapus string kueri dari kunci cache.

Secara selektif menghilangkan atau menyertakan bagian dari string kueri.
  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Selain menyertakan atau menghilangkan seluruh string kueri, Anda dapat menggunakan sebagian string kueri dengan menggunakan daftar penyertaan dan daftar kecualikan.

Daftar penyertaan string kueri

Anda dapat secara selektif mengontrol parameter string kueri yang digabungkan Cloud CDN ke dalam kunci cache. Misalnya, jika Anda membuat daftar penyertaan user, https://example.com/images/cat.jpg?user=user1&color=blue akan membuat kunci cache https://example.com/images/cat.jpg?user=user1 yang juga cocok dengan https://example.com/images/cat.jpg?user=user1&color=red.

Untuk menggunakan opsi ini, Anda harus menyertakan string kueri, menentukan daftar penyertaan yang tidak kosong, dan tidak menentukan daftar pengecualian.

String kueri menyertakan daftar untuk kunci cache Cloud Storage

Menyertakan parameter kueri URL dalam kunci cache untuk bucket Cloud Storage akan membantu mendukung perusak cache. Perusak cache adalah proses yang memungkinkan pengguna menemukan versi baru dari file yang telah diupload, meskipun versi lama masih disimpan dalam cache secara valid oleh TTL.

Anda dapat mencantumkan parameter kueri khusus dalam kunci cache yang digunakan untuk menyajikan respons dari bucket backend. Meskipun Cloud Storage tidak menyajikan konten atau rute yang berbeda berdasarkan parameter kueri, Anda dapat memilih untuk menyertakan parameter yang memungkinkan Anda membuat cache konten statis yang disimpan di bucket Cloud Storage.

Misalnya, Anda dapat menambahkan parameter kueri ?version=VERSION atau ?hash=HASH yang didasarkan pada konten pokok. Hal ini membatasi kebutuhan untuk secara proaktif membatalkan validasi konten dan selaras dengan alur kerja pengembangan web modern, dengan framework web dan URL menggunakan hash konten untuk menghindari penayangan objek tidak berlaku di seluruh deployment.

Karena menyertakan parameter kueri di kunci cache bersifat keikutsertaan saja, Cloud CDN tidak mendukung pengecualian parameter kueri dari kunci cache ke bucket backend.

Daftar pengecualian string kueri

Anda dapat secara selektif mengontrol parameter string kueri mana yang diabaikan oleh Cloud CDN menggunakan daftar pengecualian. Misalnya, jika Anda membuat daftar pengecualian user, semua parameter string kueri kecuali user akan digunakan di kunci cache.

Dengan daftar pengecualian yang dikonfigurasi dan input https://example.com/images/cat.jpg?user=user1&color=blue, Cloud CDN akan membuat kunci cache https://example.com/images/cat.jpg?color=blue yang juga cocok dengan https://example.com/images/cat.jpg?user=user2&color=blue, tetapi tidak dengan https://example.com/images/cat.jpg?user=user1&color=red.

Untuk menggunakan opsi ini, Anda harus menyertakan string kueri, menentukan daftar pengecualian yang tidak kosong, dan tidak menentukan daftar penyertaan.

Urutan parameter kueri

Kunci cache yang dihasilkan tidak bergantung pada urutan parameter kueri.

Misalnya, parameter kueri berikut menghasilkan kunci cache yang sama:

  • info=123&variant=13e&geography=US
  • geography=US&variant=13e&info=123

Setelan kunci cache cookie HTTP dan header HTTP

Anda dapat meningkatkan rasio cache ditemukan dan pengurangan origin dengan setelan konfigurasi kunci cache berikut.

  • Untuk layanan dan bucket backend: Gunakan header HTTP sebagai bagian dari kunci cache dengan menyertakan header bernama dalam konfigurasi kunci cache.
  • Khusus layanan backend: Gunakan cookie HTTP bernama sebagai kunci cache, misalnya untuk pengujian A/B (multi-variasi), deployment canary, dan skenario serupa.

Permintaan cache yang menyertakan header HTTP atau cookie HTTP tambahan dalam permintaan akan di-cache pada permintaan ketiga di lokasi cache untuk kunci cache tersebut. Tindakan ini akan mengurangi dampak nilai header/cookie kardinalitas yang tinggi pada rasio penghapusan cache Anda. Dalam keadaan normal dan kondisi traffic pengguna, masalah ini tidak akan terlihat dan memastikan bahwa konten populer tetap disimpan dalam cache.

Menyertakan header permintaan

Untuk meng-cache variasi tambahan dari respons, Anda dapat menyertakan header permintaan tambahan di kunci cache.

Beberapa header tidak diizinkan dalam kunci cache karena biasanya memiliki kardinalitas sangat tinggi. Pada umumnya, nilai header ini bersifat unik per pengguna (Cookie,Authorization) atau memiliki ribuan kemungkinan nilai (Referer, User-Agent, Accept). Misalnya, header User-Agent dapat memiliki lebih dari 5.000 nilai unik mengingat beragam jenis browser, perangkat pengguna, dan sistem operasi. Jenis {i>header<i} ini akan berdampak negatif pada rasio cache ditemukan.

Hanya nama kolom header HTTP yang valid yang diterima berdasarkan RFC 7230. Nama kolom header tidak peka huruf besar/kecil, dan duplikat ditolak.

Anda dapat mengonfigurasi server origin secara opsional untuk menyertakan header permintaan kunci cache yang dikonfigurasi dalam respons Vary. Opsi ini tidak diperlukan untuk Cloud CDN, tetapi dapat bermanfaat untuk cache downstream. Untuk mengetahui informasi selengkapnya, lihat Header Variasi.

Cloud CDN tidak mengizinkan header berikut disertakan dalam daftar header:

  • Accept
  • Accept-Encoding
  • Authority, karena ini dikontrol oleh konfigurasi (cdnPolicy.includeHost)
  • Authorization, biasanya per pengguna seperti pada token Bearer OAuth
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, sering kali per klien atau per-proxy
  • From
  • Host, karena ini dikontrol oleh konfigurasi (cdnPolicy.includeHost)
  • If-Match, If-Modified-Since, atau If-None-Match
  • Origin
  • Proxy-Authorization
  • Range
  • Referer (atau Referrer)
  • User-Agent
  • Want-Digest
  • X-CSRFToken dan X-CSRF-Token seperti yang digunakan oleh Django dan Ruby on Rails
  • X-Forwarded-For, sering kali per klien atau per-proxy
  • X-User-IP
  • Header yang dimulai dengan kode berikut:
    • Access-Control-, seperti Access-Control-Request-Headers dan Access-Control-Request-Method
    • Sec-Fetch-
    • Sec-GFE-
    • Sec-Google-
    • X-Amz-
    • X-GFE-
    • X-Goog-
    • X-Google-

Header yang sama dengan nilai berbeda

Misalkan pengguna mengirim beberapa header bernama sama dengan nilai header yang berbeda—misalnya:

My-Header: Value1
My-Header: Value2

Dalam hal ini, Cloud CDN mengubah permintaan dengan mengasumsikan bahwa header harus mengikuti konvensi standar yang mengizinkan beberapa header memiliki beberapa nilai. Cloud CDN menciutkannya menjadi daftar yang dipisahkan koma untuk dikirim ke backend, sehingga klien seakan-akan mengirim perintah berikut:

My-Header: Value1, Value2

Menyertakan cookie bernama

Cookie HTTP adalah penyambungan name=value, dan sebuah permintaan dapat menyertakan beberapa cookie HTTP, baik yang dipisahkan titik koma pada baris yang sama, maupun sebagai header permintaan Cookie terpisah dengan satu cookie per header.

Anda dapat memberikan daftar hingga lima nama cookie.

Agen pengguna (seperti browser web) sering kali membatasi jumlah cookie yang disimpan per domain hingga 4 KB. Pastikan Anda tidak mengirim terlalu banyak cookie (atau terlalu besar), karena agen pengguna mungkin tidak mengirim semua cookie dalam permintaan. Hal ini dapat memengaruhi apakah pengguna menerima respons tertentu yang di-cache.

Jika Anda menayangkan konten statis dari nama host lain yang Anda gunakan untuk mengeluarkan cookie, pastikan atribut Domain cookie (dan Path) memungkinkan cookie dikirim bersama dengan permintaan untuk konten statis.

Jika permintaan menyertakan beberapa instance dari nama cookie yang sama, hanya instance pertama yang akan diterima.

Perintah kontrol cache

Perintah kontrol cache HTTP memengaruhi perilaku Cloud CDN, seperti yang diuraikan dalam tabel berikut.

T/A menandakan bahwa perintah tidak berlaku untuk permintaan atau respons.

Perintah Permintaan Respons
no-store Jika ada dalam permintaan, Cloud CDN akan memenuhinya dan tidak menyimpan respons dalam cache.

Respons dengan no-store tidak di-cache.

Hal ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL.

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

Respons dengan no-cache akan disimpan dalam cache, tetapi harus divalidasi ulang dengan asalnya sebelum ditayangkan.

Hal ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL.

public T/A

Perintah ini tidak diperlukan untuk kemampuan cache, tetapi praktik terbaiknya adalah menyertakannya untuk konten yang harus di-cache oleh proxy.

private T/A

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

Hal ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL. Gunakan no-store untuk mencegah semua cache respons.

max-age=SECONDS Perintah permintaan max-age diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. Respons dengan perintah max-age di-cache hingga ke 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 digunakan oleh Cloud CDN.

Respons dengan perintah ini tidak akan dianggap usang.

s-max-age (dua tanda hubung) tidak valid untuk tujuan caching.

min-fresh=SECONDS Perintah permintaan min-fresh diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A
max-stale=SECONDS

Perintah permintaan max-stale menentukan keusangan maksimum (dalam detik) yang ingin diterima klien.

Cloud CDN mematuhinya, dan menampilkan respons lama yang di-cache hanya jika tingkat penghentian respons lebih kecil daripada perintah max-stale. Jika tidak, permintaan akan divalidasi ulang sebelum menayangkan permintaan.

 T/A
stale-while-revalidate=SECONDS T/A

Respons dengan stale-while-revalidate ditayangkan ke klien hingga SECONDS sementara validasi ulang terjadi secara asinkron.

Perilaku ini dapat diaktifkan untuk semua respons dengan menyetel cdnPolicy.serveWhileStale di backend.

stale-if-error=SECONDS Perintah permintaan stale-if-error diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan.

Header respons ini tidak berpengaruh.

must-revalidate T/A

Respons dengan must-revalidate divalidasi ulang dengan server asal setelah masa berlakunya habis.

Respons dengan perintah ini tidak akan dianggap usang.

proxy-revalidate

Respons dengan proxy-revalidate divalidasi ulang dengan server asal setelah masa berlakunya habis.

Respons dengan perintah ini tidak akan dianggap usang.

immutable T/A Tidak berpengaruh. Ini diteruskan ke klien dalam respons.
no-transform T/A Tidak ada transformasi yang diterapkan oleh Cloud CDN.
only-if-cached Perintah permintaan only-if-cached diabaikan. Respons yang di-cache ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A

Jika memungkinkan, Cloud CDN berupaya agar sesuai dengan RFC (HTTP RFC 7234), tetapi lebih memilih pengoptimalan untuk mengurangi beban cache dan meminimalkan dampak yang dapat ditimbulkan oleh klien terhadap rasio hit dan/atau 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 pada masa lalu, tanggal yang tidak valid, atau nilai 0 menunjukkan bahwa konten sudah tidak berlaku dan perlu divalidasi ulang.
  • Jika header Cache-Control ada dalam respons, Cloud CDN mengabaikan header Expires.

Keberadaan header Expires mendatang yang valid dalam respons memungkinkan respons di-cache, dan tidak memerlukan perintah cache lainnya untuk ditentukan.

Header Pragma HTTP/1.0, jika ada dalam respons, akan diabaikan dan diteruskan apa adanya ke klien. Permintaan klien dengan header ini diteruskan ke asal dan tidak memengaruhi cara respons disalurkan oleh Cloud CDN.

Vary header

Header Vary menunjukkan bahwa responsnya bervariasi bergantung pada header permintaan klien. Selain URI permintaan, Cloud CDN menerapkan header Vary yang disertakan oleh server asal dalam respons. Misalnya, jika respons menentukan Vary: Accept, Cloud CDN akan menggunakan satu entri cache untuk permintaan yang menentukan Accept: image/webp,image/*,*/*;q=0.8 dan entri cache lainnya untuk permintaan yang menentukan Accept: */*.

Tabel di bagian Konten yang tidak dapat di-cache mencantumkan header Vary yang memungkinkan konten di-cache. Nilai header Vary lainnya mencegah konten di-cache.

Mode cache FORCE_CACHE_ALL tidak mengganti perilaku ini. Header Vary penting untuk menghindari cache poisoning di antara beberapa kemungkinan respons server origin. Akan berbahaya jika FORCE_CACHE_ALL menyebabkan respons tersebut di-cache.

Header Vary terkadang digunakan saat menayangkan konten yang dikompresi. Cloud CDN tidak mengompresi atau mendekompresi respons itu sendiri (kecuali jika kompresi dinamis diaktifkan), tetapi dapat menampilkan respons yang telah dikompresi oleh server asal. Jika server origin Anda memilih apakah akan menayangkan konten yang dikompresi atau konten yang tidak dikompresi berdasarkan nilai header permintaan Accept-Encoding, pastikan respons menentukan Vary: Accept-Encoding.

Saat menggunakan header HTTP di kunci cache, Cloud CDN menyimpan beberapa salinan respons berdasarkan nilai header permintaan yang ditentukan, mirip dengan dukungan Vary, tetapi tanpa mengharuskan server asal untuk secara eksplisit menentukan header respons Vary. Jika origin menentukan header kunci cache dalam respons Vary, Cloud CDN akan memperlakukan respons dengan benar, sama seperti jika header tidak disebutkan dalam respons Vary.

Waktu habis masa berlaku dan permintaan validasi

Waktu habis masa berlaku entri cache menentukan berapa lama entri cache tetap valid. Nilai yang diberikan oleh nilai s-maxage (atau max-age atau expires) memungkinkan validasi ulang otomatis atas konten lama yang disimpan dalam cache buatan pengguna.

Saat menerima permintaan, Cloud CDN akan mencari entri cache yang sesuai dan memeriksa usianya. Jika entri cache ada dan cukup baru, respons dapat disalurkan dari cache. Jika masa berlaku telah berlalu, Cloud CDN akan mencoba memvalidasi ulang entri cache dengan menghubungi salah satu backend Anda. Hal ini dilakukan sebelum menampilkan respons, kecuali jika Anda mengaktifkan serve-when-stale, sehingga validasi ulang dilakukan secara asinkron.

Untuk beberapa mode cache, Anda dapat menetapkan nilai TTL. Untuk mengetahui informasi lebih lanjut, baca Menggunakan setelan dan penggantian TTL.

Mode cache memengaruhi cara keaktualan ditentukan.

Mode cache Perilaku validasi
CACHE_ALL_STATIC Header origin (header Cache-Control: s-maxage, Cache-Control: max-age, atau Expires) berkonsultasi untuk menentukan keaktualan. Untuk konten statis, jika header asal tidak ada, default_ttl yang dikonfigurasi akan menentukan keaktualan. Jika konten statis sudah lebih lama dari default_ttl, Cloud CDN akan memvalidasi ulang konten.
USE_ORIGIN_HEADERS Setiap entri cache di cache Cloud CDN memiliki waktu habis masa berlaku yang ditentukan oleh header Cache-Control: s-maxage, Cache-Control: max-age, atau Expires sesuai dengan RFC 7234.
FORCE_CACHE_ALL Sebagai ganti header origin, default_ttl yang dikonfigurasi akan menentukan keaktualan. Jika konten sudah lebih lama dari default_ttl, Cloud CDN akan memvalidasi ulang konten.

Jika terdapat lebih dari satu, Cache-Control: s-maxage akan lebih diutamakan daripada Cache-Control: max-age, dan Cache-Control: max-age akan lebih diprioritaskan daripada Expires.

Secara default, saat nilai waktu habis masa berlaku melebihi 30 hari (2.592.000 detik), Cloud CDN memperlakukan nilai masa berlaku seolah-olah 2.592.000 detik. Klien downstream tetap melihat nilai yang akurat dari max-age dan s-maxage, meskipun melebihi 30 hari.

Penghapusan

Tidak ada jaminan bahwa entri cache akan tetap ada di cache hingga masa berlakunya habis karena entri yang tidak populer dapat dikeluarkan sebelum masa berlakunya habis kapan saja untuk memberikan ruang bagi konten baru. Sebagai batas atas, entri cache yang tidak diakses selama 30 hari akan otomatis dihapus.

Untuk mengetahui informasi selengkapnya, lihat Penghapusan dan akhir masa berlaku.

Menggunakan permintaan kondisional untuk validasi

Cloud CDN dapat mencoba menggunakan informasi dalam header respons yang di-cache untuk memvalidasi entri cache dengan backend. Hal ini terjadi jika kedua hal berikut terpenuhi:

  • Respons yang di-cache sebelumnya memiliki header Last-Modified atau ETag.
  • Permintaan klien adalah permintaan GET yang tidak berisi header If-Modified-Since atau If-None-Match.

Cloud CDN menjalankan validasi ini sedikit berbeda, bergantung pada apakah respons di-cache atau tidak menggunakan permintaan rentang byte:

  • Jika respons di-cache menggunakan permintaan rentang byte, Cloud CDN akan memulai permintaan validasi terpisah yang menyertakan header If-Modified-Since dan/atau If-None-Match.
  • Jika tidak, Cloud CDN akan menambahkan header If-Modified-Since dan/atau If-None-Match ke permintaan klien dan meneruskan permintaan yang diubah ke backend.

Jika salinan yang di-cache masih yang terbaru, backend dapat memvalidasi entri cache yang ada dengan mengirimkan respons 304 Not Modified. Dalam hal ini, backend hanya mengirimkan header respons, bukan isi respons. Cloud CDN menyisipkan header respons baru ke dalam cache, memperbarui waktu habis masa berlaku, dan menayangkan header respons baru dan isi respons yang di-cache ke klien.

Jika respons yang di-cache sebelumnya tidak memiliki header Last-Modified atau ETag, Cloud CDN akan mengabaikan entri cache yang telah habis masa berlakunya dan meneruskan permintaan klien ke backend yang tidak diubah.

Dukungan untuk permintaan rentang byte

Respons yang memenuhi kriteria berikut menunjukkan bahwa server asal mendukung permintaan rentang byte:

  • Kode status: 200 OK atau 206 Partial Content
  • Header: Accept-Ranges: bytes
  • Header: Content-Length dan/atau Content-Range
  • Header: Last-Modified dan/atau ETag dengan validator yang kuat

Cloud Storage mendukung permintaan rentang byte untuk sebagian besar objek. Namun, Cloud Storage tidak mendukung permintaan rentang byte untuk objek dengan metadata Content-Encoding: gzip kecuali jika permintaan klien menyertakan header Accept- Encoding: gzip. Jika Anda memiliki objek Cloud Storage yang lebih besar dari 10 MB, pastikan objek tersebut tidak memiliki metadata Content-Encoding: gzip. Untuk mengetahui informasi tentang cara mengedit metadata objek, baca Melihat dan mengedit metadata objek.

Perangkat lunak server web populer juga mendukung permintaan rentang byte. Lihat dokumentasi software server web Anda untuk mengetahui detail tentang cara mengaktifkan dukungan. Untuk mengetahui informasi selengkapnya tentang permintaan rentang byte, lihat spesifikasi HTTP.

Jika server asal mendukung permintaan rentang byte, cache Cloud CDN akan menolak untuk menyimpan respons yang dapat di-cache saat pertama kali diminta jika salah satu hal berikut terpenuhi:

  • Isi respons tidak lengkap karena klien hanya meminta sebagian dari konten.
  • Bodi respons lebih besar dari 1 MB (1.048.576 byte).

Jika hal ini terjadi dan responsnya akan memenuhi persyaratan kemampuan cache normal, cache akan mencatat bahwa server asal mendukung permintaan rentang byte untuk kunci cache tersebut dan meneruskan respons server asal ke klien.

Pada cache yang tidak ditemukan, cache akan memeriksa apakah server asal diketahui mendukung permintaan rentang byte. Jika permintaan rentang byte diketahui didukung untuk kunci cache, cache tidak akan meneruskan permintaan klien ke Load Balancer Aplikasi eksternal. Sebagai gantinya, cache memulai permintaan pengisian cache rentang byte-nya sendiri untuk bagian konten yang hilang. Jika server origin Anda menampilkan rentang byte yang diminta dalam respons 206 Partial Content, cache dapat menyimpan rentang tersebut untuk permintaan mendatang.

Cache menyimpan respons 206 Partial Content hanya jika diterima sebagai respons terhadap permintaan rentang byte yang dimulai oleh cache. Karena cache tidak memulai permintaan rentang byte kecuali telah mencatat sebelumnya bahwa server asal mendukung permintaan rentang byte untuk kunci cache tersebut, cache tertentu tidak menyimpan konten yang lebih besar dari 1 MB hingga konten diakses untuk kedua kalinya.

Karena sifatnya yang terdistribusi, Cloud CDN terkadang dapat mengambil potongan akhir dari asal lebih dari sekali per lokasi. Hal ini hanya memengaruhi beberapa permintaan pertama per kunci cache.

Permintaan diciutkan (penggabungan)

Permintaan menciutkan (juga disebut penggabungan) secara aktif menciutkan beberapa permintaan pengisian cache berbasis pengguna untuk kunci cache yang sama menjadi satu permintaan asal per node edge. Hal ini dapat secara aktif mengurangi beban pada asal, dan berlaku untuk permintaan item (respons yang diambil langsung) dan permintaan chunk. Cloud CDN menggunakan permintaan Range untuk mengambil objek yang lebih besar secara lebih efisien.

Penciutan permintaan diaktifkan secara default.

Permintaan yang diciutkan berperilaku dengan cara berikut:

  • Permintaan yang diciutkan akan mencatat permintaan pengisian cache dari permintaan yang ditampilkan kepada klien dan (diciutkan).
  • Pemimpin sesi yang diciutkan digunakan untuk membuat permintaan pengisian origin.
  • Meminta atribut yang bukan bagian dari kunci cache, seperti header User-Agent atau Accept-Encoding, hanya mencerminkan pemimpin sesi yang diciutkan.
  • Permintaan yang tidak memiliki kunci cache yang sama tidak dapat diciutkan.

Diagram berikut menunjukkan cara permintaan digabungkan:

Cloud CDN dengan permintaan diciutkan yang diaktifkan.
Cloud CDN dengan permintaan diciutkan diaktifkan (klik untuk memperbesar).

Sebagai perbandingan, dengan menciutkan permintaan yang dinonaktifkan atau untuk permintaan yang tidak dapat digabungkan, jumlah permintaan asal dan respons bisa sama dengan jumlah klien yang mencoba mengambil objek yang saat ini tidak di-cache.

Cloud CDN tanpa permintaan menciutkan permintaan diaktifkan.
Cloud CDN tanpa permintaan menciutkan permintaan (klik untuk memperbesar).

Untuk semua jenis permintaan, menciutkan diaktifkan secara default. Untuk jenis permintaan item, Anda dapat menonaktifkan penyingkatan. Sebaiknya nonaktifkan penciutan untuk permintaan item dalam skenario yang sangat sensitif terhadap latensi, seperti penayangan iklan, saat pemuatan origin tidak menjadi pertimbangan.

Tabel berikut merangkum perilaku dan kemampuan konfigurasi default untuk berbagai jenis permintaan.

Jenis permintaan Perilaku default Dapat Dikonfigurasi Manfaat menciutkan
Permintaan bagian Diaktifkan Tidak Dapat mengurangi bandwidth origin secara signifikan
Permintaan item Diaktifkan Ya Dapat mengurangi volume permintaan origin

Untuk menonaktifkan permintaan item yang diciutkan menggunakan Google Cloud CLI untuk bucket backend yang merujuk ke bucket Cloud Storage:

gcloud

Gunakan perintah gcloud compute backend-services atau backend-buckets:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-request-coalescing

Untuk mengaktifkan agar permintaan item diciutkan pada bucket backend menggunakan Google Cloud CLI:

gcloud

Gunakan perintah gcloud compute backend-buckets:

gcloud compute backend-buckets update BACKEND_BUCKET_NAME \
    --request-coalescing

Untuk mengaktifkan menciutkan permintaan item menggunakan Google Cloud CLI untuk layanan backend, termasuk grup VM dan backend eksternal:

gcloud

Gunakan perintah gcloud compute backend-services:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --request-coalescing

Permintaan yang dimulai oleh Cloud CDN

Jika server origin Anda mendukung permintaan rentang byte, Cloud CDN dapat mengirim beberapa permintaan ke server asal Anda sebagai reaksi terhadap satu permintaan klien. Cloud CDN dapat memulai dua jenis permintaan: permintaan validasi dan permintaan rentang byte.

Jika respons yang menunjukkan bahwa server asal Anda mendukung permintaan rentang byte untuk kunci cache tertentu telah berakhir, Cloud CDN akan memulai permintaan validasi untuk mengonfirmasi bahwa konten tidak berubah dan bahwa server asal Anda masih mendukung permintaan rentang untuk konten. Jika server asal Anda merespons dengan respons 304 Not Modified, Cloud CDN akan melanjutkan untuk menayangkan konten menggunakan rentang byte. Jika tidak, Cloud CDN akan meneruskan respons server asal Anda ke klien. Anda mengontrol waktu habis masa berlaku dengan menggunakan header respons Cache-Control dan Expires.

Saat cache tidak ditemukan, Cloud CDN memulai permintaan pengisian cache untuk sekumpulan rentang byte yang tumpang-tindih dengan permintaan klien. Jika beberapa rentang konten yang diminta oleh klien ada di dalam cache, Cloud CDN akan menyalurkan apa pun yang dapat dilakukannya dari cache dan mengirimkan permintaan rentang byte hanya untuk rentang yang hilang ke server asal Anda.

Setiap permintaan rentang byte yang dimulai oleh Cloud CDN menentukan rentang yang dimulai pada offset yang merupakan kelipatan 2.097.136 byte. Dengan kemungkinan pengecualian dari rentang akhir, setiap rentang juga berukuran 2.097.136 byte. Jika konten bukan kelipatan dari ukuran tersebut, rentang akhir akan lebih kecil. Ukuran dan offset yang digunakan dalam permintaan rentang byte dapat berubah di masa mendatang.

Sebagai contoh, pertimbangkan permintaan klien untuk byte 1.000.000 hingga 3.999.999 konten yang tidak ada di cache. Dalam contoh ini, Cloud CDN dapat memulai dua permintaan GET, satu untuk 2.097.136 byte konten pertama dan satu lagi untuk 2.097.136 byte kedua. Hal ini menghasilkan 4.194.272 byte cache yang terisi meskipun klien hanya meminta 3.000.000 byte.

Jika Anda menggunakan bucket Cloud Storage sebagai origin, setiap permintaan GET akan ditagih sebagai operasi Class B terpisah. Anda dikenai biaya untuk semua permintaan GET yang diproses oleh Cloud Storage, termasuk setiap permintaan yang dimulai oleh Cloud CDN. Jika respons disalurkan sepenuhnya dari cache Cloud CDN, tidak ada permintaan GET yang dikirim ke Cloud Storage, dan Anda tidak dikenai biaya untuk operasi Cloud Storage apa pun.

Saat Cloud CDN memulai permintaan validasi atau permintaan rentang byte, Cloud CDN tidak mencakup header khusus klien seperti Cookie atau User-Agent.

Di kolom httpRequest.userAgent Cloud Logging, Cloud-CDN-Google berarti Cloud CDN memulai permintaan.

Mengabaikan cache

Pengabaian cache memungkinkan permintaan yang berisi header permintaan tertentu mengabaikan cache, meskipun konten tersebut sebelumnya telah di-cache.

Bagian ini memberikan informasi cara mengabaikan cache dengan header HTTP, seperti Pragma dan Authorization. Fitur ini berguna jika Anda ingin memastikan bahwa pengguna atau pelanggan selalu memiliki konten terbaru yang diambil langsung dari server asal. Anda mungkin perlu melakukannya untuk pengujian, menyiapkan direktori staging, atau skrip.

Jika header yang ditentukan cocok, cache akan diabaikan untuk semua setelan mode cache, bahkan FORCE_CACHE_ALL. Pengabaian cache menyebabkan banyak cache yang tidak ditemukan jika header yang ditentukan sama untuk banyak permintaan.

Sebelum memulai

  • Pastikan Cloud CDN diaktifkan. Untuk mengetahui petunjuknya, lihat Menggunakan Cloud CDN.

  • Jika perlu, update Google Cloud CLI ke versi terbaru:

    gcloud components update

Mengonfigurasi pengabaian cache

Anda dapat menentukan hingga lima nama {i>header<i} HTTP. Nilai tidak peka huruf besar/kecil. Nama header harus berupa token kolom header HTTP yang valid. Nama header tidak boleh muncul lebih dari sekali dalam daftar header yang ditambahkan. Untuk mengetahui aturan tentang nama header yang valid, baca Cara kerja header kustom.

Konsol

  1. Di konsol Google Cloud, buka halaman Load Balancing.

    Buka halaman Load balancing

  2. Klik nama Load Balancer Aplikasi eksternal Anda.
  3. Klik Edit .
  4. Di Backend configuration, pilih backend lalu klik Edit .
  5. Pastikan Enable Cloud CDN dipilih.
  6. Di bagian bawah jendela, klik Advanced configurations.
  7. Di bagian Abaikan cache pada header permintaan, klik Tambahkan header.
  8. Ketik nama header, seperti Pragma atau Authorization.
  9. Klik Perbarui.
  10. Klik Perbarui lagi.

gcloud

Untuk bucket backend, gunakan perintah gcloud compute backend-buckets create atau gcloud compute backend-buckets update dengan flag --bypass-cache-on-request-headers.

Untuk layanan backend, gunakan perintah gcloud compute backend-services create atau perintah gcloud compute backend-services update dengan flag --bypass-cache-on-request-headers.

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --bypass-cache-on-request-headers=BYPASS_REQUEST_HEADER

Contoh:

gcloud compute backend-services update my-backend-service
    --bypass-cache-on-request-headers=Pragma
    --bypass-cache-on-request-headers=Authorization

api

Untuk bucket backend, gunakan panggilan API Method: backendBuckets.insert, Method: backendBuckets.update, atau Method: backendBuckets.patch.

Untuk layanan backend, gunakan panggilan API Method: backendServices.insert, Method: backendServices.update, atau Method: backendServices.patch.

Contoh:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

Tambahkan cuplikan berikut ke isi permintaan JSON:

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": string
    }
  ]
}

Menonaktifkan pengabaian cache

gcloud

Untuk bucket backend, gunakan perintah gcloud compute backend-buckets create atau gcloud compute backend-buckets update dengan flag --no-bypass-cache-on-request-headers.

Untuk layanan backend, gunakan perintah gcloud compute backend-services create atau perintah gcloud compute backend-services update dengan flag --no-bypass-cache-on-request-headers.

gcloud compute backend-services (create | update) (BACKEND_SERVICE_NAME | BACKEND_BUCKET_NAME)
    --no-bypass-cache-on-request-headers

api

Untuk bucket backend, gunakan panggilan API Method: backendBuckets.insert atau Method: backendBuckets.update.

Untuk layanan backend, gunakan panggilan API Method: backendServices.insert atau Method: backendServices.update.

Gunakan salah satu panggilan API berikut:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE

Tambahkan cuplikan berikut ke isi permintaan JSON:

"cdnPolicy": {
  "fields": "bypassCacheOnRequestHeaders"
}

Langkah selanjutnya