Penyimpanan sementara dengan Azure Front Door

Penting

Azure Front Door (klasik) tidak mendukung pembuatan profil, pendaftaran domain baru, atau sertifikat terkelola dan akan dihentikan pada 31 Maret 2027. Untuk menghindari gangguan layanan, migrasi ke Azure Front Door Standard atau Premium. Untuk informasi selengkapnya, lihat penarikan Azure Front Door (klasik).

Azure Front Door adalah jaringan pengiriman konten modern (CDN), dengan kemampuan akselerasi situs dinamis dan penyeimbangan beban. Saat caching dikonfigurasi pada rute Anda, server tepi yang menerima setiap permintaan memeriksa cache-nya untuk respons yang sah. Cache membantu mengurangi jumlah lalu lintas yang dikirim ke server asal Anda. Jika tidak ada respons cache yang tersedia, permintaan diteruskan ke asal.

Setiap situs tepi Front Door mengelola cachenya sendiri, dan permintaan mungkin dilayani oleh situs tepi yang berbeda. Akibatnya, Anda mungkin masih melihat beberapa lalu lintas mencapai server asal Anda, bahkan jika Anda mengirimkan respons cache.

Penyimpanan sementara dapat secara signifikan mengurangi latensi dan mengurangi beban pada server asal. Namun, tidak semua jenis trafik dapat memperoleh manfaat dari penyimpanan sementara (caching). Aset statis seperti gambar, CSS, dan file JavaScript sangat ideal untuk cache. Meskipun aset dinamis, seperti titik akhir API yang diautentikasi, tidak boleh di-cache untuk mencegah kebocoran informasi pribadi. Disarankan untuk memiliki rute terpisah untuk aset statis dan dinamis, dengan caching dinonaktifkan untuk aset dinamis.

Peringatan

Sebelum Anda mengaktifkan cache, tinjau dokumentasi publik secara menyeluruh, dan uji semua kemungkinan skenario sebelum mengaktifkan cache. Seperti disebutkan sebelumnya, dengan kesalahan konfigurasi, Anda secara tidak sengaja dapat menyimpan data spesifik pengguna yang dapat dibagikan oleh beberapa pengguna yang mengakibatkan insiden privasi.

Metode permintaan

Hanya permintaan yang menggunakan GET metode permintaan yang dapat di-cache. Semua metode permintaan lainnya selalu diproksi melalui jaringan.

Pengiriman file besar

Azure Front Door mengirim file besar tanpa batas ukuran file. Jika penyimpanan sementara diaktifkan, Front Door menggunakan teknik yang disebut chunking objek. Ketika file besar diminta, Front Door mengambil potongan file yang lebih kecil dari asal. Setelah Front Door menerima permintaan file utuh atau permintaan rentang byte file, sistem Front Door meminta file dari asal dalam potongan 8 MB.

Setelah potongan tiba di lingkungan Azure Front Door, potongan tersebut di-cache dan segera disampaikan kepada pengguna. Front Door kemudian mengambil potongan berikutnya secara paralel. Pengambilan sebelumnya ini memastikan bahwa konten tetap satu gugus di depan pengguna, yang mengurangi latensi. Proses ini berlanjut hingga seluruh file diunduh (jika diminta) atau klien menutup sambungan. Untuk informasi selengkapnya tentang permintaan rentang byte, lihat RFC 7233.

Front Door menyimpan semua gugus dalam cache saat diterima sehingga seluruh file tidak perlu disimpan dalam cache Front Door. Permintaan berikutnya untuk file atau rentang byte dilayani dari dalam cache. Jika potongan tidak semuanya di-cache, prefetching digunakan untuk meminta gugus dari asal.

Optimasi ini bergantung pada kemampuan asal untuk mendukung permintaan rentang byte. Jika asal tidak mendukung permintaan rentang byte, atau jika tidak menangani permintaan rentang dengan benar, pengoptimalan ini tidak efektif.

