[Ez] erabili CDNrik

Gunearen abiadura optimizatzeko ia artikulu edo tresna guztiek "erabili CDN" klausula xume bat dute. Oro har, CDN edukia bidaltzeko sarea edo edukia bidaltzeko sarea da. Method Lab-en askotan bezeroen galderak topatzen ditugu gai honi buruz; horietako batzuek beren CDN propioa gaitu. Artikulu honen helburua da ulertzea zer eman dezakeen CDN batek gunearen karga-abiadurari dagokionez, zer arazo sor daitezkeen eta zein kasutan justifikatzen den CDN baten erabilera.

Irudian inguratutako atzerapenak CDN bat erabiltzeak eragiten ditu.

Historia apur bat

Teknologia asko bezala, CDNak beharragatik sortu ziren. Interneteko erabiltzaileen artean Interneteko kanalen garapenarekin, sareko bideo zerbitzuak agertu ziren. Jakina, bideo-edukiak banda-zabalera handiagoa behar du webguneko eduki arruntekin alderatuta (argazkiak, testua eta CSS edo JS kodea).

Bideo-korronte bat zerbitzari batetik bezero askorekin paraleloan igortzen saiatzean, ziurrenik zerbitzariaren Interneteko kanala botila-lepo bihurtuko da. Oro har, mila hari batzuk nahikoak dira zerbitzari-kanal tipiko bat oztopatzeko. Jakina, baliteke beste baliabide-muga batzuk egotea, baina ez dira garrantzitsuak oraingoz. Garrantzitsua da zerbitzariaren kanala zabaltzea garestiegia izatea (eta batzuetan ezinezkoa) eta, gainera, ezinezkoa izatea. Kanalaren karga emisioetan zehar ziklikoa izango da.

Banakako zerbitzari baten kanala mugatzearen arazoa ezin hobeto konpontzen du CDNk. Bezeroak ez dira zuzenean zerbitzariarekin konektatzen, CDN sareko nodoetara baizik. Egoera ezin hobean, zerbitzariak korronte bat bidaltzen du CDN nodora, eta gero sareak bere baliabideak erabiltzen ditu korronte hori erabiltzaile askori emateko. Ikuspuntu ekonomikotik, benetan kontsumitutako baliabideengatik bakarrik ordaintzen dugu (banda-zabalera edo trafikoa izan daiteke) eta gure zerbitzuaren eskalagarritasun bikaina lortzen dugu. Eduki astunak emateko CDN bat erabiltzea guztiz justifikatua eta logikoa da. Nabarmentzekoa den arren, espazio honetako jokalaririk handienak (adibidez, Netflix) CDN propioak eraikitzen ari direla CDN komertzial handiak erabili beharrean (Akamai, Cloudflare, Fastly, etab.)

Weba eboluzionatu ahala, web aplikazioak beraiek konplexuagoak eta konplexuagoak dira. Karga abiaduraren arazoa azaleratu zen. Webguneen abiaduraren zaleek azkar identifikatu zituzten webguneak poliki kargatzea eragiten zuten hainbat arazo handi. Horietako bat sareko atzerapenak izan ziren (RTT - joan-etorriko denbora edo ping denbora). Atzerapenak webguneak kargatzeko prozesu askotan eragiten du: TCP konexioa ezartzea, TLS saio bat abiaraztea, baliabide bakoitza kargatzea (irudia, JS fitxategia, HTML dokumentua, etab.)

Arazoa areagotu egin zen HTTP/1.1 protokoloa erabiltzean (SPDY, QUIC eta HTTP/2-en etorrera baino lehen hau zen aukera bakarra), arakatzaileek ez dituztela 6 TCP konexio baino gehiago ireki ostalari batera. Horrek guztiak konexioaren etenaldia eta kanalaren banda-zabalera eraginkorra ez erabiltzea ekarri zuen. Arazoa partzialki konpondu zen domeinuaren zatiketak - ostalari gehigarriak sortzea konexio kopuruaren muga gainditzeko.

