[Ne] CDN bikar bînin

Hema hema her gotar an amûrek ji bo xweşbînkirina leza malperê xwedan xalek hindik e "CDN bikar bînin." Bi gelemperî, CDN torgilokek radestkirina naverokê an tora radestkirina naverokê ye. Em li Method Lab bi gelemperî li ser vê mijarê bi pirsên xerîdar re rû bi rû dimînin; Armanca vê gotarê ev e ku meriv fêm bike ka CDN di warê leza barkirina malperê de çi dikare peyda bike, çi pirsgirêk dikarin derkevin, û di kîjan rewşan de karanîna CDN-ê rastdar e.

Derengiyên ku di wêneyê de têne dorpêç kirin ji hêla karanîna CDN ve têne çêkirin.

Hinek dîrok

Mîna gelek teknolojiyên, CDN ji hewcedariyê derketin. Bi pêşkeftina kanalên Înternetê di nav bikarhênerên Înternetê de, karûbarên vîdyoyê yên serhêl xuya bûn. Bi xwezayî, naveroka vîdyoyê li gorî naveroka malpera birêkûpêk (wêne, nivîs, û koda CSS an JS) bi fermanên mezinahiyê bêtir bandfireh hewce dike.

Dema ku hûn hewl bidin ku ji yek serverek bi pir xerîdar re veguheztinek vîdyoyek paralel biweşînin, kanala Înternetê ya serverê bi îhtîmalek mezin dê bibe asteng. Wekî qaîdeyek, çend hezar mijar bes in ku kanalek serverê ya tîpîk xitimînin. Bê guman, dibe ku tixûbên çavkaniyek din hebin, lê ew niha ne girîng in. Di heman demê de girîng e ku berfirehkirina kanala serverê pir biha ye (û carinan ne gengaz), û di heman demê de ne pratîkî ye. Barkirina kanalê di dema weşanan de dê çerxîkî be.

Pirsgirêka sînorkirina kanala serverek kesane ji hêla CDN-ê ve bêkêmasî tê çareser kirin. Xerîdar ne rasterast bi serverê ve, lê bi nodên di tora CDN-ê re têne girêdan. Di rewşek îdeal de, server yek tîrêjê dişîne girêka CDN, û dûv re torgilok çavkaniyên xwe bikar tîne da ku vê tîrêjê bide gelek bikarhêneran. Ji hêla aboriyê ve, em tenê ji bo çavkaniyên ku bi rastî têne xerc kirin (ev dibe ku band an seyrûsefer be) drav didin û pîvana karûbarê xwe ya hêja digirin. Bikaranîna CDN-ê ji bo radestkirina naveroka giran bi tevahî rastdar û mentiqî ye. Her çend hêjayî gotinê ye ku lîstikvanên herî mezin di vê cîhê de (mînak Netflix) li şûna ku CDN-yên bazirganî yên mezin bikar bînin (Akamai, Cloudflare, Fastly, hwd.) CDN-yên xwe ava dikin.

Her ku tevn pêş ket, sepanên webê bixwe tevlihevtir û girantir bûne. Pirsgirêka leza barkirinê derket pêş. Hezkiriyên leza malperê zû çend pirsgirêkên mezin nas kirin ku bûn sedem ku malper hêdî hêdî bar bibin. Yek ji wan derengiya torê bû (RTT - dema gera dor an dema ping). Dereng bandorê li gelek pêvajoyên barkirina malperê dike: damezrandina pêwendiyek TCP, destpêkirina danişînek TLS, barkirina her çavkaniyek kesane (wêne, pelê JS, belgeya HTML, hwd.)

Pirsgirêk ji ber vê yekê dijwar bû ku dema ku protokola HTTP / 1.1 bikar tîne (berî hatina SPDY, QUIC û HTTP / 2 ev vebijarkek yekane bû), gerok ji yek mêvandar re ji 6 girêdanên TCP-ê bêtir vedike. Hemî ev bû sedem ku dema girêdanê û karanîna bêkêmasî ya berfê kanalê. Pirsgirêk bi parvekirina domainê bi qismî hate çareser kirin - afirandina mêvandarên din da ku sînorê hejmara pêwendiyan derbas bike.