Saat asal Anda merespons permintaan dengan header, asal Anda harus merespons dengan Range salah satu cara berikut:

  • Mengembalikan respons dalam jangkauan tertentu. Respons harus menggunakan kode status HTTP 206. Selain itu, Content-Range header respons harus ada, dan harus cocok dengan panjang konten aktual yang dikembalikan sumber Anda. Jika asal Anda tidak mengirim header respons yang benar dengan nilai yang valid, Azure Front Door tidak menyimpan respons, dan Anda mungkin melihat perilaku yang tidak konsisten.

    Tips

    Jika server asal Anda memadatkan respons, pastikan Content-Range nilai header cocok dengan panjang respons terkompresi yang sebenarnya.

  • Mengembalikan respons non-rentang. Jika sumber Anda tidak dapat menangani permintaan rentang, sumber tersebut dapat mengabaikan header Range dan mengembalikan respons yang tidak berjarak. Pastikan sumber mengembalikan kode status respons selain 206. Misalnya, asal usulnya mungkin mengembalikan respons 200 OK.

Jika server asal menggunakan Pengodean Transfer Chunked (CTE) untuk mengirim data ke Azure Front Door POP, ukuran respons yang lebih besar dari 8 MB tidak bisa didukung.

Kompresi file

Lihat meningkatkan performa dengan mengompresi file di Azure Front Door.

Azure Front Door (klasik) dapat secara dinamis mengompresi konten di edge, menghasilkan waktu respons yang lebih kecil dan lebih cepat untuk klien Anda. Agar file memenuhi syarat untuk kompresi, penembolokan harus diaktifkan dan file harus memiliki jenis MIME agar memenuhi syarat untuk kompresi. Saat ini, Front Door (klasik) tidak mengizinkan daftar ini diubah. Daftar saat ini adalah:

  • application/eot
  • aplikasi/font
  • "aplikasi/font-sfnt"
  • "aplikasi/javascript"
  • "aplikasi/json"
  • "aplikasi/tipe terbuka"
  • "aplikasi/otf"
  • "aplikasi/pkcs7-mime"
  • "aplikasi/truetype"
  • "aplikasi/ttf",
  • "application/vnd.ms-fontobject"
  • aplikasi/xhtml+xml
  • "aplikasi/xml"
  • aplikasi/xml+rss
  • "application/x-font-opentype"
  • "aplikasi/x-font-truetype"
  • application/x-font-ttf
  • "aplikasi/x-httpd-cgi"
  • "aplikasi/x-mpegurl"
  • "aplikasi/x-opentype"
  • "aplikasi/x-otf"
  • aplikasi/x-perl
  • "aplikasi/x-ttf"
  • "aplikasi/x-javascript"
  • font/eot
  • font/ttf
  • font/otf
  • "font/opentype"
  • "gambar/svg+xml"
  • text/css
  • "teks/csv"
  • "teks/html"
  • "text/javascript"
  • "teks/js", "teks biasa"
  • teks/teks kaya
  • teks/nilai-dipisahkan-tanda-tab
  • "teks/xml"
  • teks/x-skrip
  • "teks/komponen-x"
  • "teks/x-java-source"

Selain itu, file juga harus berukuran antara 1 KB dan 8 MB, inklusif.

Profil ini mendukung pengodean kompresi berikut:

Jika permintaan mendukung kompresi gzip dan Brotli, kompresi Brotli lebih diutamakan.

Ketika permintaan untuk aset menentukan kompresi dan permintaan mengakibatkan kehilangan cache, Azure Front Door (klasik) melakukan pemadatan aset langsung di server POP. Setelah itu, file terkompresi diambil dari cache. Item yang dihasilkan dengan header respons Transfer-Encoding: chunked dikembalikan.

Jika server asal menggunakan Pengodean Transfer Terpotong (CTE) untuk mengirim data ke Azure Front Door POP, maka kompresi tidak didukung.

Catatan

Permintaan rentang dapat dikompresi ke dalam berbagai ukuran. Azure Front Door mensyaratkan nilai panjang konten menjadi sama untuk setiap permintaan GET HTTP. Jika klien mengirimkan permintaan rentang byte dengan header Accept-Encoding, yang menyebabkan Origin merespons dengan panjang konten yang berbeda, maka Azure Front Door akan mengembalikan kesalahan 503. Anda dapat menonaktifkan kompresi di sumber, atau membuat aturan Rules Engine untuk menghapus header Accept-Encoding dari permintaan rentang byte.

Perilaku rangkaian kueri

Dengan Azure Front Door, Anda dapat mengontrol bagaimana file di-cache untuk permintaan web yang berisi string kueri.

