🥇[Ne] uporabljajte CDN

V skoraj vsakem članku ali orodju za optimizacijo hitrosti spletnih strani je skromna točka »uporabite CDN«. CDN pomeni mreža za dostavo vsebin. V podjetju „Metod Lab“ se pogosto srečujemo z vprašanji strank o tej temi, nekateri si samostojno vključujejo CDN. Cilj tega članka je razjasniti, kaj lahko CDN ponudi z vidika hitrosti nalaganja spletne strani, kakšne težave se lahko pojavijo in v katerih primerih je uporaba CDN upravičena.

Zakasnitve, prikazane na sliki, so posledica uporabe CDN.

Nekaj zgodovine

Kot mnoge tehnologije so tudi CDN-ji nastali iz potrebe. Z razvojem internetnih povezav pri uporabnikih omrežja so se pojavile storitve za predvajanje videov. Očitno je, da video vsebine zahtevajo veliko večjo prepustnost v primerjavi z običajnimi vsebinami spletnih strani (slike, besedilo ter CSS ali JS koda).

Pri poskusu vzporednega pretakanja video toka mnogim strankam z enega strežnika bo najšibkejša točka verjetno internetna povezava strežnika. Običajno zadostuje že nekaj tisoč tokov, da zapolnijo tipično povezavo strežnika. Seveda so lahko prisotne tudi druge omejitve virov, a te trenutno niso pomembne. Prav tako je pomembno, da je širitev povezave strežnika zelo draga (včasih celo nemogoča) in ekonomsko neupravičena. Obremenitev na povezavi pri prenosih bo imela cikličen značaj.

Omejitev povezave posameznega strežnika odlično rešuje CDN. Stranke se ne povezujejo neposredno na strežnik, temveč na vozlišča mreže CDN. V idealnem primeru strežnik odda en tok vozlišču CDN, nato pa mreža izkorišča lastne vire za dostavo tega toka mnogim uporabnikom. Z vidika ekonomije plačamo le za dejansko porabljene vire (to je lahko prepustnost ali promet) in dobimo odlično razširljivost naše storitve. Uporaba CDN za dostavo težkih vsebin je popolnoma upravičena in logična. Vendar pa je treba omeniti, da največji igralci na tem področju (kot je Netflix) gradijo svoje CDN-je namesto da bi uporabljali velike komercialne CDN-je (Akamai, Cloudflare, Fastly itd.).

Spletne aplikacije so se z razvojem interneta postale bolj zapletene in obsežne. Na površje je prišla težava s hitrostjo nalaganja. Navdušenci nad hitrostjo spletnih strani so hitro identificirali več ključnih težav, ki so povzročale počasno nalaganje. Ena izmed teh težav so bile zamude v omrežju (RTT - round trip time ali ping čas). Zamude vplivajo na številne procese pri nalaganju spletne strani: vzpostavitev TCP povezave, zagon TLS seje, nalaganje vsakega posameznega vira (slike, JavaScript datoteke, HTML dokumenta itd.)

Težava se je še dodatno poslabšala, ker so pri uporabi protokola HTTP/1.1 (preden so se pojavili SPDY, QUIC in HTTP/2, je to bila edina možnost) brskalniki odprli največ 6 TCP povezav do enega gostitelja. Vse to je vodilo do neaktivnosti povezave in neučinkovite rabe pasovne širine. Težavo je delno rešil domenčni šarding - ustvarjanje dodatnih gostiteljev za premostitev omejitve števila povezav.

Tu se pojavi druga zmožnost CDN - zmanjšanje zamud (RTT) z veliko število točk in bližino vozlišč uporabniku. Razdalja ima ključno vlogo: hitrost svetlobe je omejena (približno 200.000 km/s v optičnih vlaknih). To pomeni, da vsaka 1000 km poti doda 5 ms zamud ali 10 ms v RTT. To so minimalni stroški časa za prenos, saj so še vedno prisotne zamude na vmesni opremi. Ker CDN običajno shranjuje predmete na svojih strežnikih, lahko pridobimo od nalaganja takih predmetov prek CDN. Potrebni pogoji za to so: obstoj predmeta v predpomnilniku, bližina točke CDN uporabniku v primerjavi z izvornih strežnikom (origin server). Pomembno je razumeti: geografska bližina vozlišča CDN ne zagotavlja nizkih zamud. Usmerjanje med odjemalcem in CDN je lahko zgrajeno tako, da se odjemalec poveže z gostiteljem v drugi državi, morda celo na drugem kontinentu. Tukaj stopijo v veljavo odnosi med telekomunikacijskimi operaterji in CDN storitvijo (peering, prisotnost stikov, udeležba v IX itd.) in politika usmerjanja prometa samega CDN. Na primer, Cloudflare pri uporabi dveh osnovnih načrtov (brezplačnega in cenovno ugodnega) ne jamči za dostavo vsebine z najbližjega vozlišča - izbira gostitelja se opravi z namenom doseganja minimalnih stroškov.

