ProHoster > Blog > Uprava > [Ne] uporabljajte CDN

[Ne] uporabljajte CDN

Skoraj vsak članek ali orodje za optimizacijo hitrosti spletnega mesta ima skromno klavzulo »uporabi CDN«. Na splošno je CDN omrežje za dostavo vsebin ali omrežje za dostavo vsebin. V Method Labu pogosto naletimo na vprašanja naročnikov na to temo, nekateri med njimi omogočijo svoj CDN. Namen tega članka je razumeti, kaj lahko CDN zagotovi v smislu hitrosti nalaganja spletnega mesta, kakšne težave se lahko pojavijo in v katerih primerih je uporaba CDN upravičena.

[Ne] uporabljajte CDN

Zamude, obkrožene na sliki, so posledica uporabe CDN.

Malo zgodovine

Kot mnoge druge tehnologije so se CDN-ji pojavili iz nuje. Z razvojem internetnih kanalov med uporabniki interneta so se pojavile spletne video storitve. Seveda video vsebina zahteva veliko večjo pasovno širino v primerjavi z običajno vsebino spletnega mesta (slike, besedilo in koda CSS ali JS).

Ko poskušate oddajati video tok vzporedno več odjemalcem iz enega strežnika, bo internetni kanal strežnika najverjetneje postal ozko grlo. Praviloma je nekaj tisoč niti dovolj, da zamašijo tipičen strežniški kanal. Seveda lahko obstajajo druge omejitve virov, vendar trenutno niso pomembne. Pomembno je tudi, da je širitev strežniškega kanala predraga (in včasih nemogoča), pa tudi nepraktična. Obremenitev kanala med oddajami bo ciklična.

Problem omejevanja kanala posameznega strežnika CDN odlično rešuje. Odjemalci se ne povezujejo neposredno s strežnikom, temveč z vozlišči v omrežju CDN. V idealni situaciji strežnik pošlje en tok vozlišču CDN, nato pa omrežje uporabi lastne vire za dostavo tega toka številnim uporabnikom. Z ekonomskega vidika plačamo samo za dejansko porabljene vire (to je lahko pasovna širina ali promet) in dobimo odlično razširljivost naše storitve. Uporaba CDN za dostavo težke vsebine je povsem upravičena in logična. Čeprav je vredno omeniti, da največji igralci v tem prostoru (npr. Netflix) gradijo svoje lastne CDN-je namesto uporabe velikih komercialnih CDN-jev (Akamai, Cloudflare, Fastly itd.)

Z razvojem spleta so same spletne aplikacije postale bolj kompleksne in kompleksne. V ospredje je prišel problem hitrosti nalaganja. Navdušenci nad hitrostjo spletnega mesta so hitro ugotovili več večjih težav, ki so povzročile počasno nalaganje spletnih mest. Eden od njih so bile zamude v omrežju (RTT - čas povratnega potovanja ali čas pinga). Zamude vplivajo na številne procese pri nalaganju spletne strani: vzpostavitev povezave TCP, začetek seje TLS, nalaganje vsakega posameznega vira (slike, datoteke JS, dokumenta HTML itd.)

Težavo je še poslabšalo dejstvo, da brskalniki pri uporabi protokola HTTP/1.1 (pred pojavom SPDY, QUIC in HTTP/2 je bila to edina možnost) na enega gostitelja odprejo največ 6 TCP povezav. Vse to je povzročilo izpad povezave in neučinkovito uporabo pasovne širine kanala. Težavo je delno rešil domenski sharding – ustvarjanje dodatnih gostiteljev za premagovanje omejitve števila povezav.

Tu se pojavi druga sposobnost CDN - zmanjševanje latence (RTT) zaradi velikega števila točk in bližine vozlišč uporabniku. Pri tem ima odločilno vlogo razdalja: hitrost svetlobe je omejena (približno 200 km/s v optičnih vlaknih). To pomeni, da vsakih 000 km potovanja RTT doda 1000 ms zakasnitve ali 5 ms. To je minimalni čas, potreben za prenos, saj prihaja tudi do zamud na vmesni opremi. Ker CDN običajno ve, kako predpomniti predmete na svojih strežnikih, nam lahko koristi nalaganje takšnih predmetov prek CDN. Potrebni pogoji za to: prisotnost predmeta v predpomnilniku, bližina točke CDN do uporabnika v primerjavi s strežnikom spletnih aplikacij (izvorni strežnik). Pomembno je razumeti, da geografska bližina vozlišča CDN ne zagotavlja nizke zakasnitve. Usmerjanje med odjemalcem in CDN je lahko zgrajeno tako, da se bo odjemalec povezal z gostiteljem v drugi državi in ​​po možnosti na drugi celini. Tu nastopi odnos med telekomunikacijskimi operaterji in storitvijo CDN (peering, povezave, sodelovanje v IX itd.) ter politika usmerjanja prometa v samem CDN. Na primer, Cloudflare pri uporabi dveh začetnih načrtov (brezplačnega in poceni) ne zagotavlja dostave vsebine od najbližjega gostitelja - gostitelj bo izbran tako, da bo dosegel minimalne stroške.

