Ukládání do mezipaměti s využitím služby Azure Front Door

V tomto článku se dozvíte, jak se trasy a sada pravidel úrovně Azure Front Door Úrovně Standard a Premium chovají, když máte povolené ukládání do mezipaměti. Azure Front Door je moderní síť pro doručování obsahu (CDN) s akcelerací dynamické lokality a vyrovnáváním zatížení.

Metody požadavků

Obsah uložený v mezipaměti ve službě Azure Front Door může generovat pouze metoda požadavku GET. Všechny ostatní metody požadavků se vždy přesouvají přes síť.

Následující dokument určuje chování služby Azure Front Door (Classic) s pravidly směrování, která mají povolené ukládání do mezipaměti. Front Door je moderní síť pro doručování obsahu (CDN) s dynamickou akcelerací webu a vyrovnáváním zatížení a podporuje také chování ukládání do mezipaměti stejně jako jakákoli jiná síť CDN.

Doručování velkých souborů

Azure Front Door doručuje velké soubory bez omezení velikosti souboru. Front Door používá techniku označovanou jako vytváření bloků objektů. Když služba Front Door přijme požadavek na velký soubor, načte z back-endu menší části daného souboru. Po přijetí žádosti o úplný soubor nebo soubor v rozsahu bajtů si prostředí Front Door vyžádá soubor z back-endu v blocích o 8 MB.

Jakmile blok dat dorazí do prostředí služby Front Door, uloží se do mezipaměti a okamžitě se předá uživateli. Front Door pak předem načte další blok dat paralelně. Toto předběžné načtení zajišťuje, že obsah zůstane o jeden blok před uživatelem, což snižuje latenci. Tento proces pokračuje, dokud se nestáhne celý soubor (pokud je požadováno) nebo dokud klient připojení nezavře.

Další informace o požadavku na rozsah bajtů najdete v dokumentu RFC 7233. Front Door ukládá do mezipaměti všechny bloky dat, jakmile jsou přijaty, takže celý soubor se nemusí ukládat do mezipaměti služby Front Door. Následné požadavky na rozsahy souborů nebo bajtů se obsluhují z mezipaměti. Pokud nejsou všechny bloky dat uložené v mezipaměti, použije se předběžné načtení k vyžádání bloků dat z back-endu. Tato optimalizace spoléhá na schopnost back-endu podporovat požadavky na rozsah bajtů. Pokud back-end nepodporuje požadavky na rozsah bajtů, není tato optimalizace efektivní.

Komprese souboru

Projděte si téma o zvýšení výkonu komprimací souborů ve službě Azure Front Door.

Azure Front Door (Classic) dokáže dynamicky komprimovat obsah na hraničních zařízeních, což má za následek kratší a rychlejší odezvu pro vaše klienty. Aby byl soubor způsobilý ke kompresi, musí být povolené ukládání do mezipaměti a soubor musí být typu MIME, aby byl způsobilý ke kompresi. Front Door (classic) v současné době neumožňuje změnu tohoto seznamu. Aktuální seznam je:

  • "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/prostý"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

Kromě toho musí mít soubor velikost od 1 kB do 8 MB (včetně).

Tyto profily podporují následující kódování komprese:

Pokud požadavek podporuje kompresi gzip a Brotli, má přednost brotli komprese.
Když požadavek na prostředek určuje kompresi a výsledkem požadavku je chybějící mezipaměť, Azure Front Door (classic) provede kompresi prostředku přímo na serveru POP. Komprimovaný soubor se pak obsluhuje z mezipaměti. Výsledná položka se vrátí s kódováním přenosu: blokované. Pokud zdroj používá K odesílání komprimovaných dat do protokolu POP služby Azure Front Door blokované kódování přenosu (CTE), nebudou velikosti odpovědí větší než 8 MB podporovány.

Poznámka

Požadavky rozsahu se můžou komprimovat do různých velikostí. Azure Front Door vyžaduje, aby hodnoty délky obsahu byly stejné pro všechny požadavky GET HTTP. Pokud klienti odesílají žádosti o rozsah bajtů s accept-encoding hlavičkou, která vede k tomu, že zdroj odpovídá s různými délkami obsahu, vrátí Služba Azure Front Door chybu 503. Kompresi u zdroje můžete buď zakázat, nebo můžete vytvořit pravidlo sady pravidel, které se z požadavku na rozsah bajtů odebere accept-encoding .

Chování řetězce dotazu

