← Referenční architektury / reference-architecture / architectures

Referenční architektura sítě pro doručování obsahu (CDN)

Uživatelé internetu si každý den užívají výkon a spolehlivost, které jim poskytuje sítě pro doručování obsahu ↗ (CDN). Sítě CDN se staly nezbytností v boji proti latenci a nutností pro každou větší firmu, která doručuje obsah uživatelům po internetu. Kromě výkonu a spolehlivosti pro zákazníky umožňují sítě CDN firmám i lépe zabezpečit aplikace a snížit náklady. Tento dokument popisuje tradiční problémy, se kterými se zákazníci u webových aplikací potýkají, jak je řeší Cloudflare CDN a jak vypadá architektura a návrh CDN.

Tato referenční architektura je určena pracovníkům IT nebo síťových týmů, kteří mají na starosti stávající infrastrukturu organizace nebo ji dobře znají. Užitečná je zkušenost s technologiemi a koncepty důležitými pro doručování obsahu, jako je cachování, DNS a firewally.

Pro hlubší základní pochopení Cloudflare doporučujeme následující zdroje:

• Co je Cloudflare? | Web ↗ (čtení na 5 minut) nebo video ↗ (2 minuty)

• Co je CDN? | Web ↗ (čtení na 5 minut)
• Zpráva analytika: Cloudflare byl označen jako Leader v žebříčku 2024 GigaOm Radar for Content Delivery Networks ↗ (čtení na 20 minut)

Čtenáři této referenční architektury se dozvědí:

• Jak CDN Cloudflare výrazně zlepšuje doručování obsahu vašim zákazníkům
• Jaký význam má směrování anycast IP pro spolehlivý výkon CDN
• Přehled možností vrstvené cache (tiered caching) a jak z nich vybrat tu, která vyhovuje vašim potřebám

V posledních letech, zejména s příchodem pandemie COVID-19 a důrazem na práci na dálku, výrazně vzrostl objem internetového provozu. Tím dále vzrostla potřeba efektivně řídit síťový provoz, snižovat latenci a zvyšovat výkon.

Firmy, které provozují své aplikace v cloudu nebo on-premise, čelí těmto výzvám:

1. Implementace řešení pro zvýšení výkonu
2. S rostoucí poptávkou škálují svou architekturu do šířky, aby zajistili dostupnost a redundanci
3. Zabezpečení svého prostředí a aplikací před rostoucími hrozbami z internetu
4. Udržení rostoucích nákladů spojených se vším výše uvedeným pod kontrolou

Firmy obsluhující zákazníky po celém světě musí výše uvedené výzvy řešit jako rozsáhlý úkol. Web nebo aplikace se tradičně nasazuje centrálně a pro zajištění dostupnosti se replikuje do jiného regionu, případně se nasazuje na několika serverech, někdy i napříč více datacentry kvůli odolnosti.

Servery hostující weby se nazývají origin servery. Když klienti přistupují k webu, žádají server o zdroje. Návštěva jediného webu může v prohlížeči vyvolat stovky požadavků na HTML, CSS, obrázky, videa a podobně. U verzí HTTP starších než HTTP/2 navíc každý takový požadavek HTTP vyžadoval nové připojení TCP.

Vylepšení v HTTP/2 a HTTP/3 umožňují multiplexovat více požadavků na stejný server přes jediné TCP spojení, čímž šetří prostředky serveru. Výpočetní a síťové prostředky se ale i tak spotřebovávají, protože server na tyto požadavky musí odpovídat. S rostoucím počtem klientů přistupujících na web může dojít k následujícímu:

• Origin server se začíná přetěžovat požadavky, což ovlivňuje dostupnost; firmy proto začínají řešit horizontální škálování, aby další zátěž zvládly
• Protože každý požadavek musí urazit cestu až k origin serveru, ovlivňuje latence výkon i uživatelský zážitek
• Latence pro koncové uživatele se stává úměrná vzdálenosti mezi klientem a origin serverem, takže se zkušenost uživatelů liší podle jejich polohy. Platí to zejména pro určité země, kde provoz směřující z dané země nebo do ní může latenci zvyšovat, například v Číně.
• S tím, jak origin servery reagují na rostoucí počet požadavků, prudce rostou i náklady na šířku pásma, odchozí provoz a výpočetní výkon
• I když zákazníci škálují svou infrastrukturu tak, aby zvládla rostoucí provoz, zůstávají vystaveni DDoS útokům jak na úrovni infrastruktury, tak na úrovni aplikace