Številna vodilna internetna podjetja pritegnejo zanimanje javnosti (spletnih razvijalcev in lastnikov storitev) na temo hitrosti nalaganja in delovanja spletnega mesta. Med temi podjetji so Yahoo (orodje Yslow), AOL (WebPageTest) in Google (storitev Page Speed ​​​​Insights), ki razvijajo lastna priporočila za pospešitev spletnih mest (predvsem se nanašajo na optimizacijo strank). Kasneje se pojavijo nova orodja za testiranje hitrosti spletne strani, ki dajejo tudi nasvete za povečanje hitrosti spletne strani. Vsaka od teh storitev ali vtičnikov ima dosledno priporočilo: »Uporabite CDN«. Zmanjšanje zakasnitve omrežja se običajno navaja kot razlaga za učinek CDN. Na žalost niso vsi pripravljeni natančno razumeti, kako se doseže pospeševalni učinek CDN in kako ga je mogoče izmeriti, zato se priporočilo vzame za vero in se uporablja kot postulat. Pravzaprav niso vsi CDN enaki.

Uporaba CDN danes

Da bi ocenili uporabnost uporabe CDN, jih je treba razvrstiti. Kaj je zdaj mogoče najti v praksi (primeri v oklepajih seveda niso izčrpni):

  1. Brezplačni CDN za distribucijo knjižnic JS (MaxCDN, Google. Yandex).
  2. CDN storitev za optimizacijo strank (na primer Google Fonts za pisave, Cloudinary, Cloudimage za slike).
  3. CDN za statično optimizacijo in optimizacijo virov v CMS (na voljo v Bitrixu, WordPressu in drugih).
  4. CDN za splošne namene (StackPath, CDNVideo, NGENIX, Megafon).
  5. CDN za pospeševanje spletnih strani (Cloudflare, Imperva, Airi).

Ključna razlika med temi vrstami je, koliko prometa gre skozi CDN. Vrste 1-3 so dostava le dela vsebine: od ene zahteve do več deset (običajno slik). Tipa 4 in 5 sta popolno posredovanje prometa prek CDN.

V praksi to pomeni število povezav, ki se uporabljajo za nalaganje strani. S HTTP/2 uporabljamo eno samo povezavo TCP z gostiteljem za obdelavo poljubnega števila zahtev. Če delimo vire na glavnega gostitelja (origin) in CDN, potem je treba zahteve porazdeliti na več domen in ustvariti več TCP povezav. Najslabši primer je: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Ta formula ne upošteva zamud v mobilnih omrežjih za aktivacijo radijskega kanala naprave (če ta ni bil aktiven) in zamud na mobilnem stolpu.

Takole je videti na slapu nalaganja spletnega mesta (zakasnitve za povezavo s CDN so označene pri RTT 150 ms):

[Ne] uporabljajte CDN

Če CDN pokriva ves promet spletnega mesta (razen storitev tretjih oseb), lahko uporabimo eno samo povezavo TCP, s čimer prihranimo zamude pri povezovanju z dodatnimi gostitelji. Seveda to velja za povezave HTTP/2.

Nadaljnje razlike določajo funkcionalnosti posameznega CDN-ja – pri prvem je to samo gostovanje statične datoteke, pri petem pa spreminjanje več vrst vsebine spletnega mesta z namenom optimizacije.

Zmogljivosti CDN za pospeševanje spletnih strani

Opišimo celotno paleto zmogljivosti CDN za pospeševanje spletnih mest, ne glede na funkcionalnost posameznih vrst CDN, nato pa poglejmo, kaj je implementirano v vsako od njih.

1. Stiskanje besedilnih virov

Najbolj osnovna in razumljiva funkcija, a pogosto slabo implementirana. Vsi CDN-ji razglasijo prisotnost stiskanja kot svojo funkcijo pospeševanja. Toda če pogledate podrobneje, postanejo jasne pomanjkljivosti:

  • lahko uporabite nizke stopnje za dinamično stiskanje - 5-6 (na primer, za gzip je največ 9);
  • statično stiskanje (datoteke v predpomnilniku) ne uporablja dodatnih funkcij (na primer zopfi ali brotli s stopnjo 11)
  • ni podpore za učinkovito stiskanje brotli (prihranek približno 20 % v primerjavi z gzip).

Če uporabljate CDN, je vredno preveriti teh nekaj točk: vzemite datoteko, ki je prišla iz CDN, zabeležite njeno stisnjeno velikost in jo ročno stisnite za primerjavo (lahko uporabite kakšno spletno storitev s podporo za brotli, npr. vsszhat.rf).

2. Nastavitev glav predpomnjenja odjemalca

Tudi preprosta funkcija za pospešitev: dodajte glave za predpomnjenje vsebine s strani odjemalca (brskalnika). Najnovejša glava je cache-control, zastarela je expires. Poleg tega se lahko uporablja Etag. Glavna stvar je, da je največja starost nadzora predpomnilnika dovolj velika (od enega meseca ali več).Če ste pripravljeni čim bolj močno predpomniti vir, lahko dodate nespremenljivo možnost.

CDN-ji lahko znižajo vrednost največje starosti, zaradi česar mora uporabnik pogosteje znova nalagati statično vsebino. Ni jasno, s čim je to povezano: z željo po povečanju prometa v omrežju ali povečanju združljivosti s spletnimi mesti, ki ne vedo, kako ponastaviti predpomnilnik. Na primer, privzeti čas predpomnilnika glave Cloudflare je 1 ura, kar je zelo malo za nespremenljive statične podatke.

3. Optimizacija slike

Ker CDN prevzema funkcije predpomnjenja in serviranja slik, bi bilo logično, da bi jih optimizirali na strani CDN in jih v takšni obliki servirali uporabnikom. Takoj rezervirajmo, da je ta funkcija na voljo samo za vrste CDN 2, 3 in 5.

Slike lahko optimizirate na različne načine: z uporabo naprednih formatov stiskanja (kot je WebP), učinkovitejših kodirnikov (MozJPEG) ali preprosto čiščenjem nepotrebnih metapodatkov.

Na splošno obstajata dve vrsti takih optimizacij: z izgubo kakovosti in brez izgube kakovosti. CDN-ji običajno stremijo k uporabi optimizacije brez izgub, da bi se izognili morebitnim pritožbam strank glede sprememb kakovosti slike. V takih pogojih bo dobiček minimalen. V resnici je raven kakovosti JPEG pogosto veliko višja od potrebne in lahko varno znova stisnete z nižjo stopnjo kakovosti, ne da bi pri tem ogrozili uporabniško izkušnjo. Po drugi strani pa je težko določiti raven kakovosti in nastavitev univerzalno za vse možne spletne aplikacije, zato CDN uporabljajo bolj konzervativne nastavitve v primerjavi s tistimi, ki jih je mogoče uporabiti ob upoštevanju konteksta (namen slik, tip spletne aplikacije). itd.)

4. Optimizacija TLS povezave

Večina današnjega prometa poteka prek povezav TLS, kar pomeni, da porabimo več časa za pogajanja TLS. Nedavno so bile razvite nove tehnologije za pospešitev tega procesa. Na primer, to je kriptografija EC, TLS 1.3, predpomnilnik sej in vstopnice, strojno pospeševanje šifriranja (AES-NI) itd. Pravilna nastavitev TLS lahko zmanjša čas povezave na 0-1 RTT (brez štetja DNS in TCP).

S sodobno programsko opremo takšne prakse ni težko izvajati sami.

Vsi CDN-ji ne izvajajo najboljših praks TLS; to lahko preverite z merjenjem časa povezave TLS (na primer v Webpagetest). Idealno za novo povezavo - 1RTT, 2RTT - povprečna raven, 3RTT in več - slabo.

Opozoriti je treba še, da tudi pri uporabi TLS na nivoju CDN mora strežnik z našo spletno aplikacijo obdelovati tudi TLS, vendar s strani CDN, saj promet med strežnikom in CDN poteka po javnem omrežju. V najslabšem primeru bomo dobili dvojne zakasnitve povezave TLS (prvo do gostitelja CDN, drugo med njim in našim strežnikom).

Pri nekaterih aplikacijah je vredno biti pozoren na varnostna vprašanja: promet se običajno dešifrira na vozliščih CDN in to je potencialna priložnost za prestrezanje prometa. Možnost dela brez razkritja prometa je običajno na voljo v vrhunskih tarifnih načrtih za doplačilo.

5. Zmanjšajte zakasnitve povezave

Glavna prednost CDN, o kateri vsi govorijo: nizka zakasnitev (manjša razdalja) med gostiteljem CDN in uporabnikom. Doseženo z ustvarjanjem geografsko porazdeljene omrežne arhitekture, v kateri so gostitelji nameščeni na točkah koncentracije uporabnikov (mesta, točke izmenjave prometa itd.)

V praksi so lahko prednostne naloge za različna omrežja v določenih regijah. Na primer, ruski CDN bodo imeli več točk prisotnosti v Rusiji. Ameriški bodo omrežje najprej razvijali v ZDA. Na primer, eden največjih CDN Cloudflare ima samo 2 točki v Rusiji - Moskvo in Sankt Peterburg. To pomeni, da lahko prihranimo največ približno 10 ms zakasnitve v primerjavi z neposredno postavitvijo v Moskvi.

Večina zahodnih CDN sploh nima točk v Rusiji. Če se povežete z njimi, lahko samo povečate zamude za vaše rusko občinstvo.

6. Optimizacija vsebine (minifikacija, strukturne spremembe)

Najbolj zapletena in tehnološko napredna točka. Spreminjanje vsebine med dostavo je lahko zelo tvegano. Tudi če vzamemo minifikacijo: zmanjšanje izvorne kode (zaradi dodatnih presledkov, nepomembnih struktur itd.) lahko vpliva na njeno delovanje. Če govorimo o resnejših spremembah - premik kode JS na konec HTML-ja, spajanje datotek itd. - je tveganje motenj v delovanju spletnega mesta še večje.

Zato to počnejo samo nekateri CDN tipa 5. Seveda ne bo mogoče avtomatizirati vseh sprememb, ki so potrebne za pospešitev – potrebni sta ročna analiza in optimizacija. Na primer, odstranjevanje neuporabljene ali podvojene kode je ročna naloga.

Praviloma so vse takšne optimizacije nadzorovane z nastavitvami, najbolj nevarne pa so privzeto onemogočene.

Podpora za zmogljivosti pospeševanja glede na vrsto CDN

Oglejmo si torej, kakšne potencialne priložnosti za pospeševanje ponujajo različne vrste CDN.

Za udobje ponovimo razvrstitev.

  1. Brezplačni CDN za distribucijo knjižnic JS (MaxCDN, Google. Yandex).
  2. CDN storitev za optimizacijo strank (na primer Google Fonts za pisave, Cloudinary, Cloudimage za slike).
  3. CDN za statično optimizacijo in optimizacijo virov v CMS (na voljo v Bitrixu, WordPressu in drugih).
  4. CDN za splošne namene (StackPath, CDNVideo, NGENIX, Megafon).
  5. CDN za pospeševanje spletnih strani (Cloudflare, Imperva, Airi).

Zdaj pa primerjajmo funkcije in vrste CDN.

Priložnost
Tip 1
Tip 2
Tip 3
Tip 4
Tip 5

Stiskanje besedila
+–
-
+–
+–
+

Glave predpomnilnika
+
+
+
+
+

Slike
-
+–
+–
-
+

TLS
-
-
-
+–
+

Zamude
-
-
-
+
+

Vsebina
-
-
-
-
+

V tej tabeli se »+« uporablja za označevanje popolne podpore, »–« je brez podpore in »+–« je delna podpora. Seveda lahko v resnici pride do odstopanj od te tabele (na primer, nekateri splošni CDN bodo izvajali funkcije za optimizacijo slik), vendar je za splošno predstavo uporabna.

Rezultati

Upajmo, da boste po branju tega članka imeli jasnejšo sliko glede priporočila »uporabite CDN« za pospešitev svojih spletnih mest.

Kot v vsakem poslu ne morete verjeti tržnim obljubam katere koli storitve. Učinek je treba izmeriti in preizkusiti v realnih pogojih. Če že uporabljate CDN, preverite njegovo učinkovitost z uporabo meril, opisanih v članku.

Možno je, da trenutna uporaba CDN upočasnjuje čas nalaganja vašega spletnega mesta.

Kot splošno priporočilo se lahko osredotočimo na naslednje: preučite svoje občinstvo, določite njegov geografski obseg. Če je vaše glavno občinstvo koncentrirano v radiju 1-2 tisoč kilometrov, CDN ne potrebujete za njegov glavni namen - zmanjšanje zakasnitve. Namesto tega lahko svoj strežnik postavite bližje svojim uporabnikom in ga pravilno konfigurirate ter pridobite večino optimizacij, opisanih v članku (brezplačnih in trajnih).

V primeru, da je vaše občinstvo resnično geografsko porazdeljeno (radij več kot 3000 kilometrov), bo uporaba kakovostnega CDN resnično koristna. Vendar morate vnaprej razumeti, kaj točno lahko vaš CDN pospeši (glejte tabelo zmogljivosti in njihov opis). Pospeševanje spletnih strani pa še vedno ostaja kompleksna naloga, ki je ni mogoče rešiti s povezavo CDN. Poleg zgornjih optimizacij za CDN ostajajo najučinkovitejši načini pospeševanja: optimizacija strežniškega dela, napredne spremembe odjemalskega dela (odstranitev neuporabljene kode, optimizacija procesa upodabljanja, delo z vsebino, pisave, prilagodljivost itd.). )

Vir: www.habr.com

Dodaj komentar