🥇[Ne] používejte CDN

V téměř každém článku nebo nástroji pro optimalizaci rychlosti webových stránek najdete nenápadnou zmínku o „využití CDN“. CDN, což je zkratka pro content delivery network, je síť pro dodávání obsahu. V naší společnosti „Metod Lab“ se často setkáváme s dotazy klientů ohledně tohoto tématu, někteří si CDN nastavují sami. Cílem tohoto článku je vysvětlit, co může CDN přinést z pohledu rychlosti načítání webu, jaké problémy mohou nastat a v jakých případech je využití CDN vhodné.

Na obrázku vyznačené zpoždění je způsobeno použitím CDN.

Trocha historie

Stejně jako mnohé technologie, i CDN vznikly z potřeby. Jak se rozvíjely internetové kanály uživatelů, objevily se také služby pro online video. Je samozřejmé, že video obsah vyžaduje mnohem větší šířku pásma ve srovnání s běžným obsahem webových stránek (obrázky, text a CSS nebo JS kód).

Při pokusu o paralelní streamování video toku mnoha klientům z jednoho serveru se úzkým místem pravděpodobně stane internetový kanál serveru. Obvykle stačí několik tisíc streamů, aby byl typický kanál serveru přeplněn. Samozřejmě, mohou existovat i další omezení zdrojů, ale ta nyní nejsou důležitá. Také je důležité, že rozšíření kanálu serveru je příliš drahé (a někdy i nemožné) a často neefektivní. Zátěž na kanál při streamování bude mít cyklický charakter.

Problém omezeného kanálu jednotlivého serveru skvěle řeší CDN. Klienti se nepřipojují přímo k serveru, ale k uzlům sítě CDN. V ideální situaci server poskytne jeden stream uzlu CDN a ta dále využívá své vlastní zdroje k dodání tohoto streamu mnoha uživatelům. Z ekonomického hlediska platíme jen za skutečně využité zdroje (může to být šířka pásma nebo provoz) a získáváme skvělou škálovatelnost našich služeb. Použití CDN pro dodávku těžkého obsahu je zcela odůvodněné a logické. I když stojí za zmínku, že největší hráči v této oblasti (například Netflix) staví své vlastní CDN místo využívání velkých komerčních CDN (Akamai, Cloudflare, Fastly atd.).

S rozvojem webu se webové aplikace staly složitějšími a náročnějšími. Na předním místě se objevila otázka rychlosti načítání. Nadšenci do rychlosti webových stránek rychle identifikovali několik hlavních problémů způsobujících pomalé načítání. Jedním z nich byla zpoždění v síti (RTT — round trip time nebo ping). Zpoždění ovlivňuje mnoho procesů při načítání stránky: navázání TCP připojení, spuštění TLS relace, načítání každého jednotlivého zdroje (obrázku, JS souboru, HTML dokumentu atd.)

Problém se zhoršoval tím, že při používání protokolu HTTP/1.1 (před příchodem SPDY, QUIC a HTTP/2 to byla jediná možnost) prohlížeče otevíraly maximálně 6 TCP připojení k jednomu hostiteli. To všechno vedlo k nečinnosti připojení a neefektivnímu využívání šířky pásma. Problém byl částečně vyřešen doménovým shardováním – vytvářením dalších hostitelů, aby se překonal limit počtu připojení.

Zde se objevuje druhá schopnost CDN – zkracování zpoždění (RTT) díky velkému počtu bodů a blízkosti uzlů k uživateli. Vzdálenost hraje rozhodující roli: rychlost světla je omezená (asi 200 000 km/s v optickém vláknu). To znamená, že každých 1000 km cesty přidává 5 ms zpoždění nebo 10 ms v RTT. To jsou minimální časové náklady na přenos, protože existují ještě zpoždění na mezivybavení. Vzhledem k tomu, že CDN obvykle umí cachovat objekty na svých serverech, můžeme těžit z načítání takových objektů přes CDN. Nezbytné podmínky pro to jsou: dostupnost objektu v cache, blízkost bodu CDN k uživateli ve srovnání se serverem webové aplikace (origin server). Je důležité pochopit, že geografická blízkost uzlu CDN nezaručuje nízká zpoždění. Směrování mezi klientem a CDN může být nastaveno tak, že klient se připojí k hostiteli v jiné zemi, nebo dokonce na jiném kontinentu. Zde vstoupí do hry vztahy mezi operátory sítí a službou CDN (peering, dostupnost spojení, účast v IX atd.) a politika směrování provozu samotné CDN. Například Cloudflare při používání dvou základních plánů (zdarma a levného) nezaručuje dodávání obsahu z nejbližšího uzlu – výběr hostitele bude proveden za účelem dosažení minimálních nákladů.