Na obrázku 1 níže není přítomna žádná CDN a origin server se nachází v USA. Když klienti přistupují na web, prvním krokem je DNS rozpoznávání, které obvykle provádí poskytovatel internetu (ISP) uživatele. Dalším krokem je HTTP požadavek odeslaný přímo na origin server. Uživatelský zážitek se liší podle polohy uživatele. Je vidět například, že latence je výrazně nižší u uživatelů v USA, kde se origin server nachází. U uživatelů mimo USA latence roste, což vede k vyšší době odezvy (round trip time, RTT).

S tím, jak více klientů odesílá požadavky na origin server, roste zátěž sítě i serveru, což vede k vyšší latenci a vyšším nákladům na využití prostředků a šířky pásma.

Z bezpečnostního hlediska je originový server zranitelný i vůči útokům DDoS, a to jak na úrovni infrastruktury, tak aplikace. Útok DDoS může spustit botnet, který na originový server odesílá miliony požadavků, čímž vyčerpává jeho prostředky a brání mu obsluhovat legitimní klienty.

Pokud jde o odolnost, dočasný výpadek originového serveru navíc znamená, že veškerý obsah se pro uživatele stane nedostupným.

CDN pomáhá řešit problémy, se kterými se zákazníci potýkají v souvislosti s latencí, výkonem, dostupností, redundancí, zabezpečením a náklady. Hlavním cílem CDN je snížit latenci a zvýšit výkon webových stránek a aplikací tím, že ukládá obsah do mezipaměti co nejblíže koncovým uživatelům nebo těm, kdo k obsahu přistupují.

Sítě CDN snižují latenci a zvyšují výkon díky tomu, že mají po celém světě mnoho datových center, která ukládají obsah z origin serveru do cache. Cílem je mít obsah v cache co nejblíže uživatelům, proto se ukládá na okraji sítě poskytovatele CDN.

• Zkrácená doba načítání webu: Namísto toho, aby každý klient odesílal požadavek na origin server, který se může nacházet v podstatné vzdálenosti, se požadavek směruje na lokální server, jenž odpoví kešovaným obsahem, čímž se snižuje latence a zvyšuje celkový výkon. Bez ohledu na umístění origin serveru a klientů tak bude výkon konzistentnější pro všechny uživatele, protože CDN bude podle možností obsluhovat lokálně kešovaný obsah.

• Vyšší dostupnost obsahu a redundance: Protože už není nutné každý klientský požadavek posílat na origin server, přináší CDN nejen výkonnostní výhody, ale i vyšší dostupnost a redundanci. Požadavky se rozkládají mezi lokální servery s obsahem v mezipaměti, které odpovídají na místní požadavky a výrazně tak snižují celkovou zátěž origin serveru. Ten se kontaktuje pouze v případě potřeby, tedy když obsah není v mezipaměti nebo jde o dynamický obsah, který se do mezipaměti ukládat nedá.

• Vyšší zabezpečení webu: CDN funguje jako reverzní proxy a stojí před origin servery. Díky tomu může poskytovat rozšířené zabezpečení, jako je zmírňování DDoS útoků, vylepšení bezpečnostních certifikátů a další optimalizace.

• Nižší náklady na šířku pásma: Protože CDN odpovídá na požadavky obsahem z mezipaměti, snižuje se počet požadavků odesílaných na origin server, čímž klesají i související náklady na přenos dat.

Důležitým rozdílem u některých implementací CDN je způsob, jakým směrují provoz k příslušným místním uzlům CDN. Směrování požadavků na uzly CDN lze provést dvěma různými metodami:

Unicastové směrování DNS

