Cara kerja pembuatan cache

Artikel
03/22/2024

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

Penting

Secara default, titik akhir Azure Content Delivery Network yang dioptimalkan untuk DSA mengabaikan header direktif cache dan melewati penembolokan. Untuk profil Azure CDN Standard dari Edgio , Anda dapat menyesuaikan bagaimana titik akhir Azure Content Delivery Network memperlakukan header ini dengan menggunakan aturan penembolokan jaringan pengiriman konten untuk mengaktifkan penembolokan. Hanya untuk profil Azure CDN Premium dari Edgio , Anda menggunakan mesin aturan untuk mengaktifkan penembolokan.

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:
- Azure CDN Standard/Premium dari Edgio dan Azure CDN Standard dari Microsoft mendukung semua Cache-Control arahan.
- Azure CDN Standard/Premium dari Edgio dan Azure CDN Standard dari Microsoft 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/Premium dari Edgio mendukung ETag validator dan Last-Modified secara default, sementara Azure CDN Standard dari Microsoft hanya Last-Modifiedmendukung .

ETag:

Azure CDN Standard/Premium dari Edgio mendukung ETag secara default, sementara Azure CDN Standard dari Microsoft tidak.
ETag menentukan string yang unik untuk setiap file dan versi file. Contohnya,ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
Diperkenalkan dalam HTTP 1.1 dan lebih baru daripada Last-Modified. Berguna ketika tanggal terakhir modifikasi sulit ditentukan.
Mendukung validasi yang kuat dan validasi yang lemah; namun, Azure Content Delivery Network hanya mendukung validasi yang kuat. Untuk validasi yang meyakinkan, setiap byte kedua representasi sumber daya harus identik.
Cache memvalidasi file yang menggunakan ETag dengan mengirim header If-None-Match dengan satu atau beberapa validator ETag dalam permintaan. Contohnya,If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Jika versi server cocok dengan ETag validator dalam daftar, versi tersebut akan mengirim kode status 304 (Tidak Diubah) dalam responsnya. Jika versinya berbeda, server merespons dengan kode status 200 (OK) dan sumber daya yang diperbarui.

Terakhir Diubah:

Hanya untuk Azure CDN Standard/Premium dari Edgio , Last-Modified digunakan jika ETag bukan bagian dari respons HTTP.
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. Hanya untuk Azure CDN Premium dari Edgio , Anda dapat menggunakan mesin aturan untuk menyesuaikan beberapa kondisi ini.

	Azure Content Delivery Network dari Microsoft	Azure Content Delivery Network dari Edgio
Kode status HTTP	200, 203, 206, 300, 301, 410, 416	200
Metode HTTP	GET, HEAD	GET
Batas ukuran file	300 GB	300 GB

Untuk pembuatan cache Azure CDN Standard dari Microsoft agar berfungsi pada sumber daya, server asal harus mendukung permintaan HEAD dan GET HTTP serta nilai sepanjang konten harus sama untuk semua respons HEAD dan GET HTTP untuk aset. Untuk permintaan HEAD, server asal harus mendukung permintaan HEAD, dan harus merespons dengan header yang sama seolah-olah menerima permintaan GET.

Catatan

Permintaan yang menyertakan header otorisasi tidak akan di-cache.

Perilaku pembuatan cache default

Tabel berikut ini menjelaskan perilaku penembolokan default untuk produk Azure Content Delivery Network dan pengoptimalannya.

	Microsoft: Pengiriman web umum	Edgio: Pengiriman web umum	Edgio: DSA
Asal pengatur	Ya	Ya	Tidak
durasi cache jaringan pengiriman konten	Dua hari	Tujuh hari	Tidak

Asal pengatur: Menentukan apakah akan mengikuti header yang diarahkan cache yang didukung jika ada dalam respons HTTP dari server asal.

Durasi cache CDN: Menentukan jumlah waktu sumber daya di-cache di jaringan pengiriman konten Azure. Namun, jika asal Honor adalah Ya dan respons HTTP dari server asal menyertakan header Expires direktif cache atau Cache-Control: max-age, Azure Content Delivery Network menggunakan nilai durasi yang ditentukan oleh header sebagai gantinya.