CDN

CDN (Content Delivery Network) je distribuovaná síť serverů, která doručuje obsah webů a aplikací. Část odpovědí může obsloužit z uložených kopií blíže návštěvníkovi, takže se při každém požadavku nemusí přenášet stejná data z původního serveru. Výsledek závisí na umístění uzlů, pravidlech cache a povaze aplikace: samotné zapnutí CDN nezaručuje rychlejší ani bezpečnější web.

Co se děje mezi návštěvníkem a původním serverem

Původní server se označuje jako origin. Uchovává nebo vytváří obsah: může jít o webhosting s PHP aplikací, objektové úložiště fotografií nebo server pro video. CDN před něj přidává vlastní distribuční vrstvu. Její uzly, často nazývané edge servery, přijímají požadavky návštěvníků a podle nastavení vracejí odpověď nebo kontaktují origin.

V běžném zapojení s reverzní proxy komunikuje prohlížeč s CDN, která dále komunikuje s originem. Jinou možností je doručovat přes CDN jen soubory na samostatné subdoméně, například obrázky, zatímco HTML zůstává na původním hostingu. CDN tedy nemusí obsluhovat celý web a její zapojení nemusí vyžadovat převod všech DNS záznamů k jednomu poskytovateli.

Síťově vhodný uzel nemusí být geograficky nejbližší. Rozhodují propojení operátorů, směrování, dostupná kapacita a způsob výběru serveru. Menší vzdálenost na mapě sama o sobě nezaručí menší odezvu.

Cache hit, miss a odpověď, kterou ukládat nechceme

Cache hit znamená, že příslušná cache našla použitelnou uloženou odpověď. Při cache miss ji nemá a požadavek musí získat z další vrstvy nebo originu. Síť může používat více úrovní cache, takže miss na jednom okrajovém uzlu ještě nemusí znamenat přímý požadavek do aplikace.

Uložené objekty mají pravidla čerstvosti. Po jejich uplynutí může cache vyžádat nové tělo odpovědi, nebo existující kopii ověřit pomocí podmínek jako ETag. Odpověď 304 pak umožní znovu použít uložená data. Konkrétní chování závisí také na pravidlech pro obsluhu zastaralého obsahu a na konfiguraci poskytovatele.

Od miss se liší úmyslné vynechání cache. Přihlášený účet, košík nebo soukromý výpis objednávek mohou přes CDN procházet, ale nesmějí se sdílet mezi návštěvníky. Pojmy HIT, MISS či BYPASS ve stavových hlavičkách jsou diagnostika konkrétní služby; nejsou univerzálně povinným názvoslovím všech CDN.

Hlavičky a klíč uložené odpovědi

HTTP nabízí pravidla jako Cache-Control. Direktivy public a private rozlišují možnosti sdíleného ukládání, no-store zakazuje uložení a no-cache vyžaduje před opětovným použitím ověření. No-cache tedy neznamená totéž co no-store. Doba pro sdílenou cache může být nastavena pomocí s-maxage odlišně od doby pro prohlížeč.

Cache-Control: public, max-age=300, s-maxage=3600

V tomto zjednodušeném příkladu je čerstvost pro prohlížeč pět minut a pro sdílenou cache hodina. Přepsaná pravidla CDN nebo jiné hlavičky mohou výsledek změnit. Pro soukromou stránku účtu není takové nastavení vhodné.

Důležitý je také cache key: klíč, pod kterým se odpověď ukládá. Může zahrnovat hostitele, cestu, parametry dotazu a další vlastnosti požadavku. Chybně sloučené varianty mohou vracet nesprávný jazyk, cenu nebo osobní údaje. Zbytečně rozdělené varianty naopak snižují využití cache.

Statický a dynamický obsah v praxi

Fotografie nebo verzovaný CSS soubor bývají pro ukládání vhodné. PHP stránka ovšem také může vytvořit stejné veřejné HTML pro všechny čtenáře, které lze za správných podmínek sdílet. Opačně může soubor s běžnou příponou obsahovat soukromý nebo často měněný obsah. Rozhoduje význam odpovědi a pravidla, nikoli jen označení „statický“ či „dynamický“.

