[Mos] përdorni një CDN

Pothuajse çdo artikull ose mjet për optimizimin e shpejtësisë së faqes ka një klauzolë modeste "përdor një CDN". Në përgjithësi, CDN është një rrjet i ofrimit të përmbajtjes ose rrjet i ofrimit të përmbajtjes. Ne në Method Lab shpesh hasim pyetje nga klientët për këtë temë; disa prej tyre mundësojnë CDN-në e tyre. Qëllimi i këtij artikulli është të kuptojë se çfarë mund të ofrojë një CDN për sa i përket shpejtësisë së ngarkimit të faqes, çfarë problemesh mund të lindin dhe në cilat raste justifikohet përdorimi i një CDN.

Vonesat e rrethuara në foto janë shkaktuar nga përdorimi i një CDN.

Pak histori

Ashtu si shumë teknologji, CDN-të dolën nga nevoja. Me zhvillimin e kanaleve të Internetit midis përdoruesve të Internetit, u shfaqën shërbime video në internet. Natyrisht, përmbajtja e videos kërkon më shumë gjerësi bande në krahasim me përmbajtjen e zakonshme të faqes në internet (foto, tekst dhe kod CSS ose JS).

Kur përpiqeni të transmetoni një transmetim video paralelisht me shumë klientë nga një server, kanali i Internetit i serverit ka shumë të ngjarë të bëhet pengesa. Si rregull, disa mijëra fije janë të mjaftueshme për të bllokuar një kanal tipik të serverit. Sigurisht, mund të ketë kufizime të tjera të burimeve, por ato nuk janë të rëndësishme tani. Është gjithashtu e rëndësishme që zgjerimi i kanalit të serverit është shumë i shtrenjtë (dhe ndonjëherë i pamundur), dhe gjithashtu jopraktik. Ngarkesa në kanal gjatë transmetimeve do të jetë ciklike.

Problemi i kufizimit të kanalit të një serveri individual zgjidhet në mënyrë të përkryer nga CDN. Klientët nuk lidhen drejtpërdrejt me serverin, por me nyjet në rrjetin CDN. Në një situatë ideale, serveri dërgon një transmetim në nyjen CDN, dhe më pas rrjeti përdor burimet e veta për të ofruar këtë transmetim te shumë përdorues. Nga pikëpamja ekonomike, ne paguajmë vetëm për burimet e konsumuara në të vërtetë (kjo mund të jetë gjerësia e brezit ose trafiku) dhe marrim shkallëzim të shkëlqyer të shërbimit tonë. Përdorimi i një CDN për të ofruar përmbajtje të rëndë është plotësisht i justifikuar dhe logjik. Edhe pse vlen të përmendet se lojtarët më të mëdhenj në këtë hapësirë ​​(p.sh. Netflix) ndërtojnë CDN-të e tyre në vend që të përdorin CDN-të e mëdha komerciale (Akamai, Cloudflare, Fastly, etj.)

Ndërsa ueb-i ka evoluar, vetë aplikacionet në ueb janë bërë më komplekse dhe komplekse. Problemi i shpejtësisë së ngarkimit doli në pah. Të apasionuarit pas shpejtësisë së faqes në internet identifikuan shpejt disa probleme të mëdha që bënë që faqet e internetit të ngarkoheshin ngadalë. Një prej tyre ishte vonesat në rrjet (RTT - koha e udhëtimit vajtje-ardhje ose koha e ping-ut). Vonesat ndikojnë në shumë procese në ngarkimin e faqes në internet: vendosja e një lidhjeje TCP, fillimi i një sesioni TLS, ngarkimi i çdo burimi individual (imazhi, skedari JS, dokumenti HTML, etj.)

Problemi u përkeqësua nga fakti se kur përdorni protokollin HTTP/1.1 (para ardhjes së SPDY, QUIC dhe HTTP/2 ky ishte opsioni i vetëm), shfletuesit hapin jo më shumë se 6 lidhje TCP në një host. E gjithë kjo çoi në ndërprerjen e lidhjes dhe përdorimin joefikas të gjerësisë së brezit të kanalit. Problemi u zgjidh pjesërisht me ndarjen e domenit - krijimi i hosteve shtesë për të kapërcyer kufirin në numrin e lidhjeve.

Këtu shfaqet aftësia e dytë e CDN - zvogëlimi i vonesës (RTT) për shkak të numrit të madh të pikave dhe afërsisë së nyjeve me përdoruesin. Distanca luan një rol vendimtar këtu: shpejtësia e dritës është e kufizuar (rreth 200 km/sek në fibër optike). Kjo do të thotë që çdo 000 km udhëtim shton 1000 ms vonesë ose 5 ms në RTT. Kjo është koha minimale e nevojshme për transmetim, pasi ka edhe vonesa në pajisjet e ndërmjetme. Meqenëse një CDN zakonisht di se si t'i ruajë objektet në serverët e tij, ne mund të përfitojmë nga ngarkimi i objekteve të tilla përmes një CDN. Kushtet e nevojshme për këtë: prania e objektit në cache, afërsia e pikës CDN me përdoruesin në krahasim me serverin e aplikacionit në internet (serveri i origjinës). Është e rëndësishme të kuptohet se afërsia gjeografike e një nyje CDN nuk garanton vonesë të ulët. Drejtimi ndërmjet klientit dhe CDN-së mund të ndërtohet në atë mënyrë që klienti të lidhet me një host në një vend tjetër, dhe ndoshta në një kontinent tjetër. Këtu hyjnë në lojë marrëdhënia midis operatorëve të telekomit dhe shërbimit CDN (peering, lidhjet, pjesëmarrja në IX, etj.) dhe politika e drejtimit të trafikut të vetë CDN-së. Për shembull, Cloudflare, kur përdor dy plane fillestare (falas dhe të lirë), nuk garanton shpërndarjen e përmbajtjes nga hosti më i afërt - hosti do të zgjidhet për të arritur koston minimale.

Shumë kompani kryesore të internetit tërheqin interesin publik (zhvilluesit e uebit dhe pronarët e shërbimeve) për temën e shpejtësisë së ngarkimit dhe performancës së faqes në internet. Midis këtyre kompanive janë Yahoo (mjet Yslow), AOL (WebPageTest) dhe Google (shërbimi Page Speed ​​​​Insights), të cilat po zhvillojnë rekomandimet e tyre për përshpejtimin e faqeve (kryesisht ato kanë të bëjnë me optimizimin e klientit). Më vonë shfaqen mjete të reja për testimin e shpejtësisë së faqes në internet, të cilat ofrojnë edhe këshilla për rritjen e shpejtësisë së faqes në internet. Secili prej këtyre shërbimeve ose shtojcave ka një rekomandim të qëndrueshëm: "Përdor një CDN". Reduktimi i vonesës së rrjetit zakonisht përmendet si një shpjegim për efektin e CDN. Fatkeqësisht, jo të gjithë janë gati të kuptojnë saktësisht se si arrihet efekti i përshpejtimit të CDN dhe si mund të matet, kështu që rekomandimi merret mbi besimin dhe përdoret si postulat. Në fakt, jo të gjitha CDN-të janë krijuar të barabarta.

Duke përdorur një CDN Sot

Për të vlerësuar dobinë e përdorimit të CDN-ve, ato duhet të klasifikohen. Çfarë mund të gjendet tani në praktikë (shembuj në kllapa, natyrisht, nuk janë shterues):

1. CDN falas për shpërndarjen e bibliotekave JS (MaxCDN, Google. Yandex).
2. CDN e shërbimeve për optimizimin e klientit (për shembull, Google Fonts për fontet, Cloudinary, Cloudimage për imazhe).
3. CDN për optimizimin statik dhe të burimeve në CMS (i disponueshëm në Bitrix, WordPress dhe të tjerë).
4. CDN për qëllime të përgjithshme (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN për përshpejtimin e faqes në internet (Cloudflare, Imperva, Airi).

Dallimi kryesor midis këtyre llojeve është se sa nga trafiku kalon përmes CDN. Llojet 1-3 janë shpërndarja e vetëm një pjese të përmbajtjes: nga një kërkesë në disa dhjetra (zakonisht fotografi). Llojet 4 dhe 5 janë proksimi i plotë i trafikut nëpërmjet një CDN.

Në praktikë, kjo nënkupton numrin e lidhjeve që përdoren për të ngarkuar sitin. Me HTTP/2, ne përdorim një lidhje të vetme TCP me hostin për të përpunuar çdo numër kërkesash. Nëse i ndajmë burimet në hostin kryesor (origjinën) dhe CDN, atëherë është e nevojshme të shpërndahen kërkesat në disa domene dhe të krijohen disa lidhje TCP. Rasti më i keq është: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Kjo formulë nuk merr parasysh vonesat në rrjetet celulare për aktivizimin e kanalit radio të pajisjes (nëse nuk ishte aktiv) dhe vonesat në kullën celulare.

Ja se si duket në ujëvarën e ngarkimit të sajtit (vonesat për t'u lidhur me CDN janë theksuar në RTT 150 ms):

Nëse CDN mbulon të gjithë trafikun e faqes (përveç shërbimeve të palëve të treta), atëherë ne mund të përdorim një lidhje të vetme TCP, duke kursyer vonesat në lidhjen me hostet shtesë. Sigurisht, kjo vlen për lidhjet HTTP/2.

Dallimet e mëtejshme përcaktohen nga funksionaliteti i një CDN të veçantë - për llojin e parë ai thjesht pret një skedar statik, për të pestin po ndryshon disa lloje të përmbajtjes së faqes për qëllime optimizimi.

Aftësitë CDN për përshpejtimin e faqes në internet

Le të përshkruajmë gamën e plotë të aftësive CDN për përshpejtimin e faqeve, pa marrë parasysh funksionalitetin e llojeve individuale të CDN, dhe më pas të shohim se çfarë zbatohet në secilën prej tyre.

1. Kompresimi i burimeve të tekstit

Tipari më themelor dhe më i kuptueshëm, por shpesh i zbatuar dobët. Të gjitha CDN-të deklarojnë praninë e kompresimit si tipar të tyre të përshpejtimit. Por nëse shikoni më në detaje, mangësitë bëhen të qarta:

• mund të përdoren shkallë të ulëta për kompresim dinamik - 5-6 (për shembull, për gzip maksimumi është 9);
• Kompresimi statik (skedarët në cache) nuk përdor veçori shtesë (për shembull, zopfi ose brotli me shkallën 11)
• nuk ka mbështetje për kompresim efikas të brotli (duke kursyer rreth 20% në krahasim me gzip).

Nëse përdorni një CDN, ia vlen të kontrolloni këto disa pika: merrni skedarin që erdhi nga CDN, regjistroni madhësinë e tij të ngjeshur dhe ngjeshni manualisht për krahasim (mund të përdorni ndonjë shërbim online me mbështetjen e brotli, për shembull vsszhat.rf).

2. Vendosja e titujve të memorizimit të klientit

Gjithashtu një veçori e thjeshtë përshpejtimi: shtoni tituj për ruajtjen e përmbajtjes nga klienti (shfletuesi). Titulli më aktual është kontrolli i cache-it, ai i vjetëruar skadon. Për më tepër, Etag mund të përdoret. Gjëja kryesore është që mosha maksimale e kontrollit të cache-it është mjaft e madhe (nga një muaj ose më shumë).Nëse jeni gati të ruani sa më fort burimin, mund të shtoni opsionin e pandryshueshëm.

CDN-të mund të ulin vlerën maksimale të moshës, duke e detyruar përdoruesin të ringarkojë përmbajtjen statike më shpesh. Nuk është e qartë se me çfarë lidhet kjo: dëshira për të rritur trafikun në rrjet ose për të rritur përputhshmërinë me faqet që nuk dinë të rivendosin cache. Për shembull, koha e paracaktuar e cache-it të kokës së Cloudflare është 1 orë, e cila është shumë e ulët për të dhënat statike të pandryshueshme.

3. Optimizimi i imazhit

Meqenëse CDN merr funksionet e cachimit dhe shërbimit të imazheve, do të ishte logjike që ato të optimizoheshin në anën e CDN-së dhe t'u shërbenin përdoruesve në këtë formë. Le të bëjmë një rezervim menjëherë se kjo veçori është e disponueshme vetëm për llojet 2, 3 dhe 5 të CDN.

Mund të optimizoni imazhet në mënyra të ndryshme: duke përdorur formate të avancuara të kompresimit (si WebP), kodues më efikas (MozJPEG) ose thjesht duke pastruar meta të dhënat e panevojshme.

Në përgjithësi, ekzistojnë dy lloje të optimizimeve të tilla: me humbje të cilësisë dhe pa humbje të cilësisë. CDN-të zakonisht përpiqen të përdorin optimizimin pa humbje për të shmangur ankesat e mundshme të klientëve për ndryshimet në cilësinë e imazhit. Në kushte të tilla, fitimi do të jetë minimal. Në realitet, shpesh niveli i cilësisë JPEG është shumë më i lartë se sa duhet dhe ju mund të rikompresoni në mënyrë të sigurt me një nivel më të ulët cilësie pa kompromentuar përvojën e përdoruesit. Nga ana tjetër, është e vështirë të përcaktohet niveli i cilësisë dhe cilësimeve në mënyrë universale për të gjitha aplikacionet e mundshme në internet, kështu që CDN-të përdorin cilësime më konservatore në krahasim me ato që mund të aplikohen duke marrë parasysh kontekstin (qëllimin e imazheve, llojin e aplikacionit në internet , etj.)

4. Optimizimi i lidhjes TLS

Shumica e trafikut sot udhëton përmes lidhjeve TLS, që do të thotë se ne shpenzojmë kohë shtesë në negociatat TLS. Kohët e fundit, teknologjitë e reja janë zhvilluar për të përshpejtuar këtë proces. Për shembull, kjo është kriptografia EC, TLS 1.3, cache e sesioneve dhe biletat, përshpejtimi i enkriptimit të harduerit (AES-NI), etj. Vendosja e saktë e TLS mund të reduktojë kohën e lidhjes në 0-1 RTT (pa llogaritur DNS dhe TCP ).

Me softuer modern, nuk është e vështirë të zbatosh praktika të tilla vetë.

Jo të gjitha CDN-të zbatojnë praktikat më të mira të TLS; mund ta kontrolloni këtë duke matur kohën e lidhjes TLS (për shembull, në Webpagetest). Ideale për një lidhje të re - 1RTT, 2RTT - niveli mesatar, 3RTT dhe më shumë - i keq.

Gjithashtu duhet theksuar se edhe kur përdoret TLS në nivel CDN, serveri me web aplikacionin tonë duhet të përpunojë edhe TLS, por nga ana CDN, sepse trafiku ndërmjet serverit dhe CDN-së kalon në rrjetin publik. Në rastin më të keq, do të marrim vonesa të dyfishta të lidhjes TLS (e para në hostin CDN, e dyta midis tij dhe serverit tonë).

Për disa aplikacione, ia vlen t'i kushtohet vëmendje çështjeve të sigurisë: trafiku zakonisht deshifrohet në nyjet CDN, dhe kjo është një mundësi e mundshme për përgjimin e trafikut. Opsioni i punës pa zbulim të trafikut zakonisht ofrohet në planet tarifore më të larta për një tarifë shtesë.

5. Zvogëloni vonesat e lidhjes

Përfitimi kryesor i CDN për të cilin të gjithë flasin: vonesë e ulët (më pak distancë) midis hostit CDN dhe përdoruesit. Arrihet duke krijuar një arkitekturë rrjeti të shpërndarë gjeografikisht, në të cilën hostet janë të vendosur në pikat e përqendrimit të përdoruesve (qytetet, pikat e shkëmbimit të trafikut, etj.)

Në praktikë, prioritetet për rrjete të ndryshme mund të jenë në rajone specifike. Për shembull, CDN-të ruse do të kenë më shumë pika prezence në Rusi. Amerikanët fillimisht do ta zhvillojnë rrjetin në SHBA. Për shembull, një nga CDN Cloudflare më të mëdha ka vetëm 2 pika në Rusi - Moskë dhe Shën Petersburg. Kjo do të thotë, ne mund të kursejmë një maksimum prej rreth 10 ms vonesë në krahasim me vendosjen e drejtpërdrejtë në Moskë.

Shumica e CDN-ve perëndimore nuk kanë fare pika në Rusi. Duke u lidhur me ta, ju mund të rrisni vetëm vonesat për audiencën tuaj ruse.

6. Optimizimi i përmbajtjes (minimizimi, ndryshimet strukturore)

Pika më komplekse dhe më e avancuar teknologjikisht. Ndryshimi i përmbajtjes gjatë dorëzimit mund të jetë shumë i rrezikshëm. Edhe nëse marrim minifikimin: reduktimi i kodit burimor (për shkak të hapësirave shtesë, strukturave të parëndësishme, etj.) mund të ndikojë në performancën e tij. Nëse flasim për ndryshime më serioze - zhvendosja e kodit JS në fund të HTML, bashkimi i skedarëve, etj. - rreziku i prishjes së funksionalitetit të faqes është edhe më i lartë.

Prandaj, vetëm disa CDN të tipit 5 e bëjnë këtë. Sigurisht, nuk do të jetë e mundur të automatizohen të gjitha ndryshimet e nevojshme për të shpejtuar gjërat - kërkohet analiza manuale dhe optimizimi. Për shembull, heqja e kodit të papërdorur ose të kopjuar është një detyrë manuale.

Si rregull, të gjitha optimizimet e tilla kontrollohen nga cilësimet dhe ato më të rrezikshmet çaktivizohen si parazgjedhje.

Mbështetje për aftësitë e përshpejtimit sipas llojit CDN

Pra, le të hedhim një vështrim se cilat mundësi potenciale përshpejtimi ofrojnë llojet e ndryshme të CDN-ve.

Për lehtësi, ne përsërisim klasifikimin.

1. CDN falas për shpërndarjen e bibliotekave JS (MaxCDN, Google. Yandex).
2. CDN e shërbimeve për optimizimin e klientit (për shembull, Google Fonts për fontet, Cloudinary, Cloudimage për imazhe).
3. CDN për optimizimin statik dhe të burimeve në CMS (i disponueshëm në Bitrix, WordPress dhe të tjerë).
4. CDN për qëllime të përgjithshme (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN për përshpejtimin e faqes në internet (Cloudflare, Imperva, Airi).

Tani le të krahasojmë tiparet dhe llojet e CDN.

mundësi
Lloji 1
Lloji 2
Lloji 3
Lloji 4
Lloji 5

Kompresimi i tekstit
+–
-
+–
+–
+

Kokat e memories së memories
+
+
+
+
+

pictures
-
+–
+–
-
+

TLS
-
-
-
+–
+

Vonesat
-
-
-
+
+

Përmbajtje
-
-
-
-
+

Në këtë tabelë, "+" përdoret për të treguar mbështetje të plotë, "-" nuk është mbështetje dhe "+-" është mbështetje e pjesshme. Sigurisht, mund të ketë devijime nga kjo tabelë në realitet (për shembull, disa CDN me qëllime të përgjithshme do të zbatojnë veçori për optimizimin e imazheve), por për një ide të përgjithshme është e dobishme.

Rezultatet e

Shpresojmë, pasi të keni lexuar këtë artikull, do të keni një pamje më të qartë në lidhje me rekomandimin "përdorni një CDN" për të shpejtuar faqet tuaja.

Si në çdo biznes, ju nuk mund t'i besoni premtimeve të marketingut të ndonjë shërbimi. Efekti duhet të matet dhe të testohet në kushte reale. Nëse jeni duke përdorur tashmë një CDN, kontrolloni atë për efektivitet duke përdorur kriteret e përshkruara në artikull.

Është e mundur që përdorimi i një CDN tani po ngadalëson kohën e ngarkimit të faqes suaj.

Si rekomandim i përgjithshëm, ne mund të përqendrohemi në sa vijon: studioni audiencën tuaj, përcaktoni shtrirjen e saj gjeografike. Nëse audienca juaj kryesore është e përqendruar brenda një rrezeje prej 1-2 mijë kilometrash, nuk keni nevojë për një CDN për qëllimin e tij kryesor - uljen e vonesës. Në vend të kësaj, ju mund ta vendosni serverin tuaj më afër përdoruesve tuaj dhe ta konfiguroni atë siç duhet, duke marrë shumicën e optimizimeve të përshkruara në artikull (falas dhe të përhershëm).

Në rast se audienca juaj është me të vërtetë e shpërndarë gjeografikisht (rrezja prej më shumë se 3000 kilometra), përdorimi i një CDN cilësore do të jetë vërtet i dobishëm. Sidoqoftë, duhet të kuptoni paraprakisht se çfarë saktësisht CDN-ja juaj mund të shpejtojë (shih tabelën e aftësive dhe përshkrimin e tyre). Sidoqoftë, përshpejtimi i faqes në internet mbetet ende një detyrë komplekse që nuk mund të zgjidhet duke lidhur një CDN. Përveç optimizimeve të mësipërme, mjetet më efektive të përshpejtimit mbeten pas CDN: optimizimi i pjesës së serverit, ndryshimet e avancuara në pjesën e klientit (heqja e kodit të papërdorur, optimizimi i procesit të renderimit, puna me përmbajtjen, fontet, përshtatshmëria, etj. )

Burimi: www.habr.com