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 cara respons di-cache, apakah Cloud CDN akan menerapkan perintah cache yang dikirim oleh server asal, dan cara TTL cache diterapkan.

Mode cache yang tersedia ditampilkan dalam tabel berikut:

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

Sebelum Anda menyetel 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 menyetel mode cache ke CACHE_ALL_STATIC, dan respons tidak memiliki arahan cache eksplisit di header Cache-Control atau Expires, Cloud CDN akan secara otomatis meng-cache respons tersebut untuk aset-aset 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 yang diformat, termasuk PDF (application/pdf)

Tabel berikut memberikan ringkasan.

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 tiap respons. Banyak server web yang otomatis menetapkan header Content-Type, termasuk NGINX, Varnish, dan Apache.

• Cloud Storage akan menyetel header Content-Type secara otomatis saat Anda menggunakan konsol Google Cloud atau Google Cloud CLI untuk mengupload konten.

• Cloud Storage akan 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 tidak secara tidak sengaja 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 bagian aturan kemampuan di-cache.

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 yang diautentikasi. 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. Beberapa persyaratan ini ditentukan oleh RFC 7234, dan yang lainnya khusus untuk Cloud CDN.

Cloud CDN dapat mengubah secara berkala kumpulan kondisi persisnya 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.

Untuk bucket backend Cloud Storage, ikuti saran tambahan berikut:

• Jadikan bucket Anda dapat dibaca oleh publik. Hal ini adalah pendekatan yang kami rekomendasikan untuk konten publik. Dengan setelan ini, siapa pun di internet dapat melihat dan mencantumkan objek Anda dan metadatanya, kecuali ACL. Praktik yang direkomendasikan adalah mendedikasikan bucket tertentu untuk objek publik.

• Gunakan folder terkelola untuk membuat sebagian bucket Anda dapat dibaca oleh publik.

• Membuat tiap objek dapat dibaca oleh publik. Kami tidak menyarankannya karena penggunaan ini menggunakan sistem pemberian izin khusus Cloud Storage yang lama.

• Jangan menyimpan objek di bucket yang mengaktifkan Requester Pays atau berada dalam perimeter layanan Virtual Private Cloud.

• Jangan mengenkripsi objek menggunakan kunci enkripsi yang dikelola pelanggan atau kunci enkripsi yang disediakan pelanggan.

Secara default, jika 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 bagian Menyiapkan Cloud CDN dengan bucket backend.

Ukuran maksimum

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

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

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 caching respons. Cloud CDN dapat secara berkala mengubah kumpulan kondisi persisnya 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.

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 caching semua respons.

Mencegah caching

Untuk mencegah informasi pribadi di-cache di Cloud CDN, lakukan hal-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 yang ditandatangani, 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

Tiap entri cache yang ada 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 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 untuk 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 defaultnya adalah kunci cache 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 kombinasi protokol, host, atau string kueri saat menyesuaikan kunci cache. Menggunakan kunci cache menjelaskan cara menyesuaikan kunci cache.

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

Daftar penyertaan string kueri

Anda dapat mengontrol secara selektif parameter string kueri yang disertakan Cloud CDN ke dalam kunci cache. Misalnya, jika Anda membuat daftar penyertaan user, maka 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 di 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 yang mendasarinya. Hal ini akan membatasi kebutuhan untuk membatalkan validasi konten secara proaktif dan selaras dengan alur kerja pengembangan web modern, di mana framework web dan URL 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 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), canarying, 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 pada rasio pengeluaran konten dari cache Anda. Dalam situasi normal dan kondisi traffic pengguna, 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 yang sangat tinggi. Dalam kebanyakan kasus, 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 banyaknya variasi browser, perangkat pengguna, dan sistem operasi. Jenis header ini akan berdampak negatif parah pada 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 dapat secara opsional mengonfigurasi server asal untuk menyertakan header permintaan kunci cache yang dikonfigurasi dalam respons Vary. Hal ini tidak diperlukan untuk Cloud CDN, tetapi dapat membantu 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
• Segala jenis 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 tiap 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-hal berikut:

1. Tentukan header permintaan kustom untuk layanan backend Anda. Sertakan satu atau beberapa variabel untuk nilai header permintaan kustom.
2. Update 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 tiap nilai client_city_lat_long. Hal ini pada akhirnya akan menyebabkan penggunaan cache yang berlebihan, penghapusan konten yang 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 yang berbeda

Misalkan pengguna mengirim beberapa header dengan nama yang sama dan nilai header yang 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 beberapa nilai. Cloud CDN akan menggabungkannya menjadi daftar yang 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, baik yang dipisahkan oleh titik koma pada baris yang sama, atau 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 untuk 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 akan menerima respons khusus yang di-cache atau tidak.

Jika Anda menyajikan konten statis dari nama host yang berbeda dengan nama host tempat Anda mengeluarkan cookie, pastikan atribut Domain cookie (dan atribut Path) 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.