Sdílet prostřednictvím

Jak funguje ukládání do mezipaměti

  • Článek

Důležité

30. září 2027 bude vyřazena služba Azure CDN Standard od Microsoftu (Classic). Abyste se vyhnuli přerušení služeb, je důležité do 30. září 2027 migrovat profily Azure CDN Standard z Microsoftu (classic) na úroveň Azure Front Door Standard nebo Premium. Další informace najdete v tématu Azure CDN Standard od Microsoftu (klasického) vyřazení.

15. ledna 2025 byla vyřazena služba Azure CDN z Edgio. Další informace najdete v tématu Azure CDN z nejčastějších dotazů k vyřazení Edgio.

Tento článek obsahuje přehled obecných konceptů ukládání do mezipaměti a o tom, jak Azure Content Delivery Network využívá ukládání do mezipaměti ke zlepšení výkonu. Pokud se chcete dozvědět, jak přizpůsobit chování ukládání do mezipaměti v koncovém bodu sítě pro doručování obsahu, přečtěte si téma Řízení chování služby Azure Content Delivery Network při ukládání do mezipaměti pomocí pravidel ukládání do mezipaměti a chování služby Azure Content Delivery Network při ukládání do mezipaměti pomocí řetězců dotazů.

Úvod do ukládání do mezipaměti

Ukládání dat do mezipaměti je proces ukládání dat místně, aby k budoucím požadavkům na tato data bylo možné přistupovat rychleji. Ve nejběžnějším typu ukládání do mezipaměti webový prohlížeč ukládá webový prohlížeč kopie statických dat místně na místním pevném disku. Díky ukládání do mezipaměti se webový prohlížeč může vyhnout několika odezvám na server a místo toho přistupovat ke stejným datům místně, což šetří čas a prostředky. Ukládání do mezipaměti je vhodné pro místní správu malých statických dat, jako jsou statické obrázky, soubory CSS a javascriptové soubory.

Podobně ukládání do mezipaměti používá síť pro doručování obsahu na hraničních serverech blízko uživatele, aby se zabránilo tomu, že požadavky putují zpět do původu a snižují latenci koncových uživatelů. Na rozdíl od mezipaměti webového prohlížeče, která se používá jenom pro jednoho uživatele, má síť pro doručování obsahu sdílenou mezipaměť. Ve sdílené mezipaměti sítě pro doručování obsahu může uživatel použít žádost o soubor jiný uživatel, což výrazně snižuje počet požadavků na původní server.

Dynamické prostředky, které se často mění nebo jsou jedinečné pro jednotlivé uživatele, se nedají ukládat do mezipaměti. Tyto typy prostředků ale můžou využít optimalizaci dynamické akcelerace webu (DSA) v síti pro doručování obsahu Azure kvůli vylepšení výkonu.

Ukládání do mezipaměti může probíhat na několika úrovních mezi počátečním serverem a koncovým uživatelem:

  • Webový server: Používá sdílenou mezipaměť (pro více uživatelů).
  • Síť pro doručování obsahu: Používá sdílenou mezipaměť (pro více uživatelů).
  • Poskytovatel internetových služeb (ISP): Používá sdílenou mezipaměť (pro více uživatelů).
  • Webový prohlížeč: Používá privátní mezipaměť (pro jednoho uživatele).

Každá mezipaměť obvykle spravuje vlastní aktuálnost prostředků a provádí ověření, když je soubor zastaralý. Toto chování je definováno ve specifikaci ukládání do mezipaměti HTTP RFC 7234.

Aktuálnost zdroje

Vzhledem k tomu, že prostředek uložený v mezipaměti může být zastaralý nebo zastaralý (ve srovnání s odpovídajícím prostředkem na zdrojovém serveru), je důležité, aby jakýkoli mechanismus ukládání do mezipaměti kontroloval, kdy se obsah aktualizuje. Pokud chcete ušetřit čas a spotřebu šířky pásma, prostředek uložený v mezipaměti se nerovná s verzí na zdrojovém serveru při každém přístupu. Místo toho se předpokládá, že pokud je prostředek uložený v mezipaměti aktuální, předpokládá se, že se jedná o nejaktuálnější verzi a odesílá se přímo klientovi. Prostředek uložený v mezipaměti se považuje za čerstvý, pokud je jeho věk menší než věk nebo období definované nastavením mezipaměti. Když například prohlížeč znovu načte webovou stránku, ověří, že každý prostředek uložený v mezipaměti na pevném disku je čerstvý a načte ho. Pokud prostředek není aktuální (zastaralý), načte se ze serveru aktuální kopie.

