[Ne] izmantojiet CDN

GandrÄ«z katrā rakstā vai rÄ«kotājā, kas veltÄ«ts mājaslapu ātruma optimizācijai, ir pieticÄ«gs punkts "izmantojiet CDN". PatiesÄ«bā, CDN ir saturu piegādes tÄ«kls. Mēs uzņēmumā "Metod Lab" bieži saskaramies ar klientu jautājumiem par Å”o tēmu, daži no viņiem paÅ”i aktivizē CDN. Å Ä« raksta mērÄ·is ir noskaidrot, ko var sniegt CDN ātruma ielādes kontekstā, kādas problēmas var rasties un kad CDN izmantoÅ”ana ir pamatota.

[Ne] izmantojiet CDN

Attēlā aplÅ«kotās aizkaves ir saistÄ«tas ar CDN izmantoÅ”anu.

Mazliet vēstures

Kā daudzas tehnoloÄ£ijas, CDN parādÄ«jās vajadzÄ«bas dēļ. AttÄ«stoties interneta kanāliem lietotājiem, radās tieÅ”saistes video pakalpojumi. Protams, ka video saturs prasa daudz lielāku caurlaidspēju salÄ«dzinājumā ar parastajiem mājaslapu satura veidiem (attēliem, tekstu un CSS vai JS koda).

Centienos paralēli pārraidÄ«t video straumi vairāk nekā vienam klientam no viena servera, Å”aurais posms, visticamāk, bÅ«s servera interneta kanāls. Parasti pietiek ar dažiem tÅ«kstoÅ”iem straumju, lai aizsprostotu tipisku servera kanālu. Protams, var bÅ«t arÄ« citi ierobežojumi resursos, taču Å”obrÄ«d tie nav svarÄ«gi. Tāpat svarÄ«gi ir, ka paplaÅ”ināt servera kanālu ir pārāk dārgi (dažreiz pat neiespējami), un tas nav arÄ« saprātÄ«gi. Slodze uz kanālu pārraidīŔanas laikā bÅ«s cikliska.

AtseviŔķa servera kanāla ierobežojumu problēmu lieliski risina CDN. Klienti nepieslēdzas tieÅ”i serverim, bet CDN tÄ«kla mezglam. Ideālajā situācijā serveris nodod vienu straumi CDN mezglam, un tad tÄ«kls izmanto savus resursus, lai Å”o straumi piegādātu daudziem lietotājiem. Ekonomikas viedokļa mēs maksājam tikai par faktiski patērētajiem resursiem (tas var bÅ«t caurlaidspēja vai trafiks) un iegÅ«stam lielisku mÅ«su pakalpojuma mērogojamÄ«bu. CDN izmantoÅ”ana smagā satura piegādei ir pilnÄ«bā pamatota un loÄ£iska. JāatzÄ«mē arÄ«, ka lielākie spēlētāji Å”ajā jomā (piemēram, Netflix) veido savus CDN, nevis izmanto lielos komerciālos CDN (Akamai, Cloudflare, Fastly u.c.).

AttÄ«stoties tÄ«meklim, paÅ”i tÄ«mekļa lietojumi kļuva sarežģītāki un smagāki. Prioritāte bija kļuvusi ātruma problēma. Ātruma entuziasti diezgan ātri izcēla vairākas galvenās problēmas, kas izraisÄ«ja lēnu tÄ«mekļa lapu ielādi. Viena no tām bija kavēŔanās tÄ«klā (RTT — round trip time vai ping laiks). KavēŔanās ietekmē daudzus procesus tÄ«mekļa lapas ielādēŔanā: TCP savienojuma izveidi, TLS sesijas uzsākÅ”anu, katra atseviŔķā resursa (attēla, JS faila, HTML dokumenta utt.) ielādi.

