🥇[Ne] uzu CDN | ProHoster

Preskaŭ ĉiu artikolo aŭ ilo por optimumigi la rapidecon de la retejo havas modestan klaŭzon "uzu CDN". Ĝenerale, CDN estas enhavo-livera reto aŭ enhavo-livera reto. Ni ĉe Method Lab ofte renkontas demandojn de klientoj pri ĉi tiu temo; kelkaj el ili ebligas sian propran CDN. La celo de ĉi tiu artikolo estas kompreni, kion CDN povas provizi laŭ retejo-ŝarĝada rapideco, kiaj problemoj povas ekesti, kaj en kiuj kazoj la uzo de CDN estas pravigita.

La prokrastoj rondigitaj en la bildo estas kaŭzitaj de la uzo de CDN.

Iom da historio

Kiel multaj teknologioj, CDN-oj aperis pro neceso. Kun la disvolviĝo de interretaj kanaloj inter interretaj uzantoj aperis interretaj videoservoj. Kompreneble, videoenhavo postulas ordojn de grandeco pli da bendolarĝo kompare kun regula retejo enhavo (bildoj, teksto kaj CSS aŭ JS-kodo).

Kiam vi provas elsendi videofluon paralele al multaj klientoj de unu servilo, la interreta kanalo de la servilo plej verŝajne fariĝos la proplemkolo. Kiel regulo, kelkaj miloj da fadenoj sufiĉas por ŝtopi tipan servilan kanalon. Kompreneble, povas esti aliaj limigoj de rimedoj, sed ili ne estas gravaj nun. Ankaŭ gravas, ke vastigi la servilan kanalon estas tro multekosta (kaj foje neebla), kaj ankaŭ nepraktika. La ŝarĝo sur la kanalo dum elsendoj estos cikla.

La problemo limigi la kanalon de individua servilo estas perfekte solvita de CDN. Klientoj ne konektas rekte al la servilo, sed al nodoj en la CDN-reto. En ideala situacio, la servilo sendas unu fluon al la CDN-nodo, kaj tiam la reto uzas siajn proprajn rimedojn por liveri ĉi tiun fluon al multaj uzantoj. De ekonomia vidpunkto, ni pagas nur por la rimedoj efektive konsumitaj (ĉi tio povus esti larĝa de bando aŭ trafiko) kaj ricevas bonegan skaleblon de nia servo. Uzi CDN por liveri pezan enhavon estas tute pravigita kaj logika. Kvankam indas rimarki, ke la plej grandaj ludantoj en ĉi tiu spaco (ekz. Netflix) konstruas siajn proprajn CDN-ojn anstataŭ uzi grandajn komercajn CDN-ojn (Akamai, Cloudflare, Fastly, ktp.)

Dum la reto evoluis, TTT-aplikoj mem fariĝis pli kompleksaj kaj kompleksaj. La problemo de ŝarĝrapideco aperis. Entuziasmuloj pri rapideco de retejoj rapide identigis plurajn gravajn problemojn, kiuj kaŭzis retejojn malrapide ŝargi. Unu el ili estis retprokrastoj (RTT - rondvetura tempo aŭ ping-tempo). Prokrastoj influas multajn procezojn en reteja ŝarĝo: establi TCP-konekton, komenci TLS-sesion, ŝarĝi ĉiun individuan rimedon (bildo, JS-dosiero, HTML-dokumento, ktp.)

La problemo estis pligravigita de la fakto, ke uzante la HTTP/1.1-protokolon (antaŭ la apero de SPDY, QUIC kaj HTTP/2 ĉi tio estis la sola opcio), retumiloj malfermas ne pli ol 6 TCP-konektoj al unu gastiganto. Ĉio ĉi kondukis al ligmalfunkcio kaj malefika uzo de kanala bendolarĝo. La problemo estis parte solvita per domajna sharding - la kreado de pliaj gastigantoj por venki la limon de la nombro da konektoj.

Ĉi tie aperas la dua kapablo de CDN - reduktanta latencia (RTT) pro la granda nombro da punktoj kaj la proksimeco de nodoj al la uzanto. Distanco ludas ĉi tie decidan rolon: la lumrapideco estas limigita (ĉirkaŭ 200 000 km/sec en optika fibro). Ĉi tio signifas, ke ĉiu 1000 km da vojaĝo aldonas 5 ms da prokrasto aŭ 10 ms al RTT. Ĉi tio estas la minimuma tempo bezonata por transsendo, ĉar ankaŭ estas prokrastoj ĉe la meza ekipaĵo. Ĉar CDN kutime scias kiel kaŝmemori objektojn sur siaj serviloj, ni povas profiti ŝarĝante tiajn objektojn per CDN. Necesaj kondiĉoj por ĉi tio: la ĉeesto de la objekto en la kaŝmemoro, la proksimeco de la CDN-punkto al la uzanto kompare kun la ret-aplika servilo (devenservilo). Gravas kompreni, ke geografia proksimeco de CDN-nodo ne garantias malaltan latentecon. Itinero inter la kliento kaj la CDN povas esti konstruita tiel ke la kliento konektos al gastiganto en alia lando, kaj eble sur alia kontinento. Ĉi tie eniras la rilaton inter teleentreprenistoj kaj la CDN-servo (peering, konektoj, partopreno en IX, ktp.) kaj la trafikvojigo-politiko de la CDN mem. Ekzemple, Cloudflare, kiam vi uzas du komencajn planojn (senpaga kaj malmultekosta), ne garantias la liveron de enhavo de la plej proksima gastiganto - la gastiganto estos elektita por atingi la minimuman koston.

Multaj ĉefaj interretaj kompanioj altiras publikan intereson (retaj programistoj kaj servaj posedantoj) al la temo de ŝarĝo-rapideco kaj reteja rendimento. Inter ĉi tiuj kompanioj estas Yahoo (Yslow-ilo), AOL (WebPageTest) kaj Google (servo de Page Speed Insights), kiuj disvolvas siajn proprajn rekomendojn por akceli retejojn (ĉefe ili rilatas al klienta optimumigo). Poste aperas novaj iloj por testaj rapideco de retejoj, kiuj ankaŭ donas konsilojn pri pliigo de rapideco de la retejo. Ĉiu el ĉi tiuj servoj aŭ kromprogramoj havas konsekvencan rekomendon: "Uzu CDN." La redukto en retlatenteco estas kutime citita kiel klarigo por la efiko de CDN. Bedaŭrinde, ne ĉiuj pretas kompreni ĝuste kiel la akcela efiko de CDN estas atingita kaj kiel ĝi povas esti mezurita, do la rekomendo estas prenita sur fido kaj uzata kiel postulato. Fakte, ne ĉiuj CDN-oj estas kreitaj egalaj.

Uzante CDN Hodiaŭ

Por taksi la utilecon uzi CDNojn, ili devas esti klasifikitaj. Kio troveblas nun en la praktiko (la ekzemploj inter krampoj estas, kompreneble, ne ĝisfundaj):

Senpaga CDN por distribuado de JS-bibliotekoj (MaxCDN, Google. Yandex).
CDN de servoj por optimumigo de klientoj (ekzemple, Google Tiparoj por tiparoj, Cloudinary, Cloudimage por bildoj).
CDN por statika kaj rimeda optimumigo en CMS (disponebla en Bitrix, WordPress kaj aliaj).
Ĝenerala celo CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN por reteja akcelo (Cloudflare, Imperva, Airi).

La ŝlosila diferenco inter ĉi tiuj tipoj estas kiom da trafiko trairas la CDN. Tipoj 1-3 estas la livero de nur parto de la enhavo: de unu peto ĝis kelkaj dekoj (kutime bildoj). Tipoj 4 kaj 5 estas plena prokurado de trafiko per CDN.

En la praktiko, ĉi tio signifas la nombron da konektoj uzataj por ŝarĝi la retejon. Kun HTTP/2, ni uzas ununuran TCP-konekton al la gastiganto por procesi ajnan nombron da petoj. Se ni dividas rimedojn en la ĉefa gastiganto (deveno) kaj CDN, tiam necesas distribui petojn tra pluraj domajnoj kaj krei plurajn TCP-ligojn. La plej malbona kazo estas: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Ĉi tiu formulo ne konsideras prokrastojn en moveblaj retoj por aktivigo de la radiokanalo de la aparato (se ĝi ne estis aktiva) kaj prokrastojn sur la ĉela turo.

