🥇[Ärge] kasutage CDN-i

Peaaegu igal artiklil või saidi kiiruse optimeerimise tööriistal on tagasihoidlik klausel „kasuta CDN-i”. Üldiselt on CDN sisuedastusvõrk või sisuedastusvõrk. Meil Method Labis tekib sageli klientidelt selleteemalisi küsimusi; mõned neist võimaldavad oma CDN-i. Selle artikli eesmärk on mõista, mida CDN võib saidi laadimiskiiruse osas pakkuda, millised probleemid võivad tekkida ja millistel juhtudel on CDN-i kasutamine õigustatud.

Pildil ringiga märgitud viivitused on põhjustatud CDN-i kasutamisest.

Veidi ajalugu

Nagu paljud tehnoloogiad, tekkisid CDN-id vajadusest. Interneti-kanalite arenguga Interneti-kasutajate seas ilmusid veebipõhised videoteenused. Loomulikult nõuab videosisu võrreldes tavalise veebisaidi sisuga (pildid, tekst ja CSS- või JS-kood) suurusjärku rohkem ribalaiust.

Kui proovite ühest serverist videovoogu paralleelselt paljudele klientidele edastada, muutub kitsaskohaks suure tõenäosusega serveri Interneti-kanal. Tüüpilise serverikanali ummistumiseks piisab reeglina mõnest tuhandest lõimest. Muidugi võib olla ka muid ressursipiiranguid, kuid need pole praegu olulised. Samuti on oluline, et serverikanali laiendamine on liiga kallis (ja mõnikord võimatu) ja ka ebapraktiline. Kanali koormus ülekannete ajal on tsükliline.

Üksiku serveri kanali piiramise probleemi lahendab CDN suurepäraselt. Kliendid ei loo ühendust otse serveriga, vaid CDN-võrgu sõlmedega. Ideaalses olukorras saadab server ühe voo CDN-sõlme ja seejärel kasutab võrk oma ressursse selle voo edastamiseks paljudele kasutajatele. Majanduslikust seisukohast maksame ainult tegelikult tarbitud ressursside eest (see võib olla ribalaius või liiklus) ja saame oma teenuse suurepärase mastaapsuse. CDN-i kasutamine raske sisu edastamiseks on täiesti õigustatud ja loogiline. Kuigi väärib märkimist, et selle ruumi suurimad mängijad (nt Netflix) ehitavad oma CDN-e, selle asemel, et kasutada suuri kaubanduslikke CDN-e (Akamai, Cloudflare, Fastly jne).

Veebi arenedes on veebirakendused ise muutunud keerukamaks ja keerukamaks. Laadimiskiiruse probleem kerkis esile. Veebisaidi kiiruse entusiastid tuvastasid kiiresti mitu suurt probleemi, mis põhjustasid veebisaitide aeglase laadimise. Üks neist oli võrgu viivitused (RTT – ringreisi aeg või pingiaeg). Viivitused mõjutavad paljusid veebisaidi laadimise protsesse: TCP-ühenduse loomine, TLS-seansi käivitamine, iga üksiku ressursi (pilt, JS-fail, HTML-dokument jne) laadimine.

Probleemi süvendas asjaolu, et HTTP/1.1 protokolli kasutamisel (enne SPDY, QUIC ja HTTP/2 tulekut oli see ainuke võimalus) avavad brauserid ühe hostiga kuni 6 TCP-ühendust. Kõik see tõi kaasa ühenduse katkemise ja kanali ribalaiuse ebaefektiivse kasutamise. Probleemi lahendas osaliselt domeenide jagamine - täiendavate hostide loomine, et ületada ühenduste arvu piirang.