Hor agertzen da CDNren bigarren gaitasuna: latentzia (RTT) murriztea, puntu kopuru handia eta nodoak erabiltzailearekiko hurbiltasuna direla eta. Distantziak paper erabakigarria du hemen: argiaren abiadura mugatua da (200 km/seg inguru zuntz optikoan). Horrek esan nahi du 000 km-ko bidaia bakoitzak 1000 ms atzerapena edo 5 ms gehitzen dizkiola RTT-ri. Hau da transmisiorako behar den gutxieneko denbora, tarteko ekipoetan ere atzerapenak baitaude. CDN batek normalean bere zerbitzarietan objektuak gordetzen dakienez, horrelako objektuak CDN baten bidez kargatzeak onura ditzakegu. Horretarako beharrezkoak diren baldintzak: objektua cachean egotea, CDN puntua erabiltzailearekiko hurbiltasuna web aplikazioen zerbitzariarekin alderatuta (jatorri zerbitzaria). Garrantzitsua da ulertzea CDN nodo baten hurbiltasun geografikoak ez duela latentzia baxua bermatzen. Bezeroaren eta CDNren arteko bideratzea bezeroa beste herrialde bateko ostalari batera konektatuko den moduan eraiki daiteke, eta agian beste kontinente batean. Hor sartzen dira telekomunikazio-operadoreen eta CDN zerbitzuaren arteko harremana (peering-a, konexioak, IX-en parte hartzea, etab.) eta CDNren beraren trafiko-bideratze-politika. Adibidez, Cloudflare-k, hasierako bi plan (doakoa eta merkea) erabiltzean, ez du bermatzen hurbilen dagoen ostalariaren edukia entregatzea - ​​ostalaria hautatuko da gutxieneko kostua lortzeko.

Interneteko enpresa nagusi askok interes publikoa erakartzen dute (web garatzaileak eta zerbitzuen jabeak) kargatzeko abiaduraren eta webgunearen errendimenduaren gaia. Enpresa horien artean Yahoo (Yslow tresna), AOL (WebPageTest) eta Google (Page Speed ​​​​Insights zerbitzua), guneak bizkortzeko gomendio propioak garatzen ari dira (bezeroen optimizazioari dagozkio nagusiki). Geroago, webguneen abiadura probatzeko tresna berriak agertzen dira, webgunearen abiadura handitzeko aholkuak ere ematen dituztenak. Zerbitzu edo plugin horietako bakoitzak gomendio koherente bat du: "Erabili CDN bat". Sarearen latentziaren murrizketa CDNren eraginaren azalpen gisa aipatu ohi da. Zoritxarrez, denak ez daude prest CDNren azelerazio-efektua nola lortzen den eta nola neur daitekeen ulertzeko, beraz, gomendioa fedean hartu eta postulatu gisa erabiltzen da. Izan ere, CDN guztiak ez dira berdinak sortzen.

Gaur CDN bat erabiliz

CDNak erabiltzearen erabilgarritasuna ebaluatzeko, sailkatu egin behar dira. Praktikan orain aurki daitekeena (parentesi artean dauden adibideak, noski, ez dira zehatzak):

1. Doako CDN JS liburutegiak banatzeko (MaxCDN, Google. Yandex).
2. Bezeroa optimizatzeko zerbitzuen CDN (adibidez, Google Fonts letra-tipoetarako, Cloudinary, Cloudimage irudietarako).
3. CDN CMS estatiko eta baliabideen optimizaziorako (Bitrix, WordPress eta beste batzuetan eskuragarri).
4. Helburu orokorreko CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. Webguneak bizkortzeko CDN (Cloudflare, Imperva, Airi).

Mota hauen arteko aldea CDNtik zenbat trafikoa pasatzen den da. 1-3 motak edukiaren zati bat soilik bidaltzen dute: eskaera batetik dozena batzuetara (normalean irudiak). 4. eta 5. motak CDN baten bidez trafikoaren proxy osoa dira.

Praktikan, gunea kargatzeko erabiltzen den konexio kopurua esan nahi du. HTTP/2-rekin, TCP konexio bakarra erabiltzen dugu ostalariarekin edozein eskaera prozesatzeko. Baliabideak ostalari nagusian (jatorria) eta CDNan banatzen baditugu, beharrezkoa da eskaerak hainbat domeinutan banatu eta TCP konexio ugari sortzea. Kasurik okerrena hau da: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Formula honek ez ditu kontuan hartzen sare mugikorretako atzerapenak gailuaren irrati-kanala aktibatzeko (aktiborik ez bazegoen) eta zelularreko dorrearen atzerapenak.

