[Ne] používat CDN

Téměř každý článek nebo nástroj pro optimalizaci rychlosti webu má skromnou klauzuli „použijte CDN“. CDN je obecně síť pro doručování obsahu nebo síť pro doručování obsahu. V Method Lab se často setkáváme s dotazy klientů na toto téma, někteří z nich umožňují vlastní CDN. Účelem tohoto článku je pochopit, co může CDN poskytnout z hlediska rychlosti načítání stránek, jaké problémy mohou nastat a v jakých případech je použití CDN oprávněné.

Zpoždění zakroužkovaná na obrázku jsou způsobena použitím CDN.

Trocha historie

Stejně jako mnoho technologií se CDN objevily z nutnosti. S rozvojem internetových kanálů mezi uživateli internetu se objevily online video služby. Video obsah přirozeně vyžaduje řádově větší šířku pásma ve srovnání s běžným obsahem webových stránek (obrázky, text a kód CSS nebo JS).

Při pokusu vysílat video stream paralelně k mnoha klientům z jednoho serveru se s největší pravděpodobností stane úzkým hrdlem internetový kanál serveru. K ucpání typického kanálu serveru zpravidla stačí několik tisíc vláken. Samozřejmě mohou existovat i jiná omezení zdrojů, ale nejsou v tuto chvíli důležitá. Je také důležité, že rozšíření serverového kanálu je příliš nákladné (a někdy nemožné) a také nepraktické. Zatížení kanálu během vysílání bude cyklické.

Problém omezení kanálu jednotlivého serveru dokonale řeší CDN. Klienti se nepřipojují přímo k serveru, ale k uzlům v síti CDN. V ideální situaci server odešle jeden datový proud do uzlu CDN a poté síť použije své vlastní zdroje k doručení tohoto proudu mnoha uživatelům. Z ekonomického hlediska platíme pouze za skutečně spotřebované zdroje (může to být šířka pásma nebo provoz) a získáváme vynikající škálovatelnost naší služby. Použití CDN k doručování těžkého obsahu je zcela oprávněné a logické. I když stojí za zmínku, že největší hráči v tomto prostoru (např. Netflix) budují své vlastní CDN namísto použití velkých komerčních CDN (Akamai, Cloudflare, Fastly atd.)

Jak se web vyvíjel, samotné webové aplikace se staly složitějšími a komplexnějšími. Do popředí se dostal problém s rychlostí načítání. Nadšenci pro rychlost webových stránek rychle identifikovali několik hlavních problémů, které způsobovaly pomalé načítání webových stránek. Jedním z nich byla zpoždění sítě (RTT - round trip time nebo ping time). Zpoždění ovlivňují mnoho procesů při načítání webových stránek: navázání TCP spojení, zahájení relace TLS, načtení každého jednotlivého zdroje (obrázek, soubor JS, dokument HTML atd.)

Problém zhoršovala skutečnost, že při použití protokolu HTTP/1.1 (před příchodem SPDY, QUIC a HTTP/2 to byla jediná možnost) prohlížeče otevírají maximálně 6 TCP spojení na jeden hostitel. To vše vedlo k výpadkům připojení a neefektivnímu využití šířky pásma kanálu. Problém částečně vyřešilo sharding domény – vytvoření dalších hostitelů pro překonání limitu na počet připojení.

Zde se objevuje druhá schopnost CDN – snížení latence (RTT) díky velkému počtu bodů a blízkosti uzlů k uživateli. Rozhodující roli zde hraje vzdálenost: rychlost světla je omezená (asi 200 000 km/s v optickém vláknu). To znamená, že každých 1000 km jízdy přidá 5 ms zpoždění nebo 10 ms k RTT. Toto je minimální čas potřebný pro přenos, protože dochází také ke zpožděním na mezilehlém zařízení. Protože CDN obvykle ví, jak ukládat objekty do mezipaměti na svých serverech, můžeme mít prospěch z načítání takových objektů prostřednictvím CDN. Nezbytné podmínky k tomu: přítomnost objektu v cache, blízkost CDN bodu k uživateli ve srovnání s webovým aplikačním serverem (origin server). Je důležité pochopit, že geografická blízkost uzlu CDN nezaručuje nízkou latenci. Směrování mezi klientem a CDN může být postaveno tak, že se klient připojí k hostiteli v jiné zemi a možná i na jiném kontinentu. Zde vstupuje do hry vztah mezi telekomunikačními operátory a službou CDN (peering, připojení, účast v IX atd.) a samotná politika směrování provozu CDN. Například Cloudflare při použití dvou počátečních plánů (zdarma a levně) nezaručuje doručení obsahu z nejbližšího hostitele – hostitel bude vybrán tak, aby bylo dosaženo minimálních nákladů.

Mnoho předních internetových společností přitahuje veřejný zájem (vývojáře webu a vlastníky služeb) na téma rychlosti načítání a výkonu webových stránek. Mezi tyto společnosti patří Yahoo (nástroj Yslow), AOL (WebPageTest) a Google (služba Page Speed ​​Insights), které vyvíjejí vlastní doporučení pro zrychlení webů (týkají se především optimalizace klientů). Později se objevují nové nástroje pro testování rychlosti webu, které také poskytují tipy na zvýšení rychlosti webu. Každá z těchto služeb nebo pluginů má konzistentní doporučení: "Používejte CDN." Snížení latence sítě se obvykle uvádí jako vysvětlení účinku CDN. Bohužel ne každý je připraven přesně porozumět tomu, jak je dosaženo akceleračního účinku CDN a jak jej lze měřit, takže doporučení je vzato na základě víry a používáno jako postulát. Ve skutečnosti nejsou všechny CDN vytvořeny stejně.

Pomocí CDN Today

Aby bylo možné posoudit užitečnost používání CDN, je třeba je klasifikovat. Co lze nyní nalézt v praxi (příklady v závorkách samozřejmě nejsou vyčerpávající):

1. Zdarma CDN pro distribuci knihoven JS (MaxCDN, Google. Yandex).
2. CDN služeb pro optimalizaci klienta (například Google Fonts pro písma, Cloudinary, Cloudimage pro obrázky).
3. CDN pro statickou optimalizaci a optimalizaci zdrojů v CMS (dostupné v Bitrix, WordPress a dalších).
4. Univerzální CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pro akceleraci webu (Cloudflare, Imperva, Airi).

Klíčový rozdíl mezi těmito typy je v tom, jak velká část provozu prochází CDN. Typy 1-3 představují dodání pouze části obsahu: od jednoho požadavku po několik desítek (obvykle obrázky). Typy 4 a 5 jsou plné proxy provozu přes CDN.

V praxi to znamená počet připojení, které se používají k načtení webu. U HTTP/2 používáme jediné připojení TCP k hostiteli ke zpracování libovolného počtu požadavků. Pokud zdroje rozdělíme na hlavního hostitele (origin) a CDN, pak je potřeba distribuovat požadavky přes více domén a vytvořit několik TCP spojení. Nejhorší případ je: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Tento vzorec nebere v úvahu zpoždění v mobilních sítích pro aktivaci rádiového kanálu zařízení (pokud nebyl aktivní) a zpoždění na mobilní věži.

Zde je návod, jak to vypadá na vodopádu načítání webu (latence pro připojení k CDN jsou zvýrazněny při RTT 150 ms):

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

Další rozdíly jsou dány funkčností konkrétní CDN - u prvního typu je to jen hostování statického souboru, u pátého je to změna několika typů obsahu stránek za účelem optimalizace.

Možnosti CDN pro zrychlení webových stránek

Pojďme si popsat celou škálu možností CDN pro akceleraci webů bez ohledu na funkcionalitu jednotlivých typů CDN a poté se podívejme, co je v každém z nich implementováno.

1. Komprese textových zdrojů

Nejzákladnější a nejsrozumitelnější funkce, ale často špatně implementovaná. Všechny CDN deklarují přítomnost komprese jako svou akcelerační vlastnost. Ale když se podíváte podrobněji, nedostatky budou jasné:

• pro dynamickou kompresi lze použít nízké stupně - 5-6 (například pro gzip je maximum 9);
• statická komprese (soubory v mezipaměti) nepoužívá další funkce (například zopfi nebo brotli se stupněm 11)
• neexistuje žádná podpora pro účinnou kompresi brotli (úspora asi 20 % ve srovnání s gzip).

Pokud používáte CDN, stojí za to zkontrolovat těchto několik bodů: vezměte soubor, který pochází z CDN, zaznamenejte jeho komprimovanou velikost a komprimujte jej ručně pro srovnání (můžete použít nějakou online službu s podporou brotli, například vsszhat.rf).

2. Nastavení hlaviček klientské mezipaměti

Také jednoduchá funkce zrychlení: přidejte záhlaví pro ukládání obsahu do mezipaměti klientem (prohlížečem). Nejaktuálnější hlavička je cache-control, ta zastaralá vyprší. Kromě toho lze použít Etag. Hlavní věc je, že maximální doba kontroly mezipaměti je dostatečně velká (od měsíce nebo déle) Pokud jste připraveni ukládat zdroj do mezipaměti co nejtěžší, můžete přidat možnost neměnný.

CDN mohou snížit hodnotu maximálního stáří a nutí uživatele častěji znovu načítat statický obsah. Není jasné, s čím to souvisí: touha zvýšit provoz v síti nebo zvýšit kompatibilitu s weby, které nevědí, jak resetovat mezipaměť. Například výchozí čas mezipaměti hlavičky Cloudflare je 1 hodina, což je velmi málo pro neměnná statická data.

3. Optimalizace obrazu

Protože CDN přebírá funkce ukládání do mezipaměti a poskytování obrázků, bylo by logické je optimalizovat na straně CDN a poskytovat je uživatelům v této podobě. Okamžitě si rezervujme, že tato funkce je k dispozici pouze pro typy CDN 2, 3 a 5.

Obrazy můžete optimalizovat různými způsoby: pomocí pokročilých kompresních formátů (jako je WebP), efektivnějších kodérů (MozJPEG) nebo jednoduše vyčistit nepotřebná metadata.

Obecně existují dva typy takových optimalizací: se ztrátou kvality a bez ztráty kvality. CDN se obvykle snaží používat bezeztrátovou optimalizaci, aby se vyhnuly případným stížnostem zákazníků na změny v kvalitě obrazu. V takových podmínkách bude zisk minimální. Ve skutečnosti je často úroveň kvality JPEG mnohem vyšší, než je nutné, a můžete bezpečně znovu komprimovat s nižší úrovní kvality, aniž byste ohrozili uživatelský dojem. Na druhou stranu je obtížné určit úroveň kvality a nastavení univerzálně pro všechny možné webové aplikace, proto CDN používají konzervativnější nastavení oproti těm, které lze aplikovat s přihlédnutím ke kontextu (účel obrázků, typ webové aplikace , atd.)

4. Optimalizace připojení TLS

Většina provozu dnes cestuje přes připojení TLS, což znamená, že vyjednáváním TLS trávíme více času. V poslední době byly vyvinuty nové technologie, které tento proces urychlují. Jedná se například o kryptografii EC, TLS 1.3, mezipaměť relací a vstupenky, akceleraci hardwarového šifrování (AES-NI) atd. Správné nastavení TLS může zkrátit dobu připojení na 0-1 RTT (nepočítaje DNS a TCP ).

S moderním softwarem není těžké takové praktiky zavést vlastními silami.

Ne všechny CDN implementují osvědčené postupy TLS; můžete to zkontrolovat měřením doby připojení TLS (například v Webpagetest). Ideální pro nové připojení - 1RTT, 2RTT - průměrná úroveň, 3RTT a další - špatné.

Je třeba také 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 prochází veřejnou sítí. V nejhorším případě dostaneme dvojnásobné zpoždění připojení TLS (první k hostiteli CDN, druhé mezi ním a naším serverem).

U některých aplikací stojí za to věnovat pozornost bezpečnostním problémům: provoz je obvykle dešifrován na uzlech CDN a to je potenciální příležitost k zachycení provozu. Možnost práce bez prozrazení provozu je obvykle nabízena v top tarifech za příplatek.

5. Snižte zpoždění připojení

Hlavní výhoda CDN, o které všichni mluví: nízká latence (menší vzdálenost) mezi hostitelem CDN a uživatelem. Dosaženo vytvořením geograficky distribuované síťové architektury, ve které jsou hostitelé umístěni v místech koncentrace uživatelů (města, body výměny provozu atd.)

V praxi mohou být priority pro různé sítě v konkrétních regionech. Například ruské CDN budou mít v Rusku více bodů přítomnosti. Američtí budou v první řadě rozvíjet síť v USA. Například jeden z největších CDN Cloudflare má v Rusku pouze 2 body – Moskva a Petrohrad. To znamená, že můžeme ušetřit maximálně cca 10 ms latence oproti přímému umístění v Moskvě.

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

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

Nejsložitější a technologicky nejpokročilejší bod. Změna obsahu během doručení může být velmi riskantní. I když vezmeme minifikaci: zmenšení zdrojového kódu (kvůli nadbytečným mezerám, nedůležitým strukturám atd.) může ovlivnit jeho výkon. Pokud se budeme bavit o závažnějších změnách – přesun JS kódu na konec HTML, slučování souborů atd. – riziko narušení funkčnosti webu je ještě vyšší.

Proto to dělají pouze některé CDN typu 5. Samozřejmě nebude možné automatizovat všechny změny potřebné k urychlení věcí – je nutná manuální analýza a optimalizace. Například odstranění nepoužívaného nebo duplicitního kódu je ruční úkol.

Všechny takové optimalizace jsou zpravidla řízeny nastavením a ty nejnebezpečnější jsou ve výchozím nastavení zakázány.

Podpora schopností akcelerace podle typu CDN

Pojďme se tedy podívat na to, jaké potenciální možnosti urychlení poskytují různé typy CDN.

Pro větší pohodlí opakujeme klasifikaci.

1. Zdarma CDN pro distribuci knihoven JS (MaxCDN, Google. Yandex).
2. CDN služeb pro optimalizaci klienta (například Google Fonts pro písma, Cloudinary, Cloudimage pro obrázky).
3. CDN pro statickou optimalizaci a optimalizaci zdrojů v CMS (dostupné v Bitrix, WordPress a dalších).
4. Univerzální CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pro akceleraci webu (Cloudflare, Imperva, Airi).

Nyní porovnejme funkce a typy CDN.

Příležitost
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Komprese textu
+–
-
+–
+–
+

Záhlaví mezipaměti
+
+
+
+
+

Obrázky
-
+–
+–
-
+

TLS
-
-
-
+–
+

Zpoždění
-
-
-
+
+

Obsah
-
-
-
-
+

V této tabulce se „+“ používá k označení plné podpory, „–“ není podpora a „+–“ je částečná podpora. Samozřejmě mohou existovat odchylky od této tabulky ve skutečnosti (například některé univerzální CDN budou implementovat funkce pro optimalizaci obrázků), ale pro obecnou představu je to užitečné.

Výsledky

Doufejme, že po přečtení tohoto článku budete mít jasnější představu o doporučení „použít CDN“ k urychlení vašich stránek.

Jako v každém podnikání nemůžete věřit marketingovým slibům jakékoli služby. Účinek je třeba měřit a testovat v reálných podmínkách. Pokud již používáte CDN, zkontrolujte jeho účinnost pomocí kritérií popsaných v článku.

Je možné, že současné používání CDN zpomaluje načítání vašeho webu.

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

V případě, že je vaše publikum skutečně geograficky rozmístěno (poloměr větší než 3000 kilometrů), bude použití kvalitní CDN opravdu užitečné. Musíte však předem pochopit, co přesně může vaše CDN urychlit (viz tabulka schopností a jejich popis). Akcelerace webových stránek však stále zůstává složitým úkolem, který nelze vyřešit připojením CDN. Kromě výše uvedených optimalizací zůstávají za CDN nejúčinnější prostředky akcelerace: optimalizace serverové části, pokročilé změny klientské části (odstranění nepoužívaného kódu, optimalizace procesu vykreslování, práce s obsahem, fonty, přizpůsobivost atd.). )

Zdroj: www.habr.com