Siin ilmneb CDN-i teine võime – latentsuse (RTT) vähendamine, mis on tingitud punktide suurest arvust ja sõlmede lähedusest kasutajale. Siin mängib määravat rolli kaugus: valguse kiirus on piiratud (ligikaudu 200 000 km/sek optilises kius). See tähendab, et iga 1000 km läbisõit lisab RTT-le 5 ms viivitust või 10 ms. See on minimaalne edastamiseks vajalik aeg, kuna ka vaheseadmetes esineb viivitusi. Kuna CDN teab tavaliselt, kuidas oma serverites olevaid objekte vahemällu salvestada, saame kasu selliste objektide laadimisest CDN-i kaudu. Selleks vajalikud tingimused: objekti olemasolu vahemälus, CDN-punkti lähedus kasutajale võrreldes veebirakenduse serveriga (origin server). Oluline on mõista, et CDN-sõlme geograafiline lähedus ei taga madalat latentsust. Kliendi ja CDN-i vahelise marsruutimise saab üles ehitada nii, et klient loob ühenduse teises riigis ja võib-olla ka teisel kontinendil asuva hostiga. Siin tulevad mängu sideoperaatorite ja CDN-teenuse vahelised suhted (peering, ühendused, IX-s osalemine jne) ning CDN-i enda liikluse suunamise poliitika. Näiteks ei garanteeri Cloudflare kahe esialgse paketi (tasuta ja odav) kasutamisel sisu kohaletoimetamist lähimast hostist - host valitakse minimaalse kulu saavutamiseks.

Paljud juhtivad Interneti-ettevõtted äratavad avalikku huvi (veebiarendajad ja teenuste omanikud) laadimiskiiruse ja veebisaidi jõudluse teema vastu. Nende ettevõtete hulka kuuluvad Yahoo (Yslow tööriist), AOL (WebPageTest) ja Google (Page Speed Insights), kes töötavad välja oma soovitusi saitide kiirendamiseks (peamiselt on need seotud klientide optimeerimisega). Hiljem ilmuvad uued veebisaidi kiiruse testimise tööriistad, mis annavad näpunäiteid ka veebisaidi kiiruse suurendamiseks. Kõigil neil teenustel või pistikprogrammidel on järjepidev soovitus: „Kasutage CDN-i”. Võrgu latentsusaja vähenemist nimetatakse tavaliselt CDN-i mõju selgituseks. Kahjuks ei ole kõik valmis täpselt aru saama, kuidas CDN-i kiirendusefekt saavutatakse ja kuidas seda mõõta, seega lähtutakse soovitusest usust ja kasutatakse seda postulaadina. Tegelikult ei ole kõik CDN-id võrdsed.

CDN-i kasutamine täna

CDN-ide kasutamise kasulikkuse hindamiseks tuleb need klassifitseerida. Mida võib praegu praktikas leida (sulgudes olevad näited ei ole muidugi ammendavad):

Tasuta CDN JS-teekide levitamiseks (MaxCDN, Google. Yandex).
Klientide optimeerimise teenuste CDN (nt Google Fonts fontide jaoks, Cloudinary, Cloudimage piltide jaoks).
CDN staatiliseks ja ressursside optimeerimiseks CMS-is (saadaval Bitrixis, WordPressis ja teistes).
Üldotstarbeline CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN veebisaidi kiirendamiseks (Cloudflare, Imperva, Airi).

Peamine erinevus nende tüüpide vahel on see, kui suur osa liiklusest läbib CDN-i. Tüübid 1-3 on ainult osa sisu kohaletoimetamine: ühest päringust mitmekümneni (tavaliselt pildid). Tüübid 4 ja 5 on liikluse täielik puhverserver CDN-i kaudu.

Praktikas tähendab see ühenduste arvu, mida saidi laadimiseks kasutatakse. HTTP/2 puhul kasutame suvalise arvu päringute töötlemiseks ühte TCP-ühendust hostiga. Kui jagame ressursid põhihostiks (origin) ja CDN-iks, siis on vaja päringud jaotada mitme domeeni vahel ja luua mitu TCP ühendust. Halvim juhtum on: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. See valem ei võta arvesse mobiilsidevõrkude viivitusi seadme raadiokanali aktiveerimisel (kui see ei olnud aktiivne) ega viivitusi mobiilsidetornis.

