Memecahkan masalah Cloud CDN

Pelajari langkah-langkah pemecahan masalah yang mungkin berguna jika Anda mengalami masalah berikut saat menggunakan Cloud CDN.

Jika masalah yang Anda alami terkait dengan backend eksternal, baca juga Memecahkan masalah backend eksternal dan NEG internet.

Masalah umum dan solusinya

Respons tidak di-cache

Jika respons tidak di-cache, periksa terlebih dahulu apakah Cloud CDN diaktifkan untuk layanan backend atau bucket backend Anda. Saat Anda mengaktifkan Cloud CDN, mungkin perlu waktu beberapa menit sebelum respons mulai di-cache.

Cloud CDN hanya menyimpan respons dengan konten yang dapat disimpan dalam cache. Informasi ini disampaikan dalam header respons HTTP, yang dikombinasikan dengan konfigurasi backend. Jika respons untuk URL tidak di-cache, periksa header yang ditampilkan untuk URL tersebut, dan cara kemampuan cache dikonfigurasi untuk backend Anda.

Ada beberapa cara untuk memeriksa header respons:

Di Google Chrome, panel jaringan DevTools
Di Mozilla Firefox, Developer Tools Network Monitor
Alat command line seperti curl atau GNU Wget

Contoh berikut menunjukkan penggunaan curl guna memeriksa header respons HTTP untuk http://example.com/style.css:

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

Membandingkan header ini dengan persyaratan konten yang dapat di-cache mengungkapkan bahwa respons tidak memiliki header Cache-Control yang diperlukan (dengan asumsi bahwa mode cache ditetapkan ke USE_ORIGIN_HEADERS).

Metode untuk menyetel header bergantung pada jenis server asal. Jika Anda menjalankan server web di Compute Engine, baca dokumentasi software server web untuk mengetahui detail tentang cara mengonfigurasi header respons. Untuk Cloud Storage, menandai objek sebagai dibagikan secara publik akan menyebabkan header yang sesuai dikirim.

Setelah mengonfigurasi ulang server origin untuk menambahkan header yang diperlukan, Anda dapat menggunakan curl lagi untuk memeriksa hasilnya:

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Output:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

Respons terakhir dalam contoh ini menyertakan header Age. Cloud CDN menambahkan header Age ke respons yang disalurkan dari cache. Di sini, header menunjukkan bahwa respons berhasil disalurkan dari cache menggunakan entri cache yang dibuat dua detik yang lalu.

Selain itu, jika ETags diaktifkan pada instance backend, Cloud CDN akan mengandalkan ETag untuk mengonfirmasi keaktualan objek. Jika instance backend menyajikan ETag yang berbeda pada objek yang sama, Cloud CDN menghitung ketidakcocokan sebagai cache yang tidak ditemukan dan memuat ulang objek. Untuk mencegah hal ini, instance backend harus menayangkan ETag atau ETag yang sama.

Untuk memeriksanya, jalankan curl berulang kali dan pantau perubahan dalam nilai ETag:

curl -s -D - -o /dev/null http://example.com/image.png

Output:

HTTP/2 200
date: Fri, 20 Mar 2020 15:02:30 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:20:59 GMT
etag: "10f-5a0f1256f1402"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:02:30 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

curl -s -D - -o /dev/null http://example.com/image.png

Output:

HTTP/2 200
date: Fri, 20 Mar 2020 15:03:11 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:18:31 GMT
etag: "10f-5a0f11ca09b7a"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:03:11 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

Objek Cloud Storage tidak dapat diakses

Untuk memberikan akses ke objek di Cloud Storage, Anda harus mengonfigurasi URL yang ditandatangani atau memberi bucket dan semua objeknya akses publik untuk allUsers.

Jika memutuskan untuk memberikan akses allUsers, Anda dapat memverifikasi akses tingkat objek seperti berikut.

Konsol

Di Konsol Google Cloud, buka browser Cloud Storage.
Buka browser Storage
Klik bucket untuk melihat halaman Bucket details.
Di kolom Akses publik, arahkan kursor ke ikon tanda seru dan klik Edit akses.

Untuk setiap objek di bucket, pastikan izin berikut telah ditetapkan:
- Entitas: Pengguna
- Nama: allUsers
- Akses: Pembaca

Untuk mempelajari lebih lanjut kontrol akses untuk Cloud Storage, baca dokumentasi Identity and Access Management (IAM) untuk Cloud Storage.

Untuk mempelajari lebih lanjut URL yang ditandatangani, lihat Menggunakan URL yang ditandatangani.

