[Nemojte] koristiti CDN

Gotovo svaki članak ili alat za optimizaciju brzine stranice ima skromnu klauzulu „koristite CDN“. Općenito, CDN je mreža za isporuku sadržaja ili mreža za isporuku sadržaja. Mi u Method Labu često nailazimo na pitanja klijenata na ovu temu; neki od njih omogućavaju vlastiti CDN. Svrha ovog članka je razumjeti šta CDN može pružiti u smislu brzine učitavanja stranice, koji problemi mogu nastati i u kojim slučajevima je korištenje CDN-a opravdano.

Kašnjenja zaokružena na slici su uzrokovana upotrebom CDN-a.

Malo istorije

Poput mnogih tehnologija, CDN-ovi su se pojavili iz nužde. S razvojem internetskih kanala među korisnicima interneta pojavili su se online video servisi. Naravno, video sadržaj zahteva za redove veličine više propusnog opsega u poređenju sa redovnim sadržajem veb sajta (slike, tekst i CSS ili JS kod).

Kada pokušavate da emitujete video stream paralelno na više klijenata sa jednog servera, Internet kanal servera će najverovatnije postati usko grlo. Po pravilu, nekoliko hiljada niti je dovoljno da začepi tipičan serverski kanal. Naravno, mogu postojati i druga ograničenja resursa, ali ona trenutno nisu važna. Takođe je važno da je proširenje serverskog kanala preskupo (a ponekad i nemoguće), a takođe i nepraktično. Opterećenje kanala tokom emitiranja bit će ciklično.

Problem ograničavanja kanala pojedinačnog servera savršeno je riješen CDN-om. Klijenti se ne povezuju direktno na server, već na čvorove u CDN mreži. U idealnoj situaciji, server šalje jedan stream do CDN čvora, a zatim mreža koristi vlastite resurse da isporuči ovaj stream mnogim korisnicima. Sa ekonomske tačke gledišta, plaćamo samo za stvarno potrošene resurse (to može biti propusni opseg ili saobraćaj) i dobijamo odličnu 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 svoje vlastite CDN-ove umjesto da koriste velike komercijalne CDN-ove (Akamai, Cloudflare, Fastly, itd.)

Kako je web evoluirao, same web aplikacije postale su složenije i složenije. Problem brzine utovara došao je do izražaja. Ljubitelji brzine web stranica brzo su identificirali nekoliko velikih problema zbog kojih se web stranice sporo učitavaju. Jedna od njih bila su kašnjenja mreže (RTT - round trip time ili ping time). Kašnjenja utiču na mnoge procese učitavanja web stranice: uspostavljanje TCP veze, pokretanje TLS sesije, učitavanje svakog pojedinačnog resursa (slika, JS datoteka, HTML dokument, itd.)

Problem je pogoršala činjenica da pri korištenju HTTP/1.1 protokola (prije pojave SPDY, QUIC i HTTP/2 ovo je bila jedina opcija), pretraživači otvaraju najviše 6 TCP konekcija na jedan host. Sve je to dovelo do prekida veze i neefikasnog korištenja propusnog opsega kanala. Problem je djelimično riješen dijeljenjem domena - stvaranjem dodatnih hostova za prevazilaženje ograničenja broja veza.

Tu se pojavljuje druga mogućnost CDN-a - smanjenje latencije (RTT) zbog velikog broja tačaka i blizine čvorova korisniku. Udaljenost ovdje igra odlučujuću ulogu: brzina svjetlosti je ograničena (oko 200 km/sec u optičkom vlaknu). To znači da svakih 000 km putovanja dodaje 1000 ms kašnjenja ili 5 ms RTT-u. Ovo je minimalno vrijeme potrebno za prijenos, jer postoje i kašnjenja na međuopremi. Budući da CDN obično zna kako keširati objekte na svojim serverima, možemo imati koristi od učitavanja takvih objekata preko CDN-a. Neophodni uslovi za to: prisustvo objekta u kešu, blizina CDN tačke do korisnika u poređenju sa serverom web aplikacija (origin server). Važno je shvatiti da geografska blizina CDN čvora ne garantuje nisko kašnjenje. Rutiranje između klijenta i CDN-a može biti izgrađeno na takav način da će se klijent povezati na host u drugoj zemlji, a moguće i na drugom kontinentu. Tu dolazi do izražaja odnos između telekom operatera i CDN servisa (peering, veze, učešće u IX, itd.) i politika rutiranja saobraćaja samog CDN-a. Na primjer, Cloudflare, kada koristi dva početna plana (besplatan i jeftin), ne garantuje isporuku sadržaja sa najbližeg hosta - host će biti odabran tako da postigne minimalne troškove.

