[Ära] kasuta CDN-i

Peaaegu igas artiklis või tööriistas, mis käsitleb veebilehtede kiirusoptimeerimist, on tagasihoidlik punkt „kasutage CDN-i”. Tegelikult on CDN sisu edastamise võrk. Meie, ettevõttes „Metod Lab”, kohtume sageli klientide küsimustega selle teema kohta; mõned aktiveerivad CDN-i isegi ise. Selle artikli eesmärk on arutada, milliseid eeliseid võib CDN pakkuda veebilehe laadimiskiirusest, millised probleemid võivad tekkida ja millal on CDN-i kasutamine õigustatud.

Pildil kaardistatud latentsus on põhjustatud CDN-i kasutamisest.

Enne kui liigume edasi

Nagu paljude tehnoloogiate puhul, tekkisid CDN-id vajadusest. Internetikanalite arengu käigus ilmnesid veebivideo teenused. Loomulikult nõuab videosisu oluliselt suuremat läbilaskevõimet võrreldes tavalise veebisisuga (pildid, tekst ning CSS või JS-kood).

Kui proovida edastada videovoogu paljudele klientidele ühest serverist, on kitsaskohaks tõenäoliselt serveri internetikanal. Reeglina piisab mõnest tuhandest voost, et serveri tüüpiline kanal ummistuda. Loomulikult võivad olla ka teised ressursside piirangud, kuid need pole nüüd nii olulised. Samuti on oluline, et serveri kanali laiendamine on liiga kallis (mõnikord isegi võimatu) ning mitteotstarbekas. Koormus kanalil edastuste käigus on tsükliline.

CDN lahendab suure serveri kanali piirangu probleemi suurepäraselt. Kliendid ei ühendust serveriga otse, vaid CDN-i võrgusõlmedega. Ideaalsetes tingimustes edastab server ühe voolu CDN-i sõlmele ning edasi kasutab võrk oma ressursse selle voolu edastamiseks paljudele kasutajatele. Majanduslikult maksame ainult reaalselt tarbitud ressursside (see võib olla läbilaskevõime või traffic) eest ja saame suurepärase meie teenuse skaleeritavuse. CDN-i kasutamine suure sisu edastamiseks on täiesti õigustatud ja loogiline. Siiski tasub märkida, et suurimad mängijad selles valdkonnas (nt Netflix) ehitavad oma CDN-e, selle asemel et kasutada suuri kommertsd CDN-e (Akamai, Cloudflare, Fastly jne).

Veeb arendamisega koos on veebirakendused muutunud kõik keerukamaks ja raskemaks. Probleem, mis tõusis esikohale, on laadimiskiirus. Veebilehtede kiirusentusiastid tuvastasid üsna kiiresti mitu peamist probleemi, mis põhjustas veebilehtede aeglast laadimist. Üks neist oli võrgu latentsus (RTT – round trip time ehk ping-aeg). Latentsus mõjutab mitmeid protsesse veebilehe laadimisel: TCP-ühenduse loomine, TLS-seansi käivitamine, iga eraldi ressursi (pilt, JS-fail, HTML-dokument jne) laadimine.

Probleemi süvendas see, et HTTP/1.1 protokolli kasutamisel (kuni SPDY, QUIC ja HTTP/2 ilmumiseni oli see ainus valik) avavad brauserid mitte rohkem kui 6 TCP-ühendust ühe hosti juurde. See kõik viis ühenduse seiskumiseni ja ebaefektiivse läbilaskevõime kasutamiseni. Probleem lahendati osaliselt domeenide jagamise kaudu – lisahostide loomisega, et ületada ühenduste arvu piirangut.

Siin tuleb mängu CDN teine võime – latentsuse (RTT) vähendamine äärmiselt paljude punktide ja node'ide läheduse tõttu kasutajale. Siin mängib kaugus otsustavat rolli: valguse kiirus on piiratud (umbes 200 000 km/s optilise kiudude kaudu). Seega lisab iga 1000 km teekond 5 ms latentsust või 10 ms RTT-sse. Need on minimaalsed ajakulu edastamiseks, kuna on veel viivitused vahe- seadmetes. Kuna CDN suudab tavaliselt esemeid oma serverites vahemällu salvestada, saame kasu nende objektide laadimisest läbi CDN-i. Selle saavutamiseks on vajalikud tingimused: objekti olemasolu vahemälus, CDN punkti lähedus kasutajale võrreldes veebirakenduse serveriga (origin server). Oluline on mõista: geograafiline lähedus CDN-i sõlmele ei garanteeri madalaid latentsusi. Tee jaotamine kliendi ja CDN-i vahel võib olla üles ehitatud nii, et klient ühendub hostiga teises riigis või isegi teisel mandril. Siin tulevad mängu sideoperaatorite ja CDN teenuse suhted (peering, ühenduste olemasolu, osalemine IX jne) ning CDN-i enda liikluse marsruutimise poliitika. Näiteks Cloudflare ei garanteeri oma algsete kahe plaani (tasuta ja odav) kasutamise korral sisu edastamist lähimast sõlmest – hosti valik toimub minimaalsete kulude saavutamise nimel.

Paljud juhtivad internetifirmad köidavad avalikkuse (veebiarendajate ja teenusepakkujate) tähelepanu veebilehtede laadimiskiirusest ja toimimisest. Nende hulgas on Yahoo (Yslow tööriist), AOL (WebPageTest) ja Google (Page Speed Insights teenus), mis arendavad oma soovitusi veebilehtede kiirendamiseks (peamiselt kliendi optimeerimise kohta). Ajan jooksul ilmnevad uued veebilehtede kiirusetõestamisvahendid, mis jagavad samuti nõuandeid kiirusetõstmiseks. Igas nendes teenustes või pluginate seas on muutumatu soovitus „Kasutage CDN-i“. CDN-i efekti selgitamiseks tuuakse tavaliselt välja võrgu latentsuse vähenemine. Kahjuks ei ole kõik suutnud aru saada, kuidas täpselt saavutatakse CDN-i kiirusetõsteefekt ja kuidas seda mõõta, nii et soovitus võetakse usaldusena ning kasutatakse postulaadina. Tegelikult ei ole kõik CDN-id võrdselt kasulikud.

CDN-i kasutamine täna

CDN-ide kasutusmugavuse hindamiseks tuleks neid klassifitseerida. Mida saab praegu praktikas kohata (näidised sulgudes ei ole loomulikult ammendavad):