Problēmu pastiprināja fakts, ka, izmantojot protokolu HTTP/1.1 (lÄ«dz SPDY, QUIC un HTTP/2 parādÄ«jās, tas bija vienÄ«gais variants), pārlÅ«kprogrammas atver ne vairāk kā 6 TCP savienojumus uz vienu hostu. Viss tas noveda pie savienojuma dÄ«kstāves un neefektÄ«vas kanāla platuma izmantoÅ”anas. Problēma daļēji tika atrisināta, izmantojot domēnu Å”arding — papildu hostu izveidi, lai pārvarētu savienojumu skaita ierobežojumu.

Te ierodas otra CDŅ spēja – kavēŔanās (RTT) samazināŔana, pateicoties lielam punktu skaitam un mezglu tuvumam lietotājam. Attālums Å”eit spēlē izŔķiroÅ”u lomu: gaismas ātrums ir ierobežots (apmēram 200 000 km/s optiskajā Ŕķiedrā). Tādējādi katrs 1000 km ceļā pievieno 5 ms kavēŔanās vai 10 ms RTT. Tas ir minimālais laika patēriņŔ pārraidei, jo ir arÄ« kavēŔanās starpniekiekārtās. Tā kā CDŅ parasti spēj keÅ”ot objektus savos serveros, mēs varam gÅ«t labumu no Ŕādu objektu ielādes caur CDŅ. NepiecieÅ”amie nosacÄ«jumi tam ir: objekta pieejamÄ«ba keŔā un CDŅ punkta tuvums lietotājam salÄ«dzinājumā ar tÄ«mekļa lietojuma serveri (origin server). SvarÄ«gi saprast: Ä£eogrāfiskā tuvÄ«ba CDŅ mezglam negarantē zemas kavēŔanās. MarÅ”rutēŔana starp klientu un CDŅ var tikt veidota tā, ka klients savienojas ar hostu citā valstÄ«, iespējams, pat citā kontinentā. Å eit spēlē lomu sakaru operatoru un CDŅ pakalpojuma attiecÄ«bas (pierings, savienojumu pieejamÄ«ba, dalÄ«ba IX utt.) un paÅ”a CDŅ trafika marÅ”rutēŔanas politika. Piemēram, Cloudflare, izmantojot divus pamata plānus (bezmaksas un lēto), negarantē satura piegādi no tuvākā mezgla — hosta izvēle tiks veikta, lai sasniegtu minimālo izmaksu.

Daudzas vadoŔās interneta kompānijas piesaista sabiedrÄ«bas interesi (tÄ«mekļa izstrādātāju un pakalpojumu Ä«paÅ”nieku) par vietņu ielādes un darbÄ«bas ātrumu. Starp Ŕīm kompānijām ir Yahoo (rÄ«ks Yslow), AOL (WebPageTest) un Google (pakalpojums Page Speed Insights), kas izstrādā savus ieteikumus vietņu paātrināŔanai (pirmkārt, tie attiecas uz klientu optimizāciju). Vēlāk parādās jauni vietņu ātruma testēŔanas rÄ«ki, kas arÄ« sniedz ieteikumus vietņu ātruma palielināŔanai. Katram no Å”iem pakalpojumiem vai spraudņiem ir neizmaināms ieteikums "Izmantojiet CDN". Kā izskaidrojums CDN efektam parasti tiek minēts tÄ«kla aiztures samazinājums. Diemžēl ne visi ir gatavi izprast, kā tieÅ”i tiek panākts paātrinājuma efekts no CDN un kā to var izmērÄ«t, tāpēc ieteikums tiek pieņemts uz ticÄ«bu un tiek izmantots kā postulate. PatiesÄ«bā tālu ne visi CDN ir vienādi noderÄ«gi.

CDN izmantoŔana Ŕodien

