Ringkasan caching

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 di-cache.

Mode cache

Dengan mode cache, Anda dapat mengontrol faktor yang menentukan apakah Cloud CDN meng-cache konten Anda atau tidak.

Cloud CDN menawarkan tiga mode cache, yang menentukan bagaimana respons di-cache, apakah Cloud CDN akan mematuhi perintah cache yang dikirim oleh server asal atau tidak, dan cara TTL cache diterapkan.

Mode cache yang tersedia ditampilkan dalam tabel berikut:

Mode cache Perilaku
CACHE_ALL_STATIC Otomatis meng-cache respons yang berhasil dengan konten statis yang secara umum dapat di-cache. Respons server asal yang menetapkan perintah caching yang valid juga akan di-cache.

Perilaku ini bersifat default untuk backend yang diaktifkan Cloud CDN yang dibuat menggunakan Google Cloud CLI atau REST API.
USE_ORIGIN_HEADERS Memerlukan respons server asal yang berhasil untuk menetapkan header caching dan perintah cache yang valid. Respons yang berhasil tanpa perintah ini akan diteruskan dari server asal.
FORCE_CACHE_ALL Meng-cache respons yang berhasil tanpa syarat, dengan menggantikan semua perintah cache yang ditetapkan oleh server asal. Mode ini tidak sesuai jika backend menyajikan konten pribadi per pengguna (dapat mengidentifikasi pengguna), seperti respons API atau HTML dinamis.

Respons error dapat di-cache meskipun tanpa perintah cache yang valid.

Sebelum Anda menetapkan mode cache ke FORCE_CACHE_ALL, pertimbangkan perilaku berikut:

  • Untuk URL bertanda tangan atau cookie bertanda tangan, FORCE_CACHE_ALL menggantikan usia maksimum yang ditentukan melalui setelan Cache entry maximum age 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 memiliki TTL yang lebih panjang daripada header server asal) menjadi dianggap tidak berlaku, dan dapat menyebabkan hal sebaliknya.

  • FORCE_CACHE_ALL menggantikan perintah cache (Cache-Control dan Expires), tetapi tidak menggantikan header respons server asal lainnya. Secara khusus, header Vary dapat menonaktifkan caching meskipun mode cache adalah FORCE_CACHE_ALL. Untuk mengetahui informasi selengkapnya, baca bagian Header vary.

Untuk mengetahui petunjuk penyiapan, baca bagian Menetapkan mode cache.

Konten statis

Konten statis adalah konten yang selalu sama, meskipun diakses oleh pengguna yang berbeda. CSS yang Anda gunakan untuk menata gaya situs, dan JavaScript yang digunakan untuk menyediakan interaktivitas, video, serta konten gambar biasanya tidak akan berubah untuk tiap pengguna pada URL tertentu (kunci cache), sehingga diuntungkan dengan di-cache di seluruh jaringan edge global Cloud CDN.

Jika Anda menetapkan mode cache ke CACHE_ALL_STATIC, dan respons tidak memiliki perintah cache eksplisit di header Cache-Control atau Expires, Cloud CDN akan otomatis meng-cache 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 berformat, 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 akan memeriksa header respons HTTP Content-Type, yang mencerminkan jenis MIME konten yang disajikan.

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 Anda menggunakan Konsol Google Cloud atau Google Cloud CLI untuk mengupload konten.

  • Cloud Storage selalu menyediakan header Cache-Control ke Cloud CDN. Jika tidak ada nilai yang dipilih secara eksplisit, nilai default akan dikirim. Akibatnya, semua respons Cloud Storage yang berhasil akan 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 mengganti nilai yang dikirim oleh Cloud Storage.

  • Jika Anda ingin meng-cache jenis konten text/html dan application/json, Anda harus menetapkan header Cache-Control eksplisit dalam respons, dengan berhati-hati agar jangan sampai meng-cache data salah satu pengguna dan menyajikannya kepada semua pengguna.

Jika suatu respons dapat di-cache berdasarkan jenis MIME-nya, tetapi memiliki header respons Cache-Control dari private atau no-store, atau header Set-Cookie, respons tersebut tidak akan di-cache. Untuk mempelajari lebih lanjut, baca aturan cacheability.

