[Nelietojiet] CDN

GandrÄ«z katram rakstam vai rÄ«kam vietnes ātruma optimizÄ“Å”anai ir pieticÄ«ga klauzula ā€œizmantot CDNā€. Kopumā CDN ir satura piegādes tÄ«kls vai satura piegādes tÄ«kls. Mēs, Method Lab, bieži saskaramies ar klientu jautājumiem par Å”o tēmu; daži no tiem iespējo savu CDN. Å Ä« raksta mērÄ·is ir saprast, ko CDN var nodroÅ”ināt vietnes ielādes ātruma ziņā, kādas problēmas var rasties un kādos gadÄ«jumos CDN izmantoÅ”ana ir pamatota.

[Nelietojiet] CDN

Aizkaves, kas apzÄ«mētas attēlā, izraisa CDN izmantoÅ”ana.

Nedaudz vēstures

Tāpat kā daudzas tehnoloÄ£ijas, CDN radās nepiecieÅ”amÄ«bas dēļ. AttÄ«stoties interneta kanāliem interneta lietotāju vidÅ«, parādÄ«jās tieÅ”saistes video pakalpojumi. Protams, video saturam ir nepiecieÅ”ams par daudz lielāku joslas platumu, salÄ«dzinot ar parasto vietnes saturu (attēli, teksts un CSS vai JS kods).

Mēģinot pārraidÄ«t video straumi paralēli daudziem klientiem no viena servera, visdrÄ«zāk par vājo vietu kļūs servera interneta kanāls. Parasti pietiek ar dažiem tÅ«kstoÅ”iem pavedienu, lai aizsprostotu tipisku servera kanālu. Protams, var bÅ«t arÄ« citi resursu ierobežojumi, taču tie Å”obrÄ«d nav svarÄ«gi. SvarÄ«gi ir arÄ« tas, ka servera kanāla paplaÅ”ināŔana ir pārāk dārga (un dažreiz neiespējama), kā arÄ« nepraktiska. Kanāla slodze raidÄ«jumu laikā bÅ«s cikliska.

AtseviŔķa servera kanāla ierobežoÅ”anas problēmu lieliski atrisina CDN. Klienti nepieslēdzas tieÅ”i serverim, bet gan CDN tÄ«kla mezgliem. Ideālā situācijā serveris nosÅ«ta vienu straumi uz CDN mezglu, un pēc tam tÄ«kls izmanto savus resursus, lai piegādātu Å”o straumi daudziem lietotājiem. No ekonomiskā viedokļa mēs maksājam tikai par faktiski patērētajiem resursiem (tas varētu bÅ«t joslas platums vai trafika) un iegÅ«stam lielisku pakalpojuma mērogojamÄ«bu. CDN izmantoÅ”ana smaga satura piegādei ir pilnÄ«gi pamatota un loÄ£iska. Lai gan ir vērts atzÄ«mēt, ka lielākie spēlētāji Å”ajā jomā (piemēram, Netflix) veido savus CDN, nevis izmanto lielus komerciālus CDN (Akamai, Cloudflare, Fastly utt.).

TÄ«meklim attÄ«stoties, paÅ”as tÄ«mekļa lietojumprogrammas ir kļuvuÅ”as sarežģītākas un sarežģītākas. IekrauÅ”anas ātruma problēma izvirzÄ«jās priekÅ”plānā. Vietņu ātruma entuziasti ātri atklāja vairākas lielas problēmas, kuru dēļ vietnes tika ielādētas lēni. Viens no tiem bija tÄ«kla aizkave (RTT ā€” turp un atpakaļ laiks vai ping laiks). Aizkaves ietekmē daudzus procesus tÄ«mekļa vietnes ielādes: TCP savienojuma izveidoÅ”ana, TLS sesijas sākÅ”ana, katra atseviŔķa resursa (attēla, JS faila, HTML dokumenta utt.) ielāde.

