🥇[Nepoužívajte] CDN

Takmer každý článok alebo nástroj na optimalizáciu rýchlosti stránok má skromnú klauzulu „použite CDN“. Vo všeobecnosti je CDN sieť na doručovanie obsahu alebo sieť na doručovanie obsahu. My v Method Lab sa často stretávame s otázkami klientov na túto tému, niektorí z nich umožňujú vlastné CDN. Účelom tohto článku je pochopiť, čo môže CDN poskytnúť z hľadiska rýchlosti načítania stránky, aké problémy môžu nastať a v ktorých prípadoch je použitie CDN opodstatnené.

Oneskorenia zakrúžkované na obrázku sú spôsobené použitím CDN.

Trocha histórie

Ako mnohé technológie, aj CDN vznikli z nutnosti. S rozvojom internetových kanálov medzi používateľmi internetu sa objavili online video služby. Prirodzene, videoobsah vyžaduje rádovo väčšiu šírku pásma v porovnaní s bežným obsahom webových stránok (obrázky, text a kód CSS alebo JS).

Pri pokuse o vysielanie video streamu paralelne k mnohým klientom z jedného servera sa s najväčšou pravdepodobnosťou stane prekážkou internetový kanál servera. Na upchatie typického kanála servera spravidla stačí niekoľko tisíc vlákien. Samozrejme, môžu existovať aj iné obmedzenia zdrojov, ale tie nie sú momentálne dôležité. Je tiež dôležité, že rozšírenie kanála servera je príliš drahé (a niekedy nemožné) a tiež nepraktické. Zaťaženie kanálu počas vysielania bude cyklické.

Problém obmedzenia kanála jednotlivého servera dokonale rieši CDN. Klienti sa nepripájajú priamo na server, ale na uzly v sieti CDN. V ideálnej situácii server odošle jeden prúd do uzla CDN a potom sieť použije svoje vlastné zdroje na doručenie tohto prúdu mnohým používateľom. Z ekonomického hľadiska platíme iba za skutočne spotrebované zdroje (môže to byť šírka pásma alebo prevádzka) a získavame vynikajúcu škálovateľnosť našej služby. Používanie siete CDN na doručovanie ťažkého obsahu je úplne opodstatnené a logické. Aj keď stojí za zmienku, že najväčší hráči v tomto priestore (napr. Netflix) budujú svoje vlastné CDN namiesto používania veľkých komerčných CDN (Akamai, Cloudflare, Fastly atď.)

Ako sa web vyvíjal, samotné webové aplikácie sa stali zložitejšími a komplexnejšími. Do popredia sa dostal problém rýchlosti načítania. Nadšenci rýchlosti webových stránok rýchlo identifikovali niekoľko hlavných problémov, ktoré spôsobovali pomalé načítavanie webových stránok. Jedným z nich bolo meškanie siete (RTT - round trip time alebo ping time). Oneskorenia ovplyvňujú mnohé procesy pri načítavaní webových stránok: nadviazanie pripojenia TCP, spustenie relácie TLS, načítanie každého jednotlivého zdroja (obrázok, súbor JS, dokument HTML atď.)

Problém zhoršovala skutočnosť, že pri použití protokolu HTTP/1.1 (pred príchodom SPDY, QUIC a HTTP/2 to bola jediná možnosť) prehliadače neotvárajú viac ako 6 TCP spojení na jedného hostiteľa. To všetko viedlo k výpadkom pripojenia a neefektívnemu využívaniu šírky pásma kanála. Problém bol čiastočne vyriešený shardingom domény – vytvorením ďalších hostiteľov na prekonanie limitu na počet pripojení.

Tu sa objavuje druhá schopnosť CDN – zníženie latencie (RTT) vďaka veľkému počtu bodov a blízkosti uzlov k používateľovi. Rozhodujúcu úlohu tu hrá vzdialenosť: rýchlosť svetla je obmedzená (približne 200 000 km/s v optickom vlákne). To znamená, že každých 1000 km jazdy pridá 5 ms oneskorenia alebo 10 ms k RTT. Toto je minimálny čas potrebný na prenos, pretože dochádza k oneskoreniam aj na medzizariadení. Keďže CDN zvyčajne vie, ako ukladať objekty do vyrovnávacej pamäte na svojich serveroch, môžeme ťažiť z načítania takýchto objektov cez CDN. Nevyhnutné podmienky na to: prítomnosť objektu vo vyrovnávacej pamäti, blízkosť bodu CDN k používateľovi v porovnaní s webovým aplikačným serverom (origin server). Je dôležité pochopiť, že geografická blízkosť uzla CDN nezaručuje nízku latenciu. Smerovanie medzi klientom a CDN môže byť postavené tak, že sa klient pripojí k hostiteľovi v inej krajine a možno aj na inom kontinente. Tu vstupuje do hry vzťah medzi telekomunikačnými operátormi a službou CDN (peering, pripojenia, účasť v IX atď.) a samotná politika smerovania prevádzky CDN. Napríklad Cloudflare pri použití dvoch počiatočných plánov (bezplatný a lacný) nezaručuje dodanie obsahu z najbližšieho hostiteľa – hostiteľ bude vybraný tak, aby sa dosiahli minimálne náklady.

Mnoho popredných internetových spoločností priťahuje záujem verejnosti (vývojárov webu a vlastníkov služieb) o tému rýchlosti načítania a výkonu webových stránok. Medzi tieto spoločnosti patria Yahoo (nástroj Yslow), AOL (WebPageTest) a Google (služba Page Speed Insights), ktoré vyvíjajú vlastné odporúčania na zrýchlenie stránok (týkajú sa predovšetkým optimalizácie klientov). Neskôr sa objavia nové nástroje na testovanie rýchlosti webu, ktoré poskytujú aj tipy na zvýšenie rýchlosti webu. Každá z týchto služieb alebo doplnkov má konzistentné odporúčanie: „Použite CDN“. Zníženie latencie siete sa zvyčajne uvádza ako vysvetlenie účinku CDN. Bohužiaľ, nie každý je pripravený presne pochopiť, ako sa dosahuje akceleračný efekt CDN a ako sa dá merať, takže odporúčanie sa berie na vieru a používa sa ako postulát. V skutočnosti nie sú všetky CDN vytvorené rovnako.

Používanie siete CDN dnes

Na posúdenie užitočnosti používania CDN je potrebné ich klasifikovať. Čo možno teraz nájsť v praxi (príklady v zátvorkách samozrejme nie sú vyčerpávajúce):

Bezplatné CDN na distribúciu knižníc JS (MaxCDN, Google. Yandex).
CDN služieb pre optimalizáciu klienta (napríklad Google Fonts pre písma, Cloudinary, Cloudimage pre obrázky).
CDN pre statickú optimalizáciu a optimalizáciu zdrojov v CMS (dostupné v Bitrix, WordPress a ďalších).
Univerzálne CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN pre zrýchlenie webových stránok (Cloudflare, Imperva, Airi).

Kľúčový rozdiel medzi týmito typmi je v tom, aká časť prevádzky prechádza cez CDN. Typy 1-3 predstavujú dodanie len časti obsahu: od jednej požiadavky až po niekoľko desiatok (zvyčajne obrázkov). Typy 4 a 5 sú plné proxy prenosu cez CDN.

V praxi to znamená počet pripojení, ktoré sa používajú na načítanie stránky. Pri HTTP/2 používame jediné TCP spojenie s hostiteľom na spracovanie ľubovoľného počtu požiadaviek. Ak zdroje rozdelíme na hlavného hostiteľa (origin) a CDN, tak je potrebné distribuovať požiadavky cez viacero domén a vytvárať viacero TCP spojení. Najhorší prípad je: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Tento vzorec neberie do úvahy oneskorenia v mobilných sieťach pri aktivácii rádiového kanála zariadenia (ak nebol aktívny) a oneskorenia na mobilnej veži.

Takto to vyzerá vo vodopáde načítania stránky (latencie pripojenia k CDN sú zvýraznené pri RTT 150 ms):

Ak CDN pokrýva všetku návštevnosť lokality (okrem služieb tretích strán), potom môžeme použiť jediné pripojenie TCP, čím ušetríme oneskorenia pri pripájaní k ďalším hostiteľom. To sa samozrejme týka pripojení HTTP/2.

Ďalšie rozdiely sú dané funkcionalitou konkrétneho CDN – pri prvom type je to len hosťovanie statického súboru, pri piatom je to zmena viacerých typov obsahu stránky za účelom optimalizácie.

Možnosti CDN pre zrýchlenie webových stránok

Poďme si popísať celú škálu možností CDN pre akceleráciu stránok bez ohľadu na funkčnosť jednotlivých typov CDN a potom sa pozrime, čo je v každom z nich implementované.

1. Kompresia textových zdrojov

Najzákladnejšia a najzrozumiteľnejšia funkcia, ale často zle implementovaná. Všetky CDN deklarujú prítomnosť kompresie ako svoju funkciu zrýchlenia. Ak sa však pozriete podrobnejšie, nedostatky budú jasné:

nízke stupne pre dynamickú kompresiu možno použiť - 5-6 (napríklad pre gzip je maximum 9);
statická kompresia (súbory vo vyrovnávacej pamäti) nepoužíva ďalšie funkcie (napríklad zopfi alebo brotli so stupňom 11)
neexistuje žiadna podpora pre efektívnu kompresiu brotli (úspora asi 20 % v porovnaní s gzip).

Ak používate CDN, oplatí sa skontrolovať týchto pár bodov: vezmite súbor, ktorý pochádza z CDN, zaznamenajte jeho komprimovanú veľkosť a komprimujte ho ručne na porovnanie (môžete použiť niektorú online službu s podporou brotli, napr. vsszhat.rf).

2. Nastavenie hlavičiek ukladania klientov do vyrovnávacej pamäte

Tiež jednoduchá funkcia zrýchlenia: pridajte hlavičky pre ukladanie obsahu do vyrovnávacej pamäte klientom (prehliadačom). Najaktuálnejšia hlavička je cache-control, zastaraná je expirovaná. Okrem toho je možné použiť Etag. Hlavná vec je, že maximálny vek kontroly vyrovnávacej pamäte je dostatočne veľký (od mesiaca alebo viac).Ak ste pripravení uložiť zdroj do vyrovnávacej pamäte čo najťažšie, môžete pridať možnosť nemeniteľná.

CDN môžu znížiť hodnotu maximálneho veku, čím nútia používateľa častejšie načítavať statický obsah. Nie je jasné, s čím to súvisí: túžba zvýšiť návštevnosť v sieti alebo zvýšiť kompatibilitu s webmi, ktoré nevedia, ako obnoviť vyrovnávaciu pamäť. Napríklad predvolený čas vyrovnávacej pamäte hlavičky Cloudflare je 1 hodina, čo je veľmi málo pre nemenné statické údaje.

3. Optimalizácia obrazu

Keďže CDN preberá funkcie ukladania do vyrovnávacej pamäte a poskytovania obrázkov, bolo by logické optimalizovať ich na strane CDN a poskytovať ich používateľom v tejto forme. Okamžite si urobme rezerváciu, že táto funkcia je k dispozícii iba pre typy CDN 2, 3 a 5.

Obrazy môžete optimalizovať rôznymi spôsobmi: použitím pokročilých kompresných formátov (ako je WebP), efektívnejších kódovačov (MozJPEG) alebo jednoduchým vyčistením nepotrebných metadát.

Vo všeobecnosti existujú dva typy takýchto optimalizácií: so stratou kvality a bez straty kvality. CDN sa zvyčajne snažia používať bezstratovú optimalizáciu, aby sa vyhli prípadným sťažnostiam zákazníkov na zmeny v kvalite obrazu. V takýchto podmienkach bude zisk minimálny. V skutočnosti je úroveň kvality JPEG často oveľa vyššia, ako je potrebné, a môžete bezpečne znova komprimovať s nižšou úrovňou kvality bez toho, aby ste ohrozili používateľskú skúsenosť. Na druhej strane je ťažké určiť úroveň kvality a nastavenia univerzálne pre všetky možné webové aplikácie, preto CDN používajú konzervatívnejšie nastavenia v porovnaní s tými, ktoré je možné aplikovať s prihliadnutím na kontext (účel obrázkov, typ webovej aplikácie). , atď.)

4. Optimalizácia pripojenia TLS

Väčšina premávky dnes prechádza cez pripojenia TLS, čo znamená, že vyjednávaniami TLS trávime viac času. Nedávno boli vyvinuté nové technológie na urýchlenie tohto procesu. Ide napríklad o kryptografiu EC, TLS 1.3, vyrovnávaciu pamäť relácií a lístky, akceleráciu hardvérového šifrovania (AES-NI) atď. Správne nastavenie TLS môže skrátiť čas pripojenia na 0-1 RTT (nepočítajúc DNS a TCP ).

S moderným softvérom nie je ťažké zaviesť takéto praktiky svojpomocne.

Nie všetky siete CDN implementujú osvedčené postupy TLS; môžete to skontrolovať meraním času pripojenia TLS (napríklad v Webpagetest). Ideálne pre nové pripojenie - 1RTT, 2RTT - priemerná úroveň, 3RTT a ďalšie - zlé.

Treba si tiež uvedomiť, že aj pri použití TLS na úrovni CDN musí server s našou webovou aplikáciou spracovať aj TLS, ale zo strany CDN, pretože prevádzka medzi serverom a CDN prechádza cez verejnú sieť. V najhoršom prípade dostaneme dvojnásobné oneskorenie pripojenia TLS (prvé k hostiteľovi CDN, druhé medzi ním a naším serverom).

Pri niektorých aplikáciách stojí za to venovať pozornosť bezpečnostným problémom: prevádzka je zvyčajne dešifrovaná na uzloch CDN a to je potenciálna príležitosť na zachytenie prevádzky. Možnosť práce bez zverejnenia premávky je zvyčajne ponúkaná v top tarifách za príplatok.

5. Znížte meškania spojenia

Hlavná výhoda CDN, o ktorej každý hovorí: nízka latencia (menšia vzdialenosť) medzi hostiteľom CDN a používateľom. Dosiahnuté vytvorením geograficky distribuovanej sieťovej architektúry, v ktorej sú hostitelia umiestnení v miestach koncentrácie používateľov (mestá, body výmeny dopravy atď.)

V praxi môžu byť priority pre rôzne siete v konkrétnych regiónoch. Napríklad ruské CDN budú mať viac bodov prítomnosti v Rusku. Tí americkí budú v prvom rade rozvíjať sieť v USA. Napríklad jeden z najväčších CDN Cloudflare má v Rusku len 2 body – Moskva a Petrohrad. To znamená, že môžeme ušetriť maximálne asi 10 ms latencie v porovnaní s priamym umiestnením v Moskve.

Väčšina západných CDN nemá body v Rusku vôbec. Ak sa k nim pripojíte, môžete len zvýšiť oneskorenia pre vaše ruské publikum.

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

Najkomplexnejší a technologicky najpokročilejší bod. Zmena obsahu počas doručovania môže byť veľmi riskantná. Aj keď vezmeme minifikáciu: zmenšenie zdrojového kódu (kvôli extra medzerám, nedôležitým štruktúram atď.) môže ovplyvniť jeho výkon. Ak sa bavíme o vážnejších zmenách – presun JS kódu na koniec HTML, zlučovanie súborov a podobne – riziko narušenia funkčnosti stránky je ešte vyššie.

Preto to robia len niektoré CDN typu 5. Samozrejme, nebude možné automatizovať všetky zmeny potrebné na zrýchlenie – vyžaduje sa manuálna analýza a optimalizácia. Napríklad odstránenie nepoužívaného alebo duplicitného kódu je manuálna úloha.

Všetky takéto optimalizácie sú spravidla riadené nastaveniami a tie najnebezpečnejšie sú predvolene vypnuté.

Podpora možností zrýchlenia podľa typu CDN

Poďme sa teda pozrieť na to, aké potenciálne možnosti zrýchlenia poskytujú rôzne typy CDN.

Pre pohodlie opakujeme klasifikáciu.

Bezplatné CDN na distribúciu knižníc JS (MaxCDN, Google. Yandex).
CDN služieb pre optimalizáciu klienta (napríklad Google Fonts pre písma, Cloudinary, Cloudimage pre obrázky).
CDN pre statickú optimalizáciu a optimalizáciu zdrojov v CMS (dostupné v Bitrix, WordPress a ďalších).
Univerzálne CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN pre zrýchlenie webových stránok (Cloudflare, Imperva, Airi).

Teraz porovnajme funkcie a typy CDN.

Príležitosť
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Kompresia textu
+–
-
+–
+–
+

Hlavičky vyrovnávacej pamäte
+
+
+
+
+

Картинки
-
+–
+–
-
+

TLS
-
-
-
+–
+

Meškania
-
-
-
+
+

Obsah
-
-
-
-
+

V tejto tabuľke sa „+“ používa na označenie plnej podpory, „–“ nie je podpora a „+–“ je čiastočná podpora. Samozrejme, v skutočnosti môžu existovať odchýlky od tejto tabuľky (napríklad niektoré univerzálne CDN budú implementovať funkcie na optimalizáciu obrázkov), ale pre všeobecnú predstavu je to užitočné.

Výsledky

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

Ako v každom podnikaní, nemôžete veriť marketingovým sľubom akejkoľvek služby. Účinok je potrebné merať a testovať v reálnych podmienkach. Ak už používate CDN, skontrolujte jeho účinnosť pomocou kritérií opísaných v článku.

Je možné, že súčasné používanie siete CDN spomaľuje čas načítania vášho webu.

Ako všeobecné odporúčanie sa môžeme zamerať na nasledovné: študujte svoje publikum, určte jeho geografický rozsah. Ak je vaše hlavné publikum sústredené v okruhu 1-2 tisíc kilometrov, nepotrebujete CDN na jeho hlavný účel – zníženie latencie. Namiesto toho môžete umiestniť svoj server bližšie k používateľom a správne ho nakonfigurovať, čím získate väčšinu optimalizácií popísaných v článku (bezplatnú a trvalú).

V prípade, že je vaše publikum skutočne geograficky rozdelené (polomer viac ako 3000 kilometrov), bude použitie kvalitného CDN naozaj užitočné. Musíte však vopred pochopiť, čo presne môže vaša CDN urýchliť (pozri tabuľku schopností a ich popis). Zrýchlenie webových stránok však stále zostáva zložitou úlohou, ktorú nemožno vyriešiť pripojením CDN. Okrem vyššie uvedených optimalizácií zostávajú najefektívnejšie prostriedky akcelerácie za CDN: optimalizácia serverovej časti, pokročilé zmeny klientskej časti (odstránenie nepoužívaného kódu, optimalizácia procesu vykresľovania, práca s obsahom, fonty, prispôsobivosť atď.). )

Zdroj: hab.com

[Nepoužívajte] CDN