Lai novērtētu CDN lietoÅ”anas lietderÄ«bu, tās jāklasificē. Ko var sastapt Å”odien praksē (piemēri iekavās protams nav izsmeļoÅ”i):

  1. Bezmaksas CDN JS bibliotēku izplatīŔanai (MaxCDN, Google, Yandex).
  2. CDN klientu optimizācijas pakalpojumiem (piemēram, Google Fonts fontiem, Cloudinary, Cloudimage attēliem).
  3. CDN statiskajām datnēm un resursu optimizācijai CMS (sastopama Bitrix, WordPress un citur).
  4. Vispārīgas nozīmes CDN (StackPath, CDNVideo, NGENIX, Megafon).
  5. CDN vietņu paātrināŔanai (Cloudflare, Imperva, Airi).

Galvenā atŔķirÄ«ba starp Å”iem veidiem ir Ŕāda: kāda daļa trafika iziet caur CDN. 1-3 veidi ir satura piegāde tikai daļēji: no vienas pieprasÄ«juma lÄ«dz vairākiem desmitiem (parasti attēlu). 4. un 5. veidi ir pilnÄ«ga trafika tālākpārraide caur CDN.

Praktiski tas nozÄ«mē savienojumu skaitu, kas tiek izmantoti vietnes ielādei. Izmantojot HTTP/2, mēs izmantojam vienu TCP savienojumu ar hostu, lai apstrādātu jebkādu pieprasÄ«jumu skaitu. Ja mēs sadalām resursus starp galveno hostu (origin) un CDN, tad ir nepiecieÅ”ams izdalÄ«t pieprasÄ«jumus pa vairākiem domēniem un veidot vairākus TCP savienojumus. Sliktākajā gadÄ«jumā tas ir: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Å ajā formulā netiek ņemtas vērā aiztures mobilajos tÄ«klos, lai aktivizētu ierÄ«ces radio kanālu (ja tas nav bijis aktÄ«vs) un aiztures pie mobilā torņa.

Tā tas izskatās vietnes ielādes pārvadājumā (atzÄ«mētas kavēŔanās, pieslēdzoties CDN ar RTT 150 ms):

[Ne] izmantojiet CDN

Ja CDN aptver visu vietnes trafiku (izņemot treÅ”o puÅ”u pakalpojumus), tad mēs varam izmantot vienu TCP savienojumu, taupot kavēŔanos, pieslēdzoties papildu hostiem. Protams, tas attiecas uz HTTP/2 savienojumiem.

Turpmākās atŔķirÄ«bas nosaka konkrētā CDN funkcionalitāte – pirmajam tipam tā ir vienkārÅ”i hostings statiskā faila, piektajam – vairāku veidu vietnes satura maiņa optimizācijas nolÅ«kos.

CDN iespējas, lai paātrinātu vietni

Iepazīsimies ar pilno CDN iespēju klāstu, lai paātrinātu vietnes, neskatoties uz individuālo CDN veidu funkcionalitāti, un pēc tam apskatīsim, kas no tā ir īstenots katrā no tiem.

1. Teksta resursu saspieŔana

VisvienkārŔākā un saprotamākā iespēja, tomēr bieži Ä«stenota slikti. Visi CDN deklarē saspieÅ”anu kā savu paātrināŔanas funkciju, bet, ja skatāmies tuvāk, atklājas nepilnÄ«bas:

  • var tikt izmantotas zemas pakāpes dinamiskai saspieÅ”anai – 5-6 (piemēram, gzip maksimums — 9);
  • statiskajā saspieÅ”anā (faili keÅ”atmiņā) netiek izmantotas papildu iespējas (piemēram, zopfi vai brotli ar pakāpi 11);
  • nav atbalsta efektÄ«vai brotli saspieÅ”anai (ietaupÄ«jums aptuveni 20% salÄ«dzinājumā ar gzip).

Ja izmantojat CDN, ir vērts pārbaudÄ«t Å”os dažus punktus: ņemiet failu, kas nācis no CDN, fiksējiet tā izmēru saspiestā veidā un pārsaspiediet manuāli salÄ«dzinājumam (var izmantot kādu tieÅ”saistes pakalpojumu ar brotli atbalstu, piemēram, vissaspiest.lv).