Problēmu saasināja fakts, ka, izmantojot HTTP/1.1 protokolu (pirms SPDY, QUIC un HTTP/2 parādÄ«Å”anās Ŕī bija vienÄ«gā iespēja), pārlÅ«kprogrammas atver ne vairāk kā 6 TCP savienojumus vienam resursdatoram. Tas viss noveda pie savienojuma dÄ«kstāves un neefektÄ«vas kanāla joslas platuma izmantoÅ”anas. Problēmu daļēji atrisināja domēna sadalÄ«Å”ana - papildu resursdatoru izveide, lai pārvarētu savienojumu skaita ierobežojumu.

Å eit parādās otrā CDN spēja - latentuma (RTT) samazināŔana, pateicoties lielajam punktu skaitam un mezglu tuvumam lietotājam. Attālumam Å”eit ir izŔķiroÅ”a loma: gaismas ātrums ir ierobežots (apmēram 200 000 km/sek optiskajā Ŕķiedrā). Tas nozÄ«mē, ka katriem 1000 km nobraukuma RTT tiek pievienota 5 ms kavÄ“Å”anās vai 10 ms. Tas ir minimālais laiks, kas nepiecieÅ”ams pārraidei, jo starpiekārtās ir arÄ« kavÄ“Å”anās. Tā kā CDN parasti zina, kā keÅ”atmiņā saglabāt objektus savos serveros, mēs varam gÅ«t labumu no Ŕādu objektu ielādes, izmantojot CDN. Tam nepiecieÅ”amie nosacÄ«jumi: objekta klātbÅ«tne keÅ”atmiņā, CDN punkta tuvums lietotājam, salÄ«dzinot ar tÄ«mekļa lietojumprogrammu serveri (izcelsmes serveri). Ir svarÄ«gi saprast, ka CDN mezgla Ä£eogrāfiskais tuvums negarantē zemu latentumu. MarÅ”rutu starp klientu un CDN var izveidot tā, lai klients izveidotu savienojumu ar resursdatoru citā valstÄ« un, iespējams, citā kontinentā. Å eit parādās attiecÄ«bas starp telekomunikāciju operatoriem un CDN pakalpojumu (peering, savienojumi, dalÄ«ba IX utt.) un paÅ”a CDN trafika marÅ”rutÄ“Å”anas politika. Piemēram, Cloudflare, izmantojot divus sākotnējos plānus (bezmaksas un lēti), negarantē satura piegādi no tuvākā saimniekdatora ā€“ resursdators tiks izvēlēts tā, lai sasniegtu minimālās izmaksas.

Daudzi vadoÅ”ie interneta uzņēmumi piesaista sabiedrÄ«bas (tÄ«mekļa izstrādātāju un pakalpojumu Ä«paÅ”nieku) interesi par ielādes ātrumu un vietņu veiktspēju. Starp Å”iem uzņēmumiem ir Yahoo (rÄ«ks Yslow), AOL (WebPageTest) un Google (Page Speed ā€‹ā€‹ā€‹ā€‹Insights pakalpojums), kas izstrādā savus ieteikumus vietņu paātrināŔanai (galvenokārt tie attiecas uz klientu optimizāciju). Vēlāk parādās jauni vietņu ātruma testÄ“Å”anas rÄ«ki, kas sniedz arÄ« padomus vietnes ātruma palielināŔanai. Katram no Å”iem pakalpojumiem vai spraudņiem ir konsekvents ieteikums: ā€œIzmantojiet CDNā€. TÄ«kla latentuma samazinājums parasti tiek minēts kā CDN ietekmes skaidrojums. Diemžēl ne visi ir gatavi precÄ«zi saprast, kā CDN paātrinājuma efekts tiek sasniegts un kā to var izmērÄ«t, tāpēc ieteikums tiek ņemts ticÄ«bā un izmantots kā postulāts. Faktiski ne visi CDN ir izveidoti vienādi.

CDN izmantoŔana Ŕodien

