🥇[Ne] používajte CDN

V prakticky každom článku alebo nástroji na optimalizáciu rýchlosti webových stránok sa nájde skromný bod „použite CDN“. V skratke, CDN znamená content delivery network alebo sieť na doručovanie obsahu. V našej spoločnosti „Metod Lab“ sa často stretávame s otázkami zákazníkov na túto tému, niektorí si CDN sami aktivujú. Cieľom tohto článku je skúmať, čo môže CDN priniesť z hľadiska rýchlosti načítania webu, aké problémy môžu vzniknúť a v ktorých prípadoch je používanie CDN opodstatnené.

Na obrázku zvýraznené oneskorenia sú spôsobené používaním CDN.

Trochu histórie

Rovnako ako mnohé technológie, aj CDN sa objavili z potreby. S rozvojom internetových kanálov a používateľov internetu sa objavili služby online videa. Je zrejmé, že videoobsah vyžaduje omnoho väčšiu priepustnosť v porovnaní s bežným obsahom webových stránok (obrázky, text, CSS alebo JS kód).

Pri pokuse o paralelné streamovanie video prenosu viacerým zákazníkom z jedného servera sa úzkym miestom najčastejšie stane internetový kanál servera. Ako pravidlo platí, že niekoľko tisíc prúdov stačí na zahltenie typického kanála servera. Samozrejme, môžu existovať aj iné obmedzenia zdrojov, ale v tejto chvíli to nie je relevantné. Je tiež dôležité, že rozšírenie kanála servera je príliš drahé (a niekedy aj nemožné) a navyše nie je ekonomicky výhodné. Zaťaženie kanála pri prenosoch bude mať cyklickú povahu.

Problém obmedzenia kanála jednotlivého servera skvele rieši CDN. Zákazníci sa nepripojujú priamo k serveru, ale ku uzlom siete CDN. V ideálnom prípade server poskytuje jeden prúd uzlu CDN, a potom sieť využíva svoje vlastné zdroje na doručenie tohto prúdu viacerým používateľom. Z ekonomického hľadiska platíme iba za skutočne spotrebované zdroje (to môže byť priepustnosť alebo prevádzka) a získavame výbornú škálovateľnosť našich služieb. Použitie CDN na doručovanie náročného obsahu je plne opodstatnené a logické. Je však potrebné poznamenať, že najväčší hráči v tejto oblasti (napríklad Netflix) budujú svoje CDN namiesto využívania veľkých komerčných CDN (Akamai, Cloudflare, Fastly atď.).

S rozvojom webových technológií sa samotné webové aplikácie stali zložitejšími a náročnejšími. Na prvé miesto sa dostal problém rýchlosti načítania. Rýchlostní nadšenci rýchlo identifikovali niekoľko hlavných problémov, ktoré viedli k pomalému načítaniu stránok. Jedným z nich sú oneskorenia v sieti (RTT — round trip time alebo čas ping). Tieto oneskorenia ovplyvňujú mnohé procesy pri načítaní stránky: nadviazanie TCP pripojenia, spustenie TLS relácie, načítanie každého jednotlivého zdroja (obrázku, JS súboru, HTML dokumentu atď.)

Problém bol zhoršený tým, že pri použití protokolu HTTP/1.1 (pred vznikom SPDY, QUIC a HTTP/2 to bola jediná možnosť) mohli prehliadače otvoriť maximálne 6 TCP pripojení k jednému hostiteľu. To všetko viedlo k nečinnosti pripojenia a neefektívnemu využívaniu šírky pásma. Problém sa čiastočne riešil doménovým shardovaním – vytvorením ďalších hostiteľov na prekonanie limitu počtu pripojení.