Mnoge vodeće internet kompanije privlače javni interes (web programere i vlasnike usluga) za temu brzine učitavanja i performansi web stranice. Među tim kompanijama su Yahoo (Yslow alat), AOL (WebPageTest) i Google (Page Speed ​​Insights servis), koje razvijaju vlastite preporuke za ubrzanje stranica (prvenstveno se odnose na optimizaciju klijenata). Kasnije se pojavljuju novi alati za testiranje brzine web stranice, koji također pružaju savjete za povećanje brzine web stranice. Svaki od ovih servisa ili dodataka ima dosljednu preporuku: “Koristite CDN”. Smanjenje kašnjenja mreže obično se navodi kao objašnjenje za učinak CDN-a. Nažalost, nisu svi spremni da shvate kako se tačno postiže efekat ubrzanja CDN-a i kako se može izmjeriti, pa se preporuka uzima na vjeru i koristi kao postulat. Zapravo, nisu svi CDN-ovi stvoreni jednaki.

Korištenje CDN-a danas

Da bi se procijenila korisnost korištenja CDN-ova, potrebno ih je klasificirati. Ono što se sada može naći u praksi (primjeri u zagradama, naravno, nisu iscrpni):

1. Besplatan CDN za distribuciju JS biblioteka (MaxCDN, Google. Yandex).
2. CDN usluga za optimizaciju klijenata (na primjer, Google Fontovi za fontove, Cloudinary, Cloudimage za slike).
3. CDN za statičku i optimizaciju resursa u CMS-u (dostupno u Bitrix-u, WordPress-u i drugima).
4. CDN opšte namene (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN za ubrzanje web stranice (Cloudflare, Imperva, Airi).

Ključna razlika između ovih tipova je u tome koliko prometa prolazi kroz CDN. Tipovi 1-3 su isporuka samo dijela sadržaja: od jednog zahtjeva do nekoliko desetina (obično slika). Tipovi 4 i 5 su potpuni proxy promet preko CDN-a.

U praksi to znači broj priključaka koji se koriste za učitavanje stranice. Sa HTTP/2, koristimo jednu TCP vezu s hostom za obradu bilo kojeg broja zahtjeva. Ako resurse podijelimo na glavni host (origin) i CDN, onda je potrebno distribuirati zahtjeve na nekoliko 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 tornju mobilne telefonije.

Evo kako to izgleda na slapu učitavanja stranice (latencije za povezivanje na CDN su istaknute na RTT 150 ms):

Ako CDN pokriva sav saobraćaj na sajtu (osim usluga trećih strana), onda možemo koristiti jednu TCP vezu, štedeći kašnjenja pri povezivanju sa dodatnim hostovima. Naravno, ovo se odnosi na HTTP/2 veze.

Daljnje razlike su određene funkcionalnošću određenog CDN-a - za prvi tip to je samo hostovanje statične datoteke, za peti mijenja nekoliko tipova sadržaja stranice u svrhu optimizacije.

CDN mogućnosti za ubrzanje web stranice

Hajde da opišemo čitav niz CDN mogućnosti za ubrzavanje sajtova, bez obzira na funkcionalnost pojedinih tipova CDN-a, a zatim da vidimo šta je implementirano u svakom od njih.

1. Kompresija tekstualnih resursa

Najosnovnija i najrazumljivija karakteristika, ali često loše implementirana. Svi CDN-ovi deklariraju prisustvo kompresije kao svojstvo ubrzanja. Ali ako pogledate detaljnije, nedostaci postaju jasni:

• mogu se koristiti niski stepeni za dinamičku kompresiju - 5-6 (na primjer, za gzip maksimum je 9);
• statička kompresija (datoteke u kešu) ne koristi dodatne funkcije (na primjer, zopfi ili brotli sa stepenom 11)
• ne postoji podrška za efikasnu brotli kompresiju (ušteda oko 20% u poređenju sa gzip-om).

Ako koristite CDN, vrijedi provjeriti ovih nekoliko tačaka: uzmite datoteku koja je došla s CDN-a, snimite njenu komprimiranu veličinu i ručno je komprimirajte radi usporedbe (možete koristiti neki online servis s podrškom za brotli, na primjer vsszhat.rf).

2. Postavljanje zaglavlja za keširanje klijenta

Također jednostavna funkcija ubrzanja: dodajte zaglavlja za keširanje sadržaja od strane klijenta (pretraživača). Najnovije zaglavlje je kontrola keša, zastarjelo je isteklo. Dodatno se može koristiti Etag. Glavna stvar je da je maksimalna starost keš kontrole dovoljno velika (od mjesec dana ili više).Ako ste spremni da keširate resurs što je moguće teže, možete dodati nepromjenjivu opciju.

CDN-ovi mogu smanjiti vrijednost maksimalne starosti, prisiljavajući korisnika da češće 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 s web lokacijama koje ne znaju kako resetirati keš memoriju. Na primjer, zadano vrijeme keširanja Cloudflare zaglavlja je 1 sat, što je vrlo malo za nepromjenjive statičke podatke.

3. Optimizacija slike

Budući da CDN preuzima funkcije keširanja i serviranja slika, bilo bi logično optimizirati ih na CDN strani i servirati korisnicima u ovom obliku. Odmah da rezervišemo da je ova funkcija dostupna samo za CDN tipove 2, 3 i 5.

Možete optimizirati slike na različite načine: korištenjem naprednih formata kompresije (kao što je WebP), efikasnijim koderima (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 uslovima dobitak će biti minimalan. U stvarnosti, često je nivo kvaliteta JPEG mnogo veći nego što je potrebno i možete bezbedno ponovo kompresovati sa nižim nivoom kvaliteta bez ugrožavanja korisničkog iskustva. S druge strane, teško je odrediti nivo kvalitete i postavke 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, tip web aplikacije). , itd.)