Ověřování

Pokud je prostředek považován za zastaralý, server původu se zobrazí výzva k ověření, jestli data v mezipaměti stále odpovídají tomu, co je na zdrojovém serveru. Pokud byl soubor na zdrojovém serveru změněn, mezipaměť aktualizuje svou verzi prostředku. Jinak pokud je prostředek aktuální, data se doručují přímo z mezipaměti bez jejich ověření.

Ukládání do mezipaměti sítě pro doručování obsahu

Ukládání do mezipaměti je nedílnou součástí způsobu, jakým síť pro doručování obsahu funguje, aby urychlila doručování a snížila zatížení zdroje statických prostředků, jako jsou obrázky, písma a videa. Při ukládání do mezipaměti sítě pro doručování obsahu jsou statické prostředky selektivně uložené na strategicky umístěných serverech, které jsou pro uživatele více místní a nabízejí následující výhody:

  • Vzhledem k tomu, že většina webového provozu je statická (například obrázky, písma a videa), ukládání do mezipaměti sítě pro doručování obsahu snižuje latenci sítě přesunutím obsahu blíž k uživateli, čímž se sníží vzdálenost, kterou data cestují.

  • Přesměrováním práce do sítě pro doručování obsahu může ukládání do mezipaměti snížit síťový provoz a zatížení zdrojového serveru. Tím se sníží náklady a požadavky na prostředky pro aplikaci, a to i v případě, že existuje velký počet uživatelů.

Podobně jako při implementaci ukládání do mezipaměti ve webovém prohlížeči můžete řídit, jak se ukládání do mezipaměti provádí v síti pro doručování obsahu odesláním hlaviček direktiv mezipaměti. Hlavičky direktiv mezipaměti jsou hlavičky HTTP, které jsou obvykle přidány serverem původu. I když byla většina těchto hlaviček původně navržena tak, aby řešila ukládání do mezipaměti v klientských prohlížečích, používají je teď také všechny zprostředkující mezipaměti, jako jsou sítě pro doručování obsahu.

Dvě hlavičky lze použít k definování aktuálnosti mezipaměti: Cache-Control a Expires. Cache-Control je aktuální a má přednost před Expires, pokud existují obě. Pro ověřování (označované jako validátory) se používají také dva typy hlaviček: ETag a Last-Modified. ETag je aktuálnější a má přednost před Last-Modified, pokud jsou definovány oba.

Hlavičky direktiv mezipaměti

Azure Content Delivery Network podporuje následující hlavičky direktivy mezipaměti HTTP, které definují dobu trvání mezipaměti a sdílení mezipaměti.

Řízení mezipaměti:

  • Představeno v PROTOKOLU HTTP 1.1, které poskytuje webovým vydavatelům větší kontrolu nad obsahem a vyřešením omezení hlavičky Expires .
  • Přepíše hlavičku Expires , pokud je definovaná i Cache-Control definovaná.
  • Při použití v požadavku HTTP z klienta do sítě pro doručování obsahu POP se Cache-Control ve výchozím nastavení ignorují všechny profily služby Azure Content Delivery Network.
  • Při použití v odpovědi HTTP ze zdrojového serveru na pop sítě Cache-Control pro doručování obsahu se ve výchozím nastavení dodržují všechny profily služby Azure Content Delivery Network. Azure CDN také respektuje chování ukládání do mezipaměti pro direktivy Cache-Control v DOKUMENTU RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Ukládání do mezipaměti (ietf.org).

Propadává:

  • Starší hlavička představená v HTTP 1.0; podporuje zpětnou kompatibilitu.
  • Používá čas vypršení platnosti na základě data s druhou přesností.
  • Podobá se Cache-Control: max-age.
  • Používá se, když Cache-Control neexistuje.

Direktiva Pragma:

  • Služba Azure Content Delivery Network není ve výchozím nastavení dodržena.
  • Starší hlavička představená v HTTP 1.0; podporuje zpětnou kompatibilitu.
  • Používá se jako hlavička požadavku klienta s následující direktivou: no-cache. Tato direktiva dává serveru pokyn, aby doručil novou verzi prostředku.
  • Pragma: no-cache je ekvivalent Cache-Control: no-cache.

Validátory

Pokud je mezipaměť zastaralá, používají se validátory mezipaměti HTTP k porovnání verze souboru uložené v mezipaměti s verzí na zdrojovém serveru. Azure CDN Standard od Microsoftu podporuje pouze Last-Modified.

Poznámka:

Azure CDN od Microsoftu (classic) nepodporuje ETag.

Naposledy změněno:

  • Určuje datum a čas, kdy původní server určil, že prostředek byl naposledy změněn. Například Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • U obsahu většího než 8 MB by back-endové servery původu měly udržovat konzistentní Last-Modified časová razítka na prostředek. Vrácení nekonzistentních Last-Modified časů z back-endových serverů způsobí chyby neshody validátoru a způsobí selhání HTTP 5XX. Azure Storage nemusí podporovat konzistentní Last-Modified časová razítka napříč replikami, což může způsobit podobné chyby neshody validátoru.
  • Mezipaměť ověří soubor pomocí Last-Modified odeslání If-Modified-Since hlavičky s datem a časem v požadavku. Původní server porovná toto datum s hlavičkou Last-Modified nejnovějšího prostředku. Pokud se prostředek od zadaného času nezměnil, vrátí server stavový kód 304 (Neupraveno) v odpovědi. Pokud byl prostředek změněn, server vrátí stavový kód 200 (OK) a aktualizovaný prostředek.

Určení souborů, které se dají ukládat do mezipaměti

Ne všechny prostředky se dají ukládat do mezipaměti. Následující tabulka ukazuje, jaké prostředky je možné ukládat do mezipaměti na základě typu odpovědi HTTP. Prostředky doručované s odpověďmi HTTP, které nesplňují všechny tyto podmínky, se nedají ukládat do mezipaměti.

Podmínky Hodnota
Stavové kódy HTTP 200, 203, 206, 300, 301, 410, 416
Metody HTTP GET, HEAD
Omezení velikosti souboru 300 GB

Aby ukládání do mezipaměti fungovalo na prostředku, musí původní server podporovat všechny požadavky HEAD a GET HTTP a hodnoty délky obsahu musí být stejné pro všechny odpovědi HEAD a GET HTTP prostředku. V případě požadavku HEAD musí původní server podporovat požadavek HEAD a musí odpovídat se stejnými hlavičkami, jako kdyby obdržel požadavek GET.

Poznámka:

Požadavky, které obsahují autorizační hlavičku, nebudou uloženy do mezipaměti.

Výchozí chování při ukládání do mezipaměti

Výchozí chování při ukládání do mezipaměti pro Azure CDN je respektovat obsah původu a mezipaměti po dobu dvou dnů.

Čest původu: Toto nastavení určuje, jestli se mají respektovat hlavičky direktiv mezipaměti (Cache-Control nebo Expires), pokud se nacházejí v odpovědi HTTP ze zdrojového serveru.

Doba trvání mezipaměti CDN: Toto nastavení určuje dobu, po kterou se prostředek ukládá do mezipaměti v Azure CDN. Pokud je povolený zdroj Honor a odpověď HTTP ze serveru původu obsahuje hodnotu nebo Expires hlavičkuCache-Control: max-age, Azure CDN místo výchozího dvoudenního období použije dobu trvání určenou těmito hlavičkami.

Poznámka:

Azure CDN neposkytuje žádné záruky o minimální době, po kterou bude objekt uložen v mezipaměti. Obsah uložený v mezipaměti se může před vypršením platnosti vyřadit z mezipaměti sítě pro doručování obsahu, pokud se obsah nevyžaduje tak často, aby se uvolnil prostor pro častěji požadovaný obsah.

Další kroky