Tu prichádza na scénu druhá schopnosť CDN — zníženie oneskorení (RTT) vďaka množstvu bodov a blízkosti uzlov k používateľovi. Vzdialenosť zohráva rozhodujúcu úlohu: rýchlosť svetla je obmedzená (okolo 200 000 km/s v optických vláknach). To znamená, že každých 1000 km cesty pridáva 5 ms oneskorenia alebo 10 ms v RTT. To sú minimálne časové nároky na prenos, pretože existujú aj oneskorenia na medzičinnom vybavení. Keďže CDN obvykle dokáže cacheovať objekty na svojich serveroch, môžeme získať výhodu z načítania takýchto objektov prostredníctvom CDN. Nevyhnutné podmienky pre to sú: existencia objektu v cache a blízkosť bodu CDN k používateľovi v porovnaní so serverom webovej aplikácie (origin server). Je dôležité si uvedomiť: geografická blízkosť uzla CDN nezaručuje nízke oneskorenia. Routenie medzi zákazníkom a CDN môže byť naprogramované tak, že sa zákazník pripojí k hostiteľovi v inej krajine, a možno aj na inom kontinente. Tu zohráva úlohu správa operátorov telekomunikačných služieb a CDN (peerovanie, prítomnosť uzlov, účast na IX atď.) a politika routovania prevádzky samotného CDN. Napríklad Cloudflare pri použití dvoch základných plánov (bezplatného a lacného) nezaručuje dodávku obsahu z najbližšieho uzla – výber hostiteľa bude vykonaný s cieľom dosiahnuť minimálne náklady.

Mnoho popredných internetových spoločností zaujíma verejnosť (webových vývojárov a vlastníkov služieb) témou rýchlosti načítania a prevádzky webových stránok. Medzi tieto spoločnosti patrí Yahoo (nástroj Yslow), AOL (WebPageTest) a Google (služba Page Speed Insights), ktoré vypracovávajú svoje odporúčania na urýchlenie webových stránok (predovšetkým sa týkajú klientskej optimalizácie). Neskôr sa objavujú nové nástroje pre testovanie rýchlosti stránok, ktoré tiež poskytujú rady na zvýšenie rýchlosti webových stránok. V každej z týchto služieb alebo pluginov je neochvejnou odporúčania "Používajte CDN". Ako vysvetlenie efektu CDN sa väčšinou uvádza skrátenie sieťových oneskorení. Žiaľ, nie všetci sú pripravení sa zaoberať tým, ako sa efekt urýchlenia prostredníctvom CDN dosahuje a ako sa dá merať, preto sa toto odporúčanie prijíma za pravdu a používa sa ako postulát. V skutočnosti nie sú všetky CDN rovnako užitočné.

Využitie CDN dnes

Aby sme posúdili prínos využitia CDN, musíme ich klasifikovať. To, čo sa v súčasnosti prakticky stretáva (príklady v zátvorkách samozrejme nie sú vyčerpávajúce):

Bezplatné CDN na distribúciu JS knižníc (MaxCDN, Google, Yandex).
CDN služieb na klientsku optimalizáciu (napríklad Google Fonts pre písma, Cloudinary, Cloudimage pre obrázky).
CDN pre statiku a optimalizáciu zdrojov v CMS (sú dostupné v Bitrixe, WordPress a iných).
CDN všeobecného určenia (StackPath, CDNVideo, NGENIX, Megafon).
CDN na urýchlenie webových stránok (Cloudflare, Imperva, Airy).

Kľúčovým rozdielom medzi týmito typmi je: aká časť prevádzky prechádza cez CDN. Typy 1-3 sú dodávka len časti obsahu: od jedného požiadavku po niekoľko desiatok (zvyčajne obrázkov). Typy 4 a 5 predstavujú úplné proxy spracovanie prevádzky cez CDN.

V praxi to znamená počet pripojení, ktoré sa používajú na načítanie webových stránok. Pri použití HTTP/2 používame jedno TCP pripojenie k hostiteľovi na spracovanie akéhokoľvek počtu požiadaviek. Ak delíme zdroje medzi hlavným hostiteľom (origin) a CDN, je potrebné rozdeľovať požiadavky medzi niekoľkými doménami a vytvárať niekoľko TCP pripojení. V najhoršom prípade to znamená: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. V tejto rovnici nie sú zohľadnené oneskorenia v mobilných sieťach pri aktivácii rádiového kanála zariadenia (pokiaľ nebol aktívny) a oneskorenia na mobilnej veži.