Li vir qabiliyeta duyemîn a CDN xuya dike - kêmkirina derengiyê (RTT) ji ber hejmareke mezin a xalan û nêzîkbûna girêkan ji bikarhêner re. Dûr li vir rolek diyarker dilîze: leza ronahiyê sînorkirî ye (li fîbera optîkî nêzî 200 km / saniye). Ev tê wê wateyê ku her 000 km rêwîtiyê 1000 ms dereng an jî 5 ms li RTT zêde dike. Ev dema herî hindik e ku ji bo veguheztinê hewce dike, ji ber ku li ser alavên navîn jî dereng hene. Ji ber ku CDN bi gelemperî dizane ka meriv çawa tiştan li ser serverên xwe cache dike, em dikarin ji barkirina tiştên weha bi navgîniya CDN-ê sûd werbigirin. Ji bo vê şert û mercên pêwîst: Hebûna tiştê di cache de, nêzîkbûna xala CDN ji bikarhêner re li gorî servera serîlêdana malperê (pêşkêşkara eslê xwe). Girîng e ku meriv fêhm bike ku nêzîkbûna erdnîgarî ya nodek CDN derengiya kêm garantî nake. Rêwîtiya di navbera xerîdar û CDN-ê de dikare bi vî rengî were çêkirin ku xerîdar dê bi mêvandarek li welatek din, û dibe ku li parzemînek din ve girêdayî be. Li vir pêwendiya di navbera operatorên telekomê û karûbarê CDN de (peering, girêdan, beşdarbûna IX, hwd.) û polîtîkaya rêvekirina trafîkê ya CDN bixwe tê lîstin. Mînakî, Cloudflare, dema ku du plansaziyên destpêkê (belaş û erzan) bikar tîne, radestkirina naverokê ji mêvandarê herî nêzîk garantî nake - dê mêvandar were hilbijartin ku bigihîje lêçûna herî kêm.

Gelek pargîdaniyên pêşeng ên Înternetê bala gelemperî (pêşdebirên malperê û xwedan karûbar) dikişînin ser mijara leza barkirinê û performansa malperê. Di nav van pargîdaniyan de Yahoo (Amûra Yslow), AOL (WebPageTest) û Google (karûbarê Leza Rûpelê Insights) hene, ku ji bo bilezkirina malperan pêşnîyarên xwe pêş dixin (di serî de ew bi xweşbîniya xerîdar ve girêdayî ne). Dûv re, amûrên ceribandina leza malperê ya nû xuya dibin, ku di heman demê de serişteyên li ser zêdekirina leza malperê jî peyda dikin. Her yek ji van karûbar an pêvekan pêşniyarek domdar heye: "CDNek bikar bînin." Kêmkirina derengiya torê bi gelemperî wekî ravekirinek ji bo bandora CDN tête binav kirin. Mixabin, ne her kes amade ye ku tam fam bike ka bandora lezkirinê ya CDN çawa tête bidestxistin û meriv çawa dikare were pîvandin, ji ber vê yekê pêşniyar li ser baweriyê tête girtin û wekî postulate tête bikar anîn. Bi rastî, ne hemî CDN wekhev têne afirandin.

Îro CDN bikar bînin

Ji bo nirxandina kêrhatiya karanîna CDN-an, pêdivî ye ku ew werin dabeş kirin. Tiştê ku niha di pratîkê de dikare were dîtin (nimûneyên di nav kevanan de, bê guman, ne temam in):

1. CDN belaş ji bo belavkirina pirtûkxaneyên JS (MaxCDN, Google. Yandex).
2. CDN karûbarên ji bo xweşbînkirina xerîdar (mînak, Google Fonts ji bo tîpan, Cloudinary, Cloudimage ji bo wêneyan).
3. CDN ji bo xweşbîniya statîk û çavkaniyê di CMS de (di Bitrix, WordPress û yên din de heye).
4. Armanca gelemperî CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN ji bo bilezkirina malperê (Cloudflare, Imperva, Airi).

Cûdahiya sereke di navbera van celeban de ev e ku çiqas seyrûseferê di nav CDN re derbas dibe. Cûreyên 1-3 radestkirina tenê beşek naverokê ne: ji yek daxwazê ​​heya çend dehan (bi gelemperî wêne). Tîpên 4 û 5 bi riya CDN-ê ve seyrûsefera tevahî proxy dikin.

Di pratîkê de, ev tê wateya hejmara girêdanên ku ji bo barkirina malperê têne bikar anîn. Bi HTTP/2 re, em pêwendiyek TCP-ê ya bi mêvandar re bikar tînin da ku her jimarek daxwaziyan bişopînin. Ger em çavkaniyan li ser mêvandarê sereke (eslê) û CDN-ê dabeş bikin, wê hingê pêdivî ye ku daxwazan li çend domanan belav bikin û çend girêdanên TCP-ê biafirînin. Rewşa herî xirab ev e: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Ev formula derengiyên di torên mobîl de ji bo aktîvkirina kanala radyoya cîhazê (heke ew ne çalak bû) û derengiyên li ser birca hucreyê nayê hesibandin.

