[Не] kasutage CDN

Peaaegu igas artiklis või tööriistas, mis käsitleb veebisaitide kiirusoptimeerimist, on tagasihoidlik punkt „kasutage CDN-i“. Üldiselt on CDN sisu edastamise võrk. Meie ettevõttes „Metod Lab“ puutume sageli kokku klientide küsimustega selle teema kohta, mõned aktiveerivad ise oma CDN-i. Selle artikli eesmärk on uurida, mida CDN võib pakkuda veebisaidi laadimise kiirusest lähtuvalt, milliseid probleeme võib tekkida ning millal on CDN-i kasutamine põhjendatud.

Pildil esitatud viivitused on põhjustatud CDN-i kasutamisest.

Veidi ajalugu

Nagu paljude tehnoloogiate puhul, tekkisid CDN-id vajaduse tõttu. Interneti-kanalite laienedes hakkasid kasutajad juurutama online-video teenuseid. Loomulikult nõuab videosisu võrreldes tavapärase sisu (pildid, tekst, CSS või JS-kood) palju suuremat läbilaskevõimet.

Kui üritate voogedastada videot korraga paljudele klientidele ühest serverist, siis tõenäoliselt muutub serveri Interneti-kanal kitsaskohaks. Tüüpilise serveri kanali blokeerimiseks on sageli piisav vaid mõni tuhat voogu. Loomulikult võivad olla ka teised ressursipiirangud, kuid hetkel need ei ole olulised. Samuti on oluline, et serveri kanali laiendamine on liiga kallis (mõnikord isegi võimatu) ning see ei ole mõistlik. Koormus kanalile voogedastuste ajal on tsükliline.

CDN lahendab eraldi serveri ribalaiuse probleemi suurepäraselt. Klientide ühendus ei toimu otse serveriga, vaid CDN-võrgu sõlmedega. Ideaalsetes tingimustes saadab server ühe voogude sõlmele CDN, ning sealt edasi kasutab võrk oma ressursse selle voogude edastamiseks paljudele kasutajatele. Majanduslikust mõttes maksame ainult tegelikult kasutatud ressursside eest (see võib olla ribalaius või liiklus) ja saame suurepärase skaleeritavuse meie teenusele. CDN-i kasutamine raskete sisu edastamiseks on täiesti mõistlik ja õigustatud. Siiski väärib märkimist, et suurimad tegijad selles valdkonnas (nt Netflix) ehitavad oma CDN-e, asemel et kasutada suuri ärilisi CDN-e (Akamai, Cloudflare, Fastly jne).

Veebiarenduse edenemisega on veebirakendused muutunud keerukamaks ja raskemaks. Esiplaanile on kerkinud laadimiskiirus. Veebilehtede kiirusentusiastid on kiiresti tuvastanud mitmeid põhiseid probleeme, mis põhjustavad lehtede aeglast laadimist. Üks neist on võrgu viivitused (RTT — round trip time ehk ping'i aeg). Viivitused mõjutavad paljusid protsesse veebilehe laadimisel: TCP-ühenduse loomist, TLS-seansi algatamist, iga eraldi ressursi (pilt, JS-fail, HTML-dokument jne) laadimist.

Probleem süvenes veelgi, kuna HTTP/1.1 protokolli kasutamise korral (enne SPDY, QUIC ja HTTP/2 ilmumist oli see ainus variant) avab brauser kuni 6 TCP-ühendust ühe hostiga. See kõik tõi kaasa ühenduse seiskumise ja kanalite läbilaskevõime ebaefektiivse kasutamise. Probleem lahendati osaliselt domeenide šardimisega – lisahostide loomisega ühenduste arvu piiri ületamiseks.

Siin ilmneb CDN teine suutlikkus – viivituste (RTT) vähenemine, mis tuleneb suurest punktide arvust ja sõlmede lähedusest kasutajale. Siin mängib kaugus otsustavat rolli: valguse kiirus on piiratud (umbes 200 000 km/s kiudoptilises juhis). See tähendab, et iga 1000 km teekond lisab 5 ms viivitust või 10 ms RTT-d. Need on minimaalsed edastusaja kulud, kuna on veel viivitusi vahepealses seadmes. Kuna CDN suudab tavaliselt objekte oma serveurites vahemällu salvestada, saame kasu nende objektide laadimise korraldamisest CDN-i kaudu. Selleks on vajalikud tingimused: objekti olemasolu vahemälus ja CDN-i punkti lähedus kasutajale võrreldes veebirakenduse serveriga (origin server). Oluline on mõista: CDN-i sõlme geograafiline lähedus ei garanteeri madalaid viivitusi. Maršrutimine kliendi ja CDN-i vahel võib olla seatud nii, et klient ühendub serveriga teises riigis, võib-olla isegi teisel mandril. Siin astuvad mängu sideoperaatorite ja CDN-i teenusevaheline suhete tulemus (peerimine, ühenduste olemasolu, osalemine IX jne) ja CDN-i enda liiklusmarshrutimise poliitika. Näiteks, Cloudflare, kasutades kahte algplaani (tasuta ja odav), ei garanteeri sisu edastamist lähimast sõlmest – hosti valik tehakse minimaalsete kulude saavutamiseks.

Paljusid juhtivaid internetifirmasid huvitab veebiarendajate ja teenuste omanike seas veebisaitide laadimise ja töötamise kiirus. Nende seas on Yahoo (Yslow tööriist), AOL (WebPageTest) ja Google (Page Speed Insights teenus), kes arendavad oma soovitusi saitide kiirendamiseks (ennekõike puudutavad need kliendi optimeerimist). Hiljem ilmuvad uusi tööriistu saidikiiruseteste, mis pakuvad samuti nõuandeid saidi kiirusest. Igas neist teenustest või pistikprogrammidest on üks ja sama soovitus: „Kasutage CDN-i“. CDN-i efekti selgitamiseks viidatakse tavaliselt võrgu viivituste vähenemisele. Kahjuks ei ole kõik valmis uurima, kuidas täpselt saavutatakse CDN-i kiirusetõste ja kuidas seda mõõta saab, seega võetakse soovitus usaldusena ja seda kasutatakse kui postulaati. Tegelikult ei ole kõik CDN-id võrdselt kasulikud.

CDN-i kasutamine täna

CDN-ide rakendamise kasulikkuse hindamiseks tuleb need klassifitseerida. Mida saab praegu praktikas kohata (juhud sulgudes ei ole muidugi ammendavad):

1. Tasuta CDN-i JS-raamatukogude edastamiseks (MaxCDN, Google, Yandex).
2. CDN teenused kliendi optimeerimiseks (nt Google Fonts fondide jaoks, Cloudinary, Cloudimage piltide jaoks).
3. CDN staatika ja ressursside optimeerimiseks CMS-is (saadaval Bitrixis, WordPressis ja teistes).
4. Üldotstarbeline CDN (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN saitide kiirendamiseks (Cloudflare, Imperva, Airi).

Peamine erinevus nende tüüpide vahel on järgmine: milline osa liiklusest kulgeb läbi CDN-i. Tüübid 1-3 edastavad ainult osa sisust: ühest päringust kuni mitme kümne (tavaliselt piltideni). Tüübid 4 ja 5 on liikluse täielik edastamine läbi CDN-i.

Tõlkes tähendab see ühenduste arvu, mida kasutatakse saidi laadimiseks. HTTP/2 kasutamisel kasutame ühte TCP-ühendust hostname'iga igasuguste päringute töötlemiseks. Kui jagame ressursid põhihostiga (originaal) ja CDN-i, peame päringud levitama mitme domeeni vahel ja looma mitu TCP-ühendust. Halvimal juhul on see: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Selle valemi sees ei arvestata mobiilsete võrkude viivitusi seadme raadiokanalite aktiveerimisel (kui see ei olnud aktiivne) ning viivitusi mobiilitornis.

Nii see välja näeb veebisaidi laadimislangu kujul (CDNi ühenduse viivitused on esile tõstetud, kui RTT on 150 ms):

Kui CDN katab kogu veebisaidi liikluse (välja arvatud kolmandate osapoolte teenused), saame kasutada ühte TCP-ühendust, säästes viivitusi täiendavatehostide ühendamise pealt. Loomulikult kehtib see HTTP/2 ühenduste kohta.

Edasised erinevused sõltuvad konkreetsest CDN-funktsionaalsusest – esimese tüübi puhul on see lihtsalt hõbustamise. staatiline fail, viienda tüübi puhul on see mitme tüüpi sisu kohandamine veebisaidil optimeerimise eesmärgil.

CDN-i võimalused veebisaidi kiirusel.

Kirjeldame CDN-i võimaluste täielikku spektrit veebisaidi kiirusel, ilma et vaataksime ühegi CDN-i eri tüübi funktsioone, ja seejärel vaatame, mis sellest on ellu viidud igas neist.

1. Tekstiresursside tihendamine.

Kõige aluslikum ja arusaadavam võimalus, siiski on tihti kehvasti ellu viidud. Kõik CDN-id deklareerivad tihendamise kui kiirusfunktsiooni. Kuid kui vaadata lähemalt, ilmnevad puudujäägid:

• võivad kasutada madalaid määrasid dünaamiliseks tihendamiseks – 5-6 (näiteks gzipi maksimaalne tase on 9);
• staatilises tihenduses (vahemälus olevad failid) ei kasutata täiendavaid võimalusi (nt zopfi või brotli astmes 11)
• brotli efektiivne tihendamine ei ole toetatud (sääst umbes 20% võrreldes gzip'iga).

Kui kasutate CDN-i, tasub kontrollida neid punkte: võtke fail, mis tuli CDN-ilt, fikseerige selle suurus tihendatud kujul ja tihendage see käsitsi võrdlemiseks (võite kasutada mõnda veebiteenust brotli toetusega, näiteks kõikssqueezed.ee).

2. Kliendivahendite vahemälupäiste seadistamine

Samuti lihtne funktsioon kiirusel: seadke vahemälupäised sisu kliendivahemäluks (brauseri jaoks). Kõige asjakohasem vahemälupäis on cache-control, vananenud – expires. Täiendavalt võib kasutada Etag'i. Peamine on see, et cache-control'i max-age oleks piisavalt suur (üle kuu) ja kui olete valmis ressursi maksimaalselt rangelt vahemällu salvestama, võite lisada võimaluse immutable.

CDN võib alandada max-age väärtust, sundides kasutajat sagedamini staatikat uuesti laadima. Siit tulenevad põhjused: soov suurendada võrgu liiklust või tõsta ühilduvust saitidega, mis ei oska vahemälu tühjendada – ei ole selged. Näiteks Cloudflare'i vahemälu aeg on vaikimisi 1 tund, mis on muutumatute staatiliste failide jaoks väga vähe.

3. Piltide optimeerimine

Kuna CDN täidab vahemälu ja piltide edastamise funktsioone, oleks mõistlik optimeerida need CDN-i poolel ja sellisel kujul kasutajatele edastada. Koheselt tuleb märkida, et see võimalus on saadaval ainult CDN-de tüüpidele 2, 3 ja 5.

Pilti saab optimeerida erinevate meetoditega: kasutades edasijõudnud kokkusurumisvorminguid (näiteks WebP), tõhusamaid kodeerijaid (MozJPEG) või lihtsalt eemaldades liigsed metaandmed.

Üldiselt on olemas kaks tüüpi optimeerimisi: kvaliteedi kadumisega ja ilma kvaliteedi kadumiseta. CDN-id püüavad tavaliselt kasutada kaotamatut optimeerimist, et vältida võimalikke kliendikaebusi piltide kvaliteedi muutumise üle. Sellistes tingimustes on kasu minimaalne. Tõelisuses ületab JPEG kvaliteedi tase sageli vajalikku taset ning seetõttu võib julgelt teostada uuesti tihendamist madalama kvaliteediga, ilma et see kahjustaks kasutajate vastuvõttu. Teisest küljest on raske määrata kvaliteeditaset ja seadeid universaalselt kõigi võimalike veebirakenduste jaoks, mistõttu kasutavad CDN-id konservatiivsemaid seadeid võrreldes nende seadistustega, mida võiks rakendada konteksti arvestades (piltide eesmärk, veebirakenduse tüüp jne ).

4. TLS-ühenduse optimeerimine

Enamik tänapäevasest liiklusest edastatakse TLS-ühenduste kaudu, mis tähendab, et me kulutame lisandunud aega TLS-i genereerimisele. Viimastel aegadel on välja töötatud uusi tehnoloogiaid selle protsessi kiirendamiseks. Näiteks on see EC-krüptograafia, TLS 1.3, sessioonide vahemälu ja sessioonipiletid, riistvaraline krüptimise kiirus (AES-NI) jne. Õige TLS-i seadistamine võimaldab vähendada ühenduse aega kuni 0-1 RTT (ilma DNS ja TCP-ta).

Kaasaegse tarkvara olemasolul ei ole selliste praktikate rakendamine omaressurssides keeruline.

Kaugelki kõik CDN-id ei rakenda parimaid TLS-i praktikaid; seda saab kontrollida TLS-ühenduse aja mõõtmisega (näiteks Webpagetest). Uue ühenduse ideaalne olek on 1 RTT, 2 RTT on keskmine tase, 3 RTT ja rohkem on halb.

Samuti tasub märkida, et isegi kui kasutame TLS-i CDN-i tasemel, peab server, kus asub meie veebirakendus, samuti TLS-i töötlema, kuid CDN-i poolt, kuna liiklus serveri ja CDN-i vahel toimub avalikus võrgus. Halvemal juhul saame kahekordse TLS-ühenduse viivituse (esimene CDN-i hostiga, teine tema ja meie serveri vahel).

Mõnede rakenduste puhul tasub pöörata tähelepanu turvaküsimustele: tavaliselt dekodeeritakse liiklus CDN-sõlmedes, mis võib võimaldada liikluse pealtkuulamist. Variante, mis töötavad ilma liikluse paljastamata, pakutakse tavaliselt tipptasemel plaanides eraldi tasu eest.

5. Ühenduse latentsuse vähendamine

CDN-i peamine eelis, millest kõik räägivad: madalad latentsusajad (lühike kaugus) CDN-i hosti ja kasutaja vahel. Seda saavutatakse geograafiliselt jaotatud võrgu arhitektuuri loomisega, kus hostid asuvad kasutajate kontsentratsioonikohtades (linnaosades, vahetuspunktides jne).

Praktikas võivad erinevate võrkude prioriteedid olla konkreetses piirkonnas. Näiteks Venemaa CDN-idel on Venemaal rohkem kohaloleku kohti. Ameerika oma arendavad peamiselt võrku USA-s. Näiteks üks suurimaid CDN-e, Cloudflare, omab Venemaal ainult 2 punkti — Moskvas ja Peterburis. See tähendab, et maksimaalselt saame kokku hoida umbes 10 ms latentsust võrreldes otsese majutamisega Moskvas.

Enamik Lääne CDN-e ei oma Venemaal punktide olemasolu. Nende ühendamine võib vaid suurendada viivitusi teie Vene publikule.

6. Sisu optimeerimine (minifitseerimine, struktuurimuudatused)

Kõige keerulisem ja tehnoloogilisem punkt. Sisu muutmine edastamise ajal võib olla väga riskantne. Isegi minifitseerimise puhul: algkoodi vähendamine (liigsete tühikute, ebaoluliste konstruktsioonide jne tõttu) võib mõjutada selle toimivust. Räägime tõsistest muudatustest – JS-koodi viimine HTML-i lõppu, failide ühinemine ja sarnased – risk rikkuda saidi funktsionaalsust on veelgi suurem.

Seetõttu tegelevad ainult mõned 5. tüüpi CDN-id sellega. Loomulikult ei saa kõiki mugavusi, mis kiirusest mõjutavad, automatiseerida – vajalik on käsitsi analüüs ja optimeerimine. Näiteks kasutamata või dubleeritud koodi eemaldamine kuulub just käsitööülesannete alla.

Reeglina juhitakse kõiki selliseid optimeerimisi seadete kaudu ja kõige ohtlikumad on vaikimisi keelatud.

Kiirenduse võimaluste tugi CDN tüüpide kaudu

Vaatame siis, milliseid võimalusi erinevad CDN-tüübid kiirusprobleemide lahendamiseks pakuvad.

Mugavuse huvides korratakse klassifikatsiooni.

1. Tasuta CDN-i JS-raamatukogude edastamiseks (MaxCDN, Google, Yandex).
2. CDN teenused kliendi optimeerimiseks (nt Google Fonts fondide jaoks, Cloudinary, Cloudimage piltide jaoks).
3. CDN staatika ja ressursside optimeerimiseks CMS-is (saadaval Bitrixis, WordPressis ja teistes).
4. Üldotstarbeline CDN (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN saitide kiirendamiseks (Cloudflare, Imperva, Airi).

Nüüd seome funktsioonid ja CDN-tüübid kokku.

Võimalus
Tüüp 1
Tüüp 2
Tüüp 3
Tüüp 4
Tüüp 5

Teksti kokkusurumine
+–
–
+–
+–
+

Vahemälu pealkirjad
+
+
+
+
+

Pildid
–
+–
+–
–
+

TLS
–
–
–
+–
+

Viivitused
–
–
–
+
+

Sisu
–
–
–
–
+

Selles tabelis tähistab '+' täielikku toetust, '–' puudumist ja '+–' osalist toetust. Loomulikult võivad tegelikud tulemused tabelist erineda (näiteks võib mõni üldine CDN rakendada pildistamise optimeerimise funktsioone), kuid see on üldise arusaama saamiseks kasulik.

Kokkuvõte

Loodetavasti annab see artikkel teile selgema ettekujutuse soovitusest 'kasutage CDN-i', et kiirusprobleeme lahendada.

Nagu igas asjas, ei tohi usaldada ükskõik millise teenuse turunduslubadusi. Efekti tuleb mõõta ja kontrollida reaalses keskkonnas. Kui juba kasutate mõnda CDN-i, kontrollige selle efektiivsust artiklis kirjeldatud kriteeriumide alusel.

Võib-olla aeglustab CDN-i kasutamine praegu teie veebisaidi laadimist.

Üldise soovituse jaoks võib jääda järgmistele punktidele: uurige oma sihtrühma, määrake nende geograafilised raamid. Kui teie põhi sihtrühm asub 1-2 tuhande kilomeetri raadiuses, ei vaja te CDN-i peamise eesmärgi – viivituste vähendamise – saavutamiseks. Selle asemel võite paigutada oma serveri lähemale kasutajatele ja seadistada selle korralikult, saades kõik optimeerimised, mis on artiklis kirjeldatud (tasuta ja pidevalt).

Kui teie sihtrühm on tõeliselt geograafiliselt hajutatud (raadius üle 3000 kilomeetri), siis kvaliteetse CDN-i kasutamine on tõeliselt kasulik. Siiski tuleb eelnevalt mõista, mida täpselt teie CDN kiirendab (vt võimaluste tabelit ja nende kirjeldust). Veebisaidi kiirendamine on siiski kompleksne ülesanne, mida ei lahenda CDN-i ühendamine. Lisaks mainitud optimeerimisele jäävad kõige efektiivsemad kiirusmeetodid CDN-i alt välja: serveripoolne optimeerimine, edasijõudnud muudatused kliendipooles (kasutamata koodi eemaldamine, renderdamisprotsessi optimeerimine, sisu, fontide ja kohandatavuse käsitlemine jne).

Allikas: habr.com