Penembolokan dengan Azure Front Door

  • Artikel

Penting

Azure Front Door (klasik) akan dihentikan pada 31 Maret 2027. Untuk menghindari gangguan layanan apa pun, penting untuk memigrasikan profil Azure Front Door (klasik) Anda ke Azure Front Door Standard atau tingkat Premium paling lambat Maret 2027. Untuk informasi selengkapnya, lihat Penghentian Azure Front Door (klasik).

Azure Front Door adalah jaringan pengiriman konten modern (CDN), dengan kemampuan akselerasi situs dinamis dan penyeimbangan beban. Saat penembolokan dikonfigurasi pada rute Anda, situs edge yang menerima setiap permintaan memeriksa cache-nya untuk respons yang valid. Penembolokan 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 asal Anda, bahkan jika Anda melayani respons cache.

Penembolokan dapat secara signifikan mengurangi latensi dan mengurangi beban pada server asal. Namun, tidak semua jenis lalu lintas dapat memperoleh manfaat dari penembolokan. Aset statis seperti gambar, CSS, dan file JavaScript sangat ideal untuk penembolokan. 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 penembolokan dinonaktifkan untuk yang terakhir.

Peringatan

Sebelum Anda mengaktifkan penembolokan, tinjau dokumentasi publik secara menyeluruh, dan uji semua skenario yang mungkin sebelum mengaktifkan penembolokan. 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 penembolokan diaktifkan, Front Door menggunakan teknik yang disebut penggugusan objek. Ketika file besar diminta, Front Door mengambil potongan file yang lebih kecil dari asal. Setelah Front Door menerima permintaan file lengkap atau permintaan file rentang byte, lingkungan Front Door meminta file dari asal dalam potongan 8 MB.

Setelah gugus tiba di lingkungan Azure Front Door, potongan tersebut di-cache dan segera dilayani 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 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 berkisar. Respons harus menggunakan kode status HTTP 206. Selain itu Content-Range , header respons harus ada, dan harus cocok dengan panjang konten aktual yang dikembalikan asal 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.

    Tip

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

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

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

Kompresi file

Lihat meningkatkan kinerja 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"
  • "application/font"
  • "application/font-sfnt"
  • "application/javascript"
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/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 yang dipadatkan disajikan dari cache. Item yang dihasilkan dikembalikan dengan Transfer-Encoding: chunked header respons.

Jika asal menggunakan Pengodean Transfer Terpotong (CTE) untuk mengirim data ke Pop Azure Front Door, pemadatan 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 mengirim permintaan rentang byte dengan header Accept-Encoding yang mengarah ke Origin yang merespons dengan panjang konten yang berbeda, maka Azure Front Door akan menampilkan kesalahan 503. Anda dapat menonaktifkan pemadatan pada asal, atau membuat aturan Mesin Aturan untuk menghapus Accept-Encoding header dari permintaan permintaan rentang byte.

Perilaku string 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 tanda dan (&).

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 untai (karakter) kueri permintaan, pesanan mereka tidak bernilai.

Saat mengonfigurasi penembolokan, 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 untuk hidup langsungnya 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 mesin aturan untuk mengecualikan userid parameter string kueri, 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 menyeluruh semua folder, subfolder, dan file di bagian titik akhir dengan /* di jalur atau hapus menyeluruh semua subfolder dan file di folder tertentu dengan menentukan folder yang diikuti oleh /*, misalnya, /pictures/*.
  • Menghapus domain akar: Hapus menyeluruh akar titik akhir dengan "/" di jalur.

Catatan

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

Penghapusan menyeluruh cache di Front Door tidak peka huruf besar/kecil. Selain itu, mereka adalah agnostik string kueri, yang berarti bahwa menghapus menyeluruh URL menghapus menyeluruh semua variasi string kuerinya.

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 menghormati nilai header ini dan tidak menyimpan respons, bahkan jika Anda mengambil alih perilaku penembolokan dengan menggunakan Mesin Aturan.

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 di Cache-Control header respons. 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

Header respons

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 ke Front Door bahwa respons dapat di-cache, dan Set-Cookie header dilucuti.

Selain itu, Front Door melampirkan X-Cache header ke semua respons. 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 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.

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 penembolokan Mesin Aturan selalu mengambil alih konfigurasi rute.

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

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

    • Asal kehormatan: Azure Front Door selalu mematuhi direktif header respons asal. Jika arahan asal hilang, Azure Front Door menyimpan konten di mana saja dari 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 menyajikan data dari cache bahkan jika data yang di-cache telah kedaluwarsa. Perilaku ini dapat membantu situs Anda agar tetap tersedia sebagian ketika 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 kontrol Cache dan menghormati perilaku penembolokan untuk arahan Cache-Control di RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Penembolokan (ietf.org).

Perilaku dan durasi cache dapat dikonfigurasi di aturan perutean perancang Front Door dan di Mesin Aturan. Konfigurasi penembolokan Mesin Aturan selalu mengambil alih konfigurasi aturan perutean perancang Front Door.

  • Saat penembolokan dinonaktifkan, Azure Front Door (klasik) tidak menyimpan konten respons, terlepas dari arahan respons asal.

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

    • Saat Gunakan durasi default cache diatur ke Ya, Azure Front Door (klasik) selalu mematuhi arahan header respons asal. Jika arahan asal hilang, Front Door menyimpan konten di mana saja dari satu hingga tiga hari.
    • Saat Gunakan durasi default cache diatur ke Tidak, Azure Front Door (klasik) selalu menimpa dengan durasi cache (bidang yang diperlukan), yang berarti bahwa cache konten untuk durasi cache 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 bahkan jika data yang di-cache telah kedaluwarsa. Perilaku ini dapat membantu situs Anda agar tetap tersedia sebagian ketika asal Anda sedang offline.
  • Durasi cache yang disetel dalam aturan perutean perancang Front Door adalah durasi cache minimum. Penggantian ini tidak akan berfungsi jika header kontrol cache dari asalnya memiliki TTL yang lebih besar daripada nilai penggantian.

Langkah berikutnya