Jika objek dapat diakses tetapi tidak di-cache, lihat Respons tidak di-cache.

Konten pribadi di-cache, atau konten yang di-cache salah

Jika Anda mengetahui alasan server origin menyajikan konten pribadi atau yang salah dan Anda dapat memperbaiki masalah tersebut, Anda dapat membatalkan cache Cloud CDN dengan menggunakan proses berikut:

Pastikan server origin tidak lagi menampilkan konten pribadi atau konten yang salah.
Minta pembatalan validasi cache untuk memerintahkan Cloud CDN berhenti menayangkan konten yang disimpan dalam cache.

Untuk informasi lebih lanjut, lihat Ringkasan pembatalan validasi cache.

Cloud CDN hanya menyimpan respons dengan konten yang dapat disimpan dalam cache dan menampilkan respons dari cache hanya hingga waktu habis masa berlaku yang ditentukan dalam respons. Jika Anda tidak mengetahui alasan konten disimpan dalam cache atau tidak dapat memperbaiki masalah dengan cepat, sebaiknya nonaktifkan Cloud CDN sampai Anda dapat memahami dan memperbaiki masalahnya, kemudian aktifkan kembali. Untuk informasi selengkapnya tentang konten yang di-cache dan durasinya, lihat Ringkasan caching.

Rasio cache ditemukan rendah

Untuk mengoptimalkan performa dan skalabilitas, penting untuk mengoptimalkan rasio hit cache. Jika rasio cache ditemukan lebih rendah dari yang diharapkan, pastikan Anda mengikuti praktik terbaik untuk mengoptimalkan rasio hit cache.

Gunakan tabel berikut untuk memahami beberapa kemungkinan alasan terjadinya rasio hit cache yang rendah dan potensi perbaikan.

Alasan	Komentar	Perbaikan
Konten Anda tidak dapat di-cache.	Respons yang dapat di-cache adalah respons HTTP yang dapat disimpan oleh Cloud CDN.	Pastikan konten Anda dapat di-cache.
Mode cache tidak optimal untuk aplikasi Anda.	Cloud CDN memiliki beberapa mode cache.	Jika Anda tidak menggunakan header kontrol cache untuk mengontrol perilaku caching, praktik terbaik yang direkomendasikan untuk mengizinkan Cloud CDN menyimpan semua konten statis ke dalam cache.
Ada sedikit traffic.	Selama pengujian dan eksperimen, jumlah traffic yang Anda hasilkan kemungkinan rendah. Google memiliki cache terdistribusi global, dan permintaan dari lokasi geografis yang berbeda dikirim ke lokasi frontend Google yang berbeda. Di setiap lokasi frontend, Google mungkin memiliki beberapa instance cache yang terpisah.	Pastikan volume traffic yang cukup dikirim ke Google untuk mengisi semua cache yang relevan. Selama pengujian, pastikan untuk melakukan sharding traffic berdasarkan URL sehingga semua traffic untuk setiap kumpulan permintaan masuk ke Google. Jangan melakukan sharding setiap permintaan secara acak ke penyedia CDN lain.
Respons untuk URL tertentu tidak di-cache.	Cloud CDN menggabungkan URI permintaan lengkap ke dalam kunci cache-nya, sehingga `http://example.com/cat.jpg?color=orange` dan `http://example.com/cat.jpg?color=gray` memiliki entri cache yang terpisah.	Selalu gunakan satu URL untuk resource yang diberikan. Jika Anda perlu meneruskan parameter ke JavaScript yang berjalan di halaman yang tidak dapat di-cache, pertimbangkan untuk menggunakan ID fragmen, bukan string kueri.
Cache di-sharding secara tidak perlu karena adanya kolom header `Vary`.	Kolom header `Vary` dalam respons menjelaskan bagian mana dari pesan permintaan (selain metode, kolom header `Host`, dan target permintaan) yang mungkin memengaruhi proses server asal untuk memilih dan merepresentasikan respons. Contohnya, Anda mungkin ingin menggunakan header `Vary: Accept-Encoding` jika menayangkan konten yang berbeda kepada klien yang dapat menangani respons terkompresi dan yang tidak.	Gunakan header respons `Vary` hanya jika diperlukan.
Anda tidak menggunakan kunci cache kustom.	Secara default, Cloud CDN menggunakan URL permintaan lengkap untuk membuat kunci cache. Anda dapat menyesuaikan kunci cache untuk menyertakan atau menghilangkan kombinasi protokol, host, dan string kueri apa pun. Misalnya, jika dua domain menggunakan konten statis yang sama, Anda dapat membuat kunci cache kustom yang menghilangkan kolom host.	Gunakan kunci cache kustom, jika perlu.