Pomocí služby Azure Front Door můžete řídit způsob ukládání souborů do mezipaměti webového požadavku, který obsahuje řetězec dotazu. Ve webovém požadavku s řetězcem dotazu je řetězcem dotazu ta část požadavku, která se vyskytuje za otazníkem (?). Řetězec dotazu může obsahovat jeden nebo více párů klíč-hodnota, ve kterých je název pole a jeho hodnota oddělené znaménkem rovná se (=). Každý pár klíč-hodnota je oddělený ampersandem (&). Například, http://www.contoso.com/content.mov?field1=value1&field2=value2. Pokud je v řetězci dotazu požadavku více než jeden pár klíč-hodnota, nezáleží na jejich pořadí.

  • Ignorovat řetězce dotazů: V tomto režimu Azure Front Door předá řetězce dotazu z žadatele do back-endu prvního požadavku a prostředek do mezipaměti. Všechny následné požadavky na prostředek, který se obsluhuje z prostředí služby Front Door, ignorují řetězce dotazů, dokud nevyprší platnost prostředku uloženého v mezipaměti.

  • Ukládat do mezipaměti každou jedinečnou adresu URL: V tomto režimu se každý požadavek s jedinečnou adresou URL, včetně řetězce dotazu, považuje za jedinečný prostředek s vlastní mezipamětí. Například odpověď z back-endu na požadavek pro www.example.ashx?q=test1 se ukládá do mezipaměti v prostředí Služby Front Door a vrací se pro následné mezipaměti se stejným řetězcem dotazu. Požadavek pro www.example.ashx?q=test2 se ukládá do mezipaměti jako samostatný prostředek s vlastním nastavením time-to-live.

  • Zadejte chování řetězce dotazu klíče mezipaměti , které chcete zahrnout nebo vyloučit zadané parametry při generování klíče mezipaměti. Výchozí klíč mezipaměti je například: /foo/image/asset.html a ukázkový požadavek je https://contoso.com//foo/image/asset.html?language=EN&userid=100&sessionid=200. Existuje pravidlo sady pravidel, které vylučuje řetězec dotazu userid. Řetězec dotazu cache-key by pak byl /foo/image/asset.html?language=EN&sessionid=200.

Vyprázdnění mezipaměti

Azure Front Door ukládá prostředky do mezipaměti, dokud nevyprší hodnota TTL (Time to Live). Pokaždé, když klient požádá o prostředek s hodnotou TTL s vypršenou platností, prostředí služby Front Door načte novou aktualizovanou kopii prostředku, která požadavek vyhoví, a pak aktualizovanou mezipaměť uloží.

Osvědčeným postupem, jak zajistit, aby uživatelé vždy získali nejnovější kopii vašich prostředků, je verze prostředků pro každou aktualizaci a jejich publikování jako nové adresy URL. Front Door okamžitě načte nové prostředky pro další požadavky klientů. Někdy můžete chtít vyprázdnit obsah uložený v mezipaměti ze všech hraničních uzlů a vynutit, aby všechny načítaly nové aktualizované prostředky. Důvodem můžou být aktualizace webové aplikace nebo rychlá aktualizace prostředků, které obsahují nesprávné informace.

Snímek obrazovky s tlačítkem a stránkou pro vyprázdnění mezipaměti

Vyberte prostředky, které chcete vyprázdnit z hraničních uzlů. Pokud chcete vymazat všechny prostředky, vyberte Vyprázdnit vše. Jinak do pole Cesta zadejte cestu ke každému prostředku, který chcete vyprázdnit.