V této metodě přesměrovávají rekurzivní DNS dotazy požadavky na uzly CDN, přičemž DNS resolver klienta předává požadavky autoritativnímu nameserveru CDN. CDN založené na unicastovém směrování DNS nejsou ideální, protože klienti mohou být geograficky vzdáleni od DNS resolveru. Výběr nejbližšího uzlu CDN se totiž řídí podle DNS serveru klienta, nikoli podle IP adresy klienta. Pokud je navíc potřeba změnit odpověď DNS, je nutné počkat na vypršení TTL (time to live).

Jelikož směrování DNS navíc využívá unicastové adresy, provoz je směrován přímo na konkrétní uzel, což může představovat problém při špičkách provozu, například během útoku DDoS.

Další výzvou u CDN založených na DNS je, že DNS se při přepnutí nechová příliš elegantně. Obvykle musí resolver DNS spustit novou relaci nebo aplikaci s jinou IP adresou, aby došlo k převzetí.

Směrování Anycast

CDN Cloudflare, kterou podrobněji popisuje následující část, využívá směrování anycast. Anycast umožňuje, aby uzly v síti sdílely stejnou IP adresu. Tatáž IP adresa je oznamována z více uzlů na různých místech a přesměrování klienta zajišťuje směrovací protokol internetu BGP.

CDN založená na anycastu přináší několik výhod:

• Příchozí provoz je směrován do nejbližšího datového centra, které má kapacitu efektivně zpracovat požadavky.
• Dostupnost a redundance jsou zajištěny automaticky. Protože stejnou IP adresu má více uzlů, v případě výpadku jednoho z nich se požadavky jednoduše přesměrují na jiný uzel v blízkém okolí.
• Anycast rozprostírá provoz mezi více datovými centry, čímž zvětšuje celkovou plochu pro jeho zpracování a brání tomu, aby byla některá lokalita zahlcena požadavky. Díky tomu jsou sítě s anycastem velmi odolné vůči útokům DDoS.

Cloudflare poskytuje CDN formou modelu Software as a Service (SaaS). Díky modelu SaaS od Cloudflare mohou zákazníci využívat CDN Cloudflare, aniž by museli spravovat nebo udržovat jakoukoli infrastrukturu či software.

Přínosy Cloudflare CDN vycházejí ze dvou níže uvedených bodů, které jsou podrobněji popsány v této části.

1. Sítě CDN díky své podstatě zvyšují výkon tím, že ukládají obsah do cache na serverech blízko uživatele
2. Jedinečná architektura a integrovaný ekosystém Cloudflare

Obrázek 2: Zjednodušené znázornění Cloudflare CDN. Klienti dostávají odpověď ze serveru v globální anycast síti Cloudflare, který je jim nejblíže, což výrazně snižuje latenci a RTT. Diagram ukazuje konzistentní uživatelský zážitek bez ohledu na fyzickou polohu klientů a originu.

Obrázek 3 je pohled na Cloudflare CDN v globální anycast síti. Kromě využití anycast pro výkon a odolnost sítě využívá Cloudflare CDN také Tiered Cache k dosažení optimalizovaných výsledků při současné úspoře nákladů pro zákazníky. Zákazníci mohou také zapněte Argo Smart Routing k nalezení nejrychlejší síťové cesty pro směrování požadavků na origin server. Těmto možnostem se podrobně věnuje zbytek tohoto dokumentu.

Na diagramu výše je několik důležitých bodů, které je třeba chápat o Cloudflare CDN a globální anycast síti, na které funguje:

• Důležitým rozlišujícím faktorem je, že Cloudflare využívá jedinou globální síť a provozuje každou službu na každém serveru v každém datovém centru Cloudflare, čímž koncovým uživatelům poskytuje největší blízkost ke službám Cloudflare při nejvyšší škálovatelnosti, odolnosti a výkonu.
• Cloudflare funguje jako reverzní proxy, což znamená, že přijímá požadavky od klientů a přeposílá je na origin servery zákazníka. Každý požadavek tak prochází sítí Cloudflare dříve, než se dostane do sít zákazníka.
• CDN Cloudflare využívá globální anycast síť Cloudflare. Příchozí požadavek je tak směrován na uzel nejblíže uživateli a tímto uzlem i zodpovězen.
• Mezi přirozené výhody anycastu patří nižší latence, odolnost sítě, vyšší dostupnost a lepší zabezpečení díky větší ploše pro pohlcení jak legitimní zátěže, tak útoků DDoS. Globální anycastová síť Cloudflare pokrývá stovky měst po celém světě ↗, dosahuje 95 % světové populace připojené k internetu do 50 milisekund a zároveň poskytuje síťovou kapacitu přes 405 Tb/s a ochranu před útoky DDoS.
• Edge uzly v síti Cloudflare ukládají obsah z origin serveru do mezipaměti (cache) a dokážou na požadavky odpovídat pomocí uložené kopie. Cloudflare také poskytuje DNS, Ochrana před DDoS, WAF, a dalších služeb pro výkon, spolehlivost a zabezpečení, které využívají stejnou edge architekturu.
• Argo využívá optimalizované směrování a technologii ukládání do mezipaměti v celé síti Cloudflare, aby uživatelům doručovala odpovědi rychleji, spolehlivěji a bezpečněji. Argo zahrnuje Smart Routing a Tiered Cache. Cloudflare k poskytování vylepšeného řešení CDN využívá Argo.

Po zavedení webu se ve výchozím nastavení nakonfiguruje standardní ukládání do mezipaměti. Při standardním ukládání do mezipaměti funguje každé datové centrum jako přímý reverzní proxy server pro origin servery. Pokud v libovolném datovém centru dojde k výpadku mezipaměti (cache miss), odešle se požadavek na origin server ze vstupního datového centra.

Standardní ukládání do mezipaměti funguje, ale není to nejoptimálnější řešení: obsah uložený blíže klientovi již může existovat v jiných datových centrech Cloudflare, a origin servery jsou proto někdy zbytečně přetíženy. Proto je nejlepší zapnout Tiered Cache, který je součástí každého plánu Cloudflare. Díky Tiered Cache funguje pro ostatní datová centra jako reverzní proxy k originu, což znamená více zásahů v mezipaměti a rychlejší odezvy.

Tiered Cache využívá rozsah sítě Cloudflare k minimalizaci požadavků na origin zákazníka. Když požadavek dorazí do datacentra Cloudflare a požadovaný obsah v něm není lokálně uložen v cache, zkontrolují se ostatní datacentra Cloudflare, zda obsah v cache mají.

Datová centra Cloudflare jsou od sebe vzdálena méně a spojení mezi nimi jsou rychlejší než spojení mezi datovými centry a origin servery zákazníka, což optimalizuje odezvu klientovi a výrazně zlepšuje poměr cache hit. CDN Cloudflare využívá data ze služby Argo Smart Routing k určení nejvhodnějších datových center vyšší úrovně pro Tiered Cache. Argo Smart Routing lze také zapnout jako doplněk, který zajišťuje nejrychlejší cesty mezi datovými centry a origin servery při cache miss a dalších typech dynamického provozu.

CDN Cloudflare umožňuje zákazníkům nakonfigurovat vrstvené ukládání do mezipaměti. V závislosti na plánu Cloudflare jsou k dispozici různé topologie pro Tiered Cache. Ve výchozím nastavení je vrstvené ukládání do mezipaměti vypnuté a lze jej zapnout na kartě caching v hlavní nabídce.

Různé topologie mezipaměti umožňují zákazníkům řídit, jak Cloudflare komunikuje s originovými servery, a přispívají tak k vyšší úspěšnosti mezipaměti, menšímu počtu připojení k originu a nižší latenci.

Na obrázku 4 je zapnuto Tiered Caching s topologií Smart Tiered Cache. Diagram znázorňuje dva samostatné toky provozu, shrnuté níže. První tok provozu (Klient 1) je požadavek od klienta, který přichází do Datacentra 1. Druhý tok provozu (Klient 2) je následný požadavek na stejný prostředek, který přichází do jiného datacentra, Datacentra 2.