2. Klientu keÅ”atmiņas vadÄ«bu galveno virsrakstu iestatīŔana

Vēl viena vienkārÅ”a funkcija paātrināŔanai: iestatÄ«t galvenes, lai nodroÅ”inātu satura keÅ”atmiņu klientā (pārlÅ«kprogrammā). VisaktÄ«vākā galvene ir cache-control, novecojusi – expires. Papildus var izmantot Etag. Galvenais, lai max-age no cache-control bÅ«tu pietiekami liels (no mēneÅ”a un vairāk), ja esat gatavi maksimāli stingri keŔēt resursu, varat pievienot opciju immutable.

CDN var samazināt max-age vērtÄ«bu, liekot lietotājam biežāk atkārtoti ielādēt statiskās sadaļas. Ar ko tas saistÄ«ts: ar vēlmi palielināt tÄ«kla trafiku vai uzlabot saderÄ«bu ar vietnēm, kuras nespēj dzēst iepriekŔējo keÅ”u – nav skaidrs. Piemēram, noklusējuma keÅ”a laika vērtÄ«ba Cloudflare virsrakstos ir 1 stunda, kas ir ļoti maz nemainÄ«gai statikai.

3. Attēlu optimizācija

Tā kā CDN uzņemas keÅ”atmiņas un attēlu piegādes funkcijas, loÄ£iski bÅ«s optimizēt tos CDN pusē un Ŕādā veidā piegādāt lietotājiem. JāatzÄ«mē, ka Ŕī iespēja ir pieejama tikai 2., 3. un 5. tipa CDN.

Attēlu optimizēŔanai var izmantot dažādus veidus: izmantojot progresÄ«vus saspieÅ”anas formātus (piemēram, WebP), efektÄ«vākus kodētājus (MozJPEG) vai vienkārÅ”i iztÄ«rot liekos metadatus.

Kopumā ir divu veidu Ŕādas optimizācijas: ar kvalitātes zudumu un bez tā. CDN parasti cenÅ”as izmantot optimizāciju bez zudumiem, lai izvairÄ«tos no iespējamiem klientu sÅ«dzÄ«bām par attēlu kvalitātes maiņu. Šādos apstākļos ieguvums bÅ«s minimāls. PatiesÄ«bā bieži JPEG kvalitātes lÄ«menis ir ievērojami augstāks par nepiecieÅ”amo un var droÅ”i veikt atkārtotu saspieÅ”anu ar zemāku kvalitātes rādÄ«tāju bez lietotāju uztveres bojāŔanas. No otras puses, universāli noteikt kvalitātes lÄ«meni un iestatÄ«jumus visām iespējamām tÄ«mekļa lietojumprogrammām ir grÅ«ti, tāpēc CDN izmanto konservatÄ«vākus iestatÄ«jumus salÄ«dzinājumā ar tiem, kurus var piemērot, ņemot vērā kontekstu (attēlu mērÄ·is, tÄ«mekļa lietojumprogrammas tips utt.)

4. TLS savienojumu optimizācija

Lielākā daļa trafika Å”odien tiek pārraidÄ«ta pa TLS savienojumiem, un tas nozÄ«mē, ka mēs tērējam papildu laiku TLS saskaņoÅ”anai. Pēdējā laikā ir izstrādātas jaunas teknoloÄ£ijas, lai paātrinātu Å”o procesu. Piemēram, tas ir EC kriptogrāfija, TLS 1.3, sesiju keÅ”atmiņa un biļetes (session tickets), aparatÅ«ras Å”ifrēŔanas paātrināŔana (AES-NI) utt. Pareiza TLS iestatīŔana ļauj samazināt savienojuma laiku lÄ«dz 0-1 RTT (neieskaitot DNS un TCP).

Ja ir pieejama moderna programmatūra, Ŕādu prakses ievieŔana savās jaudās nav sarežģīta.

