Penembolokan dengan Azure Front Door

  • Artikel

Azure Front Door adalah jaringan pengiriman konten modern (CDN), dengan akselerasi situs dinamis dan kemampuan 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 akan 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.

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 menerima permintaan file lengkap atau permintaan file rentang byte, lingkungan Azure Front Door meminta file dari asal dalam potongan 8 MB.

Setelah gugus tiba di lingkungan Azure Front Door, potongan tersebut di-cache dan segera disajikan kepada pengguna. Front Door kemudian mengambil sebelumnya gugus berikutnya secara paralel. Pengambilan sebelumnya ini memastikan bahwa konten tetap menjadi satu gugus bagi 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, pra-pengambilan digunakan untuk meminta potongan 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 yang tidak berkisar. Jika asal Anda tidak dapat menangani permintaan rentang, asal Anda dapat mengabaikan Range header dan mengembalikan respons non-rentang. Pastikan bahwa asal mengembalikan kode status respons selain 206. Misalnya, asal mungkin mengembalikan respons 200 OK.

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.

Saat permintaan untuk aset menentukan kompresi dan permintaan menghasilkan cache miss, Azure Front Door (klasik) melakukan kompresi aset secara langsung di server POP. Setelah itu, file yang dikompresi disajikan dari cache. Item yang dihasilkan dikembalikan dengan Transfer-Encoding: chunked header respons.

Jika asal menggunakan Pengodean Transfer Terpotong (CTE) untuk mengirim data terkompresi ke Azure Front Door PoP, maka ukuran respons yang lebih besar dari 8 MB 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 untai (karakter) 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 nilai kunci dipisahkan oleh tanda 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 bernilai kunci dalam string kueri permintaan, pesanan mereka tidak masalah.

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 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 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 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 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/*.
  • Penghapusan menyeluruh 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.

Akhir masa berlaku cache

Urutan header berikut digunakan untuk menentukan berapa lama item akan 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 akan 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 akan secara acak menentukan durasi cache antara satu dan tiga hari.

Catatan

Kedaluwarsa cache tidak boleh lebih besar dari 366 hari.

Header permintaan

Header permintaan berikut tidak akan 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, ini menunjukkan kepada 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 yang terlewat, dan konten diambil dari asalnya.
  • 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 akan selalu menghormati arahan header respons asal. Jika arahan asal hilang, Azure Front Door akan menyimpan konten di mana saja dari satu hingga tiga hari.
    • Override always: Azure Front Door akan selalu ditimpa dengan durasi cache, yang berarti akan men-cache konten selama durasi cache mengabaikan nilai dari arahan respons asal. Perilaku ini hanya akan diterapkan jika respons dapat disimpan dalam cache.
    • Menimpa jika asal hilang: Jika asal tidak mengembalikan nilai TTL caching, Azure Front Door akan menggunakan durasi cache yang ditentukan. Perilaku ini hanya akan diterapkan jika respons dapat disimpan dalam 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 meskipun 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 - Protokol Transfer Hypertext (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 akan 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 disetel ke Ya, Azure Front Door (klasik) akan selalu mengikuti arahan header respons asal. Jika arahan asal hilang, Front Door akan menyimpan konten di mana saja dari satu hingga tiga hari.
    • Saat Gunakan durasi default cache disetel ke Tidak, Azure Front Door (klasik) akan selalu ditimpa dengan durasi cache (bidang wajib), yang berarti akan 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