Jenis konten lainnya, seperti HTML (text/html) dan JSON (application/json), tidak di-cache secara default untuk respons yang berhasil. Jenis respons ini biasanya bersifat dinamis (per pengguna). Contohnya mencakup keranjang belanja, halaman produk dengan personalisasi pengguna, dan respons API terautentikasi. Namun, caching negatif, jika diaktifkan, masih dapat menyebabkan respons di-cache untuk kode status tertentu.

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

Konten yang dapat di-cache

Cloud CDN akan meng-cache respons yang memenuhi semua persyaratan di bagian ini. Sebagian persyaratan ini ditentukan oleh RFC 7234, dan yang sebagian lainnya khusus untuk Cloud CDN.

Cloud CDN dapat mengubah secara berkala kumpulan kondisi persis yang digunakan untuk meng-cache konten. Jika Anda ingin secara eksplisit mencegah Cloud CDN meng-cache konten Anda, ikuti panduan dalam RFC 7234 untuk menentukan cara menetapkan respons yang dijamin tidak dapat di-cache. Baca juga bagian konten yang tidak dapat di-cache berdasarkan header server asal.

Cloud CDN akan menyimpan respons dalam cache jika semua hal berikut benar.

Atribut Persyaratan
Disajikan oleh Layanan backend, bucket backend, atau backend eksternal dengan Cloud CDN aktif
Sebagai respons atas Permintaan GET
Kode status

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

Respons memiliki header Cache-Control dengan perintah max-age atau s-maxage, atau header Expires dengan stempel waktu pada 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 akan tetap memenuhi syarat untuk di-cache.

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

Jika caching negatif diaktifkan dan kode status cocok dengan kode yang TTL-nya ditentukan oleh caching negatif, respons akan memenuhi syarat untuk di-cache, meskipun tanpa perintah keaktualan yang eksplisit.
Isi

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

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

Untuk mengetahui respons dengan ukuran antara 10 MiB dan 100 GiB, lihat batasan cacheability tambahan yang dijelaskan dalam permintaan rentang byte.

Untuk bucket backend Cloud Storage, ikuti saran tambahan berikut:

Secara default, saat objek disetel ke 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, baca Menyiapkan Cloud CDN dengan bucket backend.

Ukuran maksimum

Cloud CDN memberlakukan ukuran maksimum untuk setiap respons. Respons dengan isi yang lebih besar daripada ukuran maksimum tidak akan di-cache, tetapi akan tetap dikirim ke klien.

Ukuran maksimum bervariasi, tergantung apakah server asal mendukung permintaan rentang byte atau tidak.

Server asal mendukung permintaan rentang byte Server asal tidak mendukung permintaan rentang byte
100 GiB (107.374.182.400 byte) 10 MiB (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 server asal

Ada pemeriksaan yang memblokir caching respons. Cloud CDN dapat secara berkala mengubah kumpulan kondisi persis yang digunakan untuk meng-cache konten. Jadi, jika Anda ingin secara eksplisit mencegah Cloud CDN meng-cache konten Anda, ikuti panduan dalam standar (RFC 7234) untuk menentukan cara menetapkan respons yang dijamin tidak dapat di-cache.

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

Atribut Persyaratan
Disajikan oleh Layanan backend atau backend eksternal yang tidak memiliki Cloud CDN aktif
Cookie Memiliki header Set-Cookie
Header Vary 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, yang dalam hal ini header Cache-Control diabaikan)
Perintah permintaan Permintaan memiliki perintah Cache-Control: no-store
Otorisasi permintaan Permintaan memiliki header Authorization, kecuali jika diganti oleh Cache-Control respons.
Ukuran Lebih besar daripada ukuran maksimum

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

  • Penandatanganan URL dikonfigurasi.
  • Mode cache Cloud CDN disetel untuk memaksa caching semua respons.

Mencegah caching