Siin näeb see välja saidi laadimisjuga (CDN-iga ühenduse loomise latentsusajad on esile tõstetud RTT 150 ms juures):

Kui CDN katab kogu saidiliikluse (v.a kolmanda osapoole teenused), saame kasutada ühte TCP-ühendust, säästes viivitusi täiendavate hostidega ühenduse loomisel. Muidugi kehtib see HTTP/2 ühenduste kohta.

Täiendavaid erinevusi määrab konkreetse CDN-i funktsionaalsus - esimese tüübi puhul majutab see lihtsalt staatilist faili, viienda tüübi jaoks muudab see optimeerimise eesmärgil mitut tüüpi saidi sisu.

CDN-i võimalused veebisaidi kiirendamiseks

Kirjeldame kõiki CDN-i võimalusi saitide kiirendamiseks, arvestamata üksikute CDN-tüüpide funktsionaalsust, ja seejärel vaatame, mida neist igaühes rakendatakse.

1. Tekstiressursside tihendamine

Kõige elementaarsem ja arusaadavam funktsioon, kuid sageli halvasti rakendatud. Kõik CDN-id deklareerivad tihendamise olemasolu oma kiirendusfunktsioonina. Kuid kui vaatate üksikasjalikumalt, ilmnevad puudused:

dünaamilise tihendamise jaoks saab kasutada madalaid kraadi - 5-6 (näiteks gzipi puhul on maksimum 9);
staatiline pakkimine (vahemälus olevad failid) ei kasuta lisavõimalusi (nt zopfi või brotli astmega 11)
ei toeta tõhusat brotli tihendamist (sääst umbes 20% võrreldes gzipiga).

Kui kasutate CDN-i, tasub üle vaadata need mõned punktid: võtke CDN-ist pärit fail, salvestage selle tihendatud suurus ja tihendage see võrdluseks käsitsi (saate kasutada näiteks mõnda brotli toega võrguteenust vsszhat.rf).

2. Kliendi vahemällu salvestamise päiste seadistamine

Samuti lihtne kiirendamisfunktsioon: lisage kliendi (brauseri) sisu vahemällu salvestamiseks päised. Kõige uuem päis on cache-control, aegunud on aegunud. Lisaks saab kasutada Etag-i. Peaasi, et vahemälu juhtimise max-vanus oleks piisavalt suur (alates kuus või rohkem) Kui olete valmis ressurssi võimalikult kõvasti vahemällu salvestama, võite lisada muutumatu võimaluse.

CDN-id võivad alandada maksimaalse vanuse väärtust, sundides kasutajat staatilist sisu sagedamini uuesti laadima. Pole selge, millega see on seotud: soov suurendada võrguliiklust või suurendada ühilduvust saitidega, mis ei tea, kuidas vahemälu lähtestada. Näiteks Cloudflare'i päise vahemälu vaikeaeg on 1 tund, mis on muutumatute staatiliste andmete jaoks väga madal.

3. Pildi optimeerimine

Kuna CDN võtab enda peale piltide vahemällu salvestamise ja teenindamise funktsioonid, oleks loogiline neid CDN-i poolel optimeerida ja kasutajatele sellisel kujul serveerida. Teeme kohe reservatsiooni, et see funktsioon on saadaval ainult CDN-i tüüpide 2, 3 ja 5 jaoks.

Saate pilte optimeerida mitmel viisil: kasutades täiustatud tihendusvorminguid (nt WebP), tõhusamaid kodeerijaid (MozJPEG) või lihtsalt puhastades mittevajalikke metaandmeid.

