Ukládání do mezipaměti se službou Azure Front Door

  • Článek

Důležité

Služba Azure Front Door (Classic) bude vyřazena 31. března 2027. Abyste se vyhnuli přerušení služeb, je důležité do března 2027 migrovat profily služby Azure Front Door (Classic) na úroveň Azure Front Door Standard nebo Premium. Další informace najdete v části Vyřazení služby Azure Front Door (Classic).

Azure Front Door je moderní síť pro doručování obsahu (CDN) s možnostmi dynamické akcelerace lokality a vyrovnávání zatížení. Při konfiguraci ukládání do mezipaměti na vaší trase hraniční lokalita, která obdrží každý požadavek, zkontroluje jeho mezipaměť pro platnou odpověď. Ukládání do mezipaměti pomáhá snížit objem provozu odesílaný na původní server. Pokud není k dispozici žádná odpověď uložená v mezipaměti, požadavek se předá do zdroje.

Každý hraniční web služby Front Door spravuje svou vlastní mezipaměť a požadavky mohou být obsluhovány různými hraničními weby. V důsledku toho se může stále zobrazovat nějaký provoz, který se dostane do vašeho původu, i když jste obsluhovali odpovědi uložené v mezipaměti.

Ukládání do mezipaměti může výrazně snížit latenci a snížit zatížení na původních serverech. Ne všechny typy přenosů ale můžou těžit z ukládání do mezipaměti. Statické prostředky, jako jsou obrázky, šablony stylů CSS a soubory JavaScriptu, jsou ideální pro ukládání do mezipaměti. Dynamické prostředky, jako jsou například ověřené koncové body rozhraní API, by se neměly ukládat do mezipaměti, aby se zabránilo úniku osobních údajů. Doporučuje se mít samostatné trasy pro statické a dynamické prostředky, u kterých je ukládání do mezipaměti zakázané.

Upozorňující

Než povolíte ukládání do mezipaměti, důkladně si projděte veřejnou dokumentaci a před povolením ukládání do mezipaměti otestujte všechny možné scénáře. Jak jsme uvedli dříve, s chybnou konfigurací můžete neúmyslně ukládat data specifická pro uživatele do mezipaměti, která můžou sdílet více uživatelů, což vede k incidentům ochrany osobních údajů.

Metody žádosti

Do mezipaměti se dají ukládat jenom požadavky, které používají metodu GET požadavku. Všechny ostatní metody požadavků se vždy přes síť přesouvají.

Doručování velkých souborů

Azure Front Door poskytuje velké soubory bez omezení velikosti souboru. Pokud je ukládání do mezipaměti povolené, služba Front Door používá techniku označovanou jako bloky objektů. Při vyžádání velkého souboru služba Front Door načte menší části souboru z původního zdroje. Jakmile služba Front Door obdrží úplnou žádost o soubor nebo žádost o soubor v rozsahu bajtů, prostředí Front Door požádá o soubor ze zdroje v blocích o velikosti 8 MB.

Jakmile blok dat dorazí do prostředí Služby Azure Front Door, uloží se do mezipaměti a okamžitě se uživateli obsluhuje. Front Door pak předem načte další blok dat paralelně. Díky tomuto předběžnému načtení zůstane obsah před uživatelem jeden blok dat, což snižuje latenci. Tento proces pokračuje, dokud se nestáhne celý soubor (pokud je to požadováno) nebo klient připojení zavře. Další informace o požadavku na rozsah bajtů najdete v dokumentu RFC 7233.

Služba Front Door ukládá do mezipaměti všechny bloky dat, které se přijímají, takže celý soubor nemusí být uložený v mezipaměti služby Front Door. Další požadavky na soubor nebo rozsahy 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 ze zdroje.

Tato optimalizace spoléhá na schopnost původu podporovat požadavky na rozsah bajtů. Pokud zdroj nepodporuje požadavky na rozsah bajtů nebo pokud nezpracuje správně požadavky na rozsah rozsahu, není tato optimalizace efektivní.