4. Optimizacija TLS veze

Većina saobraćaja danas 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, keš sesije i tiketi, ubrzanje hardverske enkripcije (AES-NI), itd. Ispravno podešavanje TLS-a može smanjiti vrijeme veze na 0-1 RTT (ne računajući DNS i TCP).

Uz savremeni softver, nije teško samostalno implementirati takve prakse.

Ne implementiraju svi CDN-ovi najbolje prakse TLS-a; to možete provjeriti mjerenjem vremena TLS veze (na primjer, u Webpagetest-u). Idealno za novu vezu - 1RTT, 2RTT - prosječan nivo, 3RTT i više - loš.

Takođe treba napomenuti da čak i kada se koristi TLS na nivou CDN-a, server sa našom web aplikacijom takođe mora da obrađuje TLS, ali sa CDN strane, jer saobraćaj između servera i CDN-a prolazi javnom mrežom. U najgorem slučaju, dobit ćemo dvostruko kašnjenje TLS veze (prvo do CDN hosta, drugo između njega i našeg servera).

Za neke aplikacije vrijedi obratiti pažnju na sigurnosna pitanja: promet se obično dešifruje na CDN čvorovima, a to je potencijalna prilika za presretanje prometa. Opcija rada bez otkrivanja saobraćaja obično se nudi u vrhunskim tarifnim planovima uz dodatnu naknadu.

5. Smanjite kašnjenje veze

Glavna prednost CDN-a o kojoj svi govore: mala latencija (manja udaljenost) između CDN hosta i korisnika. Postiže se kreiranjem geografski distribuirane mrežne arhitekture, u kojoj se hostovi nalaze u tačkama koncentracije korisnika (gradovi, tačke razmene saobraćaja itd.)

U praksi, prioriteti za različite mreže mogu biti u određenim regionima. Na primjer, ruski CDN-ovi će imati više tačaka prisutnosti u Rusiji. Američki će prije svega mrežu razvijati 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 maksimalno oko 10 ms latencije u poređenju sa direktnim postavljanjem u Moskvi.

Većina zapadnih CDN-ova uopšte nema punktove u Rusiji. Povezivanjem s njima možete samo povećati kašnjenja za svoju rusku publiku.