1. Tasuta CDN-id JS-teekide jagamiseks (MaxCDN, Google, Yandex).
2. CDN-id kliendi optimeerimise teenustele (näiteks Google Fonts fontide jaoks, Cloudinary, Cloudimage piltide jaoks).
3. CDN-id staatilistele elementidele ja ressursside optimeerimisele CMS-is (leitud Bitrixis, WordPressis ja teistes).
4. Üldotstarbelised CDN-id (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN-id veebilehtede kiirendamiseks (Cloudflare, Imperva, Airi).

Peamine erinevus nende tüüpide vahel seisneb järgmis: kui suur osa liiklusest läbib CDN-i. Tüübid 1-3 toimetavad ainult osa sisust: ühest päringust mitmekümne eri vormini (tavaliselt piltide jaoks). Tüübid 4 ja 5 on täielik liikluse vahendamine CDN-i kaudu.

Praktikas tähendab see, kui palju ühendusi kasutatakse veebilehe laadimiseks. HTTP/2 kasutamisel kasutame ühte TCP-ühendust hostiga, et hallata igasuguseid päringuid. Kui jagame ressursid peamise hosti (origin) ja CDN-i vahel, tuleb päringud jaotada mitme domeeni vahel ja luua mitu TCP-ühendust. Halvimal juhul see tähendab: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Selles valemis ei arvestata mobiilivõrkude viivitusi seadme raadiosidekanali aktiveerimisel (kui see ei olnud aktiivne) ja viivitusi mobiilitornis.

Nii see välja näeb veebilehe laadimisvees (CDN-iga ühenduse viivituse väärtused on 150 ms):

Kui CDN katab kogu veebilehe liikluse (välja arvatud kolmandate osapoolte teenused), siis saame kasutada ühte TCP-ühendust, säästes viivitusi, mis on seotud täiendavate hostidega ühendamisega. Loomulikult kehtib see HTTP/2-ühenduste korral.

Edasiõiendused määratakse kindlaks konkreetse CDN funktsionaalsusega – esimesel tüübil on see vaid hostimine staatiline fail, viienda puhul on see mitu tüüpi veebisisu muutmine optimeerimise eesmärgil.

CDN-i võimalused veebilehe kiirusel

Kuna arutame CDN-i täielikku potentsiaali veebilehtede kiirusel, mitte lähtudes erinevatest tüüpidest, vaatame, mis on igaühes ellu viidud.

1. Tekstide ressursside kokkusurumine

Kõige elementaarsem ja arusaadavam võimalus, kuid samas on see sageli halvasti rakendatud. Kõik CDN-id kuulutavad oma funktsiooni „kiirus“, kuid süvitsi vaadates selguvad puudused:

• kasutatakse madalaid kraade dünaamiliseks kokkusurumiseks – 5-6 (näiteks gzipi max – 9);
• staatilises kokkusurumises (failid vahemälus) ei kasutata täiendavaid võimalusi (näiteks zopfi või brotli 11 kraadiga)
• pole tõhusat brotli kokkusurumist (kokkuhoid umbes 20% võrreldes gzipiga).

Kui kasutate CDN-i, tasub kontrollida neid punkte: võtke fail, mis tuli CDN-ilt, registreerige selle suurus kokkusurutud kujul ja proovige seda ise uuesti suruda võrdlemiseks (võite kasutada mõnda veebiteenust brotli toetusega, näiteks kõiksuruda.ee).

2. Kliendi vahemälu päiste seadmine

Samuti lihtne funktsioon kiirusel: seada sisu vahemälumise päised (brauserile). Kõige olulisem päis on cache-control, aegunud – expires. Täiendavalt võib kasutada Etag-täisarvu. Peamine on see, et cache-controli max-age oleks piisavalt pikk (alates kuust ja enam), kui olete valmis ressurssi võimalikult rangelt vahemälustama, saate lisada valiku immutable.

CDN-id võivad alandada max-age väärtust, sundides kasutajat sagedamini staatilisi faile uuesti alla laadima. Miks see nii on: kas soovist suurendada võrgu liiklust või ühilduvuse parandamisest veebisaitidega, mis ei oska vahemälu tühjendada – pole selge. Näiteks, Cloudflare'i vaikimisi vahemälu aeg on 1 tund, mis on muutumatute staatiliste failide jaoks väga lühike.

3. Piltide optimeerimine

Kuna CDN võtab enda peale piltide vahemälestamise ja edastamise funktsioonid, oleks mõistlik optimeerida need CDN-is ja sellisel kujul edastada kasutajatele. Tuleb kohe märkida, et see võimalus on saadaval ainult CDN-tüüpide 2, 3 ja 5 puhul.

Pilti on võimalik optimeerida mitmel viisil: kasutades arenenumaid tihendamisformaatide (näiteks WebP), tõhusamaid kodeerijaid (MozJPEG) või lihtsalt eemaldades liigsed metaandmed.

Üldiselt on selliste optimeerimiste puhul kaks tüüpi: kvaliteedikaotuseta ja kvaliteedikadudega. CDN-d püüavad tavaliselt kasutada kvaliteedikaotuseta optimeerimist – et vältida võimalikke kaebusi klientidelt piltide kvaliteedi muutumise kohta. Nendes tingimustes on kasu minimaalne. Tegelikult ületab JPEG kvaliteedi tase sageli vajalikku ja võib julgelt teha rekodeerimise madalama kvaliteedihindega, ilma et kasutajate tajumine kannataks. Teisest küljest on kvaliteedi taseme ja seadistuste määramine universaalselt kõigi võimalike veebirakenduste jaoks keeruline, seega kasutavad CDN-d konservatiivsemaid seadeid võrreldes nendega, mida võiks rakendada konteksti arvesse võttes (piltide eesmärk, veebirakenduse tüüp jne).

4. TLS-ühenduse optimeerimine

Enamik liiklust edastatakse täna TLS-ühenduste kaudu, seega kulutame lisa aega TLS-i kokkulepete tegemiseks. Viimasel ajal on arendatud uusi tehnoloogiaid selle protsessi kiirendamiseks. Näiteks EC-krüptograafia, TLS 1.3, sessioonide vahemälu ja piletid (session tickets), krüpteerimise riistvara kiirus (AES-NI) jne. Õige TLS-i seadistamine võimaldab vähendada ühendusaega 0–1 RTT (ilma DNS-i ja TCP-ta).

Kaasaegsete tarkvarade olemasolu korral pole selliste praktikate rakendamine enda võimsustes keeruline.

Kaugelgi pole kõik CDN-id rakendavad parimaid praktikaid TLS-i osas, mida saab kontrollida TLS-ühenduse aja mõõtmise teel (näiteks Webpagetestis). Ideaalne uue ühenduse puhul on 1RTT, 2RTT - keskmine tase, 3RTT ja rohkem - kehv.

Samuti tuleb märkida, et isegi kui kasutatakse TLS-i tasemel CDN-is, peab server meie veebirakendusega samuti TLS-i käsitlema, kuid CDN-i poolelt, kuna liiklus serveri ja CDN-i vahel liigub avalikus võrgus. Halvimal juhul saame kahekordse TLS-ühenduse viivituse (esimene CDN-i hosti, teine tema ja meie serveri vahel).

Mõnede rakenduste puhul tasub tähelepanu pöörata turvaküsimustele: tavaliselt dekodeeritakse liiklus CDN-i sõlmedes, mis on potentsiaalne võimalus liikluse pealtkuulamiseks. Liikluseta töötamise variant pakutakse tavaliselt tipptasemel plaanides eritasu eest.

5. Ühenduse viivituste vähendamine

CDN-i peamine eelis, millest kõik räägivad: madalad viivitused (väiksem kaugus) CDN-i hosti ja kasutaja vahel. See saavutatakse geograafiliselt hajutatud võrguarhitektuuri loomise teel, kus hostid asuvad kasutajate kontsentratsiooni punkti (linnad, liikluse vahetuspunkid ja t. d.).

Praktikas võivad erinevate võrkude prioriteedid olla konkreetses piirkonnas. Näiteks on Venemaa CDN-idel Venemaal rohkem kohaloleku punkte. Ameerika CDN-id arendavad eeskätt oma võrku USA-s. Näiteks üks suurimaid CDN-e Cloudflare'il on Venemaal vaid 2 punkti - Moskvas ja Peterburis. See tähendab, et maksimaalselt saame praeguse asukoha äärde säästa umbes 10 ms viivitust võrreldes otse Moskvas majutamisega.

Enamik lääne CDN-e ei oma Venemaal üldse kohaloleku punkte. Nende juurde ühendudes võid suurendada viivitusi oma Venemaa publikule.

6. Sisu optimeerimine (minifitseerimine, struktuurilised muudatused)

Kõige keerulisem ja tehnilisem punkt. Sisu muutmine tarnimise ajal võib olla väga riskantne. Isegi kui rääkida minifitseerimisest: algse koodi vähendamine (ülearuste vahede, ebaoluliste struktuuride jms tõttu) võib mõjutada selle töövõimet. Kui rääkida tõsisematest muudatustest – JS-koodi seadmine HTML-i lõppu, failide ühendamine ja sarnased – on risk veebisaidi funktsionaalsuse rikkuda veelgi kõrgem.

Seetõttu tegelevad vaid mõned CDN-i tüübid 5 sellega. Loomulikult ei ole võimalik automatiseerida kõik nõutavad muudatused kiirusel – vajalik on käsitsi analüüs ja optimeerimine. Näiteks kõlbmatute või dubleeritud koodi eemaldamine kuulub just käsitööülesannete hulka.

Reeglina hallatakse kõiki sarnaseid optimeerimisi seadistuste kaudu ja kõige ohtlikumad on vaikimisi välja lülitatud.

Kiirendamisvõimaluste tugi CDN-tüüpide kaupa

Nii et vaatame, millised potentsiaalsed kiirusvõimalused erinevad CDN-tüübid pakuvad.

Oma mugavuse huvides kordame klassifikatsiooni.

1. Tasuta CDN-id JS-teekide jagamiseks (MaxCDN, Google, Yandex).
2. CDN-id kliendi optimeerimise teenustele (näiteks Google Fonts fontide jaoks, Cloudinary, Cloudimage piltide jaoks).
3. CDN-id staatilistele elementidele ja ressursside optimeerimisele CMS-is (leitud Bitrixis, WordPressis ja teistes).
4. Üldotstarbelised CDN-id (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN-id veebilehtede kiirendamiseks (Cloudflare, Imperva, Airi).

Nüüd seostame funktsioonid ja CDN-tüübid.

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

Teksti tihendamine
+–
–
+–
+–
+

Vahemälu päised
+
+
+
+
+

Pildid
–
+–
+–
–
+

TLS
–
–
–
+–
+

Viivitused
–
–
–
+
+

Sisu
–
–
–
–
+

Selles tabelis tähistab „+” täielikku toetust, „–” puudumist ja „+–” – osalist toetust. Loomulikult võivad selle tabeli osas reaalsuses esineda erandid (näiteks mõni universaalne CDN võib rakendada piltide optimeerimise funktsioone), kuid see on üldise arusaama jaoks kasulik.

Summary

Loodan, et pärast selle artikli lugemist on teil selgem arusaam soovitusest „kasutage CDN” oma veebisaitide kiirendamiseks.

Nagu iga asja puhul, ei tohiks uskuda ühegi teenuse turunduslubadusi. Tõhusust tuleb mõõta ja kontrollida reaalsetes tingimustes. Kui kasutate juba mõnda CDN-i, kontrollige selle efektiivsust artiklis toodud kriteeriumide järgi.

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

Üldise soovitusena võiks peatus olla järgmine: uurige oma sihtrühma, määratlege selle geograafilised piirid. Kui teie peamine sihtrühm on koondunud 1-2 tuhande kilomeetri raadiuses, ei vaja te CDN-i peamise eesmärgina – viivituste vähendamiseks. Selle asemel võite oma serveri kasutajatele lähemale paigutada ja seadistada selle korralikult, saades enamikku artiklis kirjeldatud optimeeringutest (tasuta ja pidevalt).

Kui teie sihtrühm on tõepoolest geograafiliselt jaotatud (raadius üle 3000 kilomeetri), siis kvaliteetse CDN-i kasutamine on tõeliselt kasulik. Siiski tuleb eelnevalt aru saada, mida täpselt teie CDN kiiruselt parandab (vt võimaluste tabelit ja nende kirjeldust). Veebilehe kiirus jääb siiski keeruliseks ülesandeks, mida ei saa lahendada lihtsalt CDN-i ühendamisega. Lisaks mainitud optimeerimistele jäävad CDN-ist välja kõige efektiivsemad kiirusetõstmismeetodid: serveri poole optimeerimine, arenenud muudatused kliendipoolel (kasutamata koodi eemaldamine, renderdamise protsessi optimeerimine, sisu, fondide, reageerimise ja muu töö jne).

Allikas: habr.com