Lai novērtētu CDN izmantoÅ”anas lietderÄ«bu, tie ir jāklasificē. Ko tagad var atrast praksē (piemēri iekavās, protams, nav izsmeļoÅ”i):

  1. Bezmaksas CDN JS bibliotēku izplatÄ«Å”anai (MaxCDN, Google. Yandex).
  2. Klientu optimizācijas pakalpojumu CDN (piemēram, Google Fonts fontiem, Cloudinary, Cloudimage attēliem).
  3. CDN statiskai un resursu optimizācijai CMS (pieejams Bitrix, WordPress un citās).
  4. Vispārējas 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 tā, cik liela daļa trafika iet caur CDN. 1.-3. veids ir tikai satura daļas piegāde: no viena pieprasÄ«juma lÄ«dz vairākiem desmitiem (parasti attēli). 4. un 5. veids ir pilna trafika starpniekserveri, izmantojot CDN.

Praksē tas nozÄ«mē savienojumu skaitu, kas tiek izmantots vietnes ielādei. Izmantojot HTTP/2, mēs izmantojam vienu TCP savienojumu ar resursdatoru, lai apstrādātu neierobežotu skaitu pieprasÄ«jumu. Ja mēs sadalām resursus galvenajā resursdatorā (origin) un CDN, tad ir nepiecieÅ”ams sadalÄ«t pieprasÄ«jumus pa vairākiem domēniem un izveidot vairākus TCP savienojumus. Sliktākais gadÄ«jums ir: DNS (1 RTT) + TCP (1 RTT) + TLS (2ā€“3 RTT) = 6ā€“7 RTT. Å Ä« formula neņem vērā mobilo sakaru tÄ«klu aizkaves ierÄ«ces radio kanāla aktivizÄ“Å”anai (ja tas nebija aktÄ«vs) un mobilo sakaru torņa aizkavÄ“Å”anos.

LÅ«k, kā tas izskatās vietnes ielādes Å«denskritumā (latencie savienojuma izveidei ar CDN ir izcelti pie RTT 150 ms):

[Nelietojiet] CDN

Ja CDN aptver visu vietnes trafiku (izņemot treÅ”o puÅ”u pakalpojumus), mēs varam izmantot vienu TCP savienojumu, ietaupot aizkavi, izveidojot savienojumu ar papildu resursdatoriem. Protams, tas attiecas uz HTTP/2 savienojumiem.

Tālākās atŔķirÄ«bas nosaka konkrētā CDN funkcionalitāte - pirmajam tipam tas tikai mitina statisku failu, piektajam optimizācijas nolÅ«kos maina vairākus vietnes satura veidus.

CDN iespējas vietņu paātrināŔanai

AprakstÄ«sim visu CDN iespēju klāstu vietņu paātrināŔanai, neņemot vērā atseviŔķu CDN veidu funkcionalitāti, un pēc tam redzēsim, kas ir ieviests katrā no tām.

1. Teksta resursu saspieŔana

VisvienkārŔākā un saprotamākā funkcija, kas bieži vien ir vāji ieviesta. Visi CDN paziņo kompresijas esamÄ«bu kā paātrinājuma funkciju. Bet, ja paskatās sÄ«kāk, atklājas trÅ«kumi:

  • dinamiskai saspieÅ”anai var izmantot zemas pakāpes - 5-6 (piemēram, gzip maksimālais ir 9);
  • statiskā saspieÅ”ana (faili keÅ”atmiņā) neizmanto papildu lÄ«dzekļus (piemēram, zopfi vai brotli ar 11. pakāpi)
  • nav atbalsta efektÄ«vai brotli saspieÅ”anai (salÄ«dzinot ar gzip, ietaupa apmēram 20%).

Ja izmantojat CDN, ir vērts pārbaudÄ«t Å”os dažus punktus: paņemiet failu, kas nāca no CDN, ierakstiet tā saspiesto izmēru un saspiediet to manuāli salÄ«dzinājumam (varat izmantot kādu tieÅ”saistes pakalpojumu ar brotli atbalstu, piemēram, vsszhat.rf).