Untuk mencegah informasi pribadi di-cache di Cloud CDN, lakukan hal 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 cache browser web.
  3. Jangan menandatangani URL yang memberikan akses ke informasi pribadi. Saat diakses menggunakan URL bertanda tangan, konten berpotensi memenuhi syarat untuk di-cache terlepas dari adanya perintah Cache-Control dalam respons.
  4. Untuk permintaan server asal (pengisian cache) yang menyertakan header permintaan Authorization, Cloud CDN hanya 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 konten per pengguna dan konten yang memerlukan autentikasi di-cache secara tidak sengaja. Mode cache FORCE_CACHE_ALL tidak memiliki batasan ini.

Header respons kustom

Dengan header respons kustom, Anda dapat menentukan header yang ditambahkan Load Balancer Aplikasi klasik ke respons yang di-proxy-kan. Dengan header respons kustom, Anda dapat mencerminkan status cache ke klien, data geografis klien, dan header respons statis Anda sendiri.

Untuk mengetahui petunjuknya, baca bagian Mengonfigurasi header respons kustom.

Kunci cache

Setiap entri cache yang ada di cache Cloud CDN diidentifikasi oleh kunci cache. Saat permintaan masuk ke cache, cache ini akan mengonversi URI permintaan menjadi kunci cache, lalu membandingkannya dengan kunci entri yang di-cache. Jika menemukan kecocokan, cache akan menampilkan 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 bagi permintaan tertentu untuk objek cat.jpg. String ini digunakan sebagai kunci cache default. Hanya permintaan dengan string yang sama persis ini yang cocok. Permintaan untuk http://example.com/images/cat.jpg atau https://example.com/images/cat.jpg?user=user1 tidak cocok.

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

Jadi, untuk bucket backend tertentu, URI berikut di-resolve ke objek yang sama yang 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 dalam kunci cache. Meskipun nama file dan jalur harus selalu menjadi bagian dari kunci, Anda dapat menyertakan atau menghilangkan salah satu dari protokol, host, atau string kueri saat menyesuaikan kunci cache. Menggunakan kunci cache menjelaskan cara menyesuaikan kunci cache.

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

Menghilangkan string kueri dari kunci cache.

Menghilangkan atau menyertakan sebagian string kueri secara selektif.
  • 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 bagian-bagian string kueri dengan memanfaatkan daftar penyertaan dan daftar pengecualian.

Daftar penyertaan string kueri

Anda dapat mengontrol secara selektif parameter string kueri mana saja yang disertakan 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.

Daftar penyertaan string kueri untuk kunci cache Cloud Storage

Menyertakan parameter kueri URL dalam kunci cache untuk bucket Cloud Storage membantu mendukung cache busting. Dengan cache busting, pengguna dapat mengambil versi baru dari file yang telah diupload, meskipun versi sebelumnya masih di-cache secara valid berdasarkan setelan TTL.

Anda dapat menggunakan daftar penyertaan dengan parameter string kueri 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 agar dapat membatalkan cache konten statis yang disimpan di bucket Cloud Storage.

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

Karena penyertaan parameter kueri dalam kunci cache hanya dapat diaktifkan secara manual, Cloud CDN tidak mendukung pengecualian parameter kueri dari kunci cache ke bucket backend.

Daftar pengecualian string kueri

Anda dapat mengontrol secara selektif parameter string kueri mana saja yang diabaikan Cloud CDN menggunakan daftar pengecualian. Misalnya, jika Anda membuat daftar pengecualian user, semua parameter string kueri kecuali user akan digunakan dalam 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 header HTTP dan cookie HTTP

Anda dapat meningkatkan rasio cache ditemukan dan pengurangan beban server asal dengan setelan konfigurasi kunci cache berikut:

  • Untuk layanan backend dan bucket: Gunakan header HTTP sebagai bagian dari kunci cache dengan menyertakan header bernama dalam konfigurasi kunci cache.
  • Khusus untuk layanan backend: Gunakan cookie HTTP bernama sebagai kunci cache, seperti 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. Hal ini akan mengurangi dampak nilai header atau cookie kardinalitas tinggi terhadap rasio penghapusan cache. Dalam situasi dan kondisi traffic pengguna yang normal, hal ini tidak akan terlihat dan akan membantu memastikan konten populer tetap di-cache.

Menyertakan header permintaan

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

