Cara kerja pembuatan cache

Artikel ini menyediakan gambaran umum konsep penembolokan umum dan bagaimana Azure Content Delivery Network menggunakan penembolokan untuk meningkatkan performa. Jika Anda ingin mempelajari tentang cara menyesuaikan perilaku penembolokan pada titik akhir jaringan pengiriman konten Anda, lihat Mengontrol perilaku penembolokan Azure Content Delivery Network dengan aturan penembolokan dan Mengontrol perilaku penembolokan Azure Content Delivery Network dengan string kueri.

Pengantar pembuatan cache

Pembuatan cache adalah proses penyimpanan data secara lokal sehingga data yang nantinya diminta dapat diakses lebih cepat. Dalam jenis pembuatan cache yang paling umum, pembuatan cache browser web, browser web menyimpan salinan data statis secara lokal pada hard drive lokal. Dengan menggunakan pembuatan cache, browser web dapat menghindari melakukan beberapa jalur bolak-balik ke server dan mengakses data yang sama secara lokal, sehingga menghemat waktu dan sumber daya. pembuatan cache sangat cocok untuk mengelola data statis kecil secara lokal seperti gambar statis, file CSS, dan file JavaScript.

Demikian pula, pembuatan cache digunakan oleh jaringan pengiriman konten di server tepi yang dekat dengan pengguna untuk menghindari permintaan bepergian kembali ke asal dan mengurangi latensi pengguna akhir. Tidak seperti cache browser web, yang hanya digunakan untuk satu pengguna, jaringan pengiriman konten memiliki cache bersama. Dalam cache bersama jaringan pengiriman konten, permintaan file oleh pengguna dapat digunakan oleh pengguna lain, yang sangat mengurangi jumlah permintaan ke server asal.

Sumber daya dinamis yang sering berubah atau unik untuk pengguna individual tidak dapat di-cache. Namun, jenis sumber daya tersebut dapat memanfaatkan pengoptimalan akselerasi situs dinamis (DSA) pada jaringan pengiriman konten Azure untuk peningkatan performa.

pembuatan cache dapat terjadi pada beberapa tingkat antara server asal dan pengguna akhir:

• Server web: Menggunakan cache bersama (untuk beberapa pengguna).
• Jaringan pengiriman konten: Menggunakan cache bersama (untuk beberapa pengguna).
• Penyedia Layanan Internet (ISP): Menggunakan cache bersama (untuk beberapa pengguna).
• Browser web: Menggunakan cache pribadi (untuk satu pengguna).

Setiap cache biasanya mengelola kesegaran sumber dayanya sendiri dan melakukan validasi ketika file basi. Perilaku ini ditentukan dalam spesifikasi pembuatan cache HTTP, RFC 7234.

Kesegaran sumber daya

Karena sumber daya yang di-cache berpotensi kedaluarsa, atau basi (dibandingkan dengan sumber daya yang sesuai di server asal), penting bagi mekanisme penembolokan apa pun untuk dikontrol saat konten mendapatkan refresh. Untuk menghemat waktu dan konsumsi bandwidth, sumber daya yang di-cache tidak dibandingkan dengan versi di server asal setiap kali diakses. Sebaliknya, selama sumber daya yang di-cache dianggap baru, sumber tersebut dianggap sebagai versi terbaru dan dikirim langsung ke klien. Sumber daya yang ditembolok dianggap segar ketika usianya kurang dari usia atau periode yang ditentukan oleh pengaturan cache. Misalnya, ketika browser memuat ulang halaman web, ia memverifikasi bahwa setiap sumber daya yang ditembolok di hard drive Anda masih segar dan memuatnya. Jika sumber daya tidak segar (kedaluwarsa), salinan terbaru dimuat dari server.

Validasi

Jika sumber daya dianggap basi, server asal diminta untuk memvalidasinya untuk menentukan apakah data dalam cache masih cocok dengan apa yang ada di server asal. Jika file telah dimodifikasi pada server asal, cache memperbarui versi sumber dayanya. Jika tidak, jika sumber daya segar, data dikirim langsung dari cache tanpa memvalidasinya terlebih dahulu.

Penembolokan jaringan pengiriman konten

Penembolokan bersifat integral dengan cara jaringan pengiriman konten beroperasi untuk mempercepat pengiriman dan mengurangi beban asal untuk aset statis seperti gambar, font, dan video. Dalam penembolokan jaringan pengiriman konten, sumber daya statis disimpan secara selektif di server yang ditempatkan secara strategis yang lebih lokal bagi pengguna dan menawarkan keuntungan berikut:

• Karena sebagian besar lalu lintas web statis (misalnya, gambar, font, dan video), penembolokan jaringan pengiriman konten mengurangi latensi jaringan dengan memindahkan konten lebih dekat dengan pengguna, sehingga mengurangi jarak yang ditempuh data.

• Dengan membongkar pekerjaan ke jaringan pengiriman konten, penembolokan dapat mengurangi lalu lintas jaringan dan beban di server asal. Melakukannya akan mengurangi persyaratan biaya dan sumber daya untuk aplikasi, bahkan ketika penggunanya banyak.

Mirip dengan bagaimana penembolokan diterapkan di browser web, Anda dapat mengontrol bagaimana penembolokan dilakukan di jaringan pengiriman konten dengan mengirim header direktif cache. Header yang diarahkan cache adalah header HTTP, yang biasanya ditambahkan oleh server asal. Meskipun sebagian besar header ini awalnya dirancang untuk mengatasi penembolokan di browser klien, header tersebut sekarang juga digunakan oleh semua cache perantara, seperti jaringan pengiriman konten.