2. Klienta keÅ”atmiņas galveņu iestatÄ«Å”ana

ArÄ« vienkārÅ”a paātrināŔanas funkcija: pievienojiet galvenes klienta (pārlÅ«ka) satura saglabāŔanai keÅ”atmiņā. Jaunākā galvene ir keÅ”atmiņas kontrole, novecojuÅ”ajai beidzas derÄ«guma termiņŔ. Turklāt var izmantot Etag. Galvenais, lai keÅ”atmiņas kontroles maksimālais vecums ir pietiekami liels (no mēneÅ”a vai vairāk) Ja esat gatavs resursu keÅ”atmiņā pēc iespējas vairāk, varat pievienot nemainÄ«go opciju.

CDN var samazināt maksimālā vecuma vērtÄ«bu, liekot lietotājam biežāk atkārtoti ielādēt statisko saturu. Nav skaidrs, ar ko tas ir saistÄ«ts: vēlmi palielināt trafiku tÄ«klā vai palielināt saderÄ«bu ar vietnēm, kuras nezina, kā atiestatÄ«t keÅ”atmiņu. Piemēram, noklusējuma Cloudflare galvenes keÅ”atmiņas laiks ir 1 stunda, kas ir ļoti mazs nemainÄ«giem statiskiem datiem.

3. Attēla optimizācija

Tā kā CDN pārņem attēlu saglabāŔanas un apkalpoÅ”anas funkcijas, bÅ«tu loÄ£iski tos optimizēt CDN pusē un apkalpot lietotājiem Ŕādā formā. Uzreiz rezervēsim, ka Ŕī funkcija ir pieejama tikai CDN 2., 3. un 5. tipam.

Varat optimizēt attēlus dažādos veidos: izmantojot uzlabotus saspieÅ”anas formātus (piemēram, WebP), efektÄ«vākus kodētājus (MozJPEG) vai vienkārÅ”i notÄ«rot nevajadzÄ«gos metadatus.

Kopumā ir divu veidu Ŕādas optimizācijas: ar kvalitātes zudumu un bez kvalitātes zuduma. CDN parasti cenÅ”as izmantot optimizāciju bez zudumiem, lai izvairÄ«tos no iespējamām klientu sÅ«dzÄ«bām par attēla kvalitātes izmaiņām. Šādos apstākļos ieguvums bÅ«s minimāls. PatiesÄ«bā bieži JPEG kvalitātes lÄ«menis ir daudz augstāks nekā nepiecieÅ”ams, un jÅ«s varat droÅ”i atkārtoti saspiest ar zemāku kvalitātes lÄ«meni, neapdraudot lietotāja pieredzi. No otras puses, ir grÅ«ti noteikt kvalitātes lÄ«meni un iestatÄ«jumus universāli visām iespējamām tÄ«mekļa lietojumprogrammām, tāpēc CDN izmanto konservatÄ«vākus iestatÄ«jumus, salÄ«dzinot ar tiem, kurus var piemērot, ņemot vērā kontekstu (attēlu mērÄ·is, tÄ«mekļa lietojumprogrammas veids). utt.)

4. TLS savienojuma optimizēŔana

MÅ«sdienās lielākā daļa satiksmes notiek, izmantojot TLS savienojumus, kas nozÄ«mē, ka mēs pavadām papildu laiku TLS sarunām. Nesen ir izstrādātas jaunas tehnoloÄ£ijas, lai paātrinātu Å”o procesu. Piemēram, tā ir EC kriptogrāfija, TLS 1.3, sesijas keÅ”atmiņa un biļetes, aparatÅ«ras Å”ifrÄ“Å”anas paātrinājums (AES-NI) utt. Pareizi iestatot TLS, savienojuma laiku var samazināt lÄ«dz 0-1 RTT (neskaitot DNS un TCP).

Izmantojot modernu programmatūru, nav grūti patstāvīgi ieviest Ŕādu praksi.