Tyto formáty jsou podporované v seznamech cest k vymazání:

  • Vymazání jedné cesty: Vyprázdněte jednotlivé prostředky zadáním úplné cesty k prostředku (bez protokolu a domény) s příponou souboru, například /pictures/strasbourg.png;
  • Vymazání zástupných znaků: Hvězdička (*) se může použít jako zástupný znak. Vyprázdněte všechny složky, podsložky a soubory v koncovém bodu s /* v cestě nebo vyprázdněte všechny podsložky a soubory v konkrétní složce zadáním složky následované /*, například /pictures/*.
  • Vymazání kořenové domény: Vyprázdněte kořen koncového bodu s "/" v cestě.

Poznámka

Mazání zástupných domén: Určení cest v mezipaměti pro mazání, jak je popsáno v této části, se nevztahuje na žádné zástupné domény, které jsou přidružené ke službě Front Door. V současné době nepodporujeme přímé mazání zástupných domén. Cesty z konkrétních subdomén můžete vyprázdnit tak, že zadáte konkrétní subdoménu a cestu mazání. Pokud má například služba Front Door *.contoso.com, můžu vyprázdnit prostředky z mé subdomény foo.contoso.com zadáním foo.contoso.com/path/*. V současné době je zadávání názvů hostitelů v cestě k vyprázdnění obsahu omezeno na subdomény domén se zástupnými znakůmi sadou.

Při vyprázdnění mezipaměti ve službě Front Door se nerozlišují velká a malá písmena. Navíc jsou nezávislé na řetězci dotazu, což znamená, že vymazání adresy URL vymaže všechny varianty řetězce dotazu.

Vypršení platnosti mezipaměti

Následující pořadí hlaviček slouží k určení, jak dlouho bude položka uložena v naší mezipaměti:

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

Cache-Control hlavičky odpovědi, které označují, že odpověď nebude uložená v mezipaměti, například Cache-Control: private, Cache-Control: no-cache a Cache-Control: no-store. Pokud není k dispozici žádná Cache-Control, výchozí chování je, že služba Front Door uloží prostředek do mezipaměti po dobu X, kdy se X náhodně vybere mezi 1 a 3 dny.

Poznámka

Vypršení platnosti mezipaměti nesmí být delší než 366 dnů.

Hlavičky požadavku

Následující hlavičky požadavků se při použití ukládání do mezipaměti nepřesměrují do back-endu.

  • Délka obsahu
  • Transfer-Encoding
  • Přijmout
  • Accept-Charset
  • Accept-Language

Hlavičky odpovědi

Následující hlavičky odpovědi budou odstraněny, pokud je odpověď původu uložena do mezipaměti. Například hlavička odpovědi řízení mezipaměti s hodnotou max-age označuje, že odpověď se dá uložit do mezipaměti.

  • Set-Cookie

Chování a doba trvání mezipaměti

Chování a dobu trvání mezipaměti je možné nakonfigurovat ve stroji pravidel. Konfigurace ukládání do mezipaměti stroje pravidel vždy přepíše konfiguraci trasy.

  • Pokud je ukládání do mezipamětizakázané, azure Front Door neuchová obsah odpovědi do mezipaměti bez ohledu na direktivy odpovědi původu.

  • Pokud je ukládání do mezipamětipovolené, chování mezipaměti se liší v závislosti na vybrané hodnotě chování mezipaměti.

    • Čestný původ: Služba Azure Front Door bude vždy respektovat direktivu hlavičky odpovědi původu. Pokud chybí direktiva origin, azure Front Door uloží obsah do mezipaměti od 1 do 3 dnů.
    • Přepsat vždy: Služba Azure Front Door vždy přepíše dobu trvání mezipaměti, což znamená, že bude ukládat obsah do mezipaměti po dobu trvání mezipaměti bez ohledu na hodnoty z direktiv odpovědi původu. Toto chování se použije pouze v případě, že odpověď lze uložit do mezipaměti.
    • Přepsat, pokud chybí původ: Pokud zdroj nevrací hodnoty TTL ukládání do mezipaměti, azure Front Door použije zadanou dobu trvání mezipaměti. Toto chování se použije pouze v případě, že odpověď lze uložit do mezipaměti.

Poznámka

  • Azure Front Door neposkytuje žádné záruky ohledně doby, po kterou je obsah uložen v mezipaměti. Pokud se obsah v mezipaměti často nepoužívá, může být obsah uložený v mezipaměti Edge před vypršením platnosti obsahu odebrán. Služba Front Door může být schopná obsluhovat data z mezipaměti i v případě, že vypršela platnost dat uložených v mezipaměti. Toto chování může pomoct webu zůstat částečně dostupný, i když jsou back-endy offline.
  • Zdroje mohou určit, že se konkrétní odpovědi nebudou ukládat do mezipaměti pomocí hlavičky Cache-Control s hodnotou no-cache, private nebo no-store. Při použití v odpovědi HTTP ze serveru původu na POP služby Azure Front Door podporuje služba Azure Front Door direktivy cache-control a respektuje chování ukládání do mezipaměti pro direktivy Cache-Control v dokumentu RFC 7234 – PROTOKOL HTTP/1.1: Ukládání do mezipaměti (ietf.org).

Chování a doba trvání mezipaměti je možné nakonfigurovat v pravidle směrování návrháře služby Front Door i ve stroji pravidel. Konfigurace ukládání do mezipaměti stroje pravidel vždy přepíše konfiguraci pravidel směrování návrháře služby Front Door.

  • Pokud je ukládání do mezipamětizakázané, Azure Front Door (classic) neuchová obsah odpovědi do mezipaměti, a to bez ohledu na direktivy odpovědi původu.

  • Pokud je ukládání do mezipamětipovolené, chování mezipaměti se liší pro různé hodnoty použít výchozí dobu trvání mezipaměti.

    • Pokud je možnost Použít výchozí dobu trvání mezipaměti nastavená na Ano, služba Azure Front Door (Classic) bude vždy respektovat direktivu hlavičky odpovědi původu. Pokud chybí direktiva origin, služba Front Door uloží obsah do mezipaměti od 1 do 3 dnů.
    • Pokud je možnost Použít výchozí dobu trvání mezipaměti nastavená na Ne, služba Azure Front Door (Classic) vždy přepíše dobu trvání mezipaměti (povinná pole), což znamená, že obsah po dobu trvání mezipaměti uloží do mezipaměti bez ohledu na hodnoty z direktiv odpovědi původu.

Poznámka

  • Azure Front Door (classic) neposkytuje žádné záruky ohledně doby, po kterou je obsah uložen v mezipaměti. Pokud se obsah v mezipaměti často nepoužívá, může být obsah uložený v mezipaměti Edge před vypršením platnosti obsahu odebrán. Služba Azure Front Door (Classic) může být schopná obsluhovat data z mezipaměti i v případě, že vypršela platnost dat uložených v mezipaměti. Toto chování může pomoct webu zůstat částečně dostupný, i když jsou back-endy offline.
  • Doba trvání mezipaměti nastavená v pravidle směrování návrháře služby Front Door je minimální doba trvání mezipaměti. Toto přepsání nebude fungovat, pokud má hlavička ovládacího prvku mezipaměti z back-endu větší hodnotu TTL než hodnota přepsání.

Další kroky