Beberapa header tidak diizinkan dalam kunci cache karena biasanya memiliki kardinalitas sangat tinggi. Dalam kebanyakan kasus, nilai header ini dapat 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 banyaknya variasi browser, perangkat pengguna, dan sistem operasi. Jenis header ini akan berdampak sangat negatif terhadap rasio cache ditemukan.

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

Anda juga dapat mengonfigurasi server asal untuk menyertakan header permintaan kunci cache yang telah dikonfigurasi dalam respons Vary. Meskipun tidak wajib untuk Cloud CDN, hal ini dapat berguna untuk cache downstream. Untuk mengetahui informasi selengkapnya, baca bagian Header vary.

Cloud CDN tidak mengizinkan header berikut disertakan dalam daftar header:

  • Accept
  • Accept-Encoding
  • Authority, karena header ini dikontrol oleh konfigurasi (cdnPolicy.includeHost)
  • Authorization, biasanya per pengguna seperti pada token OAuth Bearer
  • CDN-Loop
  • Connection
  • Content-MD5
  • Content-Type
  • Cookie
  • Date
  • Forwarded, sering kali per klien atau per proxy
  • From
  • Host, karena header 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
  • Semua header yang diawali dengan:
    • 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-

Menggunakan variabel kustom dengan header permintaan

Kunci cache berguna saat Anda perlu menyajikan konten secara berbeda berdasarkan perangkat dan lokasi setiap pengguna. Misalnya, Anda dapat mengaktifkan situs responsif untuk menyajikan gambar yang sesuai bagi pengguna yang melihat konten berdasarkan jenis perangkat mereka atau menetapkan bahasa default yang berguna berdasarkan lokasi mereka. Anda dapat menentukan kunci cache menggunakan header permintaan kustom dan variabel kustom.

Untuk menggunakan variabel kustom dengan header permintaan, lakukan hal berikut:

  1. Tentukan header permintaan kustom untuk layanan backend Anda. Sertakan satu atau beberapa variabel untuk nilai header permintaan kustom.
  2. Perbarui kunci cache untuk menggunakan header permintaan kustom.

Untuk Cloud CDN, Anda hanya dapat menggunakan variabel berikut saat menentukan header yang merupakan header permintaan kustom dan header kunci cache:

  • device_request_type
  • user_agent_family
  • client_region
  • client_region_subdivision

Cloud CDN membatasi variabel untuk membantu mempertahankan performa cache. Hal ini mirip dengan batas pada header yang dapat digunakan sebagai kunci cache.

Misalnya, jika Anda dapat menentukan X-Lat-Long:{client_city_lat_long} sebagai header permintaan kustom, lalu menambahkan X-Lat-Long ke kumpulan header kunci cache, Cloud CDN akan mencoba meng-cache satu salinan respons untuk setiap nilai client_city_lat_long. Hal ini pada akhirnya akan menimbulkan penggunaan cache secara berlebih, penghapusan konten secara tidak perlu, dan berkurangnya peluang untuk menampilkan cache ditemukan.

Karena alasan tersebut, variabel yang memiliki kardinalitas tinggi tidak akan disertakan dalam daftar variabel yang digunakan untuk menentukan header permintaan kustom dan selanjutnya kunci cache.

Header yang sama dengan nilai berbeda

Misalkan pengguna mengirim beberapa header bernama sama, tetapi dengan header berbeda:

My-Header: Value1
My-Header: Value2

Dalam hal ini, Cloud CDN akan mengubah permintaan dengan mengasumsikan bahwa header harus mengikuti konvensi standar yang memungkinkan beberapa header memiliki banyak nilai. Cloud CDN akan menggabungkannya ke dalam daftar dipisahkan koma untuk dikirim ke backend, sehingga seolah-olah klien mengirimkan hal berikut:

My-Header: Value1, Value2

Menyertakan cookie bernama

Cookie HTTP adalah pasangan name=value, dan permintaan dapat menyertakan beberapa cookie HTTP, entah itu yang dipisahkan oleh titik koma pada baris yang sama, atau sebagai header permintaan Cookie diskret dengan satu cookie per header.

Anda dapat memberikan daftar hingga lima nama cookie.

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