Li vir li ser ava barkirina malperê çawa xuya dike (derengiyên ji bo girêdana bi CDN-ê di RTT 150 ms de têne xuyang kirin):

Ger CDN hemî seyrûsefera malperê vedigire (ji bilî karûbarên sêyemîn), wê hingê em dikarin pêwendiyek TCP-ê bikar bînin, derengiya girêdana bi mêvandarên din re hilînin. Bê guman, ev ji bo girêdanên HTTP/2 derbas dibe.

Cûdahiyên din ji hêla fonksiyona CDNek taybetî ve têne destnîşankirin - ji bo celebê yekem ew tenê pelek statîk mêvandar e, ji bo ya pêncemîn jî ew çend celeb naveroka malperê ji bo armanca xweşbîniyê diguhezîne.

Kapasîteyên CDN ji bo bilezkirina malperê

Ka em rêza tevahî kapasîteyên CDN-ê ji bo bilezkirina malperan, bêyî guh bidin fonksiyona celebên ferdî yên CDN-ê, rave bikin, û dûv re bibînin ka di her yek ji wan de çi tê bicîh kirin.

1. Compression çavkaniyên text

Taybetmendiya herî bingehîn û têgihîştî, di heman demê de pir caran kêm tê pêkanîn. Hemî CDN hebûna berhevkirinê wekî taybetmendiya bilezkirina xwe radigihînin. Lê heke hûn bi hûrgulî lê binêrin, kêmasî diyar dibin:

• pileyên nizm ji bo berhevkirina dînamîkî dikare were bikar anîn - 5-6 (mînakî, ji bo gzip herî zêde 9 e);
• komkirina statîk (pelên di cache de) taybetmendiyên zêde bikar nayîne (mînak, zopfi an brotli bi pileya 11)
• ji bo kompresyona brotli ya bikêr piştgirî tune (li gorî gzip% 20 xilas dike).

Heke hûn CDN bikar bînin, hêja ye ku hûn van çend xalan kontrol bikin: pelê ku ji CDN-ê hatî hildin, mezinahiya wê ya pêçandî tomar bikin û ji bo berhevdanê bi destan berhev bikin (hûn dikarin hin karûbarê serhêl bi piştgiriya brotli bikar bînin, mînakî vsszhat.rf).

2. Sazkirina sernivîsên caching muwekîlê

Di heman demê de taybetmendiyek bilezkirina hêsan: ji bo vekêşana naverokê ji hêla xerîdar (gerok) sernivîsan zêde bikin. Sernivîsa herî niha ya cache-kontrol e, ya kevnar diqede. Wekî din, Etag dikare were bikar anîn. Ya sereke ev e ku temenê herî zêde ya cache-kontrolê têra xwe mezin e (ji mehekê an bêtir heke hûn amade ne ku çavkaniyê bi qasî ku pêkan cache bikin, hûn dikarin vebijarka neguhêrbar lê zêde bikin).

CDN dikarin nirxa max-temenê kêm bikin, ku bikarhêner neçar dike ku pir caran naveroka statîk ji nû ve bar bike. Ne diyar e ku ev bi çi ve girêdayî ye: xwestina zêdekirina seyrûsefera li ser torê an zêdekirina lihevhatina bi malperên ku nizanin ka meriv çawa kaşê ji nû ve bike. Mînakî, dema cache ya serê Cloudflare ya xwerû 1 saet e, ku ji bo daneyên statîk ên neguhêrbar pir kêm e.

3. Optimîzasyona wêneyê

Ji ber ku CDN fonksiyonên cachkirin û xizmetkirina wêneyan digire ser xwe, mentiqî ye ku meriv wan li milê CDN xweşbîn bike û di vê formê de ji bikarhêneran re xizmet bike. Ka em tavilê rezervasyonek bikin ku ev taybetmendî tenê ji bo celebên CDN 2, 3 û 5 heye.

Hûn dikarin wêneyan bi awayên cûrbecûr xweşbîn bikin: bi karanîna formatên pêvekirî yên pêşkeftî (wek WebP), şîfrekerên bikêrtir (MozJPEG), an bi tenê paqijkirina metadatayên nehewce.