Toto je, ako to vyzerá na vodopáde načítania webovej stránky (vyznačené oneskorenia pripojenia k CDN pri RTT 150 ms):

Ak CDN pokrýva celý traffic webovej stránky (okrem externých služieb), môžeme použiť jedno TCP pripojenie, čo šetrí oneskorenie pri pripojení k ďalším hosťom. Samozrejme, to platí pre HTTP/2 pripojenia.

Ďalšie rozdiely sú určené funkčnosťou konkrétneho CDN – pre prvý typ to je len hosting statického súboru, pre piaty to je zmena niekoľkých typov obsahu webu s cieľom optimalizácie.

Možnosti CDN na zrýchlenie webu

Poďme opísať celý rozsah možností CDN na zrýchlenie webových stránok, bez ohľadu na funkčnosť jednotlivých typov CDN, a potom sa pozrieme, čo z toho je realizované v každom z nich.

1. Kompresia textových zdrojov

Najzákladnejšia a najjasnejšia možnosť, avšak často je zle implementovaná. Prítomnosť kompresie deklarujú všetky CDN ako svoju funkciu zrýchlenia. Ale ak sa pozrieme podrobnejšie, zistíme nedostatky:

môžu sa používať nízke stupne pre dynamickú kompresiu – 5-6 (napríklad pre gzip je maximum — 9);
v statickej kompresii (súbory v cache) nie sú použité dodatočné možnosti (napríklad zopfi alebo brotli so stupňom 11)
neexistuje podpora efektívneho kompresie brotli (úspora približne 20% v porovnaní s gzip).

Ak používate CDN, stojí za to skontrolovať tieto niektoré body: zoberte súbor, ktorý prišiel z CDN, zaznamenajte jeho veľkosť v komprimovanej podobe a znova ho skomprimujte ručne na porovnanie (môžete použiť nejakú online službu s podporou brotli, napríklad vsetkozatiahnut.sk).

2. Nastavenie hlavičiek klientského cachovania

Tiež jednoduchá funkcia na zrýchlenie: nastaviť hlavičky pre cachovanie obsahu klientom (prehliadačom). Najrelevantnejšia hlavička je cache-control, zastaraná – expires. Dodatočne môže byť použitý Etag. Hlavné je, aby bol max-age pri cache-control dostatočne veľký (aspoň mesiac a viac), ak ste pripravení maximálne prísne cachovať zdroj, môžete pridať možnosť immutable.

CDN môžu znižovať hodnotu max-age, nútiac používateľa častejšie znovu načítavať statický obsah. Prečo sa to deje: kvôli snahe zvýšiť sieťový prenos alebo zlepšiť kompatibilitu so stránkami, ktoré nevedia resetovať cache – nie je jasné. Napríklad, hodnota doby cachovania v hlavičkách Cloudflare je predvolene 1 hodina, čo je veľmi málo pre nemenný statický obsah.

3. Optimalizácia obrázkov

Keďže CDN preberá úlohy cachovania a poskytovania obrázkov, logické by bolo optimalizovať ich na strane CDN a v takejto forme ich poskytovať používateľom. Hneď na úvod, táto možnosť je dostupná len pre typy CDN 2, 3 a 5.

Optimalizovať obrázky je možné rôznymi spôsobmi: použitím pokročilých formátov kompresie (napríklad, WebP), efektívnejšími kódovateľmi (MozJPEG) alebo jednoducho odstránením zbytočných metadát.