Jika Anda menyajikan konten statis dari nama host yang berbeda dengan nama host tempat Anda menerbitkan cookie, pastikan atribut Domain (dan Path) cookie memungkinkan cookie dikirim bersama dengan permintaan konten statis.

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

Perintah kontrol cache

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

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

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

Respons dengan no-store tidak akan di-cache.

Perilaku ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL.

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

Respons dengan no-cache akan di-cache, tetapi harus divalidasi ulang dengan server asal sebelum disajikan.

Perilaku ini dapat diganti per backend dengan mode cache FORCE_CACHE_ALL.

public T/A

Perintah ini tidak diperlukan untuk cacheability, tetapi sebaiknya disertakan untuk konten yang harus di-cache oleh proxy.

private T/A

Respons dengan perintah private tidak akan di-cache oleh Cloud CDN, meskipun respons tersebut biasanya dianggap dapat di-cache. Klien (seperti browser) mungkin masih akan meng-cache hasilnya.

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

max-age=SECONDS Perintah permintaan max-age akan diabaikan. Respons yang di-cache akan ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. Respons dengan perintah max-age akan di-cache hingga SECONDS yang ditentukan.
s-maxage=SECONDS T/A

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

Jika max-age dan s-maxage ada, s‑maxage akan digunakan oleh Cloud CDN.

Respons dengan perintah ini tidak akan disajikan jika sudah tidak berlaku.

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

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

Perintah permintaan max-stale menentukan keadaan tidak berlaku maksimum (dalam detik) yang klien bersedia terima.

Cloud CDN akan mematuhi hal ini, dan akan menampilkan respons cache yang tidak berlaku hanya jika keadaan tidak berlaku respons tersebut kurang dari perintah max-stale. Jika tidak, permintaan akan divalidasi ulang sebelum disajikan.

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

Respons dengan stale-while-revalidate akan disajikan kepada klien selama maksimum SECONDS selagi validasi ulang berlangsung secara asinkron.

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

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

Header respons ini tidak berpengaruh.

must-revalidate T/A

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

Respons dengan perintah ini tidak akan disajikan jika sudah tidak berlaku.

proxy-revalidate

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

Respons dengan perintah ini tidak akan disajikan jika sudah tidak berlaku.

immutable T/A Tidak berpengaruh. Perintah ini akan 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 akan diabaikan. Respons yang di-cache akan ditampilkan seolah-olah header ini tidak disertakan dalam permintaan. T/A

Jika memungkinkan, Cloud CDN akan berupaya mematuhi RFC (HTTP RFC 7234), tetapi lebih memilih mengoptimalkan pengurangan beban cache dan meminimalkan dampak yang dapat ditimbulkan klien terhadap rasio cache ditemukan dan beban server asal 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 pada masa lalu, tanggal yang tidak valid, atau nilai 0 menunjukkan bahwa konten telah habis masa berlakunya dan perlu divalidasi ulang.
  • Jika header Cache-Control ada dalam respons, Cloud CDN akan mengabaikan header Expires.

Keberadaan header Expires mendatang yang valid dalam respons membuat respons tersebut dapat di-cache, dan tidak memerlukan penentuan perintah cache lainnya.

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

Header Vary