Ne visos CDN tiek ieviesta TLS paraugprakse; varat to pārbaudīt, izmērot TLS savienojuma laiku (piemēram, Webpagetest). Ideāli piemērots jaunam savienojumam - 1RTT, 2RTT - vidējais līmenis, 3RTT un vairāk - slikts.

Jāņem vērā arī tas, ka pat izmantojot TLS CDN līmenī, serverim ar mūsu tīmekļa aplikāciju ir jāapstrādā arī TLS, taču no CDN puses, jo trafika starp serveri un CDN pāriet publiskajā tīklā. Sliktākajā gadījumā mēs saņemsim dubultu TLS savienojuma aizkavi (pirmais uz CDN saimniekdatora, otrais starp to un mūsu serveri).

Dažām lietojumprogrammām ir vērts pievērst uzmanÄ«bu droŔības problēmām: datplÅ«sma parasti tiek atÅ”ifrēta CDN mezglos, un tā ir potenciāla iespēja trafika pārtverÅ”anai. Iespēja strādāt bez satiksmes informācijas atklāŔanas parasti tiek piedāvāta augstākajos tarifu plānos par papildu samaksu.

5. Samaziniet savienojuma aizkavi

Galvenā CDN priekÅ”rocÄ«ba, par kuru runā visi: zems latentums (mazāks attālums) starp CDN saimniekdatoru un lietotāju. Panākts, izveidojot Ä£eogrāfiski sadalÄ«tu tÄ«kla arhitektÅ«ru, kurā resursdatori atrodas lietotāju koncentrācijas punktos (pilsētas, trafika apmaiņas punkti utt.)

Praksē dažādu tÄ«klu prioritātes var bÅ«t noteiktos reÄ£ionos. Piemēram, Krievijas CDN bÅ«s vairāk klātbÅ«tnes punktu Krievijā. Amerikāņi vispirms attÄ«stÄ«s tÄ«klu ASV. Piemēram, vienam no lielākajiem CDN Cloudflare ir tikai 2 punkti Krievijā ā€“ Maskavā un Sanktpēterburgā. Tas ir, mēs varam ietaupÄ«t maksimāli aptuveni 10 ms latentuma, salÄ«dzinot ar tieÅ”o izvietoÅ”anu Maskavā.

Lielākajai daļai Rietumu CDN punktu Krievijā vispār nav. Pieslēdzoties tiem, jÅ«s varat tikai palielināt aizkavÄ“Å”anos savai krievu auditorijai.

6. Satura optimizācija (samazināŔana, strukturālas izmaiņas)

Sarežģītākais un tehnoloÄ£iski progresÄ«vākais punkts. Satura maiņa piegādes laikā var bÅ«t ļoti riskanta. Pat ja ņemam vērā minimizÄ“Å”anu: avota koda samazināŔana (papildu atstarpju, nesvarÄ«gu struktÅ«ru utt. dēļ) var ietekmēt tā veiktspēju. Ja runājam par nopietnākām izmaiņām ā€“ JS koda pārvietoÅ”anu uz HTML beigām, failu sapludināŔanu u.tml. ā€“ risks sagraut vietnes funkcionalitāti ir vēl lielāks.

Tāpēc to dara tikai daži 5. tipa CDN. Protams, nebÅ«s iespējams automatizēt visas izmaiņas, kas nepiecieÅ”amas, lai paātrinātu darbÄ«bu ā€” ir nepiecieÅ”ama manuāla analÄ«ze un optimizācija. Piemēram, neizmantota vai dublēta koda noņemÅ”ana ir manuāls uzdevums.

Parasti visas Ŕādas optimizācijas tiek kontrolētas ar iestatÄ«jumiem, un visbÄ«stamākās pēc noklusējuma ir atspējotas.

Atbalsts paātrinājuma iespējām pēc CDN veida

Tāpēc apskatÄ«sim, kādas iespējamās paātrināŔanas iespējas nodroÅ”ina dažādi CDN veidi.