Üldiselt on selliseid optimeerimisi kahte tüüpi: kvaliteedikaotusega ja ilma kvaliteedi kadumiseta. CDN-id püüavad tavaliselt kasutada kadudeta optimeerimist, et vältida võimalikke klientide kaebusi pildikvaliteedi muutuste kohta. Sellistes tingimustes on kasum minimaalne. Tegelikkuses on sageli JPEG-i kvaliteeditase palju kõrgem kui vaja ja saate ohutult uuesti tihendada madalama kvaliteeditasemega, ilma et see kahjustaks kasutajakogemust. Teisest küljest on kõigi võimalike veebirakenduste jaoks keeruline kvaliteeditaset ja seadeid universaalselt määrata, seetõttu kasutavad CDN-id konservatiivsemaid sätteid võrreldes nendega, mida saab konteksti (piltide otstarve, veebirakenduse tüüp) arvesse võttes rakendada. , jne.)

4. TLS-ühenduse optimeerimine

Suurem osa liiklusest toimub täna TLS-i ühenduste kaudu, mis tähendab, et kulutame TLS-i läbirääkimistele lisaaega. Hiljuti on selle protsessi kiirendamiseks välja töötatud uusi tehnoloogiaid. Näiteks on see EC krüptograafia, TLS 1.3, seansi vahemälu ja piletid, riistvara krüptimise kiirendus (AES-NI) jne. TLS-i õigesti seadistamine võib vähendada ühenduse aega 0-1 RTT-ni (arvestamata DNS-i ja TCP-d).

Kaasaegse tarkvaraga pole selliseid praktikaid iseseisvalt keeruline rakendada.

Mitte kõik CDN-id ei rakenda TLS-i parimaid tavasid; saate seda kontrollida, mõõtes TLS-i ühenduse aega (nt veebilehe testis). Ideaalne uueks ühenduseks - 1RTT, 2RTT - keskmine tase, 3RTT ja rohkem - halb.

Tähele tuleb panna ka seda, et isegi CDN-i tasemel TLS-i kasutades peab meie veebirakendusega server samuti TLS-i töötlema, kuid CDN-i poolelt, sest serveri ja CDN-i vaheline liiklus liigub avalikus võrgus. Halvimal juhul saame kahekordse TLS-i ühenduse viivituse (esimene CDN-i hosti, teine selle ja meie serveri vahel).

Mõne rakenduse puhul tasub tähelepanu pöörata turvaprobleemidele: liiklus dekrüpteeritakse tavaliselt CDN-i sõlmedes ja see on potentsiaalne võimalus liikluse pealtkuulamiseks. Liikluse avalikustamiseta töötamise võimalust pakutakse tavaliselt tipptariifiplaanides lisatasu eest.

5. Vähendage ühenduse viivitusi

CDN-i peamine eelis, millest kõik räägivad: väike latentsusaeg (väiksem vahemaa) CDN-i hosti ja kasutaja vahel. Saavutatakse geograafiliselt hajutatud võrguarhitektuuri loomisega, milles hostid asuvad kasutajate koondumispunktides (linnad, liikluse vahetuspunktid jne).

Praktikas võivad eri võrgustike prioriteedid olla kindlates piirkondades. Näiteks Venemaa CDN-idel on Venemaal rohkem kohalolekukohti. Ameerika omad hakkavad võrku arendama eelkõige USA-s. Näiteks ühel suurimal CDN Cloudflare'il on Venemaal vaid 2 punkti – Moskvas ja Peterburis. See tähendab, et saame maksimaalselt säästa umbes 10 ms latentsust võrreldes otsese paigutusega Moskvas.

Enamikul Lääne CDN-idel pole Venemaal punkte üldse. Nendega ühenduse loomisel saate oma vene publiku jaoks viivitusi ainult suurendada.

6. Sisu optimeerimine (vähendamine, struktuurimuudatused)