Hona hemen guneko karga-jauzian nolakoa den (CDNra konektatzeko latentziak RTT 150 ms-tan nabarmentzen dira):

CDNak guneko trafiko guztia estaltzen badu (hirugarrenen zerbitzuak izan ezik), TCP konexio bakarra erabil dezakegu, ostalari gehigarrietara konektatzean atzerapenak aurreztuz. Jakina, hau HTTP/2 konexioei aplikatzen zaie.

Desberdintasun gehiago CDN jakin baten funtzionaltasunak zehazten ditu - lehenengo motarako fitxategi estatiko bat ostatatzen da, bosgarrenerako hainbat guneko eduki mota aldatzen ari da optimizatzeko helburuarekin.

Webguneak bizkortzeko CDN gaitasunak

Deskriba dezagun guneak bizkortzeko CDN gaitasunen sorta osoa, CDN mota indibidualen funtzionaltasuna kontuan hartu gabe, eta, ondoren, ikus dezagun haietako bakoitzean zer ezartzen den.

1. Testu-baliabideen konpresioa

Ezaugarririk oinarrizkoena eta ulergarriena, baina askotan gaizki inplementatua. CDN guztiek konpresioaren presentzia deklaratzen dute azelerazio-eginbide gisa. Baina xehetasun gehiago aztertuz gero, hutsuneak argi geratzen dira:

• konpresio dinamikorako gradu baxuak erabil daitezke - 5-6 (adibidez, gzip-erako gehienez 9 da);
• konpresio estatikoak (fitxategiak cachean) ez du funtzio gehigarririk erabiltzen (adibidez, zopfi edo brotli 11. graduarekin)
• ez dago brotli konpresio eraginkorretarako laguntzarik (% 20 inguru aurrezten da gzip-arekin alderatuta).

CDN bat erabiltzen baduzu, merezi du puntu hauek egiaztatzea: hartu CDNtik datorren fitxategia, grabatu bere tamaina konprimitua eta eskuz konprimitu konparatzeko (brotli laguntzarekin lineako zerbitzuren bat erabil dezakezu, adibidez. vsszhat.rf).

2. Bezeroaren cachearen goiburuak ezartzea

Bizkortzeko eginbide sinple bat ere: gehitu goiburuak bezeroak (arakatzailea) edukia cachean gordetzeko. Goibururik berriena cache-kontrola da, zaharkitua iraungi da. Gainera, Etag erabil daiteke. Gauza nagusia da cache-kontrolaren gehienezko adina nahikoa handia dela (hilabete edo gehiago). Baliabidea ahalik eta gogorren gordetzeko prest bazaude, aldaezina aukera gehi dezakezu.

CDNek gehienezko adinaren balioa jaitsi dezakete, erabiltzailea eduki estatikoa maizago kargatzera behartuz. Ez dago argi zerrekin lotzen den: sareko trafikoa areagotu nahia edo cachea nola berrezarri ez dakiten guneekin bateragarritasuna areagotzeko. Adibidez, Cloudflare goiburuko cache-denbora lehenetsia ordu 1 da, hau da, datu estatiko aldaezinetarako oso baxua.

3. Irudien optimizazioa

CDNak irudiak cachean gordetzeko eta hornitzeko funtzioak hartzen dituenez, logikoa litzateke CDN aldean optimizatzea eta erabiltzaileei formulario honetan hornitzea. Egin dezagun erreserba berehala eginbide hau 2., 3. eta 5. CDN motetarako soilik dagoela erabilgarri.

Irudiak hainbat modutan optimiza ditzakezu: konpresio formatu aurreratuak erabiliz (adibidez, WebP), kodetzaile eraginkorragoak (MozJPEG) edo beharrezkoak ez diren metadatuak garbituz.