Dalam permintaan web dengan string kueri, string kueri adalah bagian permintaan yang terjadi setelah tanda tanya (?). String kueri dapat berisi satu atau beberapa pasangan kunci-nilai, di mana nama bidang dan nilainya dipisahkan oleh tanda sama dengan (=). Setiap pasangan kunci-nilai dipisahkan oleh simbol ampersand (&).

Misalnya, URL http://www.contoso.com/content.mov?field1=value1&field2=value2 berisi dua string kueri:

  • field1, dengan nilai value1.
  • field2, dengan nilai value2.

Jika ada lebih dari satu pasangan kunci-nilai dalam string kueri permintaan, urutan mereka tidak penting.

Saat mengonfigurasi caching, Anda menentukan bagaimana cache harus menangani string kueri. Perilaku berikut didukung:

  • Abaikan String Kueri: Dalam mode ini, Azure Front Door meneruskan string kueri dari klien ke asal pada permintaan pertama dan menyimpan aset. Permintaan di masa mendatang untuk aset yang dilayani dari lingkungan Front Door mengabaikan string kueri hingga aset yang di-cache kedaluwarsa.

  • Gunakan String Kueri: Dalam mode ini, setiap permintaan dengan URL unik, termasuk string kueri, diperlakukan sebagai aset unik dengan cachenya sendiri. Misalnya, respons dari asal untuk permintaan www.example.ashx?q=test1 disimpan di cache dalam lingkungan Front Door dan ditampilkan untuk cache berikutnya dengan untai (karakter) kueri yang sama. Permintaan untuk www.example.ashx?q=test2 di-cache sebagai aset terpisah dengan pengaturan waktu hidupnya sendiri.

    Urutan parameter string kueri tidak masalah. Misalnya, jika lingkungan Azure Front Door menyertakan respons cache untuk URL www.example.ashx?q=test1&r=test2, permintaan untuk www.example.ashx?r=test2&q=test1 juga dilayani dari cache.

  • Abaikan String Kueri yang Ditentukan dan Sertakan String Kueri yang Ditentukan: Dalam mode ini, Anda dapat mengonfigurasi Azure Front Door untuk menyertakan atau mengecualikan parameter yang ditentukan saat kunci cache dibuat.

    Misalnya, misalkan bahwa kunci cache default adalah /foo/image/asset.html, dan permintaan dibuat ke URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Jika ada aturan pada mesin aturan untuk mengecualikan userid parameter kueri string, maka kunci cache string kueri adalah /foo/image/asset.html?language=EN&sessionid=200.

Konfigurasikan perilaku string kueri pada rute Front Door.

Penghapusan menyeluruh cache

Lihat Pembersihan cache di Azure Front Door untuk mempelajari cara mengonfigurasi pembersihan cache.

Azure Front Door menyimpan cache aset hingga time-to-live (TTL) aset kedaluwarsa. Setiap kali klien meminta aset dengan TTL yang kedaluwarsa, lingkungan Front Door mengambil salinan aset baru yang diperbarui untuk melayani permintaan, dan kemudian menyimpan cache yang disegarkan.

Praktik terbaik untuk memastikan bahwa pengguna selalu mendapatkan salinan aset terbaru adalah dengan menerapkan versi aset Anda untuk setiap pembaruan dan menerbitkannya sebagai URL baru. Front Door akan segera mengambil aset baru untuk permintaan klien berikutnya. Terkadang, Anda mungkin ingin menghapus menyeluruh konten cache dari semua simpul tepi dan memaksanya mengambil aset baru yang diperbarui. Alasannya bisa karena pembaruan aplikasi web Anda, atau untuk memperbarui aset yang berisi informasi yang salah dengan cepat.

Cuplikan layar tombol hapus menyeluruh cache dan halaman.

Pilih aset yang ingin dihapus menyeluruh dari simpul tepi. Untuk menghapus semua aset, pilih Hapus semua. Jika tidak, di Jalur, masukkan jalur setiap aset yang ingin dihapus menyeluruh.