Na obrázku 4 horní tok provozu koncového uživatele znázorňuje situaci, kdy požadavek klienta přijímá datacentrum nejbližší klientovi, Datacentrum 1. Protože ve vstupním datacentru není obsah lokálně uložen v mezipaměti a zároveň je zapnuté vrstvené ukládání do mezipaměti, odešle se požadavek do datacentra vyšší vrstvy s žádostí o kopii obsahu k uložení do mezipaměti. Protože ani datacentrum vyšší vrstvy nemá obsah v mezipaměti, odešle požadavek na origin server, po obdržení odpovědi uloží obsah do mezipaměti a datacentru nižší vrstvy odpoví obsahem z mezipaměti. Datacentrum nižší vrstvy obsah uloží do mezipaměti a odpoví klientovi.

Všimněte si, že když je nový požadavek na stejný obsah odeslán do jiného datového centra, Data Center 3 (spodní tok provozu koncového uživatele), obsah zde není lokálně uložen v cache. Získá se však z nadřazeného datového centra, kde byl uložen v cache při prvním požadavku na tentýž obsah.

Když datacentrum vyšší úrovně vrátí obsah z cache pro druhý požadavek, odpadá nutnost cesty na origin server. Výsledkem je vyšší poměr zásahů do cache, rychlejší doba odezvy, úspora nákladů na přenos dat mezi sítí Cloudflare a origin serverem a nižší zátěž origin serveru při zpracování požadavků.

Hlavní rozdíl mezi Smart Tiered Cache a Global tiered cache spočívá v počtu horních vrstev, které mohou komunikovat s origin servery. U Smart Tiered Cache se nejbližší horní vrstva k originu vybírá na základě výkonnostních a směrovacích dat Argo. To znamená, že u všech požadavků, u kterých dojde k cache MISS na nižší úrovni bude procházet touto jedinou vyšší úrovní a bude mít vyšší pravděpodobnost zásahu do HIT aby se zabránilo odesílání provozu na origin server. Nevýhodou této architektury ovšem je, že spodní vrstva se může nacházet o kus světa dál než horní vrstva. I když horní vrstva dokáže požadavek obsloužit z cache, vzdálenost mezi horní a spodní vrstvou může do odpovědi stále přidávat latenci, v závislosti na uražené vzdálenosti. Shrnuto, Smart Tiered Cache zajišťuje, že veškeré požadavky na cache procházejí jedinou lokalitou horní vrstvy cache, což zvyšuje poměr zásahů do cache HIT procent a snižuje počet požadavků na origin server, může to však vést k vyšší latenci při vyřizování těchto požadavků, protože horní vrstva se může nacházet daleko od dolní vrstvy, ze které požadavek pochází.

S obecnou globální vrstvenou cache (Generic Global Tiered Cache) používá Cloudflare svá největší datacentra po celém světě jako horní vrstvu cache, což obecně znamená, že horní vrstva cache je mnohem blíž spodní vrstvě. Díky tomu se může výrazně snížit latence, když spodní vrstvy potřebují předat požadavky vrstvám vyšším. Ve výsledku to ale zvýší počet požadavků obsluhovaných původním serverem, protože každá horní vrstva cache se musí naplnit právě z něj. Souhrnem lze říct, že obecná globální vrstvená cache dokáže po naplnění cache zlepšit dobu odezvy, zároveň ale zvyšuje zátěž původních serverů.

Regional Tiered Cache spojuje výhody obou těchto strategií tím, že do architektury přidává další vrstvu cache. Použití možnosti Regional Tiered Cache spolu se Smart Tiered Caching znamená, že zatímco jedno umístění cache horní úrovně existuje nejblíže k origin serveru, mezi horní a dolní úroveň byla přidána vrstva Regional Tier, která se geograficky nachází blíže k dolní úrovni. Požadavky z dolních úrovní se nyní nejprve porovnávají s cache ve vrstvě Regional Tier, než jsou odeslány do horní úrovně. Jedna vrstva Regional Tier může přijímat požadavky z několika cache dolních úrovní, a díky tomu může výrazně zlepšit výkon a latenci pro globálně dostupné aplikace.

