La misteraj manieroj de enhavo aŭ ni diru vorton pri CDN

Malgarantio:
Ĉi tiu artikolo ne enhavas informojn antaŭe nekonatajn al legantoj familiaraj kun la koncepto de CDN, sed estas en la naturo de teknologiorecenzo.

La unua retpaĝo aperis en 1990 kaj havis nur kelkajn bajtojn. Ekde tiam, enhavo grimpis kaj kvalite kaj kvante. La evoluo de la IT-ekosistemo kaŭzis la fakton, ke modernaj retpaĝoj estas mezuritaj en megabajtoj kaj la tendenco al pliigo de reta bendolarĝo nur plifortiĝas ĉiujare. Kiel enhavprovizantoj povas kovri grandajn geografiajn skalojn kaj provizi uzantojn ĉie per altrapida aliro al informoj? Enhavaj liveraj kaj distribuaj retoj, ankaŭ konataj kiel Content Delivery Network aŭ simple CDN, devas trakti ĉi tiujn taskojn.

Estas pli kaj pli "peza" enhavo en la Interreto. Samtempe, multaj studoj montras, ke uzantoj ne volas trakti retajn servojn se ili daŭras pli ol 4-5 sekundojn por ŝargi. Tro malalta retejo-ŝarĝada rapideco estas plena de perdo de aŭdienco, kio certe kondukos al malkresko de trafiko, konvertiĝo kaj do profito. Enhavaj liveraj retoj (CDN), teorie, forigas ĉi tiujn problemojn kaj iliajn sekvojn. Sed fakte, kiel kutime, ĉio estas decidita de la detaloj kaj nuancoj de aparta kazo, el kiuj estas multe en ĉi tiu areo.

De kie venis la ideo de distribuitaj retoj?

Ni komencu per mallonga ekskurso en historion kaj difinojn de terminoj. CDN estas reto de grupo de servilaj maŝinoj situantaj en malsamaj lokoj por havigi aliron al Interreta enhavo kovranta grandan nombron da uzantoj. La ideo de distribuitaj retoj estas havi plurajn punktojn de ĉeesto (PoP) samtempe, kiuj situas ekster la fonta servilo. Tia sistemo prilaboros aron de envenantaj petoj pli rapide, pliigante la respondon kaj rapidecon de translokigo de ajnaj datumoj.

La problemo pri liverado de enhavo al uzantoj akre ekestis ĉe la pinto de la evoluo de Interreto, t.e. meze de la 90-aj jaroj. La tiamaj serviloj, kies agado ne atingis eĉ modernajn ĉeftekkomputilojn, apenaŭ eltenis la ŝarĝon kaj ne povis elteni la ĉiam kreskantan trafikon. Mikrosofto elspezis centojn da milionoj da dolaroj ĉiujare por esploroj rilataj al la informvojo (tuj venas al la menso la fama 640 KB de Bill Gates). Por solvi ĉi tiujn problemojn, ni devis uzi hierarkian kaŝmemoron, ŝanĝi de modemoj al optika fibro, kaj analizi la retan topologion detale. La situacio rememorigis malnovan lokomotivon, kiu rapidas laŭ la reloj kaj laŭ la vojo estas modernigita per ĉiuj eblaj rimedoj por pliigi rapidecon.

Jam en la malfruaj 90-aj jaroj, la posedantoj de retportaloj rimarkis, ke por redukti la ŝarĝon kaj provizi la postulatajn petojn, ili bezonas uzi perajn servilojn. Tiel aperis la unuaj CDN-oj, distribuantaj statikan enhavon de malsamaj serviloj geografie disigitaj tra la mondo. Ĉirkaŭ la sama tempo aperis komerco bazita sur distribuitaj retoj. La plej granda (almenaŭ unu el la plej grandaj) CDN-provizanto en la mondo, Akamai, iĝis pioniro en tiu areo, komencante sian vojaĝon en 1998. Kelkajn jarojn poste, CDN iĝis ĝeneraligita, kaj enspezoj de enhavlivero kaj kontribuo sumiĝis al dekoj da milionoj da dolaroj ĉiumonate.

Hodiaŭ ni renkontas CDN ĉiufoje kiam ni iras al komerca paĝo de alta trafiko aŭ komunikas en sociaj retoj. La servo estas provizita de: Amazon, Cloudflare, Akamai, same kiel multaj aliaj transnaciaj provizantoj. Plie, grandaj kompanioj emas uzi siajn proprajn CDN-ojn, kio alportas al ili kelkajn avantaĝojn en la rapideco kaj kvalito de enhavo-livero. Se Facebook ne havis distribuitajn retojn, sed kontentiĝis kun nur originservilo situanta en Usono, povus daŭri signife pli longe por ŝarĝi profilon por uzantoj en Orienta Eŭropo.