Ērtības labad mēs atkārtojam klasifikāciju.

  1. Bezmaksas CDN JS bibliotēku izplatÄ«Å”anai (MaxCDN, Google. Yandex).
  2. Klientu optimizācijas pakalpojumu CDN (piemēram, Google Fonts fontiem, Cloudinary, Cloudimage attēliem).
  3. CDN statiskai un resursu optimizācijai CMS (pieejams Bitrix, WordPress un citās).
  4. Vispārējas nozīmes CDN (StackPath, CDNVideo, NGENIX, Megafon).
  5. CDN vietņu paātrināŔanai (Cloudflare, Imperva, Airi).

Tagad salīdzināsim CDN funkcijas un veidus.

Iespēja
1. tips
2. tips
3. tips
4. tips
5. tips

Teksta saspieŔana
+ā€“
-
+ā€“
+ā€“
+

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

Attēli
-
+ā€“
+ā€“
-
+

TLS
-
-
-
+ā€“
+

KavÄ“Å”anās
-
-
-
+
+

Saturs
-
-
-
-
+

Å ajā tabulā ā€œ+ā€ tiek izmantots, lai norādÄ«tu pilnu atbalstu, ā€œā€“ā€ nav atbalsts un ā€œ+ā€“ā€ ir daļējs atbalsts. Protams, realitātē var bÅ«t novirzes no Ŕīs tabulas (piemēram, daži vispārējas nozÄ«mes CDN ieviesÄ«s funkcijas attēlu optimizÄ“Å”anai), bet vispārējai idejai tas ir noderÄ«gi.

Rezultāti

Cerams, ka pēc Ŕī raksta izlasÄ«Å”anas jums bÅ«s skaidrāks priekÅ”stats par ieteikumu ā€œizmantot CDNā€, lai paātrinātu vietnes.

Tāpat kā jebkurā biznesā, jūs nevarat noticēt neviena pakalpojuma mārketinga solījumiem. Ietekme ir jāmēra un jāpārbauda reālos apstākļos. Ja jau izmantojat CDN, pārbaudiet tā efektivitāti, izmantojot rakstā aprakstītos kritērijus.

Iespējams, ka CDN izmantoÅ”ana Å”obrÄ«d palēnina jÅ«su vietnes ielādes laiku.

Kā vispārÄ«gu ieteikumu mēs varam koncentrēties uz sekojoÅ”o: izpētiet savu auditoriju, nosakiet tās Ä£eogrāfisko tvērumu. Ja jÅ«su galvenā auditorija ir koncentrēta 1-2 tÅ«kstoÅ”u kilometru rādiusā, jums nav nepiecieÅ”ams CDN tā galvenajam mērÄ·im - latentuma samazināŔanai. Tā vietā varat novietot savu serveri tuvāk lietotājiem un pareizi konfigurēt, iegÅ«stot lielāko daļu rakstā aprakstÄ«to optimizāciju (bezmaksas un pastāvÄ«gas).

Ja jÅ«su auditorija patieŔām ir Ä£eogrāfiski sadalÄ«ta (rādiuss vairāk nekā 3000 kilometru), kvalitatÄ«va CDN izmantoÅ”ana patieŔām bÅ«s noderÄ«ga. Tomēr jums ir iepriekÅ” jāsaprot, ko tieÅ”i jÅ«su CDN var paātrināt (skatiet iespēju tabulu un to aprakstu). Tomēr vietņu paātrināŔana joprojām ir sarežģīts uzdevums, ko nevar atrisināt, pievienojot CDN. Papildus iepriekÅ”minētajām optimizācijām aiz CDN paliek visefektÄ«vākie paātrināŔanas lÄ«dzekļi: servera daļas optimizācija, uzlabotas izmaiņas klienta daļā (neizmantotā koda noņemÅ”ana, renderÄ“Å”anas procesa optimizÄ“Å”ana, darbs ar saturu, fontiem, pielāgojamÄ«ba utt.). )

Avots: www.habr.com

Pievieno komentāru