Header Vary menunjukkan bahwa respons bervariasi bergantung pada header permintaan klien. Selain URI permintaan, Cloud CDN mematuhi header Vary yang disertakan 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 satu entri lagi untuk permintaan yang menentukan Accept: */*.

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

Mode cache FORCE_CACHE_ALL tidak akan menggantikan perilaku ini. Header Vary penting untuk menghindari cache poisoning di antara beberapa kemungkinan respons server asal. Akan berbahaya jika FORCE_CACHE_ALL membuat respons-respons tersebut dapat di-cache.

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

Saat menggunakan header HTTP dalam kunci cache, Cloud CDN akan meng-cache beberapa salinan respons berdasarkan nilai header permintaan yang ditentukan, mirip dengan dukungan Vary, tetapi tanpa keharusan bagi server asal untuk menentukan header respons Vary secara eksplisit. Jika server asal menentukan header kunci cache dalam respons Vary, Cloud CDN akan memperlakukan respons dengan benar, seolah-olah header tersebut 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 untuk konten buatan pengguna yang tidak berlaku dan di-cache.

Saat menerima permintaan, Cloud CDN akan mencari entri cache yang sesuai dan memeriksa usianya. Jika entri cache tersebut ada dan cukup baru, respons dapat disajikan dari cache. Jika waktu habis masa berlakunya telah berlalu, Cloud CDN akan mencoba memvalidasi ulang entri cache dengan menghubungi salah satu backend Anda. Hal ini dilakukan sebelum menyajikan respons, kecuali jika Anda mengaktifkan serve-while-stale, yang dalam hal ini validasi ulang dilakukan secara asinkron.

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

Mode cache memengaruhi cara keaktualan ditentukan.

Mode cache Perilaku validasi
CACHE_ALL_STATIC Header server asal (header Cache-Control: s-maxage, Cache-Control: max-age, atau Expires) diperiksa untuk menentukan keaktualan. Untuk konten statis, jika header server asal tidak ada, default_ttl yang dikonfigurasi akan menentukan keaktualan. Setelah usia konten statis lebih lama daripada default_ttl, Cloud CDN akan memvalidasi ulang konten tersebut.
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 server asal, default_ttl yang dikonfigurasi akan menentukan keaktualan. Setelah usia konten lebih lama daripada default_ttl, Cloud CDN akan memvalidasi ulang konten tersebut.

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

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

Pengeluaran konten

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

Untuk mengetahui informasi selengkapnya, baca bagian Pengeluaran konten dan waktu habis masa berlaku.

Menggunakan permintaan bersyarat untuk validasi

Cloud CDN dapat mencoba menggunakan informasi dalam header respons yang di-cache untuk memvalidasi entri cache dengan backend. Hal ini terjadi saat 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 akan melakukan validasi ini dengan sedikit berbeda, tergantung apakah respons di-cache menggunakan permintaan rentang byte atau bukan:

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

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

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

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 untuk respons 206 Partial Content, nilai Content-Range yang menunjukkan panjang lengkap objek server asal. Misalnya, Content-length: 0-100/999 dapat di-cache, sedangkan Content-length: 0-100/* tidak.
  • Header: Last-Modified dan 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 berukuran di atas 10 MB, pastikan objek tersebut tidak memiliki metadata Content-Encoding: gzip. Untuk mengetahui informasi tentang cara mengedit metadata objek, baca bagian Melihat dan mengedit metadata objek.

Software server web populer juga mendukung permintaan rentang byte. Baca dokumentasi server web Anda untuk mengetahui detail tentang cara mengaktifkan dukungan. Untuk mengetahui informasi selengkapnya tentang permintaan rentang byte, baca bagian Spesifikasi HTTP.

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

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

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

Jika terjadi cache tidak ditemukan, cache akan memeriksa apakah server asal diketahui mendukung permintaan rentang byte atau tidak. Jika permintaan rentang byte diketahui didukung untuk kunci cache, cache tidak akan meneruskan permintaan klien ke Load Balancer Aplikasi eksternal. Sebagai gantinya, cache akan memulai permintaan pengisian cache rentang byte-nya sendiri untuk bagian konten yang hilang.

Server asal akan menampilkan respons 206 Partial Content saat Cloud CDN memulai permintaan pengisian cache rentang byte-nya sendiri. Agar respons 206 Partial Content dipertimbangkan saat melakukan caching, respons tersebut harus menyertakan header Content-Range dengan perintah complete-length yang tidak menyertakan tanda bintang, misalnya 0-100/999. Cloud CDN kemudian akan meng-cache respons 206 Partial Content yang ditampilkan itu dan menggunakannya untuk merespons permintaan klien selanjutnya untuk konten tersebut.

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

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

Penggabungan permintaan (perpaduan)

Penggabungan permintaan (disebut juga perpaduan) secara aktif menggabungkan beberapa permintaan pengisian cache yang dipicu pengguna untuk kunci cache yang sama menjadi satu permintaan server asal per node edge. Hal ini dapat mengurangi beban pada server asal secara aktif, dan berlaku baik untuk permintaan item (respons diambil langsung) maupun permintaan potongan, di mana Cloud CDN menggunakan permintaan Range untuk mengambil objek yang lebih besar secara lebih efisien.

Penggabungan permintaan diaktifkan secara default.

Permintaan yang digabungkan berperilaku dengan cara berikut:

  • Permintaan yang digabungkan mencatat permintaan yang terlihat klien dan permintaan pengisian cache (yang digabungkan).
  • Leader sesi yang digabungkan digunakan untuk membuat permintaan pengisian server asal.
  • Atribut permintaan yang bukan bagian dari kunci cache, seperti header User-Agent atau Accept-Encoding, hanya mencerminkan leader sesi yang digabungkan.
  • Permintaan yang tidak memiliki kunci cache yang sama tidak dapat digabungkan.

Diagram berikut menunjukkan bagaimana permintaan digabungkan:

Cloud CDN dengan penggabungan permintaan diaktifkan.
Cloud CDN dengan penggabungan permintaan diaktifkan (klik untuk memperbesar).

Sebagai perbandingan, jika penggabungan permintaan dinonaktifkan atau untuk permintaan yang tidak dapat digabungkan, jumlah permintaan server asal dan respons dapat sama dengan jumlah klien yang mencoba mengambil objek yang tidak di-cache.

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

Untuk semua jenis permintaan, penggabungan diaktifkan secara default. Untuk jenis permintaan item, Anda dapat menonaktifkan penggabungan. Sebaiknya nonaktifkan penggabungan untuk permintaan item dalam skenario yang sangat sensitif terhadap latensi, seperti penayangan iklan, di mana beban server asal tidak dipertimbangkan.

Tabel berikut merangkum perilaku default dan konfigurabilitas berbagai jenis permintaan.

Jenis permintaan Perilaku default Dapat dikonfigurasi Manfaat penggabungan
Permintaan potongan Diaktifkan Tidak Dapat mengurangi bandwidth server asal secara signifikan
Permintaan item Diaktifkan Ya Dapat mengurangi volume permintaan server asal

Untuk menonaktifkan penggabungan permintaan item menggunakan Google Cloud CLI untuk bucket backend yang merujuk kepada 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 penggabungan permintaan item di 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 penggabungan 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 asal mendukung permintaan rentang byte, Cloud CDN dapat mengirim beberapa permintaan ke server asal sebagai respons terhadap satu permintaan klien. Cloud CDN dapat memulai dua jenis permintaan: permintaan validasi dan permintaan rentang byte.

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

Dalam kasus cache tidak ditemukan, Cloud CDN akan memulai permintaan pengisian cache untuk serangkaian rentang byte yang tumpang-tindih dengan permintaan klien. Jika beberapa rentang konten yang diminta klien ada di dalam cache, Cloud CDN akan menyajikan apa pun yang dapat disajikannya dari cache itu dan mengirim permintaan rentang byte ke server asal hanya untuk rentang yang tidak ada.

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

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

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

Saat memulai permintaan validasi atau permintaan rentang byte, Cloud CDN tidak akan menyertakan header spesifik per klien seperti Cookie atau User-Agent.

Di kolom httpRequest.userAgent Cloud Logging, Cloud-CDN-Google menunjukkan bahwa permintaan dimulai oleh Cloud CDN.

Mengabaikan cache

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

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

Jika header yang ditentukan cocok, cache akan diabaikan untuk semua setelan mode cache, bahkan FORCE_CACHE_ALL. Pengabaian cache akan mengakibatkan sejumlah besar cache tidak ditemukan jika header yang ditentukan bersifat umum untuk banyak permintaan.

Sebelum memulai

  • Pastikan Cloud CDN diaktifkan. Untuk mengetahui petunjuknya, baca bagian Menggunakan Cloud CDN.

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

    gcloud components update

Mengonfigurasi pengabaian cache

Anda dapat menentukan hingga lima nama header 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 bagian 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 Bypass cache on request header, klik Add header.
  8. Ketik nama header, seperti Pragma atau Authorization.
  9. Klik Update.
  10. Klik Update 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 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 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 berikutnya