Terdapat beberapa pengisian cache untuk konten yang sama

Secara umum, Anda dapat mengurangi jumlah pengisian cache dengan meningkatkan waktu habis masa berlaku respons yang dapat di-cache. Jika lainnya tetap sama, Anda akan melihat lebih sedikit pengisian cache untuk respons dengan Cache-Control: public, max-age=86400 dibandingkan dengan Cache-Control: public, max-age=1.

Untuk mengetahui informasi selengkapnya tentang waktu habis masa berlaku, lihat Waktu habis masa berlaku dan permintaan validasi. Untuk informasi tentang cara mengonfigurasi header respons yang sesuai, lihat dokumentasi untuk software server web Anda.

Cloud CDN mengoperasikan banyak cache di seluruh dunia, dan entri cache lama secara rutin dikeluarkan untuk memberikan ruang bagi konten baru. Akibatnya, beberapa pengisian cache per resource diharapkan sebagai bagian dari operasi normal.

Kompresi tidak berfungsi

Cloud CDN menawarkan kompresi dinamis untuk origin yang tidak dapat mengompresi responsnya. Jika memungkinkan, sebaiknya gunakan kompresi di asalnya karena dapat mengurangi biaya pengisian cache.

Jika respons yang disalurkan oleh Cloud CDN tidak dikompresi tetapi seharusnya demikian, periksa apakah software server web yang berjalan pada instance Anda dikonfigurasi untuk mengompresi respons. Secara default, beberapa software server web secara otomatis menonaktifkan kompresi untuk permintaan yang menyertakan header Via. Keberadaan header Via menunjukkan bahwa permintaan diteruskan oleh proxy. Proxy HTTP seperti Load Balancer Aplikasi eksternal menambahkan header Via ke setiap permintaan seperti yang diwajibkan oleh spesifikasi HTTP. Untuk mengaktifkan kompresi, Anda mungkin harus mengganti konfigurasi default server web untuk memintanya mengompresi respons meskipun permintaan memiliki header Via.

Jika Anda menggunakan software server web nginx, ubah file konfigurasi nginx.conf untuk mengaktifkan kompresi. Lokasi file ini bergantung pada tempat nginx diinstal. Dalam banyak distribusi Linux, file disimpan di /etc/nginx/nginx.conf.

Agar kompresi nginx berfungsi dengan Load Balancer Aplikasi eksternal Anda, tambahkan dua baris berikut ke bagian http di nginx.conf:

gzip_proxied any;
gzip_vary on;

Baris pertama memungkinkan kompresi bahkan untuk permintaan yang diteruskan oleh proxy seperti Load Balancer Aplikasi eksternal.
Baris kedua menambahkan header Vary: Accept-Encoding ke respons. Vary: Accept-Encoding memberi tahu proxy caching seperti Cloud CDN bahwa proxy harus mempertahankan entri cache terpisah untuk varian resource yang dikompresi dan tidak dikompresi.

Setelah mengubah nginx.conf, Anda perlu memulai ulang nginx sebelum menggunakan konfigurasi baru. Di banyak distribusi Linux, Anda dapat memulai ulang nginx dengan menjalankan sudo service nginx restart atau /etc/init.d/nginx restart.

Respons dihentikan dengan error byte_range_caching_aborted

Saat menyusun respons dari beberapa permintaan rentang byte, Cloud CDN memeriksa apakah rentang tersebut berasal dari versi resource yang sama dengan membandingkan header respons ETag dan Last-Modified. Jika menemukan bahwa nilai salah satu header tidak konsisten dengan rentang yang telah disalurkan ke klien, Cloud CDN akan membatalkan respons.

Jika Anda melihat respons yang dihentikan secara tidak terduga, entri log Cloud Logging dengan statusDetails byte_range_caching_aborted, atau instance Anda menampilkan respons 412 Precondition Failed, pastikan software server web yang berjalan di semua instance virtual machine (VM) menampilkan nilai ETag dan Last-Modified yang sama untuk resource tertentu.

Saat menyajikan file dari disk, software server web biasanya mendapatkan nilai ETag dan Last-Modified dari waktu modifikasi file. Dalam hal ini, Anda dapat memastikan bahwa instance VM Anda melaporkan nilai yang konsisten menggunakan image yang sama untuk semua instance. Untuk mengetahui detail tentang cara software server web Anda menentukan nilai ETag dan Last-Modified, lihat dokumentasi software server web Anda.

Memecahkan masalah cookie yang ditandatangani