Pats par sevi ne visi CDN ievieÅ” labākās prakses tls, to var pārbaudÄ«t, mērot tls savienojuma laiku (piemēram, izmantojot webpagetest). Ideāls jaunajam savienojumam ir 1RTT, 2RTT — vidējais lÄ«menis, 3RTT un vairāk — slikti.

Vēl jāatzÄ«mē, ka pat tad, ja tiek izmantots tls CDN lÄ«menÄ«, serverim ar mÅ«su tÄ«mekļa lietojumprogrammu joprojām jāapstrādā tls, bet no CDN puses, jo satiksme starp serveri un CDN notiek publiskajā tÄ«klā. Sliktākajā gadÄ«jumā mēs iegÅ«sim divkārÅ”us tls savienojuma aiztures laikus (pirmais uz CDN saimnieku, otrais starp to un mÅ«su serveri).

Dažiem lietojumiem vērts pievērst uzmanÄ«bu droŔības jautājumiem: parasti satiksme tiek atÅ”ifrēta CDN mezglos, kas ir potenciāla iespēja satiksmes uzÄ·erÅ”anai. Darba variants bez satiksmes atklāŔanas parasti tiek piedāvāts top plānos par atseviŔķu maksu.

5. Savienojuma aizturu samazināŔana

Galvenā CDN priekÅ”rocÄ«ba, par kuru visi runā: zema aizture (mazāks attālums) starp CDN saimnieku un lietotāju. To panāk, izveidojot Ä£eogrāfiski izplatÄ«tu tÄ«kla arhitektÅ«ru, kurā saimnieki atrodas lietotāju koncentrācijas punktos (pilsētās, datu apmaiņas punktos utt.)

Praksē prioritātes dažādām tÄ«klam var bÅ«t konkrētās reÄ£ionos. Piemēram, Krievijas CDN bÅ«s vairāk klātbÅ«tnes punktu Krievijā. Amerikāņu pirmkārt attÄ«stÄ«s tÄ«klu ASV. Piemēram, viens no lielākajiem CDN, Cloudflare, ir tikai 2 punkti Krievijā — Maskavā un Sanktpēterburgā. Tas nozÄ«mē, ka maksimāli varam ietaupÄ«t apmēram 10 ms aizturi salÄ«dzinājumā ar tieÅ”o izvietojumu Maskavā.

Lielākajai daļai rietumu CDN vispār nav punktu Krievijā. Pieslēdzoties tiem, jūs varat tikai palielināt aizturi jūsu krievu auditorijai.

6. Satura optimizācija (minifikācija, strukturālas izmaiņas)

VisgrÅ«tākais un tehnoloÄ£iski sarežģītais punkts. Satura izmaiņas piegādes laikā var bÅ«t ļoti riskantas. Pat ja runājam par minifikāciju: sākotnējā koda saÄ«sināŔana (pateicoties liekām atstarpēm, nevajadzÄ«gām konstrukcijām utt.) var ietekmēt tā darbÄ«bu. Ja runājam par nopietnākām izmaiņām — JS koda pārvietoÅ”ana HTML beigās, failu apvienoÅ”ana un lÄ«dzÄ«gi — risks izjaukt vietnes funkcionalitāti ir vēl lielāks.

Tāpēc tikai daži 5. tipa CDN to dara. Protams, automātiski veikt visus nepiecieÅ”amos uzlabojumus, lai paātrinātu, nav iespējams – nepiecieÅ”ama manuāla analÄ«ze un optimizācija. Piemēram, lieko vai dublēto kodu dzēŔana ir tieÅ”i manuāla uzdevumu daļa.

Parasti visas Ŕādas optimizācijas pārvalda iestatÄ«jumi, un vissbÄ«stamākie ir izslēgti pēc noklusējuma.

Atbalsts paātrināŔanas iespējām pēc CDN tipiem

Tātad, aplÅ«kosim, kuras potenciālās paātrināŔanas iespējas piedāvā dažādie CDN tipi.