Bi gelemperî, du celeb xweşbîniyên weha hene: bi windabûna kalîteyê û bêyî windabûna kalîteyê. CDN bi gelemperî hewl didin ku xweşbîniya bê windahî bikar bînin da ku ji giliyên mimkun ên xerîdar ên di derbarê guhertinên di qalîteya wêneyê de dûr nekevin. Di şert û mercên wiha de, qezenc dê kêmtir be. Di rastiyê de, pir caran asta kalîteya JPEG ji ya pêwîst pir bilindtir e û hûn dikarin bi ewlehî bi astek kalîteya jêrîn re ji nû ve bişopînin bêyî ku ezmûna bikarhêner tawîz bidin. Ji hêla din ve, dijwar e ku meriv asta kalîteyê û mîhengan bi gerdûnî ji bo hemî serîlêdanên malperê yên mimkun diyar bike, ji ber vê yekê CDN mîhengên muhafezekartir bikar tînin li gorî yên ku dikarin bêne sepandin li gorî çarçovê (armanca wêneyan, celebê serîlêdana malperê). , hwd.)

4. Optimîzekirina girêdana TLS

Piraniya seyrûsefera îro li ser girêdanên TLS dimeşe, ku tê vê wateyê ku em wextê zêde li ser danûstandinên TLS derbas dikin. Di demên dawî de, teknolojiyên nû hatine pêşve xistin ku vê pêvajoyê bilezînin. Mînakî, ev krîptografya EC, TLS 1.3, cache û bilêtên danişînê, lezkirina şîfrekirina hardware (AES-NI), hwd. Bi rast danîna TLS dikare dema girêdanê kêm bike 0-1 RTT (DNS û TCP nayê hesibandin).

Bi nermalava nûjen re, ne dijwar e ku meriv van pratîkan bi serê xwe bicîh bîne.

Ne hemî CDN pratîkên çêtirîn ên TLS-ê bicîh dikin, hûn dikarin vê yekê bi pîvandina dema pêwendiya TLS-ê kontrol bikin (mînak, di Webpagetest). Ji bo pêwendiyek nû îdeal - 1RTT, 2RTT - asta navîn, 3RTT û bêtir - xirab.

Di heman demê de divê were zanîn ku tewra dema ku TLS di asta CDN-ê de bikar tîne, servera bi serîlêdana meya webê re jî divê TLS-ê pêvajoyê bike, lê ji hêla CDN ve, ji ber ku seyrûsefera di navbera server û CDN-ê de li ser tora gelemperî derbas dibe. Di rewşa herî xirab de, em ê du caran derengiya pêwendiya TLS-ê bistînin (ya yekem ji mêvandarê CDN re, ya duyemîn di navbera wê û servera me de).

Ji bo hin serîlêdanan, hêja ye ku bala xwe bidin pirsgirêkên ewlehiyê: seyrûsefer bi gelemperî li ser girêkên CDN-ê tê deşîfrekirin, û ev fersendek potansiyel e ji bo girtina trafîkê. Vebijarka xebitandina bêyî eşkerekirina seyrûseferê bi gelemperî di planên tarîfê yên jorîn de ji bo dravê zêde tê pêşkêş kirin.

5. Kêmkirina dereng girêdanê

Feydeya sereke ya CDN ya ku her kes li ser diaxive: derengiya kêm (kêmtir dûr) di navbera mêvandarê CDN û bikarhêner de. Bi afirandina mîmariya torê ya bi erdnîgarî ve hatî belav kirin, ku tê de mêvandar di xalên berhevdana bikarhêneran de cih digirin (bajar, xalên pevguhertina trafîkê, hwd.)

Di pratîkê de, pêşanî ji bo torên cûda dibe ku li herêmên taybetî bin. Mînakî, CDN-yên rûsî dê li Rûsyayê bêtir xalên hebûna xwe hebin. Yên Emerîkî beriya her tiştî wê şebekeyê li DYAyê pêş bixin. Mînakî, yek ji mezintirîn CDN Cloudflare li Rûsyayê tenê 2 xal hene - Moskow û St. Ango, em dikarin li gorî cîhkirina rasterast li Moskowê herî zêde bi qasî 10 ms derengiyê xilas bikin.

Piraniya CDN-yên rojavayî li Rûsyayê qet xalên wan tune. Bi girêdana wan re, hûn tenê dikarin derengiyên ji bo temaşevanên xwe yên rûsî zêde bikin.

6. Optimîzasyona naverokê (kêmkirin, guhertinên avahî)

Xala herî tevlihev û teknolojîk ya pêşkeftî. Guhertina naverokê di dema radestkirinê de dikare pir xeternak be. Tewra ku em piçûkkirinê bigirin jî: kêmkirina koda çavkaniyê (ji ber cîhên zêde, strukturên ne girîng, hwd.) dikare bandorê li performansa wê bike. Ger em li ser guhertinên cidîtir biaxivin - guheztina koda JS-ê berbi dawiya HTML-ê, hevgirtina pelan, hwd. - xetereya têkbirina fonksiyona malperê hîn zêdetir e.