Představme si článek s fotografií. První čtenář vyžádá obrázek přes CDN, která jej stáhne z originu a uloží. Další čtenář obsloužený stejnou použitelnou cache už může dostat kopii bez nového přenosu z hostingu. Čtenář v jiné části sítě však může narazit na uzel, který obrázek dosud nemá.

Při změně fotografie je potřeba myslet na její kopie. Nový název s verzí nebo hashem oddělí nový soubor od starého. Alternativou je invalidace, tedy zneplatnění cache, případně vyčkání do konce čerstvosti. Vyprázdnění cache CDN navíc samo o sobě nemusí odstranit kopii uloženou v prohlížeči.

DNS, Anycast a hledání skutečného hostingu

DNS nasměruje jméno na infrastrukturu služby. Některé distribuční sítě vybírají uzel pomocí DNS odpovědí, jiné kombinují více mechanismů. Anycast znamená, že stejná IP adresa je nabízena z více míst a síťové směrování vybírá cestu k jednomu z nich. Je to technika využitelná i pro DNS nebo jiné služby, nikoli jiné označení CDN.

Při proxy zapojení mohou veřejné IPv4 a IPv6 adresy patřit CDN. Z takové odpovědi nelze bez dalších podkladů vyvodit, kde leží původní webhosting. Stejně tak se poskytovatel autoritativního DNS nemusí shodovat s provozovatelem webu, registrátorem nebo vlastníkem sítě.

Rychlost, náklady a skutečný vztah k SEO

CDN může omezit opakované přenosy z originu a snížit odezvu vzdáleným čtenářům. Nejlépe se tento přínos projeví u často požadovaných sdílitelných dat. U málo navštěvované stránky, kde většina požadavků končí miss, nebo u aplikace se vzdálenou databází nemusí další proxy vrstva hlavní problém vyřešit. Záleží také na ceně přenosů, objemu požadavků a pravidlech konkrétního tarifu.

Pro rozhodnutí sleduj odezvu z různých míst, zatížení originu, podíl požadavků i objemu dat obsloužených z cache a uživatelské metriky. Vysoký hit ratio malých ikon nemusí znamenat velkou úsporu přenosu. Jedno číslo také neodhalí pomalé vykreslování způsobené JavaScriptem nebo obrázky.

Google používá Core Web Vitals ve svých systémech hodnocení, ale dobré výsledky nezaručují přední pozice. CDN může pomoci rychlosti doručení; nenahradí kvalitní obsah, správnou indexaci ani použitelnou stránku. Přínos pro konkrétní web se musí měřit, ne odvozovat ze samotné přítomnosti služby.

Bezpečnost je samostatná vrstva

Někteří poskytovatelé přidávají filtraci DDoS útoků, WAF nebo pravidla pro roboty. CDN jako způsob distribuce obsahu ovšem automaticky nezaručuje žádnou z těchto ochran. Rozhoduje nabídka služby, zvolený tarif a nastavení. Cache neodstraní chybu aplikace ani neopraví špatné oprávnění uživatele.

Pokud útočník zná veřejně dostupný origin, může za určitých podmínek CDN obejít. Ochrana původního serveru proto zahrnuje i řízení přístupu k originu a správné HTTPS spojení v obou úsecích. Chybné cachování soukromých odpovědí může samo vytvořit únik dat. Výpadek CDN nebo nevhodná ochranná výzva navíc může zablokovat legitimní návštěvníky i roboty.

Od distribuce souborů k okrajovým platformám

Komerční CDN se rozvíjely už na konci devadesátých let; Akamai zahájilo komerční provoz v roce 1999. Původní motivací bylo účinněji doručovat obsah ve velkém měřítku. K distribuci obrázků a souborů postupně přibylo video, API a u některých poskytovatelů i spouštění kódu na okrajových uzlech.

Proto dnes nabídka jedné firmy často spojuje CDN, DNS, bezpečnostní produkty a vývojářskou platformu. Při porovnávání je užitečné tyto funkce znovu rozdělit: která řeší opakované přenosy, která směrování, která ochranu a která samotný výpočet. Značka poskytovatele není technickou definicí všech jeho služeb.