Kõige keerulisem ja tehnoloogiliselt arenenum punkt. Sisu muutmine kohaletoimetamise ajal võib olla väga riskantne. Isegi kui võtame minimeerimise: lähtekoodi vähendamine (lisate tühikute, ebaoluliste struktuuride jms tõttu) võib selle jõudlust mõjutada. Kui rääkida tõsisematest muudatustest - JS-koodi viimine HTML-i lõppu, failide liitmine jne -, on oht saidi funktsionaalsust häirida veelgi suurem.

Seetõttu teevad seda ainult mõned 5. tüüpi CDN-id. Loomulikult ei ole võimalik kõiki kiirendamiseks vajalikke muudatusi automatiseerida – vaja on käsitsi analüüsi ja optimeerimist. Näiteks kasutamata või dubleeriva koodi eemaldamine on käsitsi ülesanne.

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

Kiirendusvõimaluste tugi CDN-i tüübi järgi

Nii et vaatame, milliseid potentsiaalseid kiirendusvõimalusi eri tüüpi CDN-id pakuvad.

Mugavuse huvides kordame klassifikatsiooni.

Tasuta CDN JS-teekide levitamiseks (MaxCDN, Google. Yandex).
Klientide optimeerimise teenuste CDN (nt Google Fonts fontide jaoks, Cloudinary, Cloudimage piltide jaoks).
CDN staatiliseks ja ressursside optimeerimiseks CMS-is (saadaval Bitrixis, WordPressis ja teistes).
Üldotstarbeline CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN veebisaidi kiirendamiseks (Cloudflare, Imperva, Airi).

Võrdleme nüüd CDN-i funktsioone ja tüüpe.

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 kasutatakse tähist “+” täieliku toe tähistamiseks, “–” ei ole tugi ja “+-” on osaline tugi. Muidugi võib tegelikkuses esineda kõrvalekaldeid sellest tabelist (näiteks mõni üldotstarbeline CDN rakendab funktsioone piltide optimeerimiseks), kuid üldise idee jaoks on see kasulik.

Tulemused

Loodetavasti on teil pärast selle artikli lugemist selgem pilt soovitusest "kasutage CDN-i" oma saitide kiirendamiseks.

Nagu iga ettevõtte puhul, ei saa te uskuda ühegi teenuse turunduslubadusi. Mõju tuleb mõõta ja testida reaalsetes tingimustes. Kui kasutate juba CDN-i, kontrollige selle tõhusust artiklis kirjeldatud kriteeriumide alusel.

Võimalik, et praegune CDN-i kasutamine aeglustab teie saidi laadimisaega.

Üldise soovitusena saame keskenduda järgmisele: uurige oma vaatajaskonda, määrake selle geograafiline ulatus. Kui teie peamine vaatajaskond on koondunud 1–2 tuhande kilomeetri raadiusesse, ei vaja te CDN-i selle peamiseks otstarbeks - latentsusaja vähendamiseks. Selle asemel saate oma serveri kasutajatele lähemale paigutada ja selle õigesti konfigureerida, saades enamiku artiklis kirjeldatud optimeeringutest (tasuta ja püsiv).

Kui teie vaatajaskond on tõeliselt geograafiliselt jaotunud (raadius üle 3000 kilomeetri), on kvaliteetse CDN-i kasutamine tõesti kasulik. Siiski peate eelnevalt aru saama, mida täpselt teie CDN võib kiirendada (vt võimaluste tabelit ja nende kirjeldust). Veebisaidi kiirendamine on aga endiselt keeruline ülesanne, mida ei saa lahendada CDN-i ühendamisega. Lisaks ülaltoodud optimeerimistele jäävad CDN-i taha kõige tõhusamad kiirendamise vahendid: serveriosa optimeerimine, kliendiosa täpsemad muudatused (kasutamata koodi eemaldamine, renderdusprotsessi optimeerimine, töö sisuga, fontidega, kohanemisvõimega jne. )

Allikas: www.habr.com

[Ära] kasutage CDN-i