Oro har, bi optimizazio mota daude: kalitate galerarekin eta kalitate galerarik gabe. CDN-ak normalean galerarik gabeko optimizazioa erabiltzen ahalegintzen dira, bezeroen kexa posibleak saihesteko irudiaren kalitatearen aldaketei buruz. Horrelako baldintzetan, irabazia minimoa izango da. Egia esan, askotan JPEG kalitate-maila beharrezkoa baino askoz ere altuagoa da eta segurtasun maila baxuago batekin berriro konprima dezakezu erabiltzailearen esperientzia arriskuan jarri gabe. Bestalde, zaila da web-aplikazio posible guztien kalitate-maila eta ezarpenak modu unibertsalean zehaztea, beraz CDNek ezarpen kontserbadoreagoak erabiltzen dituzte testuingurua kontuan hartuta (irudien helburua, web aplikazio mota) aplika daitezkeenekin alderatuta. , etab.)

4. TLS konexioa optimizatzea

Gaur egungo trafiko gehiena TLS konexioen bidez egiten da, hau da, denbora gehiago ematen dugu TLS negoziazioan. Azkenaldian, teknologia berriak garatu dira prozesu hori bizkortzeko. Esaterako, hau da EC kriptografia, TLS 1.3, saioko cachea eta txartelak, hardware-enkriptatzea azelerazioa (AES-NI), etab. TLS behar bezala ezartzeak konexio-denbora 0-1 RTTra murriztu dezake (DNS eta TCP kontatu gabe).

Software modernoarekin, ez da zaila horrelako praktikak zure kabuz ezartzea.

CDN guztiek ez dituzte TLS praktika onenak ezartzen; hori egiazta dezakezu TLS konexio-denbora neurtuz (adibidez, Webpagetest-en). Konexio berri baterako aproposa - 1RTT, 2RTT - batez besteko maila, 3RTT eta gehiago - txarra.

Kontuan izan behar da, baita ere, TLS CDN mailan erabilita ere, gure web aplikazioa duen zerbitzariak TLS ere prozesatu behar duela, baina CDN aldetik, zerbitzariaren eta CDNren arteko trafikoa sare publikotik pasatzen delako. Kasurik txarrenean, TLS konexio-atzerapen bikoitzak lortuko ditugu (lehena CDN ostalariarengana, bigarrena haren eta gure zerbitzariaren artean).

Aplikazio batzuetarako, merezi du segurtasun arazoei arreta jartzea: normalean trafikoa CDN nodoetan deszifratzen da, eta hori trafikoa atzemateko aukera potentziala da. Trafikoaren berri eman gabe lan egiteko aukera normalean tarifa-plan nagusietan eskaintzen da kuota gehigarri baten truke.

5. Konexio-atzerapenak murriztea

Denek hitz egiten duten CDNren abantaila nagusia: CDN ostalariaren eta erabiltzailearen arteko latentzia txikia (distantzia txikiagoa). Geografikoki banatutako sare-arkitektura bat sortuz lortzen da, non ostalariak erabiltzaileen kontzentrazio puntuetan kokatuta dauden (hiriak, trafikoa trukatzeko puntuak, etab.)

Praktikan, sare ezberdinen lehentasunak eskualde zehatzetan egon daitezke. Adibidez, Errusiako CDNek presentzia puntu gehiago izango dituzte Errusian. Amerikarrek lehenik eta behin AEBn garatuko dute sarea. Adibidez, CDN Cloudflare handienetako batek 2 puntu baino ez ditu Errusian - Mosku eta San Petersburgo. Hau da, gehienez 10 ms inguruko latentzia gorde dezakegu Moskun zuzeneko kokapenarekin alderatuta.

Mendebaldeko CDN gehienek ez dute punturik Errusian. Haiekin konektatuz gero, zure audientzia errusiarentzako atzerapenak handitu ditzakezu.

6. Edukiaren optimizazioa (minifikazioa, egitura-aldaketak)

Puntu konplexuena eta teknologikoki aurreratuena. Bidaltzean edukia aldatzea oso arriskutsua izan daiteke. Minifikazioa hartzen badugu ere: iturburu-kodea murrizteak (espazio gehigarriengatik, garrantzirik gabeko egituragatik, etab.) bere errendimenduan eragina izan dezake. Aldaketa larriagoez hitz egiten badugu -JS kodea HTML amaierara eraman, fitxategiak batu, etab.- are handiagoa da gunearen funtzionaltasuna eteteko arriskua.