Masalah berikut dapat terjadi saat Anda menggunakan cookie yang ditandatangani.

Encoding

Saat membuat tanda tangan, permintaan secara tidak terduga ditolak karena ketidakcocokan tanda tangan.

Saat mengenkode nilai URL dan Signature, pastikan Anda menggunakan varian keamanan URL dari base64. Base64 Standard akan gagal jika karakter yang dihasilkan tidak aman untuk URL. Padding diterima.

Penandatanganan

Permintaan Anda ditolak oleh Cloud CDN.

Pastikan Anda menggunakan HMAC-SHA-1 sebagai algoritme penandatanganan Anda, dan bukan varian lain dari HMAC.
Pastikan parameter KeyName (peka huruf besar/kecil) cocok dengan nama kunci yang valid untuk layanan backend atau bucket backend) yang digunakan oleh Cloud CDN.
Jangan tanda tangani parameter kueri saat membuat dan menandatangani URLPrefix. Pastikan URLPrefix hanya berisi komponen jalur skema, host, dan (sebagian) URL.
Pastikan blok tanda tangan—URLPrefix, Expires, KeyName, dan Signature—adalah bagian cookie yang dipisahkan : terakhir.
Pastikan URLPrefix, Expires, KeyName, dan Signature terjadi dalam urutan tersebut.
Jangan sertakan karakter tanda bintang (*) di akhir URLPrefix dalam cookie yang ditandatangani.

Cookie

Browser biasanya membatasi cookie hingga 4 KB per domain, dengan total batas 50 cookie per domain. Perhatikan cookie lain yang Anda keluarkan dan yang mengharuskan klien untuk mengirimnya, karena banyak server web juga memiliki batas header permintaan maksimum.
Pastikan Anda menggunakan karakter titik dua (:), titik kode Unicode U+003A, sebagai pembatas untuk parameter bernama dalam cookie yang ditandatangani, dan bukan karakter ampersand (&).
Pastikan stempel waktu Expires pada cookie yang Anda keluarkan tidak terlalu singkat. Periode validitas yang kurang dari satu hingga dua menit mungkin rentan terhadap masalah clock condong antara aplikasi yang menerbitkan dan infrastruktur Cloud CDN.
Pastikan Anda tidak menetapkan beberapa cookie untuk Domain dan Path yang sama dengan nilai yang berbeda. Menetapkan satu cookie per pengguna dengan nilai awalan URL yang mencakup semua konten yang perlu diakses pengguna.

Pesan error

Error pembatalan validasi cache

Kode error Notes

Kode error	Notes
`Invalid value for field 'resource.path'`	Nilai jalur memiliki format yang tidak valid. Jalur harus dimulai dengan `/`, tidak boleh berisi `?` atau `#`, dan hanya boleh memiliki satu `*`, yang harus berupa karakter akhir setelah `/`. Jalur tidak boleh lebih dari 1.024 karakter. Jika Anda menerima error ini, periksa nilai jalur dan perbaiki error format yang ada. Error ini hanya mengatasi format jalur. Jalur yang memiliki format valid, tetapi tidak ada, akan tetap diperlakukan sebagai valid.
`Rate Limit Exceeded`	Cloud CDN membatasi tingkat operasi pembatalan validasi cache yang dapat dilakukan. Hanya satu pembatalan validasi per menit yang diizinkan. Namun, setiap operasi dapat menentukan pola jalur yang cocok dengan sejumlah objek.

Invalid value for field 'resource.path'

Nilai jalur memiliki format yang tidak valid. Jalur harus dimulai dengan /, tidak boleh berisi ? atau #, dan hanya boleh memiliki satu *, yang harus berupa karakter akhir setelah /.

Jalur tidak boleh lebih dari 1.024 karakter. Jika Anda menerima error ini, periksa nilai jalur dan perbaiki error format yang ada.

Error ini hanya mengatasi format jalur. Jalur yang memiliki format valid, tetapi tidak ada, akan tetap diperlakukan sebagai valid.

Rate Limit Exceeded Cloud CDN membatasi tingkat operasi pembatalan validasi cache yang dapat dilakukan. Hanya satu pembatalan validasi per menit yang diizinkan. Namun, setiap operasi dapat menentukan pola jalur yang cocok dengan sejumlah objek.

Masalah umum

Pembatalan validasi cache dibatasi hingga satu pembatalan per peta URL per menit.

Penyelesaian: Tunggu setidaknya satu menit sebelum mencoba membatalkan peta URL lainnya.

Untuk mengetahui informasi selengkapnya tentang pembatasan kapasitas pembatalan validasi cache, lihat Batasan.