Dua header dapat digunakan untuk menentukan kesegaran cache: Cache-Control dan Expires. Cache-Control lebih baru dan lebih penting dari Expires, jika keduanya ada. Ada pula dua jenis header yang digunakan untuk validasi (yang disebut validator): ETag dan Last-Modified. ETag lebih baru dan lebih penting dari Last-Modified, jika keduanya ada.

Header yang diarahkan cache

Azure Content Delivery Network mendukung header direktif cache HTTP berikut, yang menentukan durasi cache dan berbagi cache.

Cache-Control:

• Diperkenalkan di HTTP 1.1 untuk memberi penerbit web kontrol lebih besar atas konten mereka dan untuk mengatasi keterbatasan header Expires.
• Menimpa header Expires, jika keduanya dan Cache-Control ditentukan.
• Saat digunakan dalam permintaan HTTP dari klien ke jaringan pengiriman konten POP, Cache-Control diabaikan oleh semua profil Azure Content Delivery Network, secara default.
• Saat digunakan dalam respons HTTP dari server asal ke JARINGAN pengiriman konten POP, Cache-Control dihormati oleh semua profil Azure Content Delivery Network, secara default. Azure CDN juga menghormati perilaku penembolokan untuk arahan Cache-Control di RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Penembolokan (ietf.org).

Kedaluwarsa:

• Header warisan yang diperkenalkan di HTTP 1.0; didukung untuk kompatibilitas mundur.
• Menggunakan waktu kedaluwarsa berbasis tanggal dengan presisi kedua.
• Mirip dengan Cache-Control: max-age.
• Digunakan ketika Cache-Control tidak ada.

Pragma:

• Tidak dihormati oleh Azure Content Delivery Network, secara default.
• Header warisan yang diperkenalkan di HTTP 1.0; didukung untuk kompatibilitas mundur.
• Digunakan sebagai header permintaan klien dengan arahan berikut: no-cache. Arahan ini menginstruksikan server untuk memberikan versi sumber daya yang segar.
• Pragma: no-cache setara dengan Cache-Control: no-cache.

Validator

Ketika cache menjadi basi, validator cache HTTP digunakan untuk membandingkan versi ditembolok file dengan versi pada server asal. Azure CDN Standard dari Microsoft hanya Last-Modifiedmendukung .

Terakhir Diubah:

• Menentukan tanggal dan waktu bahwa server asal telah menentukan sumber daya terakhir diubah. Contohnya,Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
• Untuk konten yang lebih besar dari 8 MB, server backend asal harus mempertahankan tanda waktu yang konsisten Last-Modified per aset. Mengembalikan waktu yang tidak konsisten Last-Modified dari server backend akan menyebabkan kesalahan ketidakcocokan validator dan mengakibatkan kegagalan HTTP 5XX. Azure Storage mungkin tidak mendukung tanda waktu yang konsisten Last-Modified di seluruh replika, yang dapat menyebabkan kesalahan ketidakcocokan validator serupa.
• Cache memvalidasi file menggunakan Last-Modified dengan mengirim header If-Modified-Since dengan tanggal dan waktu dalam permintaan. Server asal membandingkan tanggal tersebut dengan header Last-Modified sumber daya terbaru. Jika sumber daya belum dimodifikasi sejak waktu yang ditentukan, server mengembalikan kode status 304 (Tidak Diubah) dalam responsnya. Jika sumber daya telah dimodifikasi, server mengembalikan kode status 200 (OK) dan sumber daya yang diperbarui.

Menentukan file mana yang dapat ditembolok

Tidak semua sumber daya dapat ditembolok. Tabel berikut ini memperlihatkan sumber daya apa yang bisa ditembolok, berdasarkan tipe respons HTTP. Sumber daya yang dikirimkan dengan respons HTTP yang tidak memenuhi semua kondisi ini tidak dapat di-cache.

Agar penembolokan berfungsi pada sumber daya, server asal harus mendukung permintaan HTTP HEAD dan GET apa pun dan nilai panjang konten harus sama untuk respons HEAD dan GET HTTP apa pun untuk aset. Untuk permintaan HEAD, server asal harus mendukung permintaan HEAD, dan harus merespons dengan header yang sama seolah-olah menerima permintaan GET.

Perilaku pembuatan cache default

Perilaku penembolokan default untuk Azure CDN adalah menghormati konten asal dan cache selama dua hari.

Asal kehormatan: Pengaturan ini menentukan apakah akan menghormati header direktif cache (Cache-Control atau Expires) jika ada dalam respons HTTP dari server asal.

Durasi cache CDN: Pengaturan ini menentukan durasi sumber daya di-cache di Azure CDN. Jika asal Honor diaktifkan dan respons HTTP dari server asal menyertakan Cache-Control: max-age header atau Expires , Azure CDN akan menggunakan durasi yang ditentukan oleh header ini alih-alih periode dua hari default.

Langkah berikutnya

• Untuk mempelajari cara menyesuaikan dan mengambil alih perilaku penembolokan default pada jaringan pengiriman konten melalui aturan penembolokan, lihat Mengontrol perilaku penembolokan Azure Content Delivery Network dengan aturan penembolokan.
• Untuk mempelajari cara menggunakan string kueri untuk mengontrol perilaku penembolokan, lihat Mengontrol perilaku penembolokan Azure Content Delivery Network dengan string kueri.