Në pothuajse çdo artikull ose mjet për optimizimin e shpejtësisë së përgjigjes së faqeve të internetit, ka një pikë të përmendur: "përdorni CDN". Në thelb, CDN nënkupton rrjetin e shpërndarjes së përmbajtjes. Ne në kompaninë "Metod Lab" shpesh hasim pyetje nga klientët mbi këtë temë, disa vetë e aktivizojnë CDN. Qëllimi i këtij artikulli është të kuptojmë se çfarë përfitimesh mund të sjellë CDN në aspektin e shpejtësisë së ngarkesës së faqes, cilat probleme mund të lindin dhe në cilat raste përdorimi i CDN është i justifikuar.
![[ĐĐ”] pĂ«rdorni CDN](/wp-content/uploads/2019/10/6f32a7973856989f2adac4171a6ef9dd.jpg)
Ngadalësitë e shënuara në figurë janë rezultat i përdorimit të CDN.
Pak histori
Siç ndodh me shumë teknologji, CDN u shfaq si një nevojë. Me zhvillimin e kanaleve të internetit për përdoruesit e rrjetit, u shfaqën shërbime të videove në internet. Natyrisht, përmbajtja video kërkon një kapacitet shumë më të madh krahasuar me përmbajtjen standarde të faqeve (imazhe, tekst dhe kod CSS ose JS).
Kur përpiqeni të transmetoni një rrjedhë video në mënyrë të njëhershme për shumë klientë nga një server, ngushtimi më i mundshëm do të jetë kanali i internetit të serverit. Zakonisht, mjaftojnë disa mijëra rrjedha për të mbushur një kanal tipik serveri. Sigurisht, mund të ketë edhe kufizime të tjera në burime, por tani nuk janë të rëndësishme. Po ashtu, është e rëndësishme që zgjerimi i kanalit të serverit është shumë i shtrenjtë (dhe ndonjëherë i pamundur), si dhe jo funksional. Ngarkesa në kanal gjatë transmetimeve do të ketë një karakter ciklik.
Problemi i kufizimit të kanalit të një serveri të veçantë zgjidhet shkëlqyeshëm nga CDN. Klientët lidhen jo direkt me serverin, por me nyje të rrjetit CDN. Në situatën ideale, serveri dërgon një rrjedhë në nyjën CDN, dhe më pas rrjeti përdor burimet e tij për të shpërndarë këtë rrjedhë për të shumë përdoruesve. Nga një pikëpamje ekonomike, ne paguajmë vetëm për burimet e konsumuar në mënyrë efektive (kjo mund të jetë kapaciteti i transmetimit ose trafiku) dhe arrijmë një shkallëzueshmëri të shkëlqyer të shërbimit tonë. Përdorimi i CDN për shpërndarjen e përmbajtjes së rëndë është plotësisht i justifikuar dhe logjik. Megjithatë, duhet të theksohet që lojtarët më të mëdhenj në këtë fushë (p.sh., Netflix) ndajnë CDN-të e tyre përpara se të përdorin CDN-të e mëdha komerciale (Akamai, Cloudflare, Fastly etj.).
Me zbatimin e internetit, aplikacionet web filluan të bëhen më komplekse dhe më të rëndë. Problemi i shpejtësisë së ngarkesës doli në pah. Entuziastët e shpejtësisë së faqeve të internetit shpejt identifikuan disa nga problemet kryesore që çonin në ngarkesë të ngadaltë. Një nga to ishin vonesat në rrjet (RTT - round trip time ose koha e ping). Vonesat ndikojnë në shumë procese gjatë ngarkesës së faqes: krijimin e lidhjes TCP, fillimin e sesionit TLS, ngarkimin e çdo burimi individual (imazhe, skedarë JS, dokumente HTML, etj.)
Problemi u pĂ«rkeqĂ«sua nga fakti se, nĂ« pĂ«rdorimin e protokollit HTTP/1.1 (deri nĂ« shfaqjen e SPDY, QUIC dhe HTTP/2, ky ishte opsioni i vetĂ«m), shfletuesit hapin jo mĂ« shumĂ« se 6 lidhje TCP me njĂ« host. TĂ« gjitha kĂ«to çonin nĂ« zbrazje tĂ« lidhjes dhe pĂ«rdorim tĂ« papĂ«rshtatshĂ«m tĂ« kapacitetit tĂ« kanalit. Problemi u zgjidh paksa me ndarjen e domain-it â krijimin e hosteve tĂ« tjera pĂ«r tĂ« kaluar kufirin pĂ«r numrin e lidhjeve.
KĂ«tu shfaqet kapaciteti i dytĂ« i CDN - reduktimi i vonesave (RTT) pĂ«rmes numrit tĂ« madh tĂ« pikave dhe afĂ«rsisĂ« sĂ« nyjeve me pĂ«rdoruesin. Distanca luan njĂ« rol kyç kĂ«tu: shpejtĂ«sia e dritĂ«s Ă«shtĂ« e kufizuar (rreth 200,000 km/s nĂ« fibra optike). KĂ«shtu, çdo 1000 km rrugĂ« shton 5 ms vonesa ose 10 ms nĂ« RTT. KĂ«to janĂ« shpenzime minimale tĂ« kohĂ«s pĂ«r transferim, pasi ka edhe vonesa nĂ« pajisjet ndĂ«rmjetĂ«se. Duke qenĂ« se CDN zakonisht mund tĂ« ruajĂ« objekte nĂ« serverĂ«t e saj, ne mund tĂ« pĂ«rfitojmĂ« nga ngarkimi i kĂ«tyre objekteve pĂ«rmes CDN. Kushte tĂ« nevojshme pĂ«r kĂ«tĂ«: prania e objektit nĂ« cache dhe afĂ«rsia e pikĂ«s CDN me pĂ«rdoruesin nĂ« krahasim me serverin e aplikacionit web (serverin origjinal). ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet: afĂ«rsia gjeografike e nyjes CDN nuk garanton vonesa tĂ« ulĂ«ta. RrugĂ«zimi midis klientit dhe CDN mund tĂ« ndĂ«rtohet nĂ« njĂ« mĂ«nyrĂ« qĂ« klienti tĂ« lidhet me njĂ« host nĂ« njĂ« vend tjetĂ«r, madje ndoshta edhe nĂ« njĂ« kontinent tjetĂ«r. KĂ«tu hyjnĂ« nĂ« lojĂ« marrĂ«dhĂ«niet e operatorĂ«ve tĂ« komunikimit dhe shĂ«rbimi CDN (peering, ekzistenca e lidhjeve, pjesĂ«marrja nĂ« IX, etj.) dhe politika e rrugĂ«zimit tĂ« trafikut e vetĂ« CDN-sĂ«. PĂ«r shembull, Cloudflare, kur pĂ«rdor dy planet fillestare (tĂ« lirĂ« dhe tĂ« pĂ«rballueshme) nuk garanton dorĂ«zimin e pĂ«rmbajtjes nga nyja mĂ« e afĂ«rt - zgjedhja e hostit do tĂ« bĂ«het pĂ«r tĂ« arritur koston mĂ« minimale.
Shumë kompani të njohura në internet tërheqin interesin e publikut (web-developerëve dhe pronarëve të shërbimeve) në temën e shpejtësisë së ngarkesës dhe punës së faqeve. Mes këtyre kompanive janë Yahoo (mjeti Yslow), AOL (WebPageTest) dhe Google (shërbimi Page Speed Insights), të cilat hartojnë rekomandime për përshpejtimin e faqeve (përgjithësisht ato lidhen me optimizimin e klientëve). Më vonë shfaqen mjete të reja për testimin e shpejtësisë së faqeve, të cilat gjithashtu japin këshilla për rritjen e shpejtësisë së faqeve. Në çdo një nga këto shërbime ose plugins ka një rekomandim të pandryshuar "Përdorni CDN". Për të shpjeguar efektin e CDN zakonisht përmendet ulja e vonesave në rrjet. Fatkeqësisht, jo të gjithë janë të gatshëm të kuptojnë se si arrihet efektin e përshpejtimit nga CDN dhe si mund të matet, prandaj rekomandimi pranohet në besim dhe përdoret si postulati. Në të vërtetë, aspak të gjitha CDN janë në mënyrë të barabartë të dobishme.
PĂ«rdorimi i CDN sot
PĂ«r tĂ« vlerĂ«suar dobishmĂ«rinĂ« e aplikimit tĂ« CDN, ato duhen klasifikuar. ĂfarĂ« mund tĂ« takoni tani nĂ« praktikĂ« (shembujt nĂ« paranteza natyrisht nuk janĂ« shterues):
- CDN falas për shpërndarjen e JS-librarive (MaxCDN, Google, Yandex).
- CDN shërbimesh për optimizimin e klientëve (për shembull Google Fonts për fonte, Cloudinary, Cloudimage për imazhe).
- CDN për statikë dhe optimizimin e burimeve në CMS (është në Bitrix, WordPress dhe të tjera).
- CDN për përdorim të përgjithshëm (StackPath, CDNVideo, NGENIX, Megafon).
- CDN për përshpejtimin e faqeve (Cloudflare, Imperva, Airi).
Dallimi kryesor midis këtyre llojeve qëndron në këtë: cila pjesë e trafik të kalon përmes CDN. Llojet 1-3 përbëjnë shpërndarjen e vetëm një pjese të përmbajtjes: nga një kërkesë deri në disa dhjetëra (zakonisht imazhe). Llojet 4 dhe 5 përbëjnë proksimin e plotë të trafik të përmes CDN.
Në praktikë, kjo do të thotë numri i lidhjeve që përdoren për ngarkimin e faqes. Kur përdorim HTTP/2 ne përdorim një lidhje TCP me host-in për të përpunuar çdo numër kërkesash. Nëse ne ndajmë burimet në hostin kryesor (origin) dhe CDN, atëherë është e nevojshme të ndahen kërkesat në disa domene dhe të krijohen disa lidhje TCP. Në rastin më të keq, kjo është: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Në këtë formulë nuk merren parasysh vonesat në rrjetet mobile për aktivizimin e kanalit radio të pajisjes (nëse ai nuk është aktiv) dhe vonesat në kullën celular.
Këtu është si duket në ujëvarën e ngarkesës së faqes së internetit (vonesat për lidhjen me CDN janë theksuar me RTT 150 ms):
![[ĐĐ”] pĂ«rdorni CDN](/wp-content/uploads/2019/10/d0aafcc5aa4dff6c8a97307f39c8c025.jpg)
Nëse CDN mbulon të gjithë trafikun e faqes (përveç shërbimeve të jashtme), atëherë ne mund të përdorim një lidhje TCP të vetme, duke kursyer vonesat për lidhjen me hoste të tjerë. Sigurisht, kjo i përket lidhjeve HTTP/2.
Dallimet e mĂ«tejshme pĂ«rcaktohen nga funksionaliteti i CDN-ve specifike â pĂ«r llojin e parĂ« Ă«shtĂ« vetĂ«m hosting njĂ« skedari statik, pĂ«r tĂ« pestin kjo nĂ«nkupton ndryshimin e disa llojeve tĂ« pĂ«rmbajtjes sĂ« faqes me qĂ«llim optimizimin.
Kapacitetet e CDN për të përshpejtuar faqen
Le të përshkruajmë gamën e plotë të mundësive të CDN-ve për të përshpejtuar faqet e internetit, pa marrë parasysh funksionalitetin e llojeve të veçanta të CDN-ve, dhe pastaj të shohim se çfarë nga kjo është realizuar në secilën prej tyre.
1. Kompresimi i burimeve tekstuale
Mundësia më themelore dhe më e kuptueshme, megjithatë shpesh realizohet keq. Të gjitha CDN deklarojnë praninë e kompresimit si karakteristikë të tyre për përshpejtim. Por nëse shohim më në detaje, zbulojmë mangësi:
- mund tĂ« pĂ«rdoren gradĂ« tĂ« ulĂ«ta pĂ«r kompresimin dinamik â 5-6 (pĂ«r shembull, maksimumi pĂ«r gzip Ă«shtĂ« 9);
- në kompresimin statik (skedarët në cache) nuk përdoren mundësi të tjera shtesë (për shembull, zopfi ose brotli me gradë 11)
- nuk ka mbështetje për kompresimin efektiv brotli (kosto prej rreth 20% në krahasim me gzip).
Nëse po përdorni CDN, është mirë të kontrolloni këto disa pika: merrni një skedar, që ka ardhur nga CDN, regjistroni madhësinë e tij të ngjeshur dhe ripërjetoni manualisht për krahasim (mund të përdorni ndonjë shërbim online me mbështetje për brotli, për shembull, ).
2. Cilësimi i titujve të skedimit të klientit
Po ashtu një veçori e thjeshtë për përshpejtim: vendosni tituj për skedimin e përmbajtjes nga klienti (shfletuesi). Titulli më i rëndësishëm është cache-control, ndërsa ai i vjetëruar është expires. Shtesë mund të përdoret Etag. E rëndësishme është që max-age në cache-control të jetë mjaft i madh (nga një muaj dhe më shumë), nëse jeni të gatshëm të skedoni burimin sa më fort të jetë e mundur, mund të shtoni opsionin immutable.
CDN mund të ulë vlerën max-age, duke detyruar përdoruesin të ngarkojë përsëri statikën më shpesh. Pse ndodh kjo: për të rritur trafikun në rrjet ose për të përmirësuar përputhshmërinë me faqet e internetit që nuk dinë të spastrojnë cache-n - nuk është e qartë. Për shembull, vlera e kohës së caching në titujt e Cloudflare, nga e para, është 1 orë, që është shumë e vogël për statikën e pandryshueshme.
3. Optimizimi i imazheve
Duke qenë se CDN merr përsipër funksionet e caching dhe dhënies së imazheve, do të ishte logjike t'i optimizonte ato në anën e CDN dhe t'i dorëzonte në këtë formë për përdoruesit. Le të theksojmë se kjo mundësi është e disponueshme vetëm për llojet e CDN 2, 3 dhe 5.
Imazhet mund të optimizohen në mënyra të ndryshme: duke përdorur formate të përparuara kompresimi (p.sh., WebP), kodues më efikas (MozJPEG), ose thjesht duke pastruar metadatat e panevojshme.
NĂ« pĂ«rgjithĂ«si, ka dy lloje tĂ« tillĂ« optimizimesh: me humbje cilĂ«sie dhe pa humbje cilĂ«sie. CDN zakonisht pĂ«rpiqen tĂ« pĂ«rdorin optimizimin pa humbje â pĂ«r tĂ« evituar ankesat e mundshme tĂ« klientĂ«ve mbi ndĂ«rrimin e cilĂ«sisĂ« sĂ« imazheve. NĂ« kĂ«to kushte, fitimi do tĂ« jetĂ« minimal. NĂ« tĂ« vĂ«rtetĂ«, shpesh niveli i cilĂ«sisĂ« JPEG e tejkalon ndjeshĂ«m atĂ« qĂ« Ă«shtĂ« e nevojshme, dhe mund tĂ« bĂ«het ri-kompresimi me njĂ« nivel mĂ« tĂ« ulĂ«t cilĂ«sie, pa dĂ«mtuar perceptimin e pĂ«rdoruesve. Nga ana tjetĂ«r, pĂ«rcaktimi i nivelit tĂ« cilĂ«sisĂ« dhe konfigurimeve universale pĂ«r tĂ« gjitha aplikacionet e mundshme nĂ« internet Ă«shtĂ« e vĂ«shtirĂ«, prandaj CDN pĂ«rdorin konfigurime mĂ« konservative krahasuar me ato qĂ« mund tĂ« aplikohen duke marrĂ« parasysh kontekstin (qĂ«llimi i imazheve, lloji i aplikacionit nĂ« internet, etj.)
4. Optimizimi i lidhjes TLS
Shumica e trafikut sot transmetohet përmes lidhjeve TLS, çka do të thotë se ne shpenzojmë kohë shtesë për miratimin TLS. Kohëve të fundit janë zhvilluar teknologji të reja për përshpejtimin e këtij procesi. Për shembull, kjo është kriptografia EC, TLS 1.3, cache e seancave dhe tiketa (session tickets), përshpejtimi harduerik i kriptimit (AES-NI), etj. Konfigurimi i saktë i TLS mundëson që koha e lidhjes të ulet në 0-1 RTT (pa llogaritur DNS dhe TCP).
Me softuerin modern, implementimi i praktikave të tilla nuk është e vështirë në kapacitetet e veta.
Jo tĂ« gjithĂ« CDN nuk zbatojnĂ« praktikat mĂ« tĂ« mira pĂ«r TLS, mund ta kontrolloni kĂ«tĂ« duke matur kohĂ«n e lidhjes TLS (p.sh. nĂ« Webpagetest). Ideale pĂ«r njĂ« lidhje tĂ« re Ă«shtĂ« 1RTT, 2RTT â niveli mesatar, 3RTT dhe mĂ« shumĂ« â e keqe.
Po ashtu duhet të vërehet se edhe pse përdoret TLS në nivelin e CDN, serveri me aplikacionin tonë web gjithashtu duhet të përpunojë TLS, por nga ana e CDN, pasi trafiku midis serverit dhe CDN kalon në rrjetin publik. Në rastin më të keq, mund të marrim dy vonesa lidhjeje TLS (e para me hostin CDN, e dyta midis tij dhe serverit tonë).
Për disa aplikacione është e rëndësishme të keni parasysh çështjet e sigurisë: zakonisht trafiku është i dekriptuar në nyjat e CDN, dhe kjo është një mundësi potenciale për kapjen e trafikut. Një variant pune pa zbuluar trafikun zakonisht ofrohet në planet më të mira për një tarifë shtesë.
5. Reduktimi i vonesave të lidhjes
Përparësia kryesore e CDN, për të cilën flasin të gjithë: vonesa të ulëta (distanca më e vogël) midis hostit CDN dhe përdoruesit. Arrije duke krijuar një arkitekturë rrjeti gjeografikisht të shpërndarë, ku hostet janë të vendosur në pikat e përqëndrimit të përdoruesve ( qytete, pika shkëmbimi trafiku etj.)
Në praktikë, përparësitë për rrjete të ndryshme mund të jenë në rajone specifike. Për shembull, CDN-të ruse do të kenë më shumë pika pranie në Rusi. Amerikane do të zhvillojnë kryesisht rrjetin e tyre në SHBA. Për shembull, një nga CDN-të më të mëdha, Cloudflare, ka vetëm 2 pika në Rusi - Moskë dhe Shën Petersburg. Kjo do të thotë, maximumi që mund të kursejmë është rreth 10 ms vonesë krahasuar me vendosjen direkte në Moskë.
Shumica e CDN-ve perëndimore nuk kanë pikë në Rusi. Duke u lidhur me to, mund të rritni vetëm vonesat për publikun tuaj rus.
6. Optimizimi i përmbajtjes (miniifikimi, ndryshime strukturore)
Pika mĂ« e ndĂ«rlikuar dhe teknike. Ndryshimi i pĂ«rmbajtjes gjatĂ« dorĂ«zimit mund tĂ« jetĂ« shumĂ« i rrezikshĂ«m. Edhe nĂ«se flasim pĂ«r miniifikimin: reduktimi i kodit burimor (pĂ«r shkak tĂ« hapĂ«sirave tĂ« tepruara, strukturave tĂ« parĂ«ndĂ«sishme etj.) mund tĂ« ndikojĂ« nĂ« funksionimin e tij. NĂ«se flasim pĂ«r ndryshime mĂ« serioze â siç Ă«shtĂ« zhvendosja e kodit JS nĂ« fund tĂ« HTML, bashkimi i skedave dhe tĂ« ngjashme â rreziku pĂ«r tĂ« prishur funksionalitetin e faqes Ă«shtĂ« edhe mĂ« i lartĂ«.
Prandaj, vetëm disa CDN të tipit 5 merren me këtë. Sigurisht, nuk do të mund të automatizoni të gjitha ndryshimet e nevojshme për përshpejtim - kërkohet analizë dhe optimizim manual. Për shembull, eliminimi i kodit të papërdorur ose të dyfishtë është një nga detyrat manuale.
Si zakonisht, të gjitha optimizimet e tilla menaxhohen nga rishtat dhe ato më të rrezikshmet janë të çaktivizuara si parazgjedhje.
Mbështetje për mundësitë e përshpejtimit sipas tipeve të CDN
Pra, le të shohim se cilat mundësi potenciale për përshpejtim ofrojnë tipet e ndryshme të CDN.
Për lehtësi, do ta përsërisim klasifikimin.
- CDN falas për shpërndarjen e JS-librarive (MaxCDN, Google, Yandex).
- CDN shërbimesh për optimizimin e klientëve (për shembull Google Fonts për fonte, Cloudinary, Cloudimage për imazhe).
- CDN për statikë dhe optimizimin e burimeve në CMS (është në Bitrix, WordPress dhe të tjera).
- CDN për përdorim të përgjithshëm (StackPath, CDNVideo, NGENIX, Megafon).
- CDN për përshpejtimin e faqeve (Cloudflare, Imperva, Airi).
Tani do të përputhim veçoritë dhe tipet e CDN.
Mundësia
Tipi 1
Tipi 2
Tipi 3
Tipi 4
Tipi 5
Kompresimi i tekstit
+â
â
+â
+â
+
Kreu i caches
+
+
+
+
+
Imazhet
â
+â
+â
â
+
TLS
â
â
â
+â
+
Vonesat
â
â
â
+
+
PĂ«rmbajtja
â
â
â
â
+
NĂ« kĂ«tĂ« tabelĂ«, "+" pĂ«rdoret pĂ«r tĂ« treguar mbĂ«shtetje tĂ« plotĂ«, "â" pĂ«r mungesĂ«, "+â" pĂ«r mbĂ«shtetje tĂ« pjesshme. Sigurisht, mund tĂ« ketĂ« devijime nga kjo tabelĂ« nĂ« realitet (p.sh., ndonjĂ« CDN i pĂ«rgjithshĂ«m mund tĂ« implementojĂ« veçori pĂ«r optimizimin e imazheve), por pĂ«r njĂ« pĂ«rmbledhje tĂ« pĂ«rgjithshme Ă«shtĂ« e dobishme.
PĂ«rfundime
Shpresoj, pas leximit të këtij artikulli, do të keni një pamje më të qartë në lidhje me rekomandimin "përdorni CDN" për përshpejtimin e faqeve të internetit.
Si në çdo fushë, nuk duhet të besoni premtimet e marketingut të ndonjë shërbimi. Efekti duhet të matet dhe verifikohet në kushte reale. Nëse tashmë po përdorni ndonjë CDN, kontrolloni eficiencën e tij sipas kriterëve të përshkruar në artikull.
Mund të ndodhë që përdorimi i CDN tani për tani po ngadalëson ngarkimin e faqes tuaj të internetit.
Si një rekomandim të përgjithshëm, mund të ndaleni në sa vijon: studio publikun tuaj, përcaktoni kufijtë e saj gjeografikë. Nëse publiku juaj kryesor është i përqendruar brenda një rrethi prej 1-2 mijë kilometrash, nuk keni nevojë për CDN për qëllimin kryesor - uljen e vonesave. Në vend të kësaj, mund të vendosni serverin tuaj më afër përdoruesve dhe ta konfiguroni siç duhet, duke marrë shumicën e optimizimeve të përshkruara në artikull (falas dhe në vazhdimësi).
Në rastin kur audienca juaj është në të vërtetë gjeografikisht e shpërndarë (me një rreze më shumë se 3000 kilometra), përdorimi i një CDN cilësore do të ishte me të vërtetë e dobishme. Megjithatë, është e nevojshme të kuptohet paraprakisht se çfarë do të përshpejtojë CDN juaj (shih tabelën e mundësive dhe përshkrimin e tyre). Përshpejtimi i faqes megjithatë mbetët një detyrë komplekse që nuk zgjidhet thjesht me lidhjen e CDN. Përveç optimizimeve të përmendura, mjetet më efektive për përshpejtim mbeten jashtë CDN: optimizimi i anës server, ndryshime të avancuara në anën klient (heqja e kodit të pavendosur, optimizimi i procesit të renditjes, punimi me përmbajtjen, fontet, adaptiviteti, etj.)
Burimi: habr.com