Lai atvieglotu, atkārtosim klasifikāciju.

  1. Bezmaksas CDN JS bibliotēku izplatīŔanai (MaxCDN, Google, Yandex).
  2. CDN klientu optimizācijas pakalpojumiem (piemēram, Google Fonts fontiem, Cloudinary, Cloudimage attēliem).
  3. CDN statiskajām datnēm un resursu optimizācijai CMS (sastopama Bitrix, WordPress un citur).
  4. Vispārīgas nozīmes CDN (StackPath, CDNVideo, NGENIX, Megafon).
  5. CDN vietņu paātrināŔanai (Cloudflare, Imperva, Airi).

Tagad salīdzināsim funkcijas un CDN tipus.

Iespēja
Tips 1
Tips 2
Tips 3
Tips 4
Tips 5

Teksta saspieŔana
+–
–
+–
+–
+

KeÅ”atmiņas galvenes
+
+
+
+
+

Attēli
–
+–
+–
–
+

TLS
–
–
–
+–
+

Aiztures
–
–
–
+
+

Saturs
–
–
–
–
+

Å ajā tabulā ā€˜+’ tiek izmantots, lai norādÄ«tu pilnÄ«gu atbalstu, ā€˜ā€“ā€™ – neesamÄ«bu, ā€˜+–’ – daļēju atbalstu. Protams, Ŕī tabula var atŔķirties no reālās situācijas (piemēram, vispārējs CDN var ieviest attēlu optimizācijas funkcijas), bet tā ir noderÄ«ga vispārējai izpratnei.

Secinājumi

Ceru, ka izlasot Å”o rakstu, jums radÄ«sies skaidrāka aina par ieteikumu ā€˜izmantojiet CDN’ mājaslapu paātrināŔanai.

Kā jebkurā jomā, nevajag uzticēties kāda pakalpojuma mārketinga solījumiem. Efekts jāizmēra un jāpārbauda reālās situācijās. Ja jau izmantojat kādu CDN, pārbaudiet tā efektivitāti saskaņā ar rakstā aprakstītajiem kritērijiem.

Iespējams, ka CDN izmantoÅ”ana tieÅ”i tagad palēnina jÅ«su mājaslapas ielādi.

Kā vispārÄ«gu ieteikumu var minēt sekojoÅ”o: izpētiet savu auditoriju, nosakiet tās Ä£eogrāfiskās robežas. Ja jÅ«su galvenā auditorija ir koncentrēta 1-2 tÅ«kstoÅ”u kilometru rādiusā, jums nav nepiecieÅ”ams CDN tā pamatfunkcijai – aizturu samazināŔanai. Tā vietā jÅ«s varat novietot savu serveri tuvāk lietotājiem un pareizi to konfigurēt, gÅ«stot lielāko daļu rakstā aprakstÄ«to optimizāciju (bez maksas un pastāvÄ«gi).

Ja gadÄ«jumā, ja jÅ«su auditorija patieŔām ir Ä£eogrāfiski izkliedēta (rādiuss vairāk par 3000 kilometriem), kvalitatÄ«vas CDN izmantoÅ”ana tieŔām bÅ«s noderÄ«ga. Tomēr jāsaprot iepriekÅ”, ko tieÅ”i jÅ«su CDN varēs paātrināt (skatiet iespēju tabulu un to aprakstu). Vietnes paātrināŔana tomēr paliek sarežģīts uzdevums, kuru nevar atrisināt tikai ar CDN pieslēgÅ”anu. Papildus norādÄ«tajām optimizācijām ārpus CDN paliek visefektÄ«vākie paātrināŔanas lÄ«dzekļi: servera puses optimizācija, uzlabotas izmaiņas klienta pusē (neizmantotā koda noņemÅ”ana, renderēŔanas procesa optimizācija, darbs ar saturu, fontiem, responsivitāti utt.)

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster