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í.

Azure CDN z Edgio bude vyřazeno z Januray 15, 2025. Před tímto datem musíte migrovat úlohu do služby Azure Front Door, abyste se vyhnuli přerušení služeb. 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

Důležité

Ve výchozím nastavení koncový bod služby Azure Content Delivery Network, který je optimalizovaný pro DSA, ignoruje hlavičky direktiv mezipaměti a obchází ukládání do mezipaměti. Pro profily Azure CDN Standard z profilů Edgio můžete upravit způsob, jakým koncový bod služby Azure Content Delivery Network zachází s těmito hlavičkami pomocí pravidel ukládání do mezipaměti sítě pro doručování obsahu, aby bylo možné ukládání do mezipaměti povolit. Pro Azure CDN Premium pouze z profilů Edgio použijete modul pravidel k povolení ukládání do 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ě pro doručování obsahu:

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/Premium z Edgio ve výchozím nastavení podporuje obojí ETag i Last-Modified validátory, zatímco Azure CDN Standard od Microsoftu podporuje pouze Last-Modified.

ETag:

  • Azure CDN Standard/Premium z Edgio ve výchozím nastavení podporuje ETag , zatímco Azure CDN Standard od Microsoftu nepodporuje.
  • ETag definuje řetězec, který je jedinečný pro každý soubor a verzi souboru. Například ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Zavedeno v HTTP 1.1 a je aktuální než Last-Modified. Užitečné, když je obtížné určit datum poslední změny.
  • Podporuje silné ověřování i slabé ověřování; Azure Content Delivery Network ale podporuje pouze silné ověřování. Pro silné ověření musí být dvě reprezentace prostředků identické bajtové bajty.
  • Mezipaměť ověří soubor, který se používá ETag odesláním If-None-Match hlavičky s jedním nebo více ETag validátory v požadavku. Například If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Pokud verze serveru odpovídá ETag validátoru v seznamu, odešle stavový kód 304 (Neupraveno) v odpovědi. Pokud se verze liší, server odpoví stavovým kódem 200 (OK) a aktualizovaným prostředkem.

Naposledy změněno:

  • Pouze pro Azure CDN Standard/Premium z Edgio se používá, Last-Modified pokud ETag není součástí odpovědi HTTP.
  • 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. Pro Azure CDN Premium pouze z Edgio můžete pomocí modulu pravidel přizpůsobit některé z těchto podmínek.

Azure Content Delivery Network od Microsoftu Azure Content Delivery Network z Edgio
Stavové kódy HTTP 200, 203, 206, 300, 301, 410, 416 200
Metody HTTP GET, HEAD GET
Omezení velikosti souboru 300 GB 300 GB

Aby služba Azure CDN Standard od Microsoftu fungovala na prostředku, musí server původu 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

Následující tabulka popisuje výchozí chování ukládání do mezipaměti pro produkty Azure Content Delivery Network a jejich optimalizace.

Microsoft: Obecné doručování webu Edgio: Obecné doručování webu Edgio: DSA
Čestný původ Ano Ano No
doba trvání mezipaměti sítě pro doručování obsahu Dva dny Sedm dní Nic

Čest původu: Určuje, jestli se mají respektovat hlavičky podporované direktivy mezipaměti, pokud existují v odpovědi HTTP ze zdrojového serveru.

Doba trvání mezipaměti CDN: Určuje dobu, po kterou se prostředek ukládá do mezipaměti v síti pro doručování obsahu Azure. Pokud je však zdroj Honor ano a odpověď HTTP ze zdrojového serveru obsahuje hlavičku Expires direktivy mezipaměti nebo Cache-Control: max-age, Azure Content Delivery Network místo toho používá hodnotu doby trvání určenou hlavičkou.

Poznámka:

Azure Content Delivery Network 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