Jen kiel ĝi aspektas sur la ŝarĝa akvofalo de la retejo (latentecoj por konekti al la CDN estas emfazitaj je RTT 150 ms):

Se la CDN kovras la tutan trafikon de la retejo (krom triaj servoj), tiam ni povas uzi ununuran TCP-konekton, ŝparante prokrastojn pri konekto al pliaj gastigantoj. Kompreneble, ĉi tio validas por HTTP/2-konektoj.

Pliaj diferencoj estas determinitaj de la funkcieco de aparta CDN - por la unua tipo ĝi nur gastigas statikan dosieron, por la kvina ĝi ŝanĝas plurajn specojn de retejo enhavo por optimumigo.

CDN-kapabloj por reteja akcelo

Ni priskribu la plenan gamon de CDN-kapabloj por akceli retejojn, sen konsidero al la funkcieco de individuaj specoj de CDN, kaj poste vidu kio estas efektivigita en ĉiu el ili.

1. Kunpremo de tekstaj rimedoj

La plej baza kaj komprenebla trajto, tamen ofte malbone efektivigita. Ĉiuj CDN-oj deklaras la ĉeeston de kunpremado kiel sia akceltrajto. Sed se vi rigardas pli detale, mankoj evidentiĝas:

malaltaj gradoj por dinamika kunpremo povas esti uzataj - 5-6 (ekzemple, por gzip la maksimumo estas 9);
Senmova kunpremo (dosieroj en kaŝmemoro) ne uzas kromajn funkciojn (ekzemple zopfi aŭ brotli kun grado 11)
ne ekzistas subteno por efika brotli-kunpremado (ŝparante ĉirkaŭ 20% kompare kun gzip).

Se vi uzas CDN, indas kontroli ĉi tiujn kelkajn punktojn: prenu la dosieron kiu venis el la CDN, registri ĝian kunpremitan grandecon kaj kunpremu ĝin permane por komparo (vi povas uzi iun retan servon kun brotli-subteno, ekzemple). vsszhat.rf).

2. Agordi klientajn kaŝmemorajn kapliniojn

Ankaŭ simpla rapidiga funkcio: aldonu kapliniojn por konservado de enhavo de la kliento (retumilo). La plej aktuala kaplinio estas kaŝmemoro-kontrolo, la malmoderna eksvalidiĝas. Aldone, Etag povas esti uzata. La ĉefa afero estas, ke la maksimuma aĝo de kaŝkontrolo estas sufiĉe granda (de unu monato aŭ pli).Se vi pretas konservi la rimedon kiel eble plej malfacile, vi povas aldoni la neŝanĝeblan opcion.

CDNoj povas malaltigi la maksimuman aĝan valoron, devigante la uzanton reŝargi senmovan enhavon pli ofte. Ne estas klare, al kio tio rilatas: la deziro pliigi trafikon en la reto aŭ pliigi kongruon kun retejoj, kiuj ne scias kiel restarigi la kaŝmemoron. Ekzemple, la defaŭlta Cloudflare-kapa kaŝmemortempo estas 1 horo, kiu estas tre malalta por neŝanĝeblaj senmovaj datumoj.

3. Bilda optimumigo

Ĉar la CDN prenas la funkciojn de kaŝmemoro kaj servado de bildoj, estus logike optimumigi ilin ĉe la CDN-flanko kaj servi ilin al uzantoj en ĉi tiu formo. Ni faru tuj rezervo, ke ĉi tiu funkcio nur disponeblas por CDN-tipoj 2, 3 kaj 5.

Vi povas optimumigi bildojn en diversaj manieroj: uzante altnivelajn kunpremajn formatojn (kiel WebP), pli efikajn kodilojn (MozJPEG), aŭ simple purigante nenecesajn metadatenojn.