Kelkaj vortoj pri CDN kaj streaming

FutureSource Consulting analizis la muzikan industrion kaj konkludis, ke en 2023 la nombro da abonoj al muzikfluaj servoj atingos preskaŭ duonmiliardo da homoj. Krome, servoj ricevos pli ol 90% de siaj enspezoj de streaming audio. La situacio kun video estas simila; terminoj kiel ni ludu, reta koncerto kaj reta kinejo jam enradikiĝis en la populara leksikono. Apple, Google, Jutubo kaj multaj aliaj kompanioj havas siajn proprajn fluajn servojn.

En ĝia frua enkonduko, CDN estis uzita ĉefe por retejoj kun senmova enhavo. Statika estas informo, kiu ne ŝanĝiĝas depende de uzant-agoj, tempo kaj aliaj faktoroj, t.e. ne estas personigita. Sed la pliiĝo de retsendado de video kaj sonservoj aldonis alian oftan uzkazon por distribuitaj retoj. Peraj serviloj, situantaj proksime al la celgrupo tra la mondo, ebligas disponigi stabilan aliron al enhavo dum periodoj de pinta ŝarĝo, forigante la mankon de interretaj proplempunktoj.

Kiel tio funkcias

La esenco de ĉiuj CDN-oj estas proksimume la sama: uzu perantojn por povi liveri enhavon al la fina konsumanto pli rapide. Ĝi funkcias jene: la uzanto sendas peton por elŝuti dosieron, ĝi estas ricevita de la CDN-servilo, kiu faras unufojan alvokon al la origina servilo kaj donas la enhavon al la uzanto. Paralele al ĉi tio, la CDN konservas dosierojn dum difinita tempodaŭro kaj prilaboras ĉiujn postajn petojn el sia propra kaŝmemoro. Laŭvole, ili ankaŭ povas antaŭŝargi dosierojn de la fontservilo, ĝustigi la konservan periodon de kaŝmemoro, kunpremi pezajn dosierojn kaj multe pli. En la plej ideala situacio, la gastiganto pasas la tutan rivereton al CDN-nodo, kiu jam uzas siajn proprajn rimedojn por liveri enhavon al uzantoj. Nekompreneblas, ke efika kaŝmemoro de informoj, same kiel distribuado de petoj ne al unu servilo, sed al la reto, kondukos al pli ekvilibra trafikŝarĝo.

La dua grava trajto de CDN-operacio estas la redukto de prokrastoj en transdono de datumoj (ankaŭ konata kiel RTT - rondvetura tempo). Establi TCP-konekton, elŝuti amaskomunikilan enhavon, JS-dosieron, komenci TLS-sesion, ĉio ĉi dependas de ping. Evidente, ju pli vi estas proksime al la fonto, des pli rapide vi povas ricevi respondon de ĝi. Ja eĉ la lumrapideco havas sian limon: ĉirkaŭ 200 mil km/s per optika fibro. Ĉi tio signifas, ke de Moskvo ĝis Vaŝingtono la prokrasto estos ĉirkaŭ 75 ms en RTT, kaj ĉi tio estas sen influo de mezaj ekipaĵoj.

Por pli bone kompreni, kiajn problemojn solvas enhavaj distribuaj retoj, jen listo de aktualaj solvoj:

• Google, Yandex, MaxCDN (uzu senpagajn CDN-ojn por distribui JS-bibliotekojn, havas pli ol 90 punktojn de ĉeesto en la plej multaj landoj de la mondo);
• Cloudinary, Cloudimage, Google (servoj kaj bibliotekoj pri optimumigo de klientoj: bildoj, filmetoj, tiparoj, ktp.);
• Jetpack, Incapsula, Swarmify, ktp. (optimumigo de rimedoj en enhav-administradsistemoj: bitrix, wordpress, ktp.);
• CDNVideo, StackPath, NGENIX, Megafon (CDN por distribuado de senmova enhavo, uzata kiel ĝeneralaj retoj);
• Imperva, Cloudflare (solvoj por akceli retejan ŝarĝon).

La unuaj 3 specoj de CDN el la listo estas dezajnitaj por transdoni nur parton de la trafiko de la ĉefa servilo. La ceteraj 2 estas uzataj kiel plenrajtaj prokurserviloj kun plena dissendo de kanaloj de la fontogastiganto.