6. Optimizacija sadržaja (minifikacija, strukturne promjene)

Najkompleksnija i tehnološki najnaprednija tačka. Promjena sadržaja tokom isporuke može biti vrlo rizična. Čak i ako uzmemo umanjivanje: smanjenje izvornog koda (zbog dodatnih razmaka, nevažnih struktura, itd.) može uticati na njegove performanse. Ako govorimo o ozbiljnijim promjenama – pomicanju JS koda na kraj HTML-a, spajanju fajlova i sl. – rizik od narušavanja funkcionalnosti stranice je još veći.

Stoga, samo neki CDN-ovi tipa 5 to rade. Naravno, neće biti moguće automatizirati sve promjene potrebne za ubrzanje stvari – potrebna je ručna analiza i optimizacija. Na primjer, uklanjanje neiskorištenog ili dupliciranog koda je ručni zadatak.

Po pravilu, sve takve optimizacije se kontroliraju postavkama, a one najopasnije su po defaultu onemogućene.

Podrška za mogućnosti ubrzanja prema CDN tipu

Dakle, pogledajmo koje potencijalne mogućnosti ubrzanja pružaju različite vrste CDN-ova.

Radi praktičnosti, ponavljamo klasifikaciju.

1. Besplatan CDN za distribuciju JS biblioteka (MaxCDN, Google. Yandex).
2. CDN usluga za optimizaciju klijenata (na primjer, Google Fontovi za fontove, Cloudinary, Cloudimage za slike).
3. CDN za statičku i optimizaciju resursa u CMS-u (dostupno u Bitrix-u, WordPress-u i drugima).
4. CDN opšte namene (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN za ubrzanje web stranice (Cloudflare, Imperva, Airi).

Sada uporedimo karakteristike i tipove CDN-a.

Sposobnost
Tip 1
Tip 2
Tip 3
Tip 4
Tip 5

Kompresija teksta
+–
-
+–
+–
+

Zaglavlja keš memorije
+
+
+
+
+

Slike
-
+–
+–
-
+

TLS
-
-
-
+–
+

Kašnjenja
-
-
-
+
+

Sadržaj
-
-
-
-
+

U ovoj tabeli, “+” se koristi za označavanje pune podrške, “–” nije podrška, a “+–” je delimična podrška. Naravno, u stvarnosti može doći do odstupanja od ove tabele (na primjer, neki CDN opće namjene će implementirati funkcije za optimizaciju slika), ali za opštu ideju to je korisno.

Ishodi

Nadajmo se da ćete nakon čitanja ovog članka imati jasniju sliku o preporuci “koristite CDN” da biste ubrzali svoje web stranice.

Kao iu svakom poslu, ne možete vjerovati marketinškim obećanjima bilo koje usluge. Efekat treba izmeriti i testirati u realnim uslovima. Ako već koristite CDN, provjerite njegovu učinkovitost koristeći kriterije opisane u članku.

Moguće je da trenutno korištenje CDN-a usporava vrijeme učitavanja vaše stranice.

Kao opću preporuku, možemo se fokusirati na sljedeće: proučite svoju publiku, odredite njen geografski opseg. Ako je vaša glavna publika koncentrirana u radijusu od 1-2 hiljade kilometara, CDN vam nije potreban za njegovu glavnu svrhu - smanjenje kašnjenja. Umjesto toga, možete postaviti svoj server bliže korisnicima i pravilno ga konfigurirati, koristeći većinu optimizacija opisanih u članku (besplatno i trajno).

U slučaju da je vaša publika zaista geografski raspoređena (radijus veći od 3000 kilometara), korištenje kvalitetnog CDN-a će zaista biti korisno. Međutim, morate unaprijed razumjeti šta tačno vaš CDN može ubrzati (pogledajte tabelu mogućnosti i njihov opis). Međutim, ubrzanje web stranice i dalje ostaje složen zadatak koji se ne može riješiti povezivanjem CDN-a. Pored navedenih optimizacija, iza CDN-a ostaju najefikasniji načini ubrzanja: optimizacija serverskog dijela, napredne izmjene klijentskog dijela (uklanjanje neiskorištenog koda, optimizacija procesa renderiranja, rad sa sadržajem, fontovima, prilagodljivost itd. )

izvor: www.habr.com