Ĝenerale, estas du specoj de tiaj optimumigoj: kun kvalita perdo kaj sen kvalita perdo. CDN-oj kutime strebas uzi senperdan optimumigon por eviti eblajn klientajn plendojn pri ŝanĝoj en bildkvalito. En tiaj kondiĉoj, la gajno estos minimuma. En realeco, ofte la JPEG-kvalita nivelo estas multe pli alta ol necesa kaj vi povas sekure rekomprimi kun pli malalta kvalita nivelo sen endanĝerigi la uzantan sperton. Aliflanke, estas malfacile determini la nivelon de kvalito kaj agordojn universale por ĉiuj eblaj TTT-aplikoj, do CDNoj uzas pli konservativan agordojn kompare kun tiuj, kiuj povas esti aplikataj konsiderante la kuntekston (celo de bildoj, speco de TTT-apliko. , ktp.)

4. Optimumigo de la TLS-konekto

Plej multe de la trafiko hodiaŭ vojaĝas tra TLS-konektoj, kio signifas, ke ni pasigas kroman tempon por TLS-intertraktado. Lastatempe, novaj teknologioj estis evoluigitaj por akceli ĉi tiun procezon. Ekzemple, ĉi tio estas EC-kriptografio, TLS 1.3, sesiokaŝmemoro kaj biletoj, aparatara ĉifrada akcelo (AES-NI), ktp. Ĝuste agordi TLS povas redukti konektan tempon al 0-1 RTT (sen kalkuli DNS kaj TCP ).

Kun moderna programaro, ne estas malfacile efektivigi tiajn praktikojn memstare.

Ne ĉiuj CDN-oj efektivigas TLS-ajn plej bonajn praktikojn; vi povas kontroli tion mezurante la TLS-konektotempon (ekzemple, en Webpagetest). Ideala por nova konekto - 1RTT, 2RTT - meza nivelo, 3RTT kaj pli - malbona.

Oni ankaŭ rimarku, ke eĉ kiam oni uzas TLS ĉe la CDN-nivelo, la servilo kun nia retejo-aplikaĵo ankaŭ devas prilabori TLS, sed de la CDN-flanko, ĉar la trafiko inter la servilo kaj la CDN pasas sur la publika reto. En la plej malbona kazo, ni ricevos duoblajn prokrastojn pri konekto TLS (la unua al la CDN-gastiganto, la dua inter ĝi kaj nia servilo).

Por iuj aplikoj, indas atenti sekurecajn problemojn: trafiko estas kutime deĉifrita sur CDN-nodoj, kaj ĉi tio estas ebla ŝanco por trafika interkapto. La opcio labori sen trafika malkaŝo estas kutime ofertita en supraj tarifplanoj kontraŭ plia kotizo.

5. Redukti konekton malfruojn

La ĉefa avantaĝo de CDN pri kiu ĉiuj parolas: malalta latencia (malpli distanco) inter la CDN-gastiganto kaj la uzanto. Atingite per kreado de geografie distribuita reto-arkitekturo, en kiu gastigantoj situas en punktoj de koncentriĝo de uzantoj (urboj, trafikinterŝanĝpunktoj, ktp.)

En praktiko, prioritatoj por malsamaj retoj povas esti en specifaj regionoj. Ekzemple, rusaj CDN-oj havos pli da punktoj de ĉeesto en Rusio. La usonanoj antaŭ ĉio disvolvos la reton en Usono. Ekzemple, unu el la plej grandaj CDN Cloudflare havas nur 2 poentojn en Rusio - Moskvo kaj Sankt-Peterburgo. Tio estas, ni povas ŝpari maksimume ĉirkaŭ 10 ms da latenteco kompare kun rekta lokigo en Moskvo.

Plej okcidentaj CDN-oj tute ne havas punktojn en Rusio. Konektante al ili, vi nur povas pliigi la prokrastojn por via rusa publiko.

6. Optimumigo de enhavo (miniigo, strukturaj ŝanĝoj)

La plej kompleksa kaj teknologie progresinta punkto. Ŝanĝi enhavon dum livero povas esti tre riska. Eĉ se ni prenas minigon: redukti la fontkodon (pro kromaj spacoj, negravaj strukturoj, ktp.) povas influi ĝian agadon. Se ni parolas pri pli seriozaj ŝanĝoj - movi la JS-kodon al la fino de la HTML, kunfandi dosierojn ktp. - la risko interrompi la funkciecon de la retejo estas eĉ pli alta.