Al kiu kaj kiaj avantaĝoj donas la teknologio?

En teorio, ajna retejo, kiu vendas siajn produktojn/servojn al kompaniaj klientoj aŭ individuoj (B2B aŭ B2C) povas profiti el efektivigo de CDN. Gravas, ke ĝia celgrupo, t.e. uzantbazo estis ekster ilia geografia loko. Sed eĉ se ĉi tio ne estas la kazo, distribuaj retoj helpos kun ŝarĝo-ekvilibro por grandaj volumoj de enhavo.

Ne estas sekreto, ke kelkaj mil fadenoj sufiĉas por ŝtopi servilan kanalon. Tial, distribuado de videoelsendoj al la ĝenerala publiko neeviteble kondukos al la formado de botelkolo - la bendolarĝo de la interreta kanalo. Ni vidas la samon kiam estas multaj malgrandaj, nekudritaj bildoj en retejo (produktaj antaŭprezentoj, ekzemple). La originservilo uzas unu TCP-konekton dum prilaborado de ajna nombro da petoj, kiuj vicigas la elŝuton. Aldonante CDN necesas distribui petojn tra pluraj domajnoj kaj uzi plurajn TCP-ligojn, malpezigante la kanalŝarĝon. Kaj la formulo de prokrasto de rondveturo, eĉ en la plej malĝojaj scenaroj, donas valoron de 6-7 RRT kaj prenas la formon: TCP+TLS+DNS. Ĉi tio ankaŭ inkluzivas prokrastojn asociitajn kun aktivigo de la radiokanalo sur la aparato kaj elsendado de la signalo al ĉelaj turoj.

Resuminte la fortojn de teknologio por interreta komerco, spertuloj emfazas la jenajn punktojn:

1. Rapida skalo de infrastrukturoj + reduktita bendolarĝo. Pli da serviloj = pli da punktoj kie informoj estas stokitaj. Kiel rezulto, unu punkto prilaboras malpli da trafiko per tempounuo, kio signifas, ke ĝi povas havi malpli da trafluo. Aldone, optimumigaj iloj funkcias, ebligante vin trakti pintajn ŝarĝojn sen perdi tempon.
2. Malpli ping. Ni jam menciis, ke homoj ne ŝatas longe atendi en Interreto. Tial alta ping kontribuas al altaj resaltaj indicoj. La prokrasto povas esti kaŭzita de problemoj kun datumtraktado sur la servilo, la uzo de malnova ekipaĵo, aŭ simple nebone pripensita reto topologio. Plej multaj el ĉi tiuj problemoj estas parte solvitaj de enhavaj distribuaj retoj. Kvankam estas grave rimarki ĉi tie, ke la reala profito de efektivigo de la teknologio nur estos videbla kiam la "konsumanta ping" superas 80-90 ms, kaj ĉi tiu estas la distanco de Moskvo ĝis Novjorko.

   

3. Sekureco de datumoj. DDos (Denial of Service virus-atakoj) celas kraŝi la servilon por akiri iun profiton. Unu servilo estas multe pli sentema al informsekurecaj vundeblecoj ol distribuita reto (instali la infrastrukturon de tia giganto kiel CloudFlare ne estas facila tasko). Danke al la uzo de filtriloj kaj taŭga distribuo de petoj tra la reto, vi povas facile malhelpi artefarite kreitajn malfacilaĵojn kun aliro al legitima trafiko.
4. Rapida dissendo de enhavo kaj pliaj servofunkcioj. Distribui grandajn kvantojn da informoj sur servila reto ebligos rapide transdoni la oferton al la fina konsumanto. Denove, vi ne bezonas serĉi malproksime ekzemplojn - nur memoru Amazon kaj AliExpress.
5. La kapablo "maski" problemojn kun la ĉefa retejo. Ne necesas atendi ĝis la DNS ĝisdatiĝos; vi povas transdoni ĝin al nova loko kaj distribui antaŭe konservitan enhavon. Ĉi tio siavice povas plibonigi misfunkciadon.

Ni ordigis la avantaĝojn. Nun ni rigardu, kiuj niĉoj profitas de ĉi tio.

Reklama komerco