Ji ber vê yekê, tenê hin celeb 5 CDN vê yekê dikin. Bê guman, ew ê ne gengaz be ku hemî guhertinên ku ji bo bilezkirina tiştan hewce ne otomatîk bikin - analîz û xweşbîniya destan hewce ne. Mînakî, rakirina koda nekarandî an dubare karek destan e.

Wekî qaîdeyek, hemî xweşbîniyên weha ji hêla mîhengan ve têne kontrol kirin û yên herî xeternak ji hêla xwerû ve têne asteng kirin.

Piştgiriya kapasîteyên bilezkirinê ji hêla celebê CDN ve

Ji ber vê yekê em ê mêze bikin ka çi derfetên lezkirinê yên potansiyel ên cûrbecûr CDN peyda dikin.

Ji bo rehetiyê, em dabeşkirinê dubare dikin.

1. CDN belaş ji bo belavkirina pirtûkxaneyên JS (MaxCDN, Google. Yandex).
2. CDN karûbarên ji bo xweşbînkirina xerîdar (mînak, Google Fonts ji bo tîpan, Cloudinary, Cloudimage ji bo wêneyan).
3. CDN ji bo xweşbîniya statîk û çavkaniyê di CMS de (di Bitrix, WordPress û yên din de heye).
4. Armanca gelemperî CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN ji bo bilezkirina malperê (Cloudflare, Imperva, Airi).

Naha werin em taybetmendî û celebên CDN bidin ber hev.

Fersend
Tîpa 1
Tîpa 2
Tîpa 3
Tîpa 4
Tîpa 5

Compression text
+–
-
+–
+–
+

Sernivîsên cache
+
+
+
+
+

Wêneyên
-
+–
+–
-
+

TLS
-
-
-
+–
+

Derengmayîn
-
-
-
+
+

Contents
-
-
-
-
+

Di vê tabloyê de, "+" ji bo nîşankirina piştgirîya tam, "-" bê piştgirî ye, û "+-" piştgirîya qismî ye. Bê guman, dibe ku di rastiyê de ji vê tabloyê veqetandî hebin (mînakek, hin CDN-armanca gelemperî dê taybetmendiyên xweşbînkirina wêneyan bicîh bîne), lê ji bo ramanek gelemperî ew bikêr e.

Encam

Hêvîdarim, piştî xwendina vê gotarê hûn ê di derbarê pêşniyara "CDN-ê bikar bînin" de wêneyek zelaltir hebe ku hûn malperên xwe bilezînin.

Mîna ku di her karsaziyê de, hûn nikarin ji sozên kirrûbirrê yên her karûbar bawer bikin. Pêdivî ye ku bandor di bin şert û mercên rastîn de were pîvandin û ceribandin. Heke hûn berê CDN-ê bikar tînin, wê ji bo bandorkeriya bi karanîna pîvanên ku di gotarê de têne diyar kirin kontrol bikin.

Mimkun e ku karanîna CDN-a nuha dema barkirina malpera we hêdî dike.

Wekî pêşniyarek gelemperî, em dikarin li ser jêrîn bisekinin: temaşevanên xwe bixwînin, qada erdnîgariya wê diyar bikin. Ger temaşevanên weya sereke di nav tîrêjek 1-2 hezar kîlometre de kom bibin, hûn ji bo armanca wê ya sereke - kêmkirina derengiyê - ne hewceyî CDN-ê ne. Di şûna wê de, hûn dikarin servera xwe nêzîkê bikarhênerên xwe bicîh bikin û wê bi rêkûpêk mîheng bikin, piraniya xweşbîniyên ku di gotarê de têne diyar kirin (belaş û daîmî) bistînin.

Ger temaşevanên we bi rastî ji hêla erdnîgarî ve hatine belav kirin (radyoya ji 3000 kîlometre zêdetir), karanîna CDN-ya kalîteyê dê bi rastî kêrhatî be. Lêbelê, hûn hewce ne ku pêşî fam bikin ka CDN-ya we bi rastî çi dikare bilez bike (tabloya kapasîteyên û danasîna wan binêre). Lêbelê, bilezkirina malperê hîn jî karekî tevlihev dimîne ku bi girêdana CDN-ê nayê çareser kirin. Ji bilî xweşbîniyên jorîn, rêgezên bilezkirinê yên herî bi bandor li pişt CDN-ê dimînin: xweşbînkirina beşa serverê, guheztinên pêşkeftî yên beşa xerîdar (rakirina koda ku nayê bikar anîn, xweşbînkirina pêvajoya vegotinê, xebata bi naverok, fonts, adaptasyon, hwd. )

Source: www.habr.com