Mnoho předních internetových společností přitahuje pozornost veřejnosti (webových vývojářů a majitelů služeb) k tématu rychlosti načítání a fungování webových stránek. Mezi těmito společnostmi jsou Yahoo (nástroj Yslow), AOL (WebPageTest) a Google (služba Page Speed Insights), které vyvíjejí své doporučení pro zrychlení webových stránek (především se týkají optimalizace na straně klienta). Později se objevují nové nástroje pro testování rychlosti webu, které také nabízejí rady pro zvýšení rychlosti webových stránek. V každé z těchto služeb nebo pluginů existuje neměnné doporučení „Používejte CDN“. Jako vysvětlení účinku CDN se obvykle uvádí snížení síťových zpoždění. Bohužel ne všichni jsou připraveni se zabývat tím, jak přesně je dosaženo zrychlení pomocí CDN a jak může být tento efekt měřen, proto je doporučení akceptováno vírou a používáno jako postulát. Ve skutečnosti však nejsou všechny CDN stejně užitečné.

Použití CDN dnes

Pro hodnocení užitečnosti nasazení CDN je třeba je klasifikovat. Co se dnes běžně setkává v praxi (příklady v závorkách samozřejmě nejsou vyčerpávající):

Bezplatné CDN pro distribuci JS knihoven (MaxCDN, Google, Yandex).
CDN pro klientskou optimalizaci (například Google Fonts pro písma, Cloudinary, Cloudimage pro obrázky).
CDN pro statické a optimalizované zdroje v CMS (je v Bitrixu, WordPress a dalších).
CDN pro obecné účely (StackPath, CDNVideo, NGENIX, MegaFon).
CDN pro zrychlení webových stránek (Cloudflare, Imperva, Iry).

Klíčový rozdíl mezi těmito typy spočívá v následujícím: jaká část provozu prochází přes CDN. Typy 1-3 to jsou dodávky pouze části obsahu: od jednoho požadavku po několik desítek (obvykle obrázků). Typy 4 a 5 to jsou úplné proxování provozu přes CDN.

V praxi to znamená počet připojení, které se používají k načtení webových stránek. Při použití HTTP/2 používáme jedno TCP připojení k hostiteli pro zpracování jakéhokoliv počtu požadavků. Pokud rozdělíme zdroje na základní hostitele (origin) a CDN, je nutné distribuovat požadavky přes několik domén a vytvořit několik TCP spojení. V nejhorším případě to je: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. V tomto vzorci nejsou zohledněna zpoždění v mobilních sítích na aktivaci rádiového kanálu zařízení (pokud nebyl aktivní) a zpoždění na mobilní věži.

Jak to vypadá na vodopádoch načítání webu (zpoždění pro připojení k CDN při RTT 150 ms jsou zvýrazněna):

Pokud CDN pokrývá veškerý provoz webu (kromě externích služeb), můžeme využít jediné TCP připojení a ušetřit tak zpoždění při připojení k dalším hostitelům. To samozřejmě platí pro HTTP/2 připojení.

Další rozdíly jsou dány funkcionalitou konkrétní CDN – pro první typ je to pouze hosting statický soubor, pro pátý typ to zahrnuje změnu několika typů obsahu webu za účelem optimalizace.

Možnosti CDN pro zrychlení webu

Pojďme popsat plný rozsah možností CDN pro zrychlení webů, aniž bychom se zaměřovali na specifickou funkcionalitu jednotlivých typů CDN, a potom se podíváme na to, co je z toho realizováno v každém z nich.

1. Komprese textových zdrojů

Nejzákladnější a nejjasnější možnost, přesto je často špatně implementována. Všechny CDN deklarují kompresi jako svou funkci pro zrychlení. Ale při bližším pohledu se odhalí nedostatky:

mohou být použity nízké stupně pro dynamickou kompresi – 5-6 (například pro gzip je maximum — 9);
v statické kompresi (souboru v cache) nejsou použity další možnosti (například zopfi nebo brotli se stupněm 11)
není podpora efektivní komprese brotli (úspora přibližně 20 % oproti gzip).