Tial nur iuj tipo 5 CDN-oj faras tion. Kompreneble, ne eblos aŭtomatigi ĉiujn ŝanĝojn necesajn por akceli aferojn — necesas mana analizo kaj optimumigo. Ekzemple, forigi neuzatan aŭ duplikatan kodon estas mana tasko.

Kiel regulo, ĉiuj tiaj optimumigoj estas kontrolataj de agordoj kaj la plej danĝeraj estas malebligitaj defaŭlte.

Subteno por akcelaj kapabloj laŭ CDN-tipo

Do ni rigardu kiajn eblajn akcelajn ŝancojn provizas la malsamaj tipoj de CDN-oj.

Por komforto, ni ripetas la klasifikon.

Senpaga CDN por distribuado de JS-bibliotekoj (MaxCDN, Google. Yandex).
CDN de servoj por optimumigo de klientoj (ekzemple, Google Tiparoj por tiparoj, Cloudinary, Cloudimage por bildoj).
CDN por statika kaj rimeda optimumigo en CMS (disponebla en Bitrix, WordPress kaj aliaj).
Ĝenerala celo CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN por reteja akcelo (Cloudflare, Imperva, Airi).

Nun ni komparu la funkciojn kaj specojn de CDN.

Ebleco
Tajpu 1
Tajpu 2
Tajpu 3
Tajpu 4
Tajpu 5

Teksto kunpremo
+–
-
+–
+–
+

Kaŝkaptaĵoj
+
+
+
+
+

Bildoj
-
+–
+–
-
+

TLS
-
-
-
+–
+

Malfruoj
-
-
-
+
+

Enhavo
-
-
-
-
+

En ĉi tiu tabelo, "+" estas uzata por indiki plenan subtenon, "-" estas neniu subteno, kaj "+-" estas parta subteno. Kompreneble, povas esti devioj de ĉi tiu tabelo en realeco (ekzemple, iu ĝeneraluzebla CDN efektivigos funkciojn por optimumigi bildojn), sed por ĝenerala ideo ĝi estas utila.

Rezultoj

Espereble, post legado de ĉi tiu artikolo vi havos pli klaran bildon pri la rekomendo "uzu CDN" por akceli viajn retejojn.

Kiel en iu ajn komerco, vi ne povas kredi la merkatajn promesojn de iu ajn servo. La efiko devas esti mezurita kaj provita en realaj kondiĉoj. Se vi jam uzas CDN, kontrolu ĝin por efikeco uzante la kriteriojn priskribitajn en la artikolo.

Eblas, ke uzi CDN nun malrapidigas la ŝarĝan tempon de via retejo.

Kiel ĝenerala rekomendo, ni povas koncentriĝi pri la sekvanta: studi vian publikon, determini ĝian geografian amplekson. Se via ĉefa spektantaro koncentriĝas ene de radiuso de 1-2 mil kilometroj, vi ne bezonas CDN por ĝia ĉefa celo - redukti latencia. Anstataŭe, vi povas meti vian servilon pli proksime al viaj uzantoj kaj agordi ĝin ĝuste, ricevante la plej multajn el la optimumigoj priskribitaj en la artikolo (senpaga kaj konstanta).

Se via publiko estas vere geografie distribuita (radiuso de pli ol 3000 kilometroj), uzi kvalitan CDN vere estos utila. Tamen, vi devas anticipe kompreni, kion precize via CDN povas akceli (vidu la tabelon de kapabloj kaj ilian priskribon). Tamen, reteja akcelo ankoraŭ restas kompleksa tasko, kiu ne povas esti solvita per konekto de CDN. Krom ĉi-supraj optimumigoj, la plej efikaj rimedoj de akcelo restas malantaŭ la CDN: optimumigo de la servila parto, altnivelaj ŝanĝoj al la klienta parto (forigo de neuzata kodo, optimumigo de la bildigo, laborado kun enhavo, tiparoj, adaptebleco ktp. )

fonto: www.habr.com

[Ne] uzu CDN