Když váš původ odpoví na požadavek hlavičkou Range , musí odpovědět jedním z následujících způsobů:

  • Vrátí odpověď s rozsahem. Odpověď musí používat stavový kód HTTP 206. Musí existovat také hlavička Content-Range odpovědi a musí odpovídat skutečné délce obsahu, který vrací váš původ. Pokud váš původ neodesílá správné hlavičky odpovědi s platnými hodnotami, Azure Front Door odpověď neuchová do mezipaměti a může se zobrazit nekonzistentní chování.

    Tip

    Pokud zdroj zkomprimuje odpověď, ujistěte se, že Content-Range hodnota hlavičky odpovídá skutečné délce komprimované odpovědi.

  • Vrátí odpověď bez rozsahu. Pokud váš původ nemůže zpracovat požadavky na rozsah, může hlavičku Range ignorovat a vrátit nerangedovanou odpověď. Ujistěte se, že zdroj vrací jiný stavový kód odpovědi než 206. Zdroj může například vrátit odpověď 200 OK.

Pokud zdroj používá k odesílání dat do protokolu POP služby Azure Front Door blokované kódování přenosu (CTE), velikost odpovědí větší než 8 MB se nepodporuje.

Komprese souborů

Podívejte se na zlepšení výkonu komprimací souborů ve službě Azure Front Door.

Azure Front Door (Classic) může dynamicky komprimovat obsah na hraničních zařízeních, což vede k menší a rychlejší době odezvy pro vaše klienty. Aby měl soubor nárok na kompresi, musí být povolená ukládání do mezipaměti a soubor musí mít typ MIME, který má nárok na kompresi. Front Door (classic) v současné době neumožňuje změny 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/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

Kromě toho musí být soubor ve velikosti 1 kB až 8 MB včetně.

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

Pokud požadavek podporuje gzip a kompresi Brotli, má přednost komprese Brotli.

Když požadavek na prostředek určuje kompresi a výsledkem požadavku je neúspěšná mezipaměť, Azure Front Door (Classic) komprimuje prostředek přímo na serveru POP. Poté se komprimovaný soubor obsluhuje z mezipaměti. Výsledná položka se vrátí s hlavičkou Transfer-Encoding: chunked odpovědi.

Pokud zdroj k odesílání dat do protokolu POP služby Azure Front Door používá blokované kódování přenosu (CTE), komprese se nepodporuje.

Poznámka:

Požadavky na rozsah 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í požadavky na rozsah bajtů s hlavičkou Accept-Encoding , která vede k reakci na zdroj s různými délkami obsahu, azure Front Door vrátí chybu 503. Můžete zakázat kompresi zdroje nebo vytvořit pravidlo stroje pravidel, které odebere hlavičku Accept-Encoding z požadavku na požadavky na rozsah bajtů.

Chování řetězce dotazu

Pomocí služby Azure Front Door můžete řídit, jak se soubory ukládají do mezipaměti pro webový požadavek, který obsahuje řetězec dotazu.

Ve webovém požadavku s řetězcem dotazu je řetězec dotazu část požadavku, která se vyskytuje po otazníku (?). Ř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é symbolem rovná se (=). Každý pár klíč-hodnota je oddělený ampersandem (&).

Adresa URL http://www.contoso.com/content.mov?field1=value1&field2=value2 například obsahuje dva řetězce dotazu:

  • field1, s hodnotou value1.
  • field2, s hodnotou value2.

Pokud je v řetězci dotazu požadavku více než jeden pár klíč-hodnota, nezáleží na jejich pořadí.

Při konfiguraci ukládání do mezipaměti určíte, jak má mezipaměť zpracovávat řetězce dotazů. Podporují se následující chování:

  • Ignorovat řetězec dotazu: V tomto režimu azure Front Door předá řetězce dotazu z klienta do zdroje při prvním požadavku a ukládá prostředek do mezipaměti. Budoucí žádosti o prostředek, který se obsluhuje z prostředí služby Front Door, ignorují řetězce dotazu, dokud nevyprší platnost prostředku uloženého v mezipaměti.

  • Použijte řetězec dotazu: 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 původu požadavku na požadavek www.example.ashx?q=test1 je uložena v mezipaměti v prostředí Služby Front Door a vrácena pro výčet mezipamětí se stejným řetězcem dotazu. Žádost www.example.ashx?q=test2 o uložení do mezipaměti je uložena jako samostatný prostředek s vlastním nastavením time-to-live.

    Pořadí parametrů řetězce dotazu nezáleží. Pokud například prostředí Služby Azure Front Door obsahuje odpověď uloženou v mezipaměti pro adresu URL www.example.ashx?q=test1&r=test2, pak se z mezipaměti také obsluhuje požadavek www.example.ashx?r=test2&q=test1 .

  • Ignorovat zadané řetězce dotazů a zahrnout zadané řetězce dotazu: V tomto režimu můžete službu Azure Front Door nakonfigurovat tak, aby při vygenerování klíče mezipaměti zahrnovala nebo vyloučila zadané parametry.

    Předpokládejme například, že výchozí klíč mezipaměti je /foo/image/asset.htmla na adresu URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200se provede požadavek . Pokud existuje pravidlo stroje pravidel pro vyloučení parametru userid řetězce dotazu, klíč mezipaměti řetězce dotazu by byl /foo/image/asset.html?language=EN&sessionid=200.