Mnoge vodeće internet kompanije privlače interes javnosti (vеб-разработчиков i vlasnika servisa) prema temi brzine učitavanja i rada sajtova. Među tim kompanijama su Yahoo (alat Yslow), AOL (WebPageTest) i Google (usluga Page Speed Insights), koje razvijaju svoje preporuke za ubrzavanje sajtova (pre svega se odnose na klijentsku optimizaciju). Kasnije se pojavljuju novi alati za testiranje brzine sajtova, koji takođe daju savete o povećanju brzine sajtova. U svakoj od ovih usluga ili dodataka postoji neizmenjena preporuka „Koristite CDN“. Kao objašnjenje efekta CDN obično se navodi smanjenje mrežnih latencija. Nažalost, nisu svi spremni da se upuste u to kako se tačno postiže efekat ubrzanja uz CDN i kako ga je moguće izmeriti, tako da se preporuka prihvata na veru i koristi kao postulat. U stvarnosti, daleko od toga da su svi CDN-ovi jednako korisni.

Korišćenje CDN-a danas

Za procenu korisnosti primene CDN-a, treba ih klasifikovati. Šta se može sresti danas u praksi (primere u zagradama naravno nisu iscrpni):

Besplatni CDN-ovi za distribuiranje JS biblioteka (MaxCDN, Google, Yandex).
CDN usluga za klijentsku optimizaciju (na primer Google Fonts za fontove, Cloudinary, Cloudimage za slike).
CDN za statiku i optimizaciju resursa u CMS-u (dostupni u Bitrix-u, WordPress-u i drugima).
CDN opšte namene (StackPath, CDNVideo, NGENIX, MegaFon).
CDN za ubrzavanje sajtova (Cloudflare, Imperva, Airi).

Ključno razlikovanje ovih tipova sastoji se u sledećem: koja deo saobraćaja prolazi kroz CDN. Tipovi 1-3 to je dostava samo dela sadržaja: od jednog zahteva do nekoliko desetina (obično slika). Tipovi 4 i 5 to je potpuno proksiranje saobraćaja kroz CDN.

U praksi to znači broj konekcija koje se koriste za učitavanje sajta. Kada koristimo HTTP/2 koristimo jednom TCP konekciju ka hostu za obradu bilo kojeg broja zahteva. Ako delimo resurse između osnovnog host-a (origin) i CDN-a, neophodno je razdvojiti zahteve između više domena i stvoriti nekoliko TCP veza. U najgorem slučaju to je: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. U ovoj formuli se ne uzimaju u obzir latencije u mobilnim mrežama za aktivaciju radio-kanala uređaja (ako nije bio aktivan) i latencije na mobilnoj stanici.

Tako izgleda na naletu naleta strani (z zamudami za povezavo na CDN pri RTT 150 ms):

Če CDN pokriva ves promet strani (razen zunanjih storitev), lahko uporabimo eno samo TCP povezavo, kar prihrani zamude pri povezovanju s dodatnimi gostitelji. Seveda to velja za povezave HTTP/2.

Dodatne razlike določajo funkcionalnosti konkretne CDN – za prvi tip gre zgolj za gostovanje statično datoteko, za peti pa gre za spremembo več tipov vsebine strani z namenom optimizacije.

Možnosti CDN za pospeševanje spletnih strani

Določimo celoten spekter možnosti CDN za pospeševanje spletnih strani, ne da bi se ozirali na funkcionalnost posameznih tipov CDN, nato pa bomo pogledali, kaj od tega je realizirano v vsakem od njih.

1. Stiskanje besedilnih virov

Najosnovnejša in najbolj razumljiva možnost, vendar je pogosto slabo izvedena. Vsi CDN deklarirajo stiskanje kot svojo funkcijo pospeševanja. A če pogledamo podrobneje, odkrijemo pomanjkljivosti:

lahko se uporabljajo nizke stopnje za dinamično stiskanje – 5-6 (na primer, za gzip je maksimum — 9);
pri statičnem stiskanju (datoteke v predpomnilniku) se ne uporabljajo dodatne možnosti (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, preverite teh nekaj točk: vzemite datoteko, ki je prišla z CDN, zabeležite njeno velikost v stisnjeni obliki in jo ponovno stisnite ročno za primerjavo (lahko uporabite kakšen spletni servis s podporo za brotli, na primer vsecompress.com).

2. Nastavitev glav pošiljanja za predpomnjenje na strani odjemalca

Tudi preprosta funkcija za pospeševanje: nastavitev glav za predpomnjenje vsebine na strani odjemalca (brskalnika). Najbolj zanimiva glavna cache-control, zastarela – expires. Dodatno se lahko uporablja Etag. Najpomembneje je, da je max-age pri cache-control dovolj velik (od enega meseca dalje); če ste pripravljeni, da kar najbolj strogo predpomnite vir, lahko dodate možnost immutable.

CDN lahko znižajo vrednost max-age, kar uporabnike prisili, da pogosteje ponovno nalagajo statiko. Zakaj to počnejo: ali da povečajo promet v omrežju ali pa zaradi večje združljivosti z mesti, ki ne znajo čistiti predpomnilnika – ni jasno. Na primer, privzeta vrednost časa predpomnjenja v naslovih Cloudflare znaša 1 ura, kar je zelo malo za nespremenljivo statiko.

3. Optimizacija slik

Ker CDN prevzemajo naloge predpomnjenja in dostave slik, bi bilo smiselno optimizirati jih na strani CDN in na ta način dostaviti uporabnikom. Takoj naj povemo, da je ta možnost na voljo le za CDN tipov 2, 3 in 5.

Sliko lahko optimiziramo na različne načine: z uporabo naprednih formatov stiskanja (na primer, WebP), bolj učinkovitimi kodirniki (MozJPEG) ali pa preprosto z odstranjevanjem odvečnih metapodatkov.

Na splošno sta dva tipa teh optimizacij: z izgubo kakovosti in brez izgube kakovosti. CDN običajno stremijo k uporabi optimizacije brez izgub – da bi se izognili morebitnim pritožbam strank zaradi spremembe kakovosti slik. V takšnih okoliščinah je dobiček minimalen. V resnici nivo kakovosti JPEG pogosto znatno presega potrebno in lahko mirno izvedemo rekodiranje z nižjim kazalnikom kakovosti, brez škode za uporabniško izkušnjo. Po drugi strani pa je težko določiti nivo kakovosti in nastavitve univerzalno za vse možne spletne aplikacije, zato CDN uporabljajo bolj konservativne nastavitve v primerjavi s tistimi, ki bi jih lahko uporabili ob upoštevanju konteksta (namen slik, tip spletne aplikacije itd.)

4. Optimizacija TLS-povezave

Večina prometa danes poteka preko TLS-povezav, kar pomeni, da porabimo dodatni čas za TLS dogovarjanje. V zadnjem času so bila razvita nova tehnološka sredstva za pospešitev tega procesa. Na primer, to so EC-kriptografija, TLS 1.3, predpomnjenje sej in vstopnice (session tickets), strojno pospeševanje šifriranja (AES-NI) itd. Pravilna nastavitev TLS omogoča, da se čas povezave skrajša na 0-1 RTT (brez upoštevanja DNS in TCP).

Ob prisotnosti sodobne programske opreme ni težko vnesti takih praks v lastnih zmogljivostih.

Niso vsi CDN izvajajo najboljše prakse glede TLS, kar lahko preverite z merjenjem časa TLS povezave (na primer v Webpagetest). Idealno za novo povezavo je 1RTT, 2RTT je povprečna raven, 3RTT in več – slabo.

Prav tako je treba omeniti, da celo pri uporabi TLS na ravni CDN strežnik z našo spletno aplikacijo prav tako mora obravnavati TLS, vendar s strani CDN, ker promet med strežnikom in CDN poteka v javnem omrežju. V najslabšem primeru bomo imeli dvojne zamude TLS povezave (prva do gostitelja CDN, druga med njim in našim strežnikom).

Za nekatere aplikacije je treba opozoriti na vprašanja varnosti: običajno se promet dešifrira na vozliščih CDN, kar je potencialna priložnost za prestrezanje prometa. Možnost delovanja brez razkritja prometa običajno ponujajo v vrhunskih tarifah za dodatno plačilo.

5. Zmanjšanje zamud pri povezavi

Glavna prednost CDN, o kateri vsi govorijo: nizke zamude (manjša razdalja) med gostiteljem CDN in uporabnikom. To se doseže z ustvarjanjem geografskih architektur omrežja, kjer so gostitelji razporejeni na koncentracijskih točkah uporabnikov (mestih, izmenjavah prometa itd.).

V praksi so prednostne naloge za različna omrežja lahko v specifičnih regijah. Na primer, ruski CDN bodo imeli več točk prisotnosti v Rusiji. Ameriški bodo predvsem razvijali omrežje v ZDA. Na primer, eden največjih CDN Cloudflare ima le 2 točki v Rusiji – Moskva in Sankt Peterburg. To pomeni, da lahko maksimalno prihranimo približno 10 ms zamude v primerjavi s neposredno namestitvijo v Moskvi.

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

6. Optimizacija vsebine (minifikacija, strukturne spremembe)

Najtežja in tehnološko zahtevna točka. Spreminjanje vsebine med dostavo je lahko zelo tvegano. Tudi če govorimo o minifikaciji: zmanjšanje izvorne kode (zaradi odvečnih presledkov, nepomembnih konstrukcij itd.) lahko vpliva na njeno delovanje. Če govorimo o bolj resnih spremembah – premestitvi JS kode na konec HTML, združevanju datotek in podobnem – je tveganje za motenje delovanja spletnega mesta še večje.

Zato se le nekateri CDN-ji tipa 5 ukvarjajo s tem. Seveda ni mogoče avtomatizirati vseh potrebnih sprememb za pospešitev — potrebna je ročna analiza in optimizacija. Na primer, odstranjevanje nepokaljenih ali podvojenih kod se uvršča med ročne naloge.

Na splošno vse te optimizacije upravljajo nastavitve, najnevarnejše pa so privzeto izklopljene.

Podpora za pospeševalne možnosti po tipih CDN

Poglejmo, katere potencialne možnosti za pospeševanje ponujajo različni tipi CDN.

Za lažjo orientacijo ponovimo klasifikacijo.

Besplatni CDN-ovi za distribuiranje JS biblioteka (MaxCDN, Google, Yandex).
CDN usluga za klijentsku optimizaciju (na primer Google Fonts za fontove, Cloudinary, Cloudimage za slike).
CDN za statiku i optimizaciju resursa u CMS-u (dostupni u Bitrix-u, WordPress-u i drugima).
CDN opšte namene (StackPath, CDNVideo, NGENIX, MegaFon).
CDN za ubrzavanje sajtova (Cloudflare, Imperva, Airi).

Zdaj bomo primerjali funkcije in tipe CDN.

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

Stiskanje besedila
+–
–
+–
+–
+

Naslovi predpomnilnika
+
+
+
+
+

Slike
–
+–
+–
–
+

, čeprav se tega zelo sramuje.
–
–
–
+–
+

Zamude
–
–
–
+
+

Sadržaj
–
–
–
–
+

V tej tabeli „+“ pomeni popolno podporo, „–“ pomeni odsotnost, „+–“ pa delno podporo. Seveda so možna odstopanja od te tabele v resničnosti (na primer, kakšen CDN splošne rabe lahko uvede funkcije za optimizacijo slik), a za splošno predstavo je koristna.

Zaključki

Upam, da boste po branju tega članka dobili jasnejšo sliko glede priporočila „uporabite CDN“ za pospešitev spletnih mest.

Kot pri vsaki stvari, ne smete verjeti trženjskim obljubam katerega koli storitve. Učinek je treba meriti in preverjati v resničnih pogojih. Če že uporabljate kakšen CDN, preverite njegovo učinkovitost glede na merila, opisana v članku.

Morda uporaba CDN trenutno upočasnjuje nalaganje vaše spletne strani.

Kot splošno priporočilo lahko povzamemo naslednje: preučite svojo publiko, določite njene geografske okvirje. Če je vaša glavna publika skoncentrirana v radiju 1-2 tisoč kilometrov, CDN za zmanjševanje zamud ni nujen. Namesto tega lahko postavite svoj strežnik bližje uporabnikom in ga ustrezno nastavite, da pridobite večino optimizacij, opisanih v članku (brezplačno in stalno).

Če je vaše občinstvo resnično geografsko razpršeno (radij več kot 3000 kilometrov), bo uporaba kakovostne CDN resnično koristna. Vendar pa je treba vnaprej razumeti, kaj točno bo vaša CDN pospešila (glejte tabelo z možnostmi in njihov opis). Pospeševanje spletne strani je vseeno kompleksna naloga, ki se ne rešuje zgolj s povezovanjem CDN. Poleg navedenih optimizacij ostajajo zunaj CDN najučinkovitejša sredstva za pospeševanje: optimizacija strežniškega dela, napredne spremembe na odjemalski strani (odstranjevanje neuporabljene kode, optimizacija procesa upodabljanja, delo s vsebino, pisavami, prilagodljivostjo itd.)

Izvor: habr.com