Format ini didukung dalam daftar jalur yang akan dihapus menyeluruh:

  • Penghapusan menyeluruh satu jalur: Hapus menyeluruh aset individu dengan menentukan jalur lengkap aset (tanpa protokol dan domain), dengan ekstensi file, misalnya, /pictures/strasbourg.png;
  • Menghapus kartubebas: Tanda bintang (*) dapat digunakan sebagai kartubebas. Hapus semua folder, subfolder, dan file pada titik akhir yang memiliki /* pada jalurnya atau hapus semua subfolder dan file di folder tertentu dengan menyebutkan folder diikuti oleh /*, misalnya, /pictures/*.
  • Pembersihan domain akar: Hapus root dari titik akhir dengan "/" di jalurnya.

Catatan

Menghapus domain wildcard: Menentukan jalur cache untuk dihapus seperti yang dibahas di bagian ini tidak berlaku untuk domain wildcard apa pun yang terkait dengan Front Door. Saat ini, kami tidak mendukung menghapus domain wildcard secara langsung. Anda dapat menghapus jalur dari subdomain tertentu dengan menentukan subdomain tersebut dan jalur yang dihapus. Misalnya, jika Front Door saya memiliki *.contoso.com, saya dapat membersihkan aset dari subdomain saya foo.contoso.com dengan mengetik foo.contoso.com/path/*. Saat ini, penentuan nama host dalam jalur penghapusan konten hanya dibatasi pada subdomain dari domain wildcard, jika mungkin.

Penghapusan cache di Front Door tidak sensitif terhadap huruf besar/kecil. Selain itu, mereka tidak membeda-bedakan string kueri, yang berarti bahwa ketika sebuah URL dihapus, semua variasi string kueri juga ikut dihapus.

Masa berakhir cache

Urutan header berikut digunakan untuk menentukan berapa lama item disimpan di cache kami:

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

Beberapa Cache-Control nilai header respons menunjukkan bahwa respons tidak dapat di-cache. Nilai-nilai ini termasuk private, no-cache, dan no-store. Front Door mematuhi nilai header ini dan tidak menyimpan respons, bahkan jika Anda menimpa perilaku penyimpanan dengan menggunakan Rules Engine.

Cache-Control Jika header tidak ada pada respons dari asal, secara default Front Door secara acak menentukan durasi cache antara satu dan tiga hari.

Catatan

Kedaluwarsa cache tidak boleh lebih besar dari 366 hari.

Anda mungkin melihat REVALIDATED_HIT dalam header jawaban Cache-Control. Ini menunjukkan bahwa konten yang di-cache di Azure Front Door divalidasi ulang dengan server asal sebelum dilayani ke klien. Ini dapat terjadi ketika konten yang di-cache telah kedaluwarsa, tetapi server asal menunjukkan bahwa konten belum berubah. Dalam hal ini, konten yang di-cache disajikan kepada klien, dan kedaluwarsa cache diatur ulang.

Header permintaan

Header permintaan berikut tidak diteruskan ke asal saat penembolokan diaktifkan:

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language
  • Vary

Catatan

Permintaan yang menyertakan header otorisasi tidak akan di-cache, kecuali respons berisi direktif Cache-Control yang memungkinkan caching. Direktif Cache-Control berikut memiliki efek seperti itu: harus memvalidasi ulang, publik, dan s-maxage.

Header tanggapan

Jika respons asal dapat di-cache, maka Set-Cookie header dihapus sebelum respons dikirim ke klien. Jika respons asal tidak dapat di-cache, Front Door tidak menghapus header. Misalnya, jika respons asal menyertakan Cache-Control header dengan max-age nilai menunjukkan kepada Front Door bahwa respons bisa di-cache, dan Set-Cookie header dihapus.

Selain itu, Front Door melampirkan X-Cache header pada semua tanggapan. Header X-Cache respons menyertakan salah satu nilai berikut:

  • TCP_HIT atau TCP_REMOTE_HIT: Potongan respons 8-MB pertama adalah hit cache, dan konten disajikan dari cache Front Door.
  • TCP_MISS: Potongan respons 8-MB pertama adalah cache miss, dan konten diambil dari sumber asal.
  • PRIVATE_NOSTORE: Permintaan tidak dapat di-cache karena header respons Cache-Control diatur ke privat atau tanpa penyimpanan.
  • CONFIG_NOCACHE: Permintaan dikonfigurasi untuk tidak melakukan cache di profil Front Door.

Catatan

Azure Front Door menghapus header Content-Type untuk file kosong saat caching diaktifkan. Agar header ini terus dikirim ke klien, gunakan mesin aturan Azure Front Door (Tindakan - Modifikasi header respons, Operator - Timpa ulang, Nama tajuk - Tipe Konten) untuk secara manual menimpanya ulang untuk file-file tersebut. Anda juga dapat menonaktifkan caching untuk file kosong, tetapi pendekatan ini kurang direkomendasikan karena meningkatkan beban pada asal Anda dan dapat memengaruhi performa.

Log dan laporan

Log akses menyertakan status cache untuk setiap permintaan. Selain itu, laporan menyertakan informasi tentang bagaimana cache Azure Front Door digunakan dalam aplikasi Anda.

Log akses menyertakan status cache untuk setiap permintaan.

Perilaku dan durasi cache

Perilaku dan durasi cache dapat dikonfigurasi di Rules Engine. Konfigurasi cache Mesin Aturan selalu menggantikan konfigurasi rute.

  • Saat cache dinonaktifkan, Azure Front Door tidak menyimpan konten respons, terlepas dari arahan respons asal.

  • Saat cache diaktifkan, perilaku cache berbeda tergantung pada nilai yang diterapkan oleh Mesin Aturan.

    • Menghormati asal: Azure Front Door selalu menghormati instruksi header respons dari asal. Jika direktif asal hilang, Azure Front Door menyimpan konten antara satu hingga tiga hari.
    • Ambil alih selalu: Azure Front Door selalu mengambil alih dengan durasi cache, yang berarti bahwa itu menyimpan cache konten untuk durasi cache yang mengabaikan nilai dari arahan respons asal. Perilaku ini hanya berlaku jika respons dapat di-cache.
    • Ambil alih jika asal hilang: Jika asal tidak mengembalikan nilai TTL penembolokan, Azure Front Door menggunakan durasi cache yang ditentukan. Perilaku ini hanya berlaku jika respons dapat di-cache.

Catatan

  • Azure Front Door tidak menjamin jumlah waktu konten disimpan dalam cache. Konten yang di-cache dapat dihapus dari cache tepi sebelum konten kedaluwarsa jika konten tidak sering digunakan.
  • Front Door mungkin dapat melayani data dari cache meskipun data yang di-cache telah kedaluwarsa atau jika sumber mengembalikan respons kesalahan. Perilaku ini dapat membantu situs Anda untuk tetap sebagian tersedia ketika server asal Anda sedang offline.
  • Origins dapat menentukan untuk tidak men-cache respons tertentu menggunakan header Cache-Control dengan nilai no-cache, private, atau no-store. Saat digunakan dalam respons HTTP dari server asal ke POP Azure Front Door, Azure Front Door mendukung direktif Cache-Control dan mematuhi perilaku penembolokan untuk direktif Cache-Control dalam RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Penembolokan (ietf.org).

Perilaku dan durasi cache dapat dikonfigurasi di aturan perutean Front Door Designer dan di Rules Engine. Konfigurasi cache Mesin Aturan selalu menggantikan konfigurasi aturan perutean Front Door.

  • Saat cache dinonaktifkan, Azure Front Door (klasik) tidak menyimpan konten respons, tanpa mempedulikan arahan respons asal.

  • Saat penembolokan diaktifkan, perilaku cache berbeda untuk nilai yang berbeda dari Gunakan durasi bawaan cache.

    • Saat Gunakan durasi default cache diatur ke Ya, Azure Front Door (klasik) selalu mematuhi arahan header respons asal. Jika direktif asal hilang, Front Door dapat menyimpan konten di mana saja selama satu hingga tiga hari.
    • Saat Gunakan durasi default cache diatur ke Tidak, Azure Front Door (klasik) selalu menggantikan dengan durasi cache (bidang yang wajib diisi), yang berarti bahwa Azure Front Door menyimpan cache konten untuk durasi tersebut dengan mengabaikan nilai dari arahan respons asal.

Catatan

  • Azure Front Door (klasik) tidak menjamin berapa lama konten disimpan dalam cache. Konten yang di-cache dapat dihapus dari cache tepi sebelum konten kedaluwarsa jika konten tidak sering digunakan.
  • Azure Front Door (klasik) mungkin dapat menyajikan data dari cache meskipun data yang di-cache telah kedaluwarsa atau backend mengembalikan respons kesalahan. Perilaku ini dapat membantu situs Anda untuk tetap tersedia sebagian ketika backend Anda offline.
  • Durasi cache yang disetel dalam aturan perutean perancang Front Door adalah durasi cache minimum. Penimpaan ini tidak berfungsi jika header kontrol cache dari asal memiliki TTL yang lebih besar daripada nilai penimpaan.

Konten terkait

  • Last updated on