Reklamado estas la motoro de progreso. Por malhelpi la motoron forbruli, ĝi devas esti ŝarĝita modere. Do la reklam-komerco, provanta trakti la modernan ciferecan mondon, alfrontas la problemojn de "peza enhavo". Peza amaskomunikilaro rilatas al plurmedia reklamado (ĉefe viglaj standardoj kaj filmetoj) kiu postulas altan retan bendolarĝon. Retejo kun plurmedio bezonas longan tempon por ŝarĝi kaj povas frostiĝi, provante la forton de la nervoj de uzantoj. Plej multaj homoj forlasas tiajn rimedojn eĉ antaŭ ol ili elŝutis ĉiujn disponeblajn informojn. Reklamaj kompanioj povas utiligi CDNojn por solvi ĉi tiujn problemojn.

Vendoj

E-komerco bezonas konstante vastigi sian geografian kovradon. Alia grava punkto estas la batalo kontraŭ konkurantoj, el kiuj estas multaj en ĉiu merkatsegmento. Se retejo ne plenumas uzantpostulojn (inkluzive longan tempon por ŝargi), ĝi ne estos populara kaj ne povos alporti konstante altajn konvertiĝojn. Efektivigi CDN devus pruvi ĝian avantaĝon en pritraktado de datenpetoj de malsamaj lokoj. Ankaŭ, trafika distribuo helpos malhelpi trafikajn pikilojn kaj postajn servilojn.

Platformoj kun distra enhavo

Ĉiuj specoj de distraj platformoj taŭgas ĉi tie, de elŝutado de filmoj kaj ludoj ĝis streaming videoj. Malgraŭ la fakto, ke la teknologio funkcias kun statikaj datumoj, fluaj datumoj povas atingi la uzanton pli rapide per ripetiloj. Denove, konservado de CDN-informoj estas savo por posedantoj de grandaj portaloj - plurmedia stokado.

Interretaj Ludoj

Interretaj ludoj devas esti metitaj en apartan sekcion. Se reklamado postulas grandan bendolarĝon, tiam interretaj projektoj eĉ pli postulas rimedojn. Provizantoj alfrontas problemon, kiu havas du flankojn: rapideco de aliro al serviloj + certigi altan ludadon kun belaj grafikaĵoj. CDN por interretaj ludoj estas ŝanco havi tiel nomatajn "puŝzonojn" kie programistoj povas stoki ludojn sur serviloj situantaj proksime al uzantoj. Ĉi tio permesas vin redukti la efikon de alirrapideco al la origina servilo, kaj tial certigi komfortan ludadon ĉie.

Kial CDN ne estas panaceo

Malgraŭ la evidentaj avantaĝoj, ne ĉiuj kaj ne ĉiam strebas enkonduki teknologion en sian komercon. Kial estas tio? Paradokse, kelkaj malavantaĝoj sekvas el la avantaĝoj, kaj pliaj kelkaj pliaj punktoj rilataj al reto-deplojo estas aldonitaj. Komercistoj bele parolos pri ĉiuj avantaĝoj de teknologio, forgesante mencii, ke ili ĉiuj fariĝas sensignifaj en ampleksa gamo de kondiĉoj. Se ni rigardas la malavantaĝojn de CDN pli detale, indas reliefigi:

• Laboru nur kun statiko. Jes, plej modernaj retejoj havas malaltan procenton de dinamika enhavo. Sed kie la paĝoj estas personigitaj, la CDN ne povos helpi (krom eble malŝarĝas grandan kvanton da trafiko);
• Prokrasto de kaŝmemoro. Optimumigo mem estas unu el la ĉefaj avantaĝoj de distribuaj retoj. Sed kiam vi faras ŝanĝon sur la originservilo, necesas tempo antaŭ ol la CDN rekaptas ĝin tra ĉiuj siaj serviloj;
• Amasaj blokadoj. Se ial la IP-adreso de CDN estas malpermesita, tiam ĉiuj retejoj, kiuj estas gastigitaj sur ĝi, estas fermitaj;
• Plejofte, la retumilo faros du konektojn (al la originservilo kaj la CDN). Kaj ĉi tiuj estas pliaj milisekundoj da atendado;
• Ligado al la IP-adreso de projektoj (inkluzive de neekzistantaj) kiuj antaŭe estis asignitaj al ĝi. Kiel rezulto, ni ricevas komplikajn rangotabelojn de Google-serĉaj robotoj kaj malfacilaĵoj por alporti la retejon al la supro dum SEO-promocio;
• La CDN-nodo estas ebla punkto de fiasko. Se vi uzas ilin, gravas anticipe kompreni kiel funkcias la sistemo-vojigo kaj kiaj eraroj povas okazi dum laborado kun la retejo;
• Ĝi estas banala, sed vi devas pagi por enhavaj liveraj servoj. Ĝenerale, kostoj estas proporciaj al la volumeno de trafiko, kio signifas ke kontroloj povas esti postulataj por plani la buĝeton.