Pokud používáte CDN, stojí za to zkontrolovat tyto body: vezměte soubor, který přišel z CDN, zaznamenejte jeho velikost ve zkomprimované podobě a znovu ho stlačte ručně pro srovnání (můžete použít nějakou online službu s podporou brotli, například všechnozcompress.net).

2. Nastavení záhlaví pro klientské cachování

Další jednoduchá funkce pro zrychlení: nastavit záhlaví pro cachování obsahu klientem (prohlížečem). Nejpoužívanější záhlaví je cache-control, zastaralé – expires. Dále se může používat Etag. Hlavní je, aby max-age u cache-control byl dostatečně velký (od měsíce a více), pokud chcete co nejpřísněji cachovat zdroj, můžete přidat možnost immutable.

CDN mohou snižovat hodnotu max-age, což nutí uživatele častěji znovu načítat statiku. Je to spojeno s touhou zvýšit provoz v síti nebo s vyšší kompatibilitou s weby, které neumějí mazat mezipaměť – není jasné. Například výchozí hodnota doby kešování v hlavičkách Cloudflare je 1 hodina, což je pro neměnnou statiku velmi málo.

3. Optimalizace obrázků

Protože CDN přebírá funkce kešování a dodávání obrázků, logické je optimalizovat je na straně CDN a v takové podobě je dodávat uživatelům. Hned si ujasníme, že tato možnost je dostupná pouze pro CDN typů 2, 3 a 5.

Optimalizovat obrázky lze různými způsoby: použitím pokročilých kompresních formátů (například WebP), efektivnějšími kodéry (MozJPEG) nebo jednoduše vyčištěním nadbytečných metadat.

Celkově existují dva typy takových optimalizací: s ochranou kvality a bez ztráty kvality. CDN se obvykle snaží používat optimalizaci bez ztráty – aby se vyhnuli možným stížnostem zákazníků na změnu kvality obrázků. V takových podmínkách je zisk minimální. Ve skutečnosti často úroveň kvality JPEG výrazně překračuje nezbytnou, a tak můžeme bez obav provést rekódování s nižší úrovní kvality, aniž bychom ohrozili vnímání uživateli. Na druhou stranu, určit úroveň kvality a nastavení univerzálně pro všechny možné webové aplikace je složité, a tak CDN používají konzervativnější nastavení ve srovnání s těmi, které by mohly být použity s ohledem na kontext (účel obrázků, typ webové aplikace atd.)

4. Optimalizace TLS-připojení

Většina provozu dnes probíhá přes TLS-připojení, což znamená, že na TLS vyjednávání strávíme další čas. V poslední době byly vyvinuty nové technologie pro urychlení tohoto procesu. Například EC-šifrování, TLS 1.3, kešování sezení a vstupenky (session tickets), hardwarové urychlení šifrování (AES-NI) atd. Správné nastavení TLS umožňuje zkrátit čas připojení na 0-1 RTT (bez zohlednění DNS a TCP).

S moderním softwarem není implementace takových praktik na vlastních prostředcích složitá.

Ne všechny CDN implementují nejlepší praktiky v oblasti TLS, což lze ověřit měřením doby TLS připojení (například pomocí Webpagetest). Ideální doba pro nové připojení je 1 RTT, 2 RTT je průměrná úroveň, 3 RTT a více - špatně.

Je také třeba poznamenat, že i při použití TLS na úrovni CDN musí server s naší webovou aplikací také zpracovávat TLS, ale ze strany CDN, protože provoz mezi serverem a CDN probíhá v veřejné síti. V horším případě dostaneme dvojnásobné zpoždění TLS připojení (první k hostiteli CDN, druhé mezi ním a naším serverem).

Pro některé aplikace stojí za to věnovat pozornost otázkám bezpečnosti: obvykle je provoz dešifrován na uzlech CDN, což představuje potenciální možnost pro odposlouchávání provozu. Varianta provozu bez odhalení provozu je obvykle nabízena v topových tarifních plánech za příplatek.

5. Snížení zpoždění připojení

Hlavní výhodou CDN, o které se všichni zmiňují: nízká zpoždění (menší vzdálenost) mezi hostitelem CDN a uživatelem. Toho je dosaženo vytvářením geograficky rozptýlené architektury sítě, kde se hostitelé nacházejí v místech koncentrace uživatelů (města, místa výměny provozu atd.).

V praxi se priority různých sítí mohou nacházet v konkrétních regionech. Například ruské CDN budou mít více bodů přítomnosti v Rusku. Americké nejprve budují síť v USA. Například jedno z největších CDN Cloudflare má pouze 2 body v Rusku — Moskvu a Petrohrad. To znamená, že maximálně můžeme ušetřit přibližně 10 ms zpoždění ve srovnání s přímým umístěním v Moskvě.

Většina západních CDN vůbec nemá body v Rusku. Připojením k nim můžete pouze zvýšit zpoždění pro vaše ruské publikum.

6. Optimalizace obsahu (minifikace, strukturální změny)

Nejkomplexnější a technologicky náročný bod. Změna obsahu při doručování může být velmi riskantní. I když vezmeme minifikaci: zkrácení původního kódu (odstraněním nadbytečných mezer, nepodstatných konstrukcí atd.) může ovlivnit jeho funkčnost. Pokud mluvíme o vážnějších změnách - přesunutí JS kódu na konec HTML, sloučení souborů a podobně - riziko narušení funkčnosti webu je ještě vyšší.

Proto se jen některé CDN typu 5 tímto zabývají. Samozřejmě nelze automatizovat všechny potřebné změny pro zrychlení – vyžaduje to manuální analýzu a optimalizaci. Například odstranění nepoužívaného nebo duplicitního kódu se týká právě manuálních úloh.

Obecně jsou všechny podobné optimalizace řízeny nastavením a nejnebezpečnější jsou ve výchozím nastavení vypnuté.

Podpora zrychlujících funkcí dle typů CDN

Tak se pojďme podívat, jaké potenciální možnosti zrychlení nabízejí různé typy CDN.

Pro přehlednost si zopakujme klasifikaci.

Bezplatné CDN pro distribuci JS knihoven (MaxCDN, Google, Yandex).
CDN pro klientskou optimalizaci (například Google Fonts pro písma, Cloudinary, Cloudimage pro obrázky).
CDN pro statické a optimalizované zdroje v CMS (je v Bitrixu, WordPress a dalších).
CDN pro obecné účely (StackPath, CDNVideo, NGENIX, MegaFon).
CDN pro zrychlení webových stránek (Cloudflare, Imperva, Iry).

Nyní přiřaďme funkce a typy CDN.

Možnost
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Kompresní text
+–
–
+–
+–
+

Cache headers
+
+
+
+
+

Obrázky
–
+–
+–
–
+

TLS
–
–
–
+–
+

Zpoždění
–
–
–
+
+

Obsah
–
–
–
–
+

V této tabulce se ‚+‘ používá k indikaci úplné podpory, ‚–‘ znamená absenci, ‚+–‘ značí částečnou podporu. Samozřejmě, v reálných podmínkách mohou existovat odchylky od této tabulky (např. nějaké CDN pro všeobecné použití implementuje funkce pro optimalizaci obrázků), ale pro obecnou představu je užitečná.

Závěry

Doufám, že po přečtení tohoto článku budete mít jasnější představu o doporučení ‚používejte CDN‘ pro zrychlení webových stránek.

Jak ve všem, nelze věřit marketingovým slibům nějaké služby. Efekt je třeba měřit a ověřovat v reálných podmínkách. Pokud již nějaké CDN používáte, zkontrolujte jeho účinnost podle kritérií popsaných v článku.

Možná, že použití CDN právě teď zpomaluje načítání vašeho webu.

Jako obecné doporučení se lze zaměřit na toto: prozkoumejte své publikum, určete jeho geografické hranice. Pokud je vaše hlavní publikum soustředěno v okruhu 1-2 tisíc kilometrů, CDN pro jeho primární účel – snížení zpoždění – nepotřebujete. Místo toho můžete umístit svůj server blíže k uživatelům a správně ho nastavit, čímž získáte většinu optimalizací popsaných v článku (zdarma a trvale).

Pokud je vaše publikum skutečně geograficky rozptýlené (ve vzdálenosti více než 3000 kilometrů), použití kvalitní CDN bude skutečně užitečné. Je však třeba předem pochopit, co přesně může vaše CDN urychlit (viz tabulka možností a jejich popis). Zrychlení webu je stále komplexní úkol, který nelze vyřešit pouze připojením CDN. Kromě uvedených optimalizací zůstávají mimo CDN nejefektivnější prostředky urychlení: optimalizace serverové části, pokročilé změny v klientské části (odstranění nepoužívaného kódu, optimalizace procesu renderování, práce s obsahem, písmy, responzivností atd.)

Zdroj: habr.com