Regional Tiered Caching se doporučuje používat společně se Smart Tiered Caching a Custom Tiered Caching. Pro zákazníky s mnoha horními úrovněmi v mnoha regionech, jako je Generic Global Tiered Cache, však Regional Tiered Cache přínos nepřináší.

Na obrázku 5 je zapnuto Tiered Caching s topologií Smart Tiered Cache. Diagram znázorňuje topologii Smart Tiered Cache se zapnutým Regional Tiered Cache. Pokud mezipaměti nižší vrstvy zaznamenají MISS nejprve odešle tyto požadavky do lokálnějšího regionálního hub datového centra, aby zjistil, zda je lze vyřídit z mezipaměti. Pokud ne, požadavek pokračuje na vyšší úroveň a v případě potřeby dále na origin server.

Argo Smart Routing je služba, která v síti Cloudflare hledá optimalizované trasy, aby uživatelům doručovala odpovědi rychleji. Jak již bylo zmíněno, Cloudflare CDN využívá Argo Smart Routing k určení nejvhodnějších datových center vyšší úrovně pro Tiered Cache.

Navíc lze zapnout Argo Smart Routing, který zajišťuje, že mezi datacentry vyšší vrstvy a origin servery se vždy volí nejrychlejší cesty v síti Cloudflare. Bez Argo Smart Routing je komunikace mezi datacentry vyšší vrstvy a origin servery i tak inteligentně směrována kolem problémů na internetu, aby byla zajištěna dosažitelnost originu.

Argo Smart Routing zrychluje provoz díky tomu, že zohledňuje data v reálném čase a síťové poznatky získané ze směrování téměř 50 milionů HTTP požadavků za sekundu; zajišťuje tak, že provoz sítí Cloudflare k origin serveru prochází nejrychlejšími a nejspolehlivějšími cestami. Argo Smart Routing v průměru zrychluje výkon webových prostředků o 30 %.

Obrázek 6 podrobně popisuje tok provozu bez zapnutých funkcí Tiered Cache a Argo Smart Routing. Požadavek přichází do nejbližšího datového centra, a protože obsah není uložen lokálně v mezipaměti a Tiered Cache není zapnutá, posílá se přímo na origin server pro daný obsah. Protože navíc není zapnutá ani funkce Argo Smart Routing, komunikace s origin serverem probíhá po spolehlivé, ale možná ne nejrychlejší cestě.

Obrázek 7 popisuje tok provozu se zapnutými funkcemi Tiered Cache i Argo Smart Routing. Když Datové centrum 1 přijme požadavek a dojde k cache miss, zkontroluje se mezipaměť datového centra vyšší úrovně, Datového centra 6. Pokud se obsah v mezipaměti nenajde ani tam, díky zapnuté funkci Argo Smart Routing se požadavek z datového centra vyšší úrovně odešle na origin server po nejrychlejší cestě.

Nejrychlejší cesta se určuje na základě inteligentních síťových funkcí Argo, které zohledňují síťová data v reálném čase, jako je přetížení, latence a RTT.

S Cloudflare CDN se Argo Smart Routing používá v těchto případech:

1. Dojde k výpadku mezipaměti (cache miss) a požadavek je nutné odeslat na origin server, aby bylo možné obsah načíst.
2. Jde o požadavek na obsah, který nelze ukládat do mezipaměti, například dynamický obsah (např. API), a požadavek musí směřovat na origin server.

Cache Reserve navazuje na myšlenku Tiered Cache: využívá rozsah a rychlost sítě Cloudflare a pro ještě delší uchovávání obsahu v cache navíc zapojuje R2, trvalé objektové úložiště Cloudflare. Cache Reserve pomáhá zákazníkům snižovat náklady tím, že eliminuje poplatky za egress z originu, a zároveň přidává další vrstvy odolnosti a ochrany, díky nimž je obsah spolehlivě dostupný, což zlepšuje výkon webu rychlejším načítáním obsahu. Cache Reserve je v podstatě další, vyšší úroveň cache s delší dobou uchování.