Nakonfigurujte chování řetězce dotazu na trase služby Front Door.

Vymazání mezipaměti

Informace o konfiguraci vyprázdnění mezipaměti ve službě Azure Front Door najdete v tématu Vymazání mezipaměti.

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

Osvědčeným postupem, jak zajistit, aby vaši 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ých adres 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 je všechny k načtení nových aktualizovaných prostředků. Důvodem může být aktualizace webové aplikace nebo rychlá aktualizace prostředků obsahujících nesprávné informace.

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

Vyberte prostředky, které chcete vyprázdnit z hraničních uzlů. Pokud chcete vymazat všechny prostředky, vyberte Vymazat vše. V opačném případě zadejte cestu ke každému prostředku, který chcete vyprázdnit.

Tyto formáty jsou podporovány v seznamech cest k vyprázdnění:

  • Vymazání jedné cesty: Vyprázdnění jednotlivých prostředků zadáním úplné cesty k prostředku (bez protokolu a domény) s příponou souboru, například /pictures/strasbourg.png;
  • Vyprázdně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 pomocí parametru /* 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 pomocí "/" v cestě.

Poznámka:

Vymazání domén se zástupnými cardy: Určení cest uložených v mezipaměti pro vymazání, jak je popsáno v této části, se nevztahuje na žádné zástupné domény přidružené ke službě Front Door. V současné době nepodporujeme přímé vymazání zástupných domén. Cesty můžete vyprázdnit z konkrétních subdomén zadáním této specifikované subdomény a vyprázdnění cesty. Pokud má například moje služba Front Door *.contoso.com, můžu vyprázdnit prostředky své 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 obsahu vyprázdnění omezeno na subdomény zástupných domén, pokud je to možné.

Vyprázdnění mezipaměti ve službě Front Door nerozlišují velká a malá písmena. Kromě toho jsou řetězce dotazu nezávislé, což znamená, že vymazání adresy URL vyprázdní všechny varianty řetězce dotazu.

Vypršení platnosti mezipaměti

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

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

Některé Cache-Control hodnoty hlavičky odpovědi označují, že odpověď není uložená v mezipaměti. Mezi tyto hodnoty patří private, no-cachea no-store. Služba Front Door respektuje tyto hodnoty hlaviček a neuchová odpovědi do mezipaměti, i když přepíšete chování ukládání do mezipaměti pomocí stroje pravidel.

Cache-Control Pokud záhlaví není k dispozici v odpovědi z původního zdroje, služba Front Door ve výchozím nastavení náhodně určuje dobu trvání mezipaměti mezi jedním a třemi dny.

Poznámka:

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

Může se zobrazit REVALIDATED_HIT v Cache-Control hlavičce odpovědi. To znamená, že obsah uložený v mezipaměti ve službě Azure Front Door byl před obsluhou klientovi znovu ověřen se serverem původu. K tomu může dojít, když vypršela platnost obsahu uloženého v mezipaměti, ale původní server indikuje, že se obsah nezměnil. V takovém případě se obsah uložený v mezipaměti obsluhuje klientovi a vypršení platnosti mezipaměti se resetuje.

Záhlaví žádosti

Následující hlavičky požadavku se při povolení ukládání do mezipaměti nepřepošla do zdroje:

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

Hlavičky odpovědi

Pokud je původní odpověď uložená v mezipaměti, Set-Cookie hlavička se odebere před odesláním odpovědi klientovi. Pokud odpověď původu není uložená v mezipaměti, služba Front Door záhlaví neodebere. Pokud například odpověď původu obsahuje hlavičku Cache-Control s hodnotou indikovanou službě max-age Front Door, že odpověď je uložená v mezipaměti a hlavička Set-Cookie se odstraní.

Front Door navíc připojí X-Cache záhlaví ke všem odpovědím. Hlavička X-Cache odpovědi obsahuje jednu z následujících hodnot:

  • TCP_HIT nebo TCP_REMOTE_HIT: První 8 MB bloku odpovědi je přístup do mezipaměti a obsah se obsluhuje z mezipaměti služby Front Door.
  • TCP_MISS: První 8 MB bloku odpovědi je neúspěšná mezipaměť a obsah se načte ze zdroje.
  • PRIVATE_NOSTORE: Požadavek nelze uložit do mezipaměti, protože hlavička odpovědi Cache-Control je nastavená na privátní nebo žádné úložiště.
  • CONFIG_NOCACHE: Požadavek je nakonfigurovaný tak, aby se neuchová do mezipaměti v profilu služby Front Door.

Protokoly a sestavy

Protokol přístupu zahrnuje stav mezipaměti pro každý požadavek. Sestavy také obsahují informace o tom, jak se ve vaší aplikaci používá mezipaměť služby Azure Front Door.

Protokol přístupu zahrnuje stav mezipaměti pro každý požadavek.

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

Chování mezipaměti a doba trvání je možné nakonfigurovat v modulu pravidel. Konfigurace modulu pravidel ukládání do mezipaměti vždy přepisuje konfiguraci trasy.

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

  • Když je ukládání do mezipaměti povolené, chování mezipaměti se liší v závislosti na hodnotě chování mezipaměti použité modulem pravidel:

    • Čest původu: Azure Front Door vždy respektuje direktivu hlavičky odpovědi původu. Pokud direktiva původu chybí, Azure Front Door ukládá obsah do mezipaměti od jednoho do tří dnů.
    • Přepsání vždy: Azure Front Door vždy přepisuje dobu trvání mezipaměti, což znamená, že ukládá obsah do mezipaměti po dobu trvání mezipaměti bez ohledu na hodnoty direktiv odpovědi původu. Toto chování platí pouze v případě, že je odpověď uložená v mezipaměti.
    • Přepsání v případě chybějícího zdroje: 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í platí pouze v případě, že je odpověď uložená v mezipaměti.

Poznámka:

  • Azure Front Door neposkytuje žádné záruky o době, po kterou je obsah uložený v mezipaměti. Obsah uložený v mezipaměti může být před vypršením platnosti obsahu odebrán z hraniční mezipaměti, pokud se obsah často nepoužívá. Služba Front Door může 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 vašemu webu pomoct zůstat částečně dostupný, když jsou vaše původy offline.
  • Původy mohou určovat, že nebudou ukládat konkrétní odpovědi do mezipaměti pomocí hlavičky Cache-Control s hodnotou typu no-cache, private nebo no-store. Při použití v odpovědi HTTP ze zdrojového serveru na POPs služby Azure Front Door služba Azure Front Door podporuje direktivy řízení mezipaměti a dodržuje chování ukládání do mezipaměti pro direktivy Cache-Control v RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Ukládání do mezipaměti (ietf.org).

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

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

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

    • Pokud je výchozí doba použití mezipaměti nastavená na Ano, Služba Azure Front Door (Classic) vždy respektuje direktivu hlavičky odpovědi zdroje. Pokud direktiva origin chybí, služba Front Door ukládá obsah do mezipaměti od jednoho do tří dnů.
    • Pokud je výchozí doba použití mezipaměti nastavená na Ne, Služba Azure Front Door (Classic) vždy přepíše dobu trvání mezipaměti (požadovaná pole), což znamená, že ukládá obsah do mezipaměti bez ohledu na hodnoty direktiv odpovědi původu.

Poznámka:

  • Azure Front Door (Classic) neposkytuje žádné záruky o době, po kterou je obsah uložený v mezipaměti. Obsah uložený v mezipaměti může být před vypršením platnosti obsahu odebrán z hraniční mezipaměti, pokud se obsah často nepoužívá. 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 vašemu webu pomoct zůstat částečně dostupný, když jsou vaše původy 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 hlavička ovládacího prvku mezipaměti z původu má větší hodnotu TTL než hodnota přepsání.

Další kroky