Takriban kila makala au zana ya kuboresha kasi ya tovuti ina kifungu cha kawaida "tumia CDN." Kwa ujumla, CDN ni mtandao wa utoaji maudhui au mtandao wa uwasilishaji wa maudhui. Sisi katika Method Lab mara nyingi hukutana na maswali kutoka kwa wateja kuhusu mada hii; baadhi yao huwasha CDN yao wenyewe. Madhumuni ya makala hii ni kuelewa nini CDN inaweza kutoa kwa kasi ya upakiaji wa tovuti, ni matatizo gani yanaweza kutokea, na katika hali gani matumizi ya CDN yanafaa.
![[Usitumie] CDN](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
Ucheleweshaji uliozungushwa kwenye picha unasababishwa na matumizi ya CDN.
kidogo ya historia
Kama teknolojia nyingi, CDN ziliibuka kwa lazima. Pamoja na maendeleo ya njia za mtandao kati ya watumiaji wa mtandao, huduma za video za mtandaoni zilionekana. Kwa kawaida, maudhui ya video yanahitaji maagizo ya kipimo data cha ukubwa zaidi ikilinganishwa na maudhui ya kawaida ya tovuti (picha, maandishi, na msimbo wa CSS au JS).
Unapojaribu kutangaza mtiririko wa video sambamba na wateja wengi kutoka kwa seva moja, kuna uwezekano mkubwa kwamba chaneli ya Mtandao ya seva itakuwa kizuizi. Kama sheria, nyuzi elfu chache zinatosha kuziba chaneli ya kawaida ya seva. Bila shaka, kunaweza kuwa na mapungufu mengine ya rasilimali, lakini sio muhimu hivi sasa. Pia ni muhimu kwamba kupanua kituo cha seva ni ghali sana (na wakati mwingine haiwezekani), na pia haiwezekani. Mzigo kwenye chaneli wakati wa matangazo utakuwa wa mzunguko.
Tatizo la kupunguza kituo cha seva ya mtu binafsi linatatuliwa kikamilifu na CDN. Wateja hawaunganishi kwa seva moja kwa moja, lakini kwa nodi kwenye mtandao wa CDN. Katika hali nzuri, seva hutuma mkondo mmoja kwenye nodi ya CDN, na kisha mtandao hutumia rasilimali zake kutoa mkondo huu kwa watumiaji wengi. Kwa mtazamo wa kiuchumi, tunalipia tu rasilimali zinazotumiwa (hii inaweza kuwa kipimo data au trafiki) na kupata uboreshaji bora wa huduma yetu. Kutumia CDN kutoa maudhui mazito ni haki na mantiki kabisa. Ingawa inafaa kukumbuka kuwa wachezaji wakubwa kwenye nafasi hii (k.m. Netflix) wanaunda CDN zao badala ya kutumia CDN kubwa za kibiashara (Akamai, Cloudflare, Fastly, n.k.)
Kadiri wavuti inavyokua, programu za wavuti zenyewe zimekuwa ngumu zaidi na ngumu. Tatizo la kasi ya upakiaji lilikuja mbele. Wapenda kasi ya tovuti walitambua haraka matatizo kadhaa makubwa yaliyosababisha tovuti kupakia polepole. Mojawapo ilikuwa ucheleweshaji wa mtandao (RTT - wakati wa safari ya kwenda na kurudi au wakati wa ping). Ucheleweshaji huathiri michakato mingi katika upakiaji wa tovuti: kuanzisha muunganisho wa TCP, kuanzisha kipindi cha TLS, kupakia kila rasilimali ya mtu binafsi (picha, faili ya JS, hati ya HTML, n.k.)
Tatizo lilichochewa na ukweli kwamba wakati wa kutumia itifaki ya HTTP/1.1 (kabla ya ujio wa SPDY, QUIC na HTTP/2 hii ndiyo ilikuwa chaguo pekee), vivinjari hufungua si zaidi ya miunganisho 6 ya TCP kwa mwenyeji mmoja. Haya yote yalisababisha kukatika kwa muunganisho na matumizi yasiyofaa ya kipimo data cha chaneli. Tatizo lilitatuliwa kwa sehemu kwa kugawanyika kwa kikoa - kuundwa kwa majeshi ya ziada ili kuondokana na kikomo cha idadi ya miunganisho.
Hapa ndipo uwezo wa pili wa CDN unaonekana - kupunguza latency (RTT) kutokana na idadi kubwa ya pointi na ukaribu wa nodes kwa mtumiaji. Umbali una jukumu muhimu hapa: kasi ya mwanga ni mdogo (takriban 200 km / s katika nyuzi za macho). Hii ina maana kwamba kila kilomita 000 za safari huongeza ms 1000 za kuchelewa au 5 ms kwa RTT. Huu ndio muda wa chini unaohitajika kwa maambukizi, kwani pia kuna ucheleweshaji kwenye vifaa vya kati. Kwa kuwa CDN kawaida hujua jinsi ya kuweka akiba ya vitu kwenye seva zake, tunaweza kufaidika kwa kupakia vitu kama hivyo kupitia CDN. Masharti ya lazima kwa hili: uwepo wa kitu kwenye kashe, ukaribu wa CDN huelekeza kwa mtumiaji kwa kulinganisha na seva ya programu ya wavuti (seva ya asili). Ni muhimu kuelewa kwamba ukaribu wa kijiografia wa nodi ya CDN hauhakikishi utulivu wa chini. Uelekezaji kati ya mteja na CDN unaweza kujengwa kwa njia ambayo mteja ataunganishwa na mwenyeji katika nchi nyingine, na ikiwezekana katika bara lingine. Hapa ndipo uhusiano kati ya waendeshaji simu na huduma ya CDN (kutazama, miunganisho, ushiriki katika IX, n.k.) na sera ya uelekezaji wa trafiki ya CDN yenyewe. Kwa mfano, Cloudflare, wakati wa kutumia mipango miwili ya awali (ya bure na ya bei nafuu), haitoi dhamana ya utoaji wa maudhui kutoka kwa mwenyeji wa karibu - mwenyeji atachaguliwa kufikia gharama ya chini.
Makampuni mengi ya mtandao yanayoongoza huvutia maslahi ya umma (watengenezaji wa wavuti na wamiliki wa huduma) kwa mada ya kasi ya upakiaji na utendaji wa tovuti. Miongoni mwa makampuni haya ni Yahoo (zana ya Yslow), AOL (WebPageTest) na Google (huduma ya Maarifa ya Kasi ya Ukurasa), ambayo yanaunda mapendekezo yao ya kuharakisha tovuti (kimsingi yanahusiana na uboreshaji wa mteja). Baadaye, zana mpya za kupima kasi ya tovuti zinaonekana, ambazo pia hutoa vidokezo vya kuongeza kasi ya tovuti. Kila moja ya huduma hizi au programu-jalizi ina pendekezo thabiti: "Tumia CDN." Kupungua kwa muda wa kusubiri mtandao kwa kawaida hutajwa kama maelezo ya athari za CDN. Kwa bahati mbaya, sio kila mtu yuko tayari kuelewa haswa jinsi athari ya kuongeza kasi ya CDN inafikiwa na jinsi inavyoweza kupimwa, kwa hivyo pendekezo hilo linachukuliwa kwa imani na kutumika kama chapisho. Kwa kweli, sio CDN zote zimeundwa sawa.
Kwa kutumia CDN Leo
Ili kutathmini manufaa ya kutumia CDN, zinahitaji kuainishwa. Ni nini kinachoweza kupatikana sasa katika mazoezi (mifano kwenye mabano, kwa kweli, sio kamili):
- CDN ya bure ya kusambaza maktaba za JS (MaxCDN, Google. Yandex).
- CDN ya huduma za uboreshaji wa mteja (kwa mfano, Fonti za Google za fonti, Cloudinary, Cloudimage kwa picha).
- CDN ya uboreshaji tuli na rasilimali katika CMS (inapatikana katika Bitrix, WordPress na zingine).
- CDN ya madhumuni ya jumla (StackPath, CDNVideo, NGENIX, Megafon).
- CDN kwa kuongeza kasi ya tovuti (Cloudflare, Imperva, Airi).
Tofauti kuu kati ya aina hizi ni kiasi gani cha trafiki hupitia CDN. Aina 1-3 ni utoaji wa sehemu tu ya maudhui: kutoka kwa ombi moja hadi kadhaa kadhaa (kawaida picha). Aina ya 4 na 5 ni wakala kamili wa trafiki kupitia CDN.
Kwa mazoezi, hii inamaanisha idadi ya viunganisho vinavyotumiwa kupakia tovuti. Kwa HTTP/2, tunatumia muunganisho mmoja wa TCP kwa seva pangishi ili kushughulikia idadi yoyote ya maombi. Ikiwa tutagawanya rasilimali katika seva pangishi kuu (asili) na CDN, basi ni muhimu kusambaza maombi katika vikoa kadhaa na kuunda miunganisho kadhaa ya TCP. Kesi mbaya zaidi ni: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Fomula hii haizingatii ucheleweshaji wa mitandao ya simu kwa kuwezesha kituo cha redio cha kifaa (ikiwa hakitumiki) na ucheleweshaji kwenye mnara wa seli.
Hivi ndivyo inavyoonekana kwenye maporomoko ya maji ya upakiaji wa tovuti (lawiti za kuunganisha kwenye CDN zimeangaziwa kwa RTT 150 ms):
Ikiwa CDN inashughulikia trafiki yote ya tovuti (isipokuwa huduma za watu wengine), basi tunaweza kutumia muunganisho mmoja wa TCP, kuokoa ucheleweshaji wa kuunganisha kwa wapangishi wa ziada. Bila shaka, hii inatumika kwa miunganisho ya HTTP/2.
Tofauti zaidi imedhamiriwa na utendaji wa CDN fulani - kwa aina ya kwanza ni mwenyeji wa faili tuli, kwa tano ni kubadilisha aina kadhaa za maudhui ya tovuti kwa madhumuni ya uboreshaji.
Uwezo wa CDN wa kuongeza kasi ya tovuti
Hebu tufafanue uwezo kamili wa CDN kwa kuongeza kasi ya tovuti, bila kuzingatia utendaji wa aina za mtu binafsi za CDN, na kisha tuone kile kinachotekelezwa katika kila mmoja wao.
1. Ukandamizaji wa rasilimali za maandishi
Kipengele cha msingi na kinachoeleweka, lakini mara nyingi hutekelezwa vibaya. CDN zote zinatangaza uwepo wa mbano kama kipengele chao cha kuongeza kasi. Lakini ukiangalia kwa undani zaidi, mapungufu yanaonekana wazi:
- digrii za chini kwa ukandamizaji wa nguvu zinaweza kutumika - 5-6 (kwa mfano, kwa gzip kiwango cha juu ni 9);
- ukandamizaji tuli (faili kwenye kache) hautumii vipengele vya ziada (kwa mfano, zopfi au brotli yenye digrii 11)
- hakuna usaidizi wa ukandamizaji bora wa brotli (kuokoa takriban 20% ikilinganishwa na gzip).
Ikiwa unatumia CDN, inafaa kuangalia vidokezo hivi vichache: chukua faili iliyotoka kwa CDN, rekodi saizi yake iliyoshinikizwa na uifinye kwa mikono kwa kulinganisha (unaweza kutumia huduma ya mtandaoni kwa msaada wa brotli, kwa mfano. ).
2. Kuweka vichwa vya kache vya mteja
Pia kipengele rahisi cha kuongeza kasi: ongeza vichwa vya uhifadhi wa maudhui na mteja (kivinjari). Kichwa cha sasa zaidi ni cache-control, kilichopitwa na wakati kinaisha. Kwa kuongeza, Etag inaweza kutumika. Jambo kuu ni kwamba umri wa juu wa udhibiti wa cache ni wa kutosha (kutoka mwezi au zaidi) Ikiwa uko tayari kuhifadhi rasilimali kwa bidii iwezekanavyo, unaweza kuongeza chaguo lisiloweza kubadilika.
CDN zinaweza kupunguza thamani ya umri wa juu zaidi, na kulazimisha mtumiaji kupakia upya maudhui tuli mara nyingi zaidi. Haijulikani ni nini hii inaunganishwa na: hamu ya kuongeza trafiki kwenye mtandao au kuongeza utangamano na tovuti ambazo hazijui jinsi ya kuweka upya cache. Kwa mfano, muda chaguo-msingi wa kache ya kichwa cha Cloudflare ni saa 1, ambayo ni ya chini sana kwa data tuli isiyobadilika.
3. Uboreshaji wa picha
Kwa kuwa CDN inachukua kazi za kuweka akiba na kuhudumia picha, itakuwa jambo la busara kuziboresha kwa upande wa CDN na kuzihudumia kwa watumiaji katika fomu hii. Hebu tuweke nafasi mara moja kwamba kipengele hiki kinapatikana kwa aina za CDN 2, 3 na 5 pekee.
Unaweza kuboresha picha kwa njia mbalimbali: kwa kutumia umbizo la ukandamizaji wa hali ya juu (kama vile WebP), usimbaji bora zaidi (MozJPEG), au kusafisha tu metadata isiyo ya lazima.
Kwa ujumla, kuna aina mbili za uboreshaji kama huu: na upotezaji wa ubora na bila upotezaji wa ubora. CDN kwa kawaida hujitahidi kutumia uboreshaji usio na hasara ili kuepuka malalamiko ya wateja kuhusu mabadiliko ya ubora wa picha. Katika hali kama hizi, faida itakuwa ndogo. Kwa kweli, mara nyingi kiwango cha ubora wa JPEG ni cha juu zaidi kuliko kinachohitajika na unaweza kukandamiza kwa usalama kwa kiwango cha chini cha ubora bila kuathiri uzoefu wa mtumiaji. Kwa upande mwingine, ni vigumu kuamua kiwango cha ubora na mipangilio kote ulimwenguni kwa programu zote zinazowezekana za wavuti, kwa hivyo CDN hutumia mipangilio ya kihafidhina ikilinganishwa na ile inayoweza kutumika kwa kuzingatia muktadha (kusudi la picha, aina ya programu ya wavuti. , na kadhalika.)
4. Kuboresha muunganisho wa TLS
Trafiki nyingi leo husafiri kupitia miunganisho ya TLS, kumaanisha kuwa tunatumia muda wa ziada kwenye mazungumzo ya TLS. Hivi karibuni, teknolojia mpya zimetengenezwa ili kuharakisha mchakato huu. Kwa mfano, hii ni cryptography ya EC, TLS 1.3, akiba ya kipindi na tiketi, kuongeza kasi ya usimbaji wa maunzi (AES-NI), n.k. Kuweka kwa usahihi TLS kunaweza kupunguza muda wa kuunganisha hadi 0-1 RTT (bila kuhesabu DNS na TCP ).
Kwa programu ya kisasa, si vigumu kutekeleza mazoea hayo peke yako.
Sio CDN zote zinazotumia mbinu bora za TLS; unaweza kuangalia hili kwa kupima muda wa muunganisho wa TLS (kwa mfano, katika Webpagetest). Inafaa kwa muunganisho mpya - 1RTT, 2RTT - kiwango cha wastani, 3RTT na zaidi - mbaya.
Ikumbukwe pia kwamba hata wakati wa kutumia TLS kwenye kiwango cha CDN, seva iliyo na programu yetu ya wavuti lazima pia ishughulikie TLS, lakini kutoka upande wa CDN, kwa sababu trafiki kati ya seva na CDN hupita kwenye mtandao wa umma. Katika hali mbaya zaidi, tutapata ucheleweshaji wa muunganisho wa TLS mara mbili (ya kwanza kwa seva pangishi ya CDN, ya pili kati yake na seva yetu).
Kwa programu zingine, inafaa kuzingatia maswala ya usalama: trafiki kawaida hutambulishwa kwenye nodi za CDN, na hii ni fursa inayowezekana ya kukatiza trafiki. Chaguo la kufanya kazi bila ufichuaji wa trafiki kawaida hutolewa katika mipango ya juu ya ushuru kwa ada ya ziada.
5. Punguza ucheleweshaji wa uunganisho
Faida kuu ya CDN ambayo kila mtu anazungumzia: utulivu wa chini (umbali mdogo) kati ya seva pangishi ya CDN na mtumiaji. Imefikiwa kwa kuunda usanifu wa mtandao uliosambazwa kijiografia, ambamo majeshi yanapatikana katika maeneo ya mkusanyiko wa watumiaji (miji, maeneo ya kubadilishana trafiki, n.k.)
Katika mazoezi, vipaumbele vya mitandao tofauti vinaweza kuwa katika mikoa maalum. Kwa mfano, CDN za Kirusi zitakuwa na pointi zaidi za uwepo nchini Urusi. Wale wa Amerika kwanza wataendeleza mtandao huko USA. Kwa mfano, moja ya CDN Cloudflare kubwa ina pointi 2 tu nchini Urusi - Moscow na St. Hiyo ni, tunaweza kuokoa kiwango cha juu cha karibu 10 ms ya latency ikilinganishwa na uwekaji wa moja kwa moja huko Moscow.
CDN nyingi za Magharibi hazina alama nchini Urusi hata kidogo. Kwa kuunganisha nao, unaweza kuongeza ucheleweshaji tu kwa hadhira yako ya Kirusi.
6. Uboreshaji wa maudhui (miniification, mabadiliko ya muundo)
Hatua ngumu zaidi na ya juu ya teknolojia. Kubadilisha maudhui wakati wa kujifungua kunaweza kuwa hatari sana. Hata tukichukua minification: kupunguza msimbo wa chanzo (kutokana na nafasi za ziada, miundo isiyo muhimu, n.k.) kunaweza kuathiri utendaji wake. Ikiwa tunazungumzia kuhusu mabadiliko makubwa zaidi - kusonga msimbo wa JS hadi mwisho wa HTML, kuunganisha faili, nk - hatari ya kuharibu utendaji wa tovuti ni kubwa zaidi.
Kwa hivyo, aina 5 tu za CDN hufanya hivi. Bila shaka, haitawezekana kuhariri mabadiliko yote yanayohitajika ili kuharakisha mamboβuchanganuzi wa mwongozo na uboreshaji unahitajika. Kwa mfano, kuondoa msimbo ambao haujatumiwa au unaorudiwa ni kazi ya mwongozo.
Kama sheria, uboreshaji wote kama huo unadhibitiwa na mipangilio na hatari zaidi huzimwa kwa chaguo-msingi.
Usaidizi wa uwezo wa kuongeza kasi kwa aina ya CDN
Kwa hivyo, hebu tuangalie ni fursa gani za kuongeza kasi ambazo aina tofauti za CDN hutoa.
Kwa urahisi, tunarudia uainishaji.
- CDN ya bure ya kusambaza maktaba za JS (MaxCDN, Google. Yandex).
- CDN ya huduma za uboreshaji wa mteja (kwa mfano, Fonti za Google za fonti, Cloudinary, Cloudimage kwa picha).
- CDN ya uboreshaji tuli na rasilimali katika CMS (inapatikana katika Bitrix, WordPress na zingine).
- CDN ya madhumuni ya jumla (StackPath, CDNVideo, NGENIX, Megafon).
- CDN kwa kuongeza kasi ya tovuti (Cloudflare, Imperva, Airi).
Sasa hebu tulinganishe vipengele na aina za CDN.
Fursa
Aina 1
Aina 2
Aina 3
Aina 4
Aina 5
Ukandamizaji wa maandishi
+β
-
+β
+β
+
Vichwa vya akiba
+
+
+
+
+
Picha
-
+β
+β
-
+
TLS
-
-
-
+β
+
Ucheleweshaji
-
-
-
+
+
Maudhui
-
-
-
-
+
Katika jedwali hili, "+" inatumiwa kuonyesha usaidizi kamili, "-" hakuna msaada, na "+-" ni usaidizi wa sehemu. Kwa kweli, kunaweza kuwa na kupotoka kutoka kwa jedwali hili kwa ukweli (kwa mfano, CDN ya kusudi la jumla itatumia huduma za kuboresha picha), lakini kwa wazo la jumla ni muhimu.
Matokeo ya
Tunatarajia, baada ya kusoma makala hii utakuwa na picha wazi zaidi kuhusu pendekezo la "tumia CDN" ili kuharakisha tovuti zako.
Kama ilivyo katika biashara yoyote, huwezi kuamini ahadi za uuzaji za huduma yoyote. Athari inahitaji kupimwa na kupimwa chini ya hali halisi. Ikiwa tayari unatumia CDN, angalia kwa ufanisi kwa kutumia vigezo vilivyoelezwa katika makala.
Inawezekana kwamba kutumia CDN hivi sasa kunapunguza kasi ya upakiaji wa tovuti yako.
Kama pendekezo la jumla, tunaweza kuzingatia yafuatayo: soma hadhira yako, tambua wigo wake wa kijiografia. Ikiwa hadhira yako kuu imejilimbikizia ndani ya eneo la kilomita elfu 1-2, hauitaji CDN kwa kusudi lake kuu - kupunguza latency. Badala yake, unaweza kuweka seva yako karibu na watumiaji wako na kuisanidi vizuri, kupata uboreshaji mwingi ulioelezewa katika kifungu (bila malipo na cha kudumu).
Iwapo hadhira yako itasambazwa kijiografia (radius ya zaidi ya kilomita 3000), kutumia CDN ya ubora itakuwa muhimu sana. Hata hivyo, unahitaji kuelewa mapema ni nini hasa CDN yako inaweza kuongeza kasi (tazama meza ya uwezo na maelezo yao). Hata hivyo, kuongeza kasi ya tovuti bado ni kazi ngumu ambayo haiwezi kutatuliwa kwa kuunganisha CDN. Kwa kuongezea uboreshaji hapo juu, njia bora zaidi za kuongeza kasi zinabaki nyuma ya CDN: uboreshaji wa sehemu ya seva, mabadiliko ya hali ya juu kwa sehemu ya mteja (kuondoa nambari isiyotumiwa, kuboresha mchakato wa utoaji, kufanya kazi na yaliyomo, fonti, kubadilika, nk. )
Chanzo: mapenzi.com