Cache Reserve sice může fungovat i bez zapnutého Tiered Cache, doporučuje se ale mít Tiered Cache spolu s Cache Reserve zapnuté. Tiered Cache soustřeďuje, a případně i zcela eliminuje, požadavky na Cache Reserve, čímž odstraňuje redundantní čtecí operace a redundantní ukládání obsahu v cache, což snižuje poplatky za odchozí provoz a úložiště. Při zapínání Cache Reserve přes Cloudflare dashboard proběhne kontrola a zobrazí se upozornění, pokud se pokusíte použít Cache Reserve bez zapnutého Tiered Cache.

Cache Reserve má dobu uchování 30 dní, což znamená, že drží obsah v cache po dobu 30 dní bez ohledu na hlavičky cache nebo zásadu TTL. Zásada TTL přitom stále ovlivňuje aktuálnost obsahu, takže jakmile uvnitř Cache Reserve vyprší TTL obsahu, je nutné obsah znovu ověřit kontrolou origin serveru na případné změny. Zásadu TTL lze nastavit několika způsoby, například pomocí hlaviček odpovědi Cache-Control, CDN-Cache-Control, pomocí Edge Cache TTL, TTL cache podle stavového kódu nebo pomocí Cache Rules. Při každém čtení z Cache Reserve se časovač uchování resetuje zpět na 30 dní. Pokud obsah v cache není z Cache Reserve po dobu 30 dní přečten, bude smazán.

Aby bylo možné obsah považovat za ukládatelný do mezipaměti pomocí Cache Reserve, musí splňovat tři hlavní kritéria:

1. Obsah musí být možné ukládat do mezipaměti. Viz Dokumentace k mezipaměti s dalšími podrobnostmi o obsahu, který lze ukládat do mezipaměti.
2. TTL je nastaveno na alespoň 10 hodin. Lze jej nastavit libovolnou metodou z předchozího odstavce.
3. V hlavičce odpovědi musí být použita hlavička Content-Length. Upozorňujeme, že to znamená, že [Transfer-Method „chunked“ zabrání naplnění Cache Reserve.

V kombinaci s Tiered Caching a Argo Smart Routing může být Cache Reserve mocným nástrojem pro zvýšení počtu zásahů v cache, čímž se sníží zátěž původních serverů a zároveň se zlepší výkon díky tomu, že se obsah přiblíží koncovému uživateli.

Obrázek 8 znázorňuje, jak Cache Reserve pomáhá snížit zátěž origin serveru a zároveň napomáhá doplňovat úložiště mezipaměti jak v datových centrech vyšší, tak nižší úrovně.

Latence nezávisí jen na vzdálenosti klienta od originu nebo cache, výrazně ji může ovlivnit i geografická oblast provozu, například Čína. Cloudflare proto nabízí dvě klíčová řešení těchto problémů s latencí:

1. China Network poskytuje ukládání do mezipaměti přímo v Číně pro koncové uživatele nacházející se v Číně bez ohledu na umístění origin serveru. Toto řešení vzniklo ve spolupráci se společností JD Cloud a využívá jejich datová centra k zajištění nejrychlejšího a nejspolehlivějšího výkonu mezipaměti pro čínské uživatele ve srovnání s datovými centry mimo Čínu.
2. Globální akcelerace nabízí spolehlivé a zabezpečené připojení pro plynulý přenos obsahu z origin serverů do datových center JD Cloud v Číně. To je výhodné zejména pro dynamický obsah, jako jsou webové aplikace a volání API.

Shrnuto, Cloudflare CDN je řešení SaaS, které zákazníkům pomáhá řešit problémy s latencí, výkonem, dostupností, redundancí, zabezpečením a náklady. Cloudflare CDN využívá globální anycastovou síť Cloudflare a Tiered Cache k dosažení optimalizovaných výsledků při současné úspoře nákladů zákazníků. Zákazníci mohou také (povolit Argo Smart)[argo-smart-routing/get-started/] Routing, aby bylo zajištěno využití nejrychlejší síťové cesty k původnímu serveru, a dále mohou povolit Cache Reserve pro zvýšení počtu zásahů v cache, což dále snižuje náklady a zvyšuje výkon jejich webu nebo aplikace.