Beveik kiekviename svetainės greičio optimizavimo straipsnyje ar įrankyje yra kukli sąlyga „naudokite CDN“. Apskritai CDN yra turinio pristatymo tinklas arba turinio pristatymo tinklas. Mes, Method Lab, dažnai susiduriame su klientų klausimais šia tema, kai kurie iš jų įgalina savo CDN. Šio straipsnio tikslas – suprasti, ką CDN gali suteikti, kalbant apie svetainės įkėlimo greitį, kokių problemų gali kilti ir kokiais atvejais CDN naudojimas yra pateisinamas.
![[Ne] naudoti CDN](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Vėlavimai, pažymėti paveikslėlyje, atsiranda dėl CDN naudojimo.
Truputis istorijos
Kaip ir daugelis technologijų, CDN atsirado iš būtinybės. Plėtojant interneto kanalus tarp interneto vartotojų, atsirado internetinės vaizdo paslaugos. Natūralu, kad vaizdo įrašų turiniui reikia daug daugiau pralaidumo, palyginti su įprastu svetainės turiniu (nuotraukomis, tekstu ir CSS arba JS kodu).
Bandant transliuoti vaizdo srautą lygiagrečiai daugeliui klientų iš vieno serverio, serverio interneto kanalas greičiausiai taps kliūtimi. Paprastai pakanka kelių tūkstančių gijų, kad užkimštų tipinį serverio kanalą. Žinoma, gali būti ir kitų išteklių apribojimų, tačiau jie šiuo metu nėra svarbūs. Taip pat svarbu, kad serverio kanalo išplėtimas yra per brangus (o kartais ir neįmanomas), be to, nepraktiškas. Kanalo apkrova transliacijų metu bus cikliška.
CDN puikiai išsprendžia atskiro serverio kanalo ribojimo problemą. Klientai jungiasi ne tiesiogiai prie serverio, o prie CDN tinklo mazgų. Idealioje situacijoje serveris siunčia vieną srautą į CDN mazgą, o tada tinklas naudoja savo išteklius, kad pateiktų šį srautą daugeliui vartotojų. Ekonominiu požiūriu mokame tik už faktiškai sunaudotus išteklius (tai gali būti pralaidumas arba srautas) ir gauname puikų savo paslaugos mastelį. CDN naudojimas sunkiam turiniui pateikti yra visiškai pagrįstas ir logiškas. Nors verta paminėti, kad didžiausi žaidėjai šioje erdvėje (pvz., „Netflix“) kuria savo CDN, o ne naudoja didelius komercinius CDN („Akamai“, „Cloudflare“, „Fastly“ ir kt.)
Internetui tobulėjant, pačios žiniatinklio programos tapo sudėtingesnės ir sudėtingesnės. Išryškėjo pakrovimo greičio problema. Svetainių greičio entuziastai greitai nustatė keletą pagrindinių problemų, dėl kurių svetainės buvo įkeliamos lėtai. Vienas iš jų buvo tinklo vėlavimai (RTT – kelionės pirmyn ir atgal laikas arba ping laikas). Vėlavimai turi įtakos daugeliui svetainės įkėlimo procesų: TCP ryšio užmezgimui, TLS seanso paleidimui, kiekvieno atskiro resurso (vaizdo, JS failo, HTML dokumento ir kt.) įkėlimui.
Problemą apsunkino tai, kad naudojant HTTP/1.1 protokolą (prieš SPDY, QUIC ir HTTP/2 atsiradimą tai buvo vienintelė galimybė), naršyklės atidaro ne daugiau kaip 6 TCP ryšius su vienu kompiuteriu. Visa tai lėmė ryšio prastovą ir neefektyvų kanalo pralaidumo naudojimą. Problema iš dalies buvo išspręsta domeno skirstymu – papildomų kompiuterių kūrimu, kad būtų galima įveikti jungčių skaičiaus limitą.
Čia atsiranda antrasis CDN gebėjimas – delsos (RTT) mažinimas dėl didelio taškų skaičiaus ir mazgų artumo vartotojui. Atstumas čia vaidina lemiamą vaidmenį: šviesos greitis ribojamas (apie 200 000 km/sek šviesolaidžiu). Tai reiškia, kad kiekvienas 1000 km nuvažiuotas RTT prideda 5 ms vėlavimą arba 10 ms. Tai yra minimalus perdavimo laikas, nes taip pat yra vėlavimų tarpinėje įrangoje. Kadangi CDN paprastai žino, kaip talpykloje saugoti objektus savo serveriuose, mums gali būti naudinga įkelti tokius objektus per CDN. Tam būtinos sąlygos: objekto buvimas talpykloje, CDN taško artumas vartotojui, palyginti su žiniatinklio programų serveriu (kilmės serveriu). Svarbu suprasti, kad CDN mazgo geografinis artumas negarantuoja mažo delsos. Maršrutas tarp kliento ir CDN gali būti sukurtas taip, kad klientas prisijungtų prie pagrindinio kompiuterio kitoje šalyje ir galbūt kitame žemyne. Čia atsiranda ryšys tarp telekomunikacijų operatorių ir CDN paslaugos (sujungimas, ryšiai, dalyvavimas IX ir kt.) ir paties CDN srauto nukreipimo politika. Pavyzdžiui, „Cloudflare“, naudojant du pradinius planus (nemokamą ir pigų), negarantuoja turinio pristatymo iš artimiausio pagrindinio kompiuterio – priegloba bus parinkta siekiant minimalių išlaidų.
Daugelis pirmaujančių interneto kompanijų pritraukia visuomenės susidomėjimą (žiniatinklio kūrėjus ir paslaugų savininkus) įkėlimo greičio ir svetainės našumo tema. Tarp šių įmonių yra „Yahoo“ („Yslow“ įrankis), „AOL“ („WebPageTest“) ir „Google“ („Page Speed Insights“ paslauga), kurios rengia savo rekomendacijas, kaip pagreitinti svetaines (visų pirma jos susijusios su klientų optimizavimu). Vėliau pasirodo nauji svetainės greičio testavimo įrankiai, kuriuose taip pat pateikiami patarimai, kaip padidinti svetainės greitį. Kiekviena iš šių paslaugų ar papildinių turi nuoseklią rekomendaciją: „Naudokite CDN“. Tinklo delsos sumažėjimas paprastai nurodomas kaip CDN poveikio paaiškinimas. Deja, ne visi yra pasirengę tiksliai suprasti, kaip pasiekiamas CDN pagreičio efektas ir kaip jį galima išmatuoti, todėl rekomendacija remiasi tikėjimu ir naudojama kaip postulatas. Tiesą sakant, ne visi CDN yra sukurti vienodai.
CDN naudojimas šiandien
Norint įvertinti CDN naudojimo naudingumą, jie turi būti klasifikuojami. Ką dabar galima rasti praktiškai (skliausteliuose pateikti pavyzdžiai, žinoma, nėra išsamūs):
- Nemokamas CDN JS bibliotekoms platinti (MaxCDN, Google. Yandex).
- Klientų optimizavimo paslaugų CDN (pvz., „Google Fonts“ šriftams, „Cloudinary“, „Cloudimage“ vaizdams).
- CDN statiniam ir išteklių optimizavimui TVS (galima naudoti Bitrix, WordPress ir kt.).
- Bendrosios paskirties CDN (StackPath, CDNVideo, NGENIX, Megafon).
- CDN svetainės pagreitinimui (Cloudflare, Imperva, Airi).
Pagrindinis skirtumas tarp šių tipų yra tai, kiek srauto patenka per CDN. 1-3 tipai yra tik dalies turinio pristatymas: nuo vienos užklausos iki kelių dešimčių (dažniausiai nuotraukos). 4 ir 5 tipai yra visiškas srauto tarpinis serveris per CDN.
Praktiškai tai reiškia jungčių, naudojamų svetainei įkelti, skaičių. Naudodami HTTP/2 naudojame vieną TCP ryšį su pagrindiniu kompiuteriu, kad galėtume apdoroti bet kokį užklausų skaičių. Jei skirstome išteklius į pagrindinį pagrindinį kompiuterį (originą) ir CDN, tuomet reikia paskirstyti užklausas per kelis domenus ir sukurti keletą TCP jungčių. Blogiausias atvejis: DNS (1 RTT) + TCP (1 RTT) + TLS (2–3 RTT) = 6–7 RTT. Šioje formulėje neatsižvelgiama į delsą mobiliuosiuose tinkluose aktyvuojant įrenginio radijo kanalą (jei jis nebuvo aktyvus) ir mobiliojo ryšio bokšto delsas.
Štai kaip atrodo svetainės įkėlimo krioklys (prisijungimo prie CDN delsos paryškintos ties RTT 150 ms):
Jei CDN apima visą svetainės srautą (išskyrus trečiųjų šalių paslaugas), galime naudoti vieną TCP ryšį, sutaupydami vėlavimo prisijungiant prie papildomų kompiuterių. Žinoma, tai taikoma HTTP/2 ryšiams.
Tolimesnius skirtumus nulemia konkretaus CDN funkcionalumas – pirmajam tipui tai tik talpina statinį failą, penktajam keičia kelių tipų svetainės turinį optimizavimo tikslais.
CDN galimybės svetainei pagreitinti
Apibūdinkime visą CDN galimybių, skirtų pagreitinti svetaines, spektrą, neatsižvelgdami į atskirų CDN tipų funkcionalumą, o tada pažiūrėkime, kas įdiegta kiekvienoje iš jų.
1. Teksto išteklių suspaudimas
Pati pagrindinė ir suprantamiausia funkcija, tačiau dažnai prastai įgyvendinama. Visi CDN deklaruoja suspaudimo buvimą kaip pagreitinimo funkciją. Bet jei pažvelgsite išsamiau, išryškės trūkumai:
- dinaminiam suspaudimui galima naudoti žemus laipsnius - 5-6 (pavyzdžiui, gzip maksimalus yra 9);
- statinis glaudinimas (failai talpykloje) nenaudoja papildomų funkcijų (pvz., zopfi arba brotli su 11 laipsniu)
- nepalaikomas efektyvus brotli suspaudimas (sutaupoma apie 20%, lyginant su gzip).
Jei naudojate CDN, verta patikrinti šiuos kelis punktus: paimkite failą, gautą iš CDN, įrašykite jo suglaudintą dydį ir suglaudinkite jį rankiniu būdu palyginimui (galite naudoti tam tikrą internetinę paslaugą su brotli palaikymu, pvz. ).
2. Kliento talpyklos antraštės nustatymas
Taip pat paprasta pagreitinimo funkcija: pridėkite antraštes, kad klientas (naršyklė) talpintų turinį. Naujausia antraštė yra talpyklos valdymas, pasenusi baigiasi. Be to, galima naudoti Etag. Svarbiausia, kad maksimalus talpyklos valdymo amžius būtų pakankamai didelis (nuo mėnesio ar daugiau, jei esate pasiruošę kuo stipriau talpinti išteklius, galite pridėti nekeičiamą parinktį).
CDN gali sumažinti maksimalaus amžiaus vertę, todėl vartotojas gali dažniau įkelti statinį turinį. Neaišku, su kuo tai susiję: noras padidinti srautą tinkle arba padidinti suderinamumą su svetainėmis, kurios nežino, kaip iš naujo nustatyti talpyklą. Pavyzdžiui, numatytasis „Cloudflare“ antraštės talpyklos laikas yra 1 valanda, o tai yra labai mažai nekintančių statinių duomenų.
3. Vaizdo optimizavimas
Kadangi CDN atlieka vaizdų kaupimo talpykloje ir aptarnavimo funkcijas, būtų logiška juos optimizuoti CDN pusėje ir teikti vartotojams tokia forma. Iš karto padarykime išlygą, kad ši funkcija prieinama tik 2, 3 ir 5 CDN tipams.
Galite optimizuoti vaizdus įvairiais būdais: naudodami pažangius glaudinimo formatus (pvz., WebP), efektyvesnius koduotuvus (MozJPEG) arba tiesiog išvalydami nereikalingus metaduomenis.
Apskritai tokie optimizavimai yra dviejų tipų: su kokybės praradimu ir be kokybės. CDN paprastai stengiasi naudoti be nuostolių optimizavimą, kad išvengtų galimų klientų skundų dėl vaizdo kokybės pokyčių. Tokiomis sąlygomis pelnas bus minimalus. Tiesą sakant, dažnai JPEG kokybės lygis yra daug aukštesnis nei būtina, todėl galite saugiai iš naujo suspausti naudodami žemesnį kokybės lygį, nepakenkiant naudotojo patirčiai. Kita vertus, sunku nustatyti visų galimų žiniatinklio programų kokybės ir nustatymų lygį, todėl CDN naudojami konservatyvesni nustatymai, palyginti su tais, kuriuos galima pritaikyti atsižvelgiant į kontekstą (vaizdų paskirtį, žiniatinklio programos tipą). ir tt)
4. TLS ryšio optimizavimas
Dauguma srauto šiandien keliauja per TLS ryšius, o tai reiškia, kad TLS deryboms skiriame daugiau laiko. Pastaruoju metu buvo sukurtos naujos technologijos, kurios pagreitina šį procesą. Pavyzdžiui, tai yra EC kriptografija, TLS 1.3, seanso talpykla ir bilietai, aparatinės įrangos šifravimo pagreitis (AES-NI) ir tt Tinkamai nustačius TLS, ryšio laikas gali sutrumpėti iki 0-1 RTT (neskaičiuojant DNS ir TCP).
Naudojant šiuolaikinę programinę įrangą, tokią praktiką nėra sunku įgyvendinti savarankiškai.
Ne visi CDN įgyvendina TLS geriausią praktiką, tai galite patikrinti išmatuodami TLS ryšio laiką (pvz., naudodami Webpagetest). Idealiai tinka naujam ryšiui – 1RTT, 2RTT – vidutinis lygis, 3RTT ir daugiau – blogas.
Taip pat reikėtų pažymėti, kad net naudojant TLS CDN lygiu, serveris su mūsų žiniatinklio programa taip pat turi apdoroti TLS, bet iš CDN pusės, nes srautas tarp serverio ir CDN pereina viešuoju tinklu. Blogiausiu atveju sulauksime dvigubo TLS ryšio vėlavimo (pirmasis – CDN priegloboje, antrasis – tarp jo ir mūsų serverio).
Kai kuriose programose verta atkreipti dėmesį į saugumo problemas: srautas dažniausiai iššifruojamas CDN mazguose, ir tai yra potenciali galimybė perimti srautą. Galimybė dirbti be srauto atskleidimo dažniausiai siūloma aukščiausiuose tarifų planuose už papildomą mokestį.
5. Sumažinkite ryšio vėlavimą
Pagrindinis CDN pranašumas, apie kurį visi kalba: mažas delsimas (mažesnis atstumas) tarp CDN pagrindinio kompiuterio ir vartotojo. Pasiekiama sukuriant geografiškai paskirstytą tinklo architektūrą, kurioje pagrindiniai kompiuteriai yra vartotojų koncentracijos taškuose (miestuose, srauto mainų taškuose ir kt.)
Praktiškai skirtingų tinklų prioritetai gali būti konkrečiuose regionuose. Pavyzdžiui, Rusijos CDN turės daugiau buvimo vietų Rusijoje. Amerikietiškiai tinklą pirmiausia plėtos JAV. Pavyzdžiui, vienas didžiausių CDN „Cloudflare“ turi tik 2 taškus Rusijoje – Maskvoje ir Sankt Peterburge. Tai reiškia, kad galime sutaupyti daugiausia apie 10 ms delsos, palyginti su tiesioginiu talpinimu Maskvoje.
Dauguma Vakarų CDN taškų Rusijoje apskritai neturi. Prisijungę prie jų, galite tik padidinti savo rusų auditorijos vėlavimus.
6. Turinio optimizavimas (sumažinimas, struktūriniai pakeitimai)
Sudėtingiausias ir technologiškai pažangiausias taškas. Turinio keitimas pristatymo metu gali būti labai rizikingas. Net jei imtume mažinti: šaltinio kodo sumažinimas (dėl papildomų tarpų, nesvarbių struktūrų ir pan.) gali turėti įtakos jo veikimui. Jei kalbėtume apie rimtesnius pakeitimus – JS kodo perkėlimą į HTML pabaigą, failų sujungimą ir pan. – rizika sutrikdyti svetainės funkcionalumą yra dar didesnė.
Todėl tai daro tik kai kurie 5 tipo CDN. Žinoma, nebus įmanoma automatizuoti visų pakeitimų, kurių reikia norint pagreitinti darbą – reikalinga rankinė analizė ir optimizavimas. Pavyzdžiui, nenaudojamo arba pasikartojančio kodo pašalinimas yra rankinė užduotis.
Paprastai visi tokie optimizavimai yra valdomi nustatymų, o pavojingiausi pagal numatytuosius nustatymus yra išjungti.
Pagreičio palaikymas pagal CDN tipą
Taigi pažiūrėkime, kokias galimas pagreitinimo galimybes suteikia skirtingų tipų CDN.
Patogumui pakartojame klasifikaciją.
- Nemokamas CDN JS bibliotekoms platinti (MaxCDN, Google. Yandex).
- Klientų optimizavimo paslaugų CDN (pvz., „Google Fonts“ šriftams, „Cloudinary“, „Cloudimage“ vaizdams).
- CDN statiniam ir išteklių optimizavimui TVS (galima naudoti Bitrix, WordPress ir kt.).
- Bendrosios paskirties CDN (StackPath, CDNVideo, NGENIX, Megafon).
- CDN svetainės pagreitinimui (Cloudflare, Imperva, Airi).
Dabar palyginkime CDN savybes ir tipus.
Galimybė
1 tipas
2 tipas
3 tipas
4 tipas
5 tipas
Teksto suspaudimas
+–
-
+–
+–
+
Talpyklos antraštės
+
+
+
+
+
Nuotraukos
-
+–
+–
-
+
TLS
-
-
-
+–
+
Vėlavimai
-
-
-
+
+
Turinys
-
-
-
-
+
Šioje lentelėje „+“ naudojamas norint nurodyti visišką palaikymą, „–“ nėra palaikymas, o „+–“ reiškia dalinį palaikymą. Žinoma, realybėje gali būti nukrypimų nuo šios lentelės (pavyzdžiui, kai kurie bendros paskirties CDN įdiegs vaizdų optimizavimo funkcijas), tačiau bendrai idėjai tai naudinga.
rezultatai
Tikimės, kad perskaitę šį straipsnį turėsite aiškesnį vaizdą apie rekomendaciją „naudokite CDN“, kad pagreitintumėte savo svetaines.
Kaip ir bet kuriame versle, negalite patikėti bet kurios paslaugos rinkodaros pažadais. Poveikis turi būti išmatuotas ir išbandytas realiomis sąlygomis. Jei jau naudojate CDN, patikrinkite jo efektyvumą pagal straipsnyje aprašytus kriterijus.
Gali būti, kad šiuo metu naudojant CDN sulėtėja svetainės įkėlimo laikas.
Kaip bendrą rekomendaciją galime sutelkti dėmesį į šiuos dalykus: ištirti savo auditoriją, nustatyti jos geografinę apimtį. Jei jūsų pagrindinė auditorija yra sutelkta 1–2 tūkstančių kilometrų spinduliu, jums nereikia CDN pagrindiniam tikslui – delsos mažinimui. Vietoj to, galite pastatyti serverį arčiau vartotojų ir tinkamai jį sukonfigūruoti, kad gautumėte daugumą straipsnyje aprašytų optimizacijų (nemokamų ir nuolatinių).
Jei jūsų auditorija yra tikrai geografiškai paskirstyta (spindulys daugiau nei 3000 kilometrų), kokybiško CDN naudojimas tikrai bus naudingas. Tačiau jūs turite iš anksto suprasti, ką tiksliai jūsų CDN gali pagreitinti (žr. galimybių lentelę ir jų aprašymą). Tačiau svetainės spartinimas vis dar yra sudėtinga užduotis, kurios negalima išspręsti prijungus CDN. Be minėtų optimizacijų, už CDN lieka efektyviausios pagreitinimo priemonės: serverio dalies optimizavimas, pažangūs kliento dalies pakeitimai (nenaudojamo kodo pašalinimas, atvaizdavimo proceso optimizavimas, darbas su turiniu, šriftais, pritaikomumas ir kt.). )
Šaltinis: www.habr.com