Hori dela eta, 5 motako CDN batzuek bakarrik egiten dute hori. Jakina, ezin izango dira automatizatu gauzak azkartzeko beharrezkoak diren aldaketa guztiak; eskuzko analisia eta optimizazioa beharrezkoak dira. Adibidez, erabili gabeko edo bikoiztutako kodea kentzea eskuzko zeregina da.

Oro har, optimizazio horiek guztiak ezarpenen bidez kontrolatzen dira eta arriskutsuenak lehenespenez desgaituta daude.

CDN motaren arabera azelerazio gaitasunetarako laguntza

Beraz, ikus ditzagun CDN mota ezberdinek zer azelerazio-aukera potentzial ematen duten.

Erosotasunerako, sailkapena errepikatzen dugu.

1. Doako CDN JS liburutegiak banatzeko (MaxCDN, Google. Yandex).
2. Bezeroa optimizatzeko zerbitzuen CDN (adibidez, Google Fonts letra-tipoetarako, Cloudinary, Cloudimage irudietarako).
3. CDN CMS estatiko eta baliabideen optimizaziorako (Bitrix, WordPress eta beste batzuetan eskuragarri).
4. Helburu orokorreko CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. Webguneak bizkortzeko CDN (Cloudflare, Imperva, Airi).

Orain aldera ditzagun CDNren ezaugarriak eta motak.

Aukera
1. mota
2. mota
3. mota
4. mota
5. mota

Testu konpresioa
+–
-
+–
+–
+

Cacheko goiburuak
+
+
+
+
+

pictures
-
+–
+–
-
+

TLS
-
-
-
+–
+

Atzerapenak
-
-
-
+
+

Edukia
-
-
-
-
+

Taula honetan, "+" euskarri osoa adierazteko erabiltzen da, "-" ez da euskarririk eta "+-" euskarri partziala da. Jakina, errealitatean taula honetatik desbideratzeak egon daitezke (adibidez, helburu orokorreko CDN batzuek irudiak optimizatzeko ezaugarriak ezarriko dituzte), baina ideia orokor baterako erabilgarria da.

Emaitzak

Zorionez, artikulu hau irakurri ondoren, "erabili CDN bat" gomendioari buruzko irudi argiagoa izango duzu zure guneak bizkortzeko.

Edozein negoziotan bezala, ezin duzu sinetsi edozein zerbitzuren marketin-promesak. Efektua baldintza errealetan neurtu eta probatu behar da. Dagoeneko CDN bat erabiltzen ari bazara, egiaztatu eraginkortasuna artikuluan deskribatutako irizpideak erabiliz.

Baliteke une honetan CDN bat erabiltzeak zure webgunea kargatzeko denbora moteltzea.

Gomendio orokor gisa, honako hauetan zentratu gaitezke: zure audientzia aztertu, bere esparru geografikoa zehaztu. Zure audientzia nagusia 1-2 mila kilometroko erradioan kontzentratzen bada, ez duzu CDNrik behar bere helburu nagusirako - latentzia murrizteko. Horren ordez, zure zerbitzaria zure erabiltzaileengandik hurbilago jar dezakezu eta behar bezala konfigura dezakezu, artikuluan deskribatutako optimizazio gehienak (doakoak eta iraunkorrak) lortuz.

Zure audientzia benetan geografikoki banatuta badago (3000 kilometro baino gehiagoko erradioa), kalitatezko CDN bat erabiltzea benetan erabilgarria izango da. Hala ere, aldez aurretik ulertu behar duzu zure CDN-k zer azkartu dezakeen (ikus gaitasunen taula eta haien deskribapena). Hala ere, webgunearen azelerazioa CDN bat konektatuz konpondu ezin den zeregin konplexua izaten jarraitzen du. Aipatutako optimizazioez gain, CDNren atzetik azelerazio-biderik eraginkorrenak geratzen dira: zerbitzariaren zatiaren optimizazioa, bezeroaren zatian aldaketa aurreratuak (erabiltzen ez den kodea kentzea, errendatze-prozesua optimizatzea, edukiak, letra-tipoak, moldagarritasuna, etab. )

Iturria: www.habr.com