Gotovo svaki članak ili alat za optimizaciju brzine web stranice ima skromnu klauzulu "koristi CDN". Općenito, CDN je mreža za isporuku sadržaja ili mreža za isporuku sadržaja. Mi u Method Labu često se susrećemo s pitanjima klijenata na ovu temu; neki od njih omogućuju vlastiti CDN. Svrha ovog članka je razumjeti što CDN može pružiti u smislu brzine učitavanja stranice, koji problemi mogu nastati i u kojim slučajevima je upotreba CDN-a opravdana.
![[Nemojte] koristiti CDN](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Kašnjenja zaokružena na slici uzrokovana su korištenjem CDN-a.
Malo povijesti
Kao i mnoge druge tehnologije, CDN-ovi su se pojavili iz nužde. S razvojem internetskih kanala među korisnicima interneta pojavili su se online video servisi. Naravno, videosadržaj zahtijeva redove veličine veće propusnosti u usporedbi s uobičajenim sadržajem web stranice (slike, tekst i CSS ili JS kod).
Prilikom pokušaja paralelnog emitiranja video streama na više klijenata s jednog poslužitelja, internetski kanal poslužitelja najvjerojatnije će postati usko grlo. U pravilu je nekoliko tisuća niti dovoljno za začepljenje tipičnog kanala poslužitelja. Naravno, mogu postojati i druga ograničenja resursa, ali ona trenutno nisu važna. Također je važno da je proširenje serverskog kanala preskupo (a ponekad i nemoguće), a i nepraktično. Opterećenje kanala tijekom emitiranja bit će cikličko.
Problem ograničavanja kanala pojedinog poslužitelja CDN savršeno rješava. Klijenti se ne spajaju izravno na poslužitelj, već na čvorove u CDN mreži. U idealnoj situaciji, poslužitelj šalje jedan tok CDN čvoru, a zatim mreža koristi vlastite resurse da isporuči ovaj tok mnogim korisnicima. S ekonomskog gledišta, plaćamo samo za stvarno potrošene resurse (to može biti propusnost ili promet) i dobivamo izvrsnu skalabilnost naše usluge. Korištenje CDN-a za isporuku teškog sadržaja potpuno je opravdano i logično. Iako je vrijedno napomenuti da najveći igrači u ovom prostoru (npr. Netflix) grade vlastite CDN-ove umjesto da koriste velike komercijalne CDN-ove (Akamai, Cloudflare, Fastly itd.)
Kako se web razvijao, same web aplikacije postale su složenije i složenije. Do izražaja je došao problem brzine učitavanja. Ljubitelji brzine web stranica brzo su identificirali nekoliko velikih problema koji su uzrokovali sporo učitavanje web stranica. Jedan od njih bila su mrežna kašnjenja (RTT - vrijeme kružnog putovanja ili vrijeme pinga). Kašnjenja utječu na mnoge procese pri učitavanju web stranice: uspostavljanje TCP veze, pokretanje TLS sesije, učitavanje svakog pojedinačnog resursa (slika, JS datoteka, HTML dokument itd.)
Problem je bio pogoršan činjenicom da pri korištenju HTTP/1.1 protokola (prije pojave SPDY, QUIC i HTTP/2 to je bila jedina opcija), preglednici otvaraju najviše 6 TCP veza na jednom hostu. Sve je to dovelo do prekida veze i neučinkovitog korištenja propusnosti kanala. Problem je djelomično riješen shardingom domene - stvaranjem dodatnih hostova kako bi se prevladalo ograničenje broja veza.
Tu se pojavljuje druga sposobnost CDN-a - smanjenje latencije (RTT) zbog velikog broja točaka i blizine čvorova korisniku. Udaljenost ovdje igra odlučujuću ulogu: brzina svjetlosti je ograničena (oko 200 000 km/s u optičkom vlaknu). To znači da svakih 1000 km putovanja dodaje 5 ms odgode ili 10 ms na RTT. Ovo je minimalno vrijeme potrebno za prijenos, budući da postoje i kašnjenja na međuopremi. Budući da CDN obično zna kako predmemorirati objekte na svojim poslužiteljima, možemo imati koristi od učitavanja takvih objekata putem CDN-a. Potrebni uvjeti za to: prisutnost objekta u cacheu, blizina CDN točke korisniku u usporedbi s poslužiteljem web aplikacije (izvorni poslužitelj). Važno je razumjeti da geografska blizina CDN čvora ne jamči nisku latenciju. Usmjeravanje između klijenta i CDN-a može se izgraditi na takav način da će se klijent spojiti na host u drugoj zemlji, a možda i na drugom kontinentu. Ovdje dolazi do izražaja odnos između telekom operatera i CDN usluge (peering, veze, sudjelovanje u IX, itd.) i politika usmjeravanja prometa samog CDN-a. Na primjer, Cloudflare, kada koristi dva početna plana (besplatan i jeftin), ne jamči isporuku sadržaja s najbližeg hosta - host će biti odabran tako da postigne minimalne troškove.
Mnoge vodeće internetske tvrtke privlače interes javnosti (web programera i vlasnika usluga) na temu brzine učitavanja i performansi web stranice. Među tim tvrtkama su Yahoo (alat Yslow), AOL (WebPageTest) i Google (usluga Page Speed Insights), koje razvijaju vlastite preporuke za ubrzanje stranica (prvenstveno se odnose na optimizaciju klijenta). Kasnije se pojavljuju novi alati za testiranje brzine web stranice, koji također daju savjete za povećanje brzine web stranice. Svaka od ovih usluga ili dodataka ima dosljednu preporuku: "Koristite CDN." Smanjenje latencije mreže obično se navodi kao objašnjenje za učinak CDN-a. Nažalost, nisu svi spremni točno razumjeti kako se postiže učinak ubrzanja CDN-a i kako se može izmjeriti, pa se preporuka uzima na vjeru i koristi se kao postulat. Zapravo, nisu svi CDN-ovi jednaki.
Korištenje CDN-a danas
Kako bi se procijenila korisnost korištenja CDN-ova, potrebno ih je klasificirati. Što se sada može naći u praksi (primjeri u zagradama, naravno, nisu iscrpni):
- Besplatni CDN za distribuciju JS biblioteka (MaxCDN, Google. Yandex).
- CDN usluga za optimizaciju klijenata (na primjer, Google Fontovi za fontove, Cloudinary, Cloudimage za slike).
- CDN za statičku optimizaciju i optimizaciju resursa u CMS-u (dostupno u Bitrixu, WordPressu i drugima).
- CDN opće namjene (StackPath, CDNVideo, NGENIX, Megafon).
- CDN za ubrzanje web stranice (Cloudflare, Imperva, Airi).
Ključna razlika između ovih vrsta je koliki dio prometa prolazi kroz CDN. Vrste 1-3 su isporuka samo dijela sadržaja: od jednog zahtjeva do nekoliko desetaka (obično slika). Tipovi 4 i 5 su potpuno proxyiranje prometa putem CDN-a.
U praksi to znači broj veza koje se koriste za učitavanje stranice. Uz HTTP/2 koristimo jednu TCP vezu s hostom za obradu bilo kojeg broja zahtjeva. Ako resurse podijelimo na glavni host (origin) i CDN, tada je potrebno zahtjeve rasporediti na više domena i kreirati nekoliko TCP veza. Najgori slučaj je: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Ova formula ne uzima u obzir kašnjenja u mobilnim mrežama za aktivaciju radio kanala uređaja (ako nije bio aktivan) i kašnjenja na mobilnom tornju.
Evo kako to izgleda na vodopadu učitavanja web-mjesta (kašnjenja za povezivanje s CDN-om istaknuta su na RTT 150 ms):
Ako CDN pokriva sav promet stranice (osim usluga trećih strana), tada možemo koristiti jednu TCP vezu, štedeći kašnjenja pri povezivanju s dodatnim hostovima. Naravno, ovo se odnosi na HTTP/2 veze.
Daljnje razlike su određene funkcionalnošću pojedinog CDN-a - za prvi tip to je samo hosting statične datoteke, za peti mijenja nekoliko tipova sadržaja stranice u svrhu optimizacije.
CDN mogućnosti za ubrzanje web stranice
Opišimo cijeli niz mogućnosti CDN-a za ubrzavanje stranica, bez obzira na funkcionalnost pojedinih vrsta CDN-a, a zatim vidimo što je implementirano u svakom od njih.
1. Sažimanje tekstualnih izvora
Najosnovnija i najrazumljivija značajka, ali često loše implementirana. Svi CDN-ovi deklariraju prisutnost kompresije kao svoju značajku ubrzanja. Ali ako pogledate detaljnije, nedostaci postaju jasni:
- mogu se koristiti niski stupnjevi za dinamičku kompresiju - 5-6 (na primjer, za gzip maksimum je 9);
- statička kompresija (datoteke u cacheu) ne koristi dodatne značajke (na primjer, zopfi ili brotli sa stupnjem 11)
- nema podrške za učinkovitu brotli kompresiju (ušteda oko 20% u usporedbi s gzipom).
Ako koristite CDN, vrijedi provjeriti ovih nekoliko točaka: uzmite datoteku koja je došla s CDN-a, zabilježite njezinu komprimiranu veličinu i kompresirajte je ručno za usporedbu (možete koristiti neki online servis s podrškom za brotli, na primjer ).
2. Postavljanje zaglavlja za predmemoriju klijenta
Također jednostavna značajka ubrzanja: dodajte zaglavlja za predmemoriju sadržaja od strane klijenta (preglednika). Najnovije zaglavlje je cache-control, zastarjelo je expires. Dodatno se može koristiti Etag. Glavna stvar je da maksimalna starost kontrole predmemorije bude dovoljno velika (od mjesec dana ili više).Ako ste spremni predmemorirati resurs što je jače moguće, možete dodati nepromjenjivu opciju.
CDN-ovi mogu sniziti vrijednost maksimalne dobi, prisiljavajući korisnika da češće ponovno učitava statički sadržaj. Nije jasno s čime je to povezano: željom za povećanjem prometa na mreži ili povećanjem kompatibilnosti sa stranicama koje ne znaju kako resetirati predmemoriju. Na primjer, zadano vrijeme predmemorije zaglavlja Cloudflare je 1 sat, što je vrlo malo za nepromjenjive statičke podatke.
3. Optimizacija slike
Budući da CDN preuzima funkcije predmemoriranja i posluživanja slika, logično bi bilo optimizirati ih na strani CDN-a i u ovakvom obliku servirati ih korisnicima. Odmah rezervirajmo da je ova značajka dostupna samo za CDN vrste 2, 3 i 5.
Slike možete optimizirati na različite načine: korištenjem naprednih formata kompresije (kao što je WebP), učinkovitijih kodera (MozJPEG) ili jednostavno čišćenjem nepotrebnih metapodataka.
Općenito, postoje dvije vrste takvih optimizacija: s gubitkom kvalitete i bez gubitka kvalitete. CDN-ovi obično nastoje koristiti optimizaciju bez gubitaka kako bi izbjegli moguće pritužbe korisnika na promjene u kvaliteti slike. U takvim uvjetima dobit će biti minimalna. U stvarnosti, često je razina kvalitete JPEG puno viša od potrebne i možete sigurno ponovno komprimirati s nižom razinom kvalitete bez ugrožavanja korisničkog iskustva. S druge strane, teško je odrediti razinu kvalitete i postavki univerzalno za sve moguće web aplikacije, pa CDN-ovi koriste konzervativnije postavke u odnosu na one koje se mogu primijeniti uzimajući u obzir kontekst (namjena slika, vrsta web aplikacije). , itd.)
4. Optimiziranje TLS veze
Većina današnjeg prometa ide preko TLS veza, što znači da trošimo dodatno vrijeme na TLS pregovore. Nedavno su razvijene nove tehnologije koje ubrzavaju ovaj proces. Na primjer, ovo je EC kriptografija, TLS 1.3, predmemorija sesije i ulaznice, hardversko ubrzanje enkripcije (AES-NI), itd. Ispravno postavljanje TLS-a može smanjiti vrijeme povezivanja na 0-1 RTT (ne računajući DNS i TCP).
S modernim softverom nije teško sami implementirati takve prakse.
Ne implementiraju svi CDN-ovi najbolje prakse TLS-a; to možete provjeriti mjerenjem vremena TLS veze (na primjer, u Webpagetestu). Idealno za novu vezu - 1RTT, 2RTT - prosječna razina, 3RTT i više - loše.
Također treba napomenuti da i kod korištenja TLS-a na razini CDN-a, poslužitelj s našom web aplikacijom također mora obrađivati TLS, ali s CDN strane, jer promet između poslužitelja i CDN-a prolazi javnom mrežom. U najgorem slučaju dobit ćemo dvostruka kašnjenja TLS veze (prvo prema CDN hostu, drugo između njega i našeg poslužitelja).
Za neke aplikacije vrijedi obratiti pozornost na sigurnosna pitanja: promet se obično dekriptira na CDN čvorovima, a to je potencijalna prilika za presretanje prometa. Mogućnost rada bez objave prometa obično se nudi u vrhunskim tarifnim planovima uz dodatnu naknadu.
5. Smanjite kašnjenja veze
Glavna prednost CDN-a o kojoj svi govore: niska latencija (manja udaljenost) između CDN hosta i korisnika. Postiže se stvaranjem geografski distribuirane mrežne arhitekture, u kojoj se hostovi nalaze u točkama koncentracije korisnika (gradovi, točke razmjene prometa itd.)
U praksi, prioriteti za različite mreže mogu biti u određenim regijama. Na primjer, ruski CDN-ovi će imati više točaka prisutnosti u Rusiji. Američki će prije svega razvijati mrežu u SAD-u. Na primjer, jedan od najvećih CDN Cloudflare ima samo 2 točke u Rusiji - Moskvu i Sankt Peterburg. Odnosno, možemo uštedjeti najviše oko 10 ms latencije u usporedbi s izravnim postavljanjem u Moskvi.
Većina zapadnih CDN-ova uopće nema bodova u Rusiji. Povezivanjem s njima možete samo povećati kašnjenja za svoju rusku publiku.
6. Optimizacija sadržaja (minifikacija, strukturne promjene)
Najsloženija i tehnološki najnaprednija točka. Promjena sadržaja tijekom isporuke može biti vrlo rizična. Čak i ako uzmemo minifikaciju: smanjenje izvornog koda (zbog dodatnih razmaka, nevažnih struktura itd.) može utjecati na njegovu izvedbu. Ako govorimo o ozbiljnijim promjenama - premještanje JS koda na kraj HTML-a, spajanje datoteka i sl. - rizik narušavanja funkcionalnosti stranice je još veći.
Stoga to rade samo neki CDN-ovi tipa 5. Naravno, neće biti moguće automatizirati sve promjene potrebne za ubrzanje stvari - potrebne su ručne analize i optimizacija. Na primjer, uklanjanje neiskorištenog ili dupliciranog koda ručni je zadatak.
U pravilu, sve takve optimizacije kontroliraju se postavkama, a one najopasnije su prema zadanim postavkama onemogućene.
Podrška za mogućnosti ubrzanja prema vrsti CDN-a
Dakle, pogledajmo koje potencijalne mogućnosti ubrzanja pružaju različite vrste CDN-ova.
Radi praktičnosti, ponavljamo klasifikaciju.
- Besplatni CDN za distribuciju JS biblioteka (MaxCDN, Google. Yandex).
- CDN usluga za optimizaciju klijenata (na primjer, Google Fontovi za fontove, Cloudinary, Cloudimage za slike).
- CDN za statičku optimizaciju i optimizaciju resursa u CMS-u (dostupno u Bitrixu, WordPressu i drugima).
- CDN opće namjene (StackPath, CDNVideo, NGENIX, Megafon).
- CDN za ubrzanje web stranice (Cloudflare, Imperva, Airi).
Sada usporedimo značajke i vrste CDN-a.
Prilika
Tip 1
Tip 2
Tip 3
Tip 4
Tip 5
Kompresija teksta
+–
-
+–
+–
+
Zaglavlja predmemorije
+
+
+
+
+
Картинки
-
+–
+–
-
+
TLS
-
-
-
+–
+
Kašnjenja
-
-
-
+
+
Sadržaj
-
-
-
-
+
U ovoj tablici, "+" se koristi za označavanje pune podrške, "–" znači da nema podrške, a "+–" označava djelomičnu podršku. Naravno, u stvarnosti mogu postojati odstupanja od ove tablice (na primjer, neki CDN opće namjene će implementirati značajke za optimizaciju slika), ali za opću ideju to je korisno.
Rezultati
Nadamo se da ćete nakon čitanja ovog članka imati jasniju sliku o preporuci "koristite CDN" za ubrzavanje svojih web stranica.
Kao u svakom poslu, ne možete vjerovati marketinškim obećanjima bilo koje usluge. Učinak je potrebno izmjeriti i testirati u stvarnim uvjetima. Ako već koristite CDN, provjerite njegovu učinkovitost pomoću kriterija opisanih u članku.
Moguće je da trenutačno korištenje CDN-a usporava vrijeme učitavanja vaše stranice.
Kao opću preporuku, možemo se usredotočiti na sljedeće: proučite svoju publiku, odredite njezin geografski opseg. Ako je vaša glavna publika koncentrirana u radijusu od 1-2 tisuće kilometara, ne trebate CDN za njegovu glavnu svrhu - smanjenje latencije. Umjesto toga, možete postaviti svoj poslužitelj bliže korisnicima i pravilno ga konfigurirati, dobivajući većinu optimizacija opisanih u članku (besplatnih i trajnih).
U slučaju da je vaša publika uistinu geografski raspoređena (radijus veći od 3000 kilometara), korištenje kvalitetnog CDN-a će doista biti korisno. Međutim, morate unaprijed razumjeti što točno vaš CDN može ubrzati (pogledajte tablicu mogućnosti i njihov opis). Međutim, ubrzanje web stranica i dalje ostaje složen zadatak koji se ne može riješiti povezivanjem CDN-a. Uz gore navedene optimizacije, iza CDN-a ostaju najučinkovitiji načini ubrzanja: optimizacija serverskog dijela, napredne promjene na klijentskom dijelu (uklanjanje neiskorištenog koda, optimiziranje procesa renderiranja, rad sa sadržajem, fontovi, prilagodljivost itd.). )
Izvor: www.habr.com