Grava fakto: eĉ la proksimeco de la CDN al la uzanto ne garantias malaltan ping-on. La itinero povas esti konstruita de kliento al gastiganto situanta en alia lando aŭ eĉ sur alia kontinento. Ĉi tio dependas de la envojiga politiko de aparta reto kaj ĝia rilato kun teleentreprenistoj (peering). Multaj grandaj CDN-provizantoj havas plurajn planojn, kie la kosto rekte influas la proksimecon de la ĉeestpunkto dum liverado de enhavo al celuzantoj.

Estas ŝancoj - lanĉu vian propran CDN

Ĉu vi malĝojas pri la politikoj de kompanioj provizantaj enhavajn distribuajn retservojn, sed via komerco bezonas plivastigi? Se eble, kial ne provi lanĉi vian propran CDN. Ĉi tio havas sencon en la sekvaj kazoj:

• Nunaj kostoj por enhavdistribuo ne renkontas atendojn kaj ne estas ekonomie pravigitaj;
• Ni bezonas konstantan kaŝmemoron, sen proksimeco al aliaj retejoj sur la servilo kaj kanalo;
• La celgrupo estas en regiono kie ne estas CDN-punktoj disponeblaj por vi;
• La bezono personecigi agordojn dum liverado de enhavo;
• Necesas akceli la liveron de dinamika enhavo;
• Suspektoj pri malobservo de uzantprivateco kaj aliaj kontraŭleĝaj agoj flanke de triaj servoj.

Lanĉi CDN postulos, ke vi havu domajnan nomon, plurajn servilojn en malsamaj regionoj (virtuala aŭ dediĉita) kaj petan prilaboran ilon. Ne forgesu pri instalo de SLL-atestiloj, agordo kaj redaktado de programoj por servi statikan enhavon (Nginx aŭ Apache), kaj efike monitori la tutan sistemon.

Ĝusta agordo de kaŝmemorprokuriloj estas temo de aparta artikolo, do ni ne detale priskribos ĉi tie: kie kaj kian parametron agordi ĝuste. Konsiderante komencajn kostojn kaj tempon por deploji reton, uzi pretajn solvojn povas esti pli promesplena. Sed necesas esti gvidata de la nuna situacio kaj plani plurajn paŝojn antaŭen.

Kio estas la rezulto

CDN estas aro de pliaj kapabloj por elsendi vian trafikon al la amasoj. Ĉu ili bezonas por interreta komerco? Jes kaj ne, ĉio dependas de kia publiko estas celita la enhavo kaj kiajn celojn la komercisto persekutas.

Regionaj kaj tre specialigitaj projektoj ricevos pli da malavantaĝoj ol avantaĝoj de la efektivigo de CDN. Petoj ankoraŭ venos unue al la fontservilo, sed per peranto. Tial la dubinda redukto de ping, sed sufiĉe difinitaj monataj kostoj por uzado de la servo. Se vi havas bonan retan ekipaĵon, vi povas facile plibonigi ekzistantajn informsekurecajn algoritmojn, meti viajn servilojn pli proksime al uzantoj kaj ricevi optimumojn kaj profitojn senpage senpage.

Sed kiuj vere devus pensi pri peraj serviloj estas grandaj kompanioj, kies infrastrukturo ne povas elteni la konstante kreskantan fluon de trafiko. CDN montras sin perfekte kiel teknologio, kiu permesas vin rapide disfaldi reton al larĝa geografio de uzantoj, provizi komfortan nuban videoludadon aŭ vendi varojn sur granda komerca platformo.

Sed eĉ kun larĝa geografia spektantaro, estas grave kompreni antaŭe kial enhavaj distribuaj retoj estas bezonataj. Reteja akcelo ankoraŭ restas kompleksa tasko, kiu ne povas esti magie solvita per efektivigo de CDN. Ne forgesu pri tiaj gravaj funkcioj kiel: transplataforma, adaptebleco, optimumigo de la servila parto, kodo, bildigo ktp. Prepara teknika revizio kaj adekvataj mezuroj por forigi problemojn ankoraŭ estas la optimuma solvo por ajna interreta projekto, sendepende de ĝia fokuso kaj skalo.

Pri la Rajtoj de Reklamado

Vi povas mendi ĝuste nun potencaj servilojkiuj uzas la plej novajn procesorojn amd epyc. Flekseblaj planoj - de 1 CPU-kerno ĝis frenezaj 128 CPU-kernoj, 512 GB RAM, 4000 GB NVMe.

fonto: www.habr.com