Celkovo existujú dva typy takýchto optimalizácií: s poškodeniu kvality a bez poškodenia kvality. CDN sa zvyčajne snažia používať optimalizáciu bez strát – aby sa predišlo možným sťažnostiam klientov na zmenu kvality obrázkov. V takých podmienkach bude zisk minimálny. V skutočnosti často úroveň kvality JPEG výrazne presahuje potrebné a je možné bez obáv uskutočniť recompresiu s nižším stupňom kvality, bez ujmy na vnímaní používateľmi. Na druhej strane, určiť úroveň kvality a nastavenia univerzálne pre všetky možné webové aplikácie je náročné, preto CDN používajú konzervatívnejšie nastavenia v porovnaní s tými, ktoré je možné aplikovať s ohľadom na kontext (účel obrázkov, typ webovej aplikácie a pod.).

4. Optimalizácia TLS pripojenia

Väčšina prenosu dnes prebieha cez TLS pripojenia, čo znamená, že strácame ďalší čas na TLS vyjednávanie. V poslednom čase boli vyvinuté nové technológie na urýchlenie tohto procesu. Napríklad, to sú EC-kriptografia, TLS 1.3, cache relácií a vstupenky (session tickets), hardvérové zrýchlenie šifrovania (AES-NI) a pod. Správne nastavenie TLS umožňuje skrátiť čas pripojenia na 0-1 RTT (nepočítajúc DNS a TCP).

S moderným softvérom nie je implementácia takýchto praktík na vlastných zdrojoch zložitá.

Nie všetky CDN implementujú najlepšie praktiky pre TLS, čo je možné overiť meraním času TLS pripojenia (napríklad pomocou Webpagetest). Ideálne pre nové pripojenie – 1RTT, 2RTT – priemerná úroveň, 3RTT a viac – zlé.

Je tiež potrebné poznamenať, že aj pri použití TLS na úrovni CDN musí server s našou webovou aplikáciou tiež spracovávať TLS, ale zo strany CDN, pretože prevádzka medzi serverom a CDN prechádza v verejnej sieti. V najhoršom prípade môžeme získať dvojité oneskorenia TLS pripojenia (prvé k hostiteľovi CDN, druhé medzi ním a naším serverom).

Pre niektoré aplikácie stojí za to venovať pozornosť otázkam bezpečnosti: zvyčajne je prevádzka dešifrovaná na uzloch CDN, čo predstavuje potenciálnu možnosť pre odpočúvanie prevádzky. Variant práce bez odhalenia prevádzky sa zvyčajne ponúka v prémiových tarifách za osobitný poplatok.

5. Zníženie oneskorenia pripojenia

Hlavnou výhodou CDN, o ktorej všetci hovoria: nízke oneskorenia (kratšia vzdialenosť) medzi hostiteľom CDN a používateľom. Dosahuje sa to vytvorením geograficky rozloženej architektúry siete, v ktorej sa hostitelia nachádzajú v bodoch koncentrácie používateľov (mestá, body výmeny prevádzky a pod.)

V praxi, priority pre rôzne siete môžu existovať v konkrétnych regiónoch. Napríklad ruské CDN budú mať viac bodov prítomnosti v Rusku. Americké sa predovšetkým budú rozvíjať v USA. Napríklad jeden z najväčších CDN Cloudflare má len 2 body v Rusku — Moskvu a Petrohrad. To znamená, že maximálne môžeme ušetriť približne 10 ms oneskorenia v porovnaní s priamym umiestnením v Moskve.

Väčšina západných CDN vôbec nemá body v Rusku. Pripojením sa k nim môžete len zvýšiť oneskorenia pre vašu ruskú publikum.

6. Optimalizácia obsahu (minifikácia, štrukturálne zmeny)

Najzložitejší a technologicky najnáročnejší bod. Zmena obsahu pri doručovaní môže byť veľmi riskantná. Aj keď vezmeme minifikáciu: skrátenie pôvodného kódu (kvôli zbytočným medzerám, nevhodným konštrukciám a pod.) môže ovplyvniť jeho funkčnosť. Ak hovoríme o vážnejších zmenách – presune JS kódu na koniec HTML, zlúčení súborov a podobne – riziko porušiť funkčnosť webu je ešte vyššie.

Preto sa len niektoré CDN typu 5 týmto zaoberajú. Samozrejme, automatizovať všetky potrebné zmeny na zrýchlenie nebude možné – vyžaduje sa manuálna analýza a optimalizácia. Napríklad, odstránenie nepoužívaného alebo duplicitného kódu patrí práve k manuálnym úlohám.

Vo všeobecnosti sú všetky podobné optimalizácie riadené nastaveniami a najnebezpečnejšie sú predvolene vypnuté.

Podpora urýchľovacích možností podľa typov CDN

Poďme sa teda pozrieť, ktoré z potenciálnych možností urýchlenia poskytujú rôzne typy CDN.

Pre pohodlie si zopakujme klasifikáciu.

Bezplatné CDN na distribúciu JS knižníc (MaxCDN, Google, Yandex).
CDN služieb na klientsku optimalizáciu (napríklad Google Fonts pre písma, Cloudinary, Cloudimage pre obrázky).
CDN pre statiku a optimalizáciu zdrojov v CMS (sú dostupné v Bitrixe, WordPress a iných).
CDN všeobecného určenia (StackPath, CDNVideo, NGENIX, Megafon).
CDN na urýchlenie webových stránok (Cloudflare, Imperva, Airy).

Teraz porovnáme funkcie a typy CDN.

Možnosť
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Kompresia textu
+–
–
+–
+–
+

Cache headers
+
+
+
+
+

Obrázky
–
+–
+–
–
+

TLS
–
–
–
+–
+

Zdržania
–
–
–
+
+

Obsah
–
–
–
–
+

V tejto tabuľke „+“ sa používa na označenie úplnej podpory, „–“ – na označenie absencie, „+–“ – na označenie čiastočnej podpory. Samozrejme, v skutočnosti sú možné odchýlky od tejto tabuľky (napríklad nejaké CDN všeobecného použitia implementuje funkcie optimalizácie obrázkov), ale pre všeobecné predstavy je užitočná.

Zhrnutie

Dúfam, že po prečítaní tohto článku budete mať jasnejšiu predstavu o odporúčaní „používajte CDN“ na zrýchlenie stránok.

Rovnako ako vo všetkom, netreba veriť marketingovým sľubom akéhokoľvek servisu. Efekt je potrebné merať a overovať v reálnych podmienkach. Ak už používate nejaké CDN, overte jeho efektívnosť podľa kritérií popísaných v článku.

Možno, že používanie CDN práve teraz spomaľuje načítanie vašej stránky.

Ako všeobecnú odporúčanú zásadu možno uviesť toto: preskúmajte svoje publikum, určte jeho geografické rámce. Ak je vaše hlavné publikum sústredené v okruhu 1-2 tisíc kilometrov, nepotrebujete CDN na jeho primárny účel – zníženie zdržaní. Namiesto toho môžete umiestniť svoj server bližšie k používateľom a správne ho nastaviť, aby ste získali väčšinu optimalizácií popísaných v článku (zadarmo a nepretržite).

Ak vaša cieľová skupina naozaj geograficky rozprestiera (s rádiom viac ako 3000 km), použitie kvalitnej CDN bude naozaj prospešné. Je však potrebné vopred porozumieť, čo presne môže vaša CDN zrýchliť (pozri tabuľku možností a ich popis). Zrýchlenie webovej stránky zostáva komplexnou úlohou, ktorá sa nedá vyriešiť len pripojením CDN. Okrem uvedených optimalizácií mimo CDN zostávajú najúčinnejšie prostriedky zrýchlenia: optimalizácia serverovej časti, pokročilé zmeny na klientskej strane (odstránenie nepoužívaného kódu, optimalizácia procesu renderovania, práca s obsahom, písmami, responzívnosť a pod.)

Zdroj: habr.com