🥇[Peidiwch â] defnyddio CDN

Mae gan bron bob erthygl neu offeryn ar gyfer optimeiddio cyflymder gwefan gymal cymedrol “defnyddio CDN.” Yn gyffredinol, rhwydwaith darparu cynnwys neu rwydwaith cyflenwi cynnwys yw CDN. Rydym ni yn Method Lab yn aml yn dod ar draws cwestiynau gan gleientiaid ar y pwnc hwn; mae rhai ohonynt yn galluogi eu CDN eu hunain. Pwrpas yr erthygl hon yw deall yr hyn y gall CDN ei ddarparu o ran cyflymder llwytho safle, pa broblemau all godi, ac ym mha achosion y gellir cyfiawnhau defnyddio CDN.

Mae'r oedi o amgylch y llun yn cael ei achosi gan ddefnyddio CDN.

Tipyn o hanes

Fel llawer o dechnolegau, daeth CDNs i'r amlwg o reidrwydd. Gyda datblygiad sianeli Rhyngrwyd ymhlith defnyddwyr y Rhyngrwyd, ymddangosodd gwasanaethau fideo ar-lein. Yn naturiol, mae cynnwys fideo yn gofyn am orchmynion maint mwy o led band o'i gymharu â chynnwys gwefan arferol (lluniau, testun, a chod CSS neu JS).

Wrth geisio darlledu ffrwd fideo ochr yn ochr â llawer o gleientiaid o un gweinydd, mae sianel Rhyngrwyd y gweinydd yn fwyaf tebygol o ddod yn dagfa. Fel rheol, mae ychydig filoedd o edafedd yn ddigon i glocsio sianel gweinydd nodweddiadol. Wrth gwrs, efallai y bydd cyfyngiadau adnoddau eraill, ond nid ydynt yn bwysig ar hyn o bryd. Mae hefyd yn bwysig bod ehangu sianel y gweinydd yn rhy ddrud (ac weithiau'n amhosibl), a hefyd yn anymarferol. Bydd y llwyth ar y sianel yn ystod darllediadau yn gylchol.

Mae'r broblem o gyfyngu ar sianel gweinydd unigol yn cael ei datrys yn berffaith gan CDN. Nid yw cleientiaid yn cysylltu â'r gweinydd yn uniongyrchol, ond â nodau yn y rhwydwaith CDN. Mewn sefyllfa ddelfrydol, mae'r gweinydd yn anfon un ffrwd i'r nod CDN, ac yna mae'r rhwydwaith yn defnyddio ei adnoddau ei hun i gyflwyno'r ffrwd hon i lawer o ddefnyddwyr. O safbwynt economaidd, rydyn ni'n talu am yr adnoddau a ddefnyddir mewn gwirionedd yn unig (gallai hyn fod yn lled band neu'n draffig) ac rydyn ni'n sicrhau bod ein gwasanaeth yn gallu cynyddu'n aruthrol. Mae defnyddio CDN i gyflwyno cynnwys trwm yn gwbl gyfiawn ac yn rhesymegol. Er ei bod yn werth nodi bod y chwaraewyr mwyaf yn y gofod hwn (e.e. Netflix) yn adeiladu eu CDNs eu hunain yn lle defnyddio CDNs masnachol mawr (Akamai, Cloudflare, Fastly, ac ati)

Wrth i'r we esblygu, mae cymwysiadau gwe eu hunain wedi dod yn fwy cymhleth a chymhleth. Daeth problem cyflymder llwytho i'r amlwg. Nododd selogion cyflymder gwefannau yn gyflym sawl problem fawr a achosodd i wefannau lwytho'n araf. Un ohonynt oedd oedi rhwydwaith (RTT - amser taith gron neu amser ping). Mae oedi yn effeithio ar lawer o brosesau wrth lwytho gwefan: sefydlu cysylltiad TCP, cychwyn sesiwn TLS, llwytho pob adnodd unigol (delwedd, ffeil JS, dogfen HTML, ac ati)

Gwaethygwyd y broblem gan y ffaith, wrth ddefnyddio'r protocol HTTP/1.1 (cyn dyfodiad SPDY, QUIC a HTTP/2 dyma'r unig opsiwn), nid yw porwyr yn agor mwy na 6 chysylltiad TCP i un gwesteiwr. Arweiniodd hyn i gyd at amser segur cysylltiad a defnydd aneffeithlon o led band sianel. Cafodd y broblem ei datrys yn rhannol trwy rannu parth - creu gwesteiwyr ychwanegol i oresgyn y terfyn ar nifer y cysylltiadau.

Dyma lle mae ail allu CDN yn ymddangos - lleihau hwyrni (RTT) oherwydd y nifer fawr o bwyntiau ac agosrwydd nodau i'r defnyddiwr. Mae pellter yn chwarae rhan bendant yma: mae cyflymder golau yn gyfyngedig (tua 200 km / eiliad mewn ffibr optegol). Mae hyn yn golygu bod pob 000 km o deithio yn ychwanegu 1000 ms o oedi neu 5 ms at RTT. Dyma'r amser lleiaf sydd ei angen ar gyfer trosglwyddo, gan fod oedi hefyd ar yr offer canolradd. Gan fod CDN fel arfer yn gwybod sut i storio gwrthrychau ar ei weinyddion, gallwn elwa o lwytho gwrthrychau o'r fath trwy CDN. Amodau angenrheidiol ar gyfer hyn: presenoldeb y gwrthrych yn y storfa, agosrwydd y pwynt CDN i'r defnyddiwr o'i gymharu â gweinydd y cymhwysiad gwe (gweinydd gwreiddiol). Mae'n bwysig deall nad yw agosrwydd daearyddol nod CDN yn gwarantu hwyrni isel. Gellir adeiladu llwybro rhwng y cleient a'r CDN yn y fath fodd fel y bydd y cleient yn cysylltu â gwesteiwr mewn gwlad arall, ac o bosibl ar gyfandir arall. Dyma lle mae'r berthynas rhwng gweithredwyr telathrebu a'r gwasanaeth CDN (syllu, cysylltiadau, cymryd rhan yn IX, ac ati) a pholisi llwybro traffig y CDN ei hun yn dod i rym. Er enghraifft, nid yw Cloudflare, wrth ddefnyddio dau gynllun cychwynnol (am ddim ac yn rhad), yn gwarantu cyflwyno cynnwys o'r gwesteiwr agosaf - bydd y gwesteiwr yn cael ei ddewis i gyflawni'r isafswm cost.

Mae llawer o gwmnïau Rhyngrwyd blaenllaw yn denu diddordeb y cyhoedd (datblygwyr gwe a pherchnogion gwasanaethau) i bwnc cyflymder llwytho a pherfformiad gwefannau. Ymhlith y cwmnïau hyn mae Yahoo (offeryn Yslow), AOL (WebPageTest) a Google (gwasanaeth Page Speed Insights), sy'n datblygu eu hargymhellion eu hunain ar gyfer cyflymu gwefannau (yn bennaf maent yn ymwneud ag optimeiddio cleientiaid). Yn ddiweddarach, mae offer profi cyflymder gwefan newydd yn ymddangos, sydd hefyd yn rhoi awgrymiadau ar gynyddu cyflymder gwefan. Mae gan bob un o'r gwasanaethau neu'r ategion hyn argymhelliad cyson: “Defnyddiwch CDN.” Cyfeirir at y gostyngiad mewn hwyrni rhwydwaith fel arfer fel esboniad am effaith CDN. Yn anffodus, nid yw pawb yn barod i ddeall yn union sut y cyflawnir effaith cyflymu CDN a sut y gellir ei fesur, felly cymerir yr argymhelliad ar ffydd a'i ddefnyddio fel rhagdyb. Mewn gwirionedd, nid yw pob CDN yn cael ei greu yn gyfartal.

Defnyddio CDN Heddiw

Er mwyn asesu defnyddioldeb defnyddio CDNs, mae angen eu dosbarthu. Beth sydd i’w gael yn ymarferol nawr (nid yw’r enghreifftiau mewn cromfachau, wrth gwrs, yn hollgynhwysfawr):

CDN am ddim ar gyfer dosbarthu llyfrgelloedd JS (MaxCDN, Google. Yandex).
CDN o wasanaethau ar gyfer optimeiddio cleientiaid (er enghraifft, Google Fonts ar gyfer ffontiau, Cloudinary, Cloudimage ar gyfer delweddau).
CDN ar gyfer optimeiddio statig ac adnoddau yn CMS (ar gael yn Bitrix, WordPress ac eraill).
CDN pwrpas cyffredinol (StackPath, CDNVideo, NGENIX, Megafon).
CDN ar gyfer cyflymiad gwefan (Cloudflare, Imperva, Airi).

Y gwahaniaeth allweddol rhwng y mathau hyn yw faint o'r traffig sy'n mynd drwy'r CDN. Mathau 1-3 yw cyflwyno rhan yn unig o'r cynnwys: o un cais i sawl dwsin (lluniau fel arfer). Mae mathau 4 a 5 yn brocsi llawn o draffig trwy CDN.

Yn ymarferol, mae hyn yn golygu nifer y cysylltiadau a ddefnyddir i lwytho'r wefan. Gyda HTTP/2, rydym yn defnyddio un cysylltiad TCP â'r gwesteiwr i brosesu unrhyw nifer o geisiadau. Os byddwn yn rhannu adnoddau yn y prif westeiwr (tarddiad) a CDN, yna mae angen dosbarthu ceisiadau ar draws sawl parth a chreu sawl cysylltiad TCP. Yr achos gwaethaf yw: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Nid yw'r fformiwla hon yn ystyried oedi mewn rhwydweithiau symudol ar gyfer actifadu sianel radio'r ddyfais (os nad oedd yn weithredol) ac oedi ar y tŵr cell.

Dyma sut mae'n edrych ar raeadr llwytho'r safle (mae cuddfannau ar gyfer cysylltu â'r CDN wedi'u hamlygu yn RTT 150 ms):

Os yw'r CDN yn cwmpasu holl draffig y safle (ac eithrio gwasanaethau trydydd parti), yna gallwn ddefnyddio un cysylltiad TCP, gan arbed hwyrni wrth gysylltu â gwesteiwyr ychwanegol. Wrth gwrs, mae hyn yn berthnasol i gysylltiadau HTTP/2.

Mae gwahaniaethau pellach yn cael eu pennu gan ymarferoldeb CDN penodol - ar gyfer y math cyntaf, dim ond cynnal ffeil statig ydyw, ar gyfer y pumed mae'n newid sawl math o gynnwys gwefan at ddibenion optimeiddio.

Galluoedd CDN ar gyfer cyflymu gwefan

Gadewch i ni ddisgrifio'r ystod lawn o alluoedd CDN ar gyfer cyflymu gwefannau, heb ystyried ymarferoldeb mathau unigol o CDN, ac yna gweld beth sy'n cael ei weithredu ym mhob un ohonynt.

1. Cywasgu adnoddau testun

Y nodwedd fwyaf sylfaenol a dealladwy, ond yn aml yn cael ei gweithredu'n wael. Mae pob CDN yn datgan presenoldeb cywasgu fel eu nodwedd cyflymu. Ond os edrychwch yn fanylach, daw diffygion yn amlwg:

gellir defnyddio graddau isel ar gyfer cywasgu deinamig - 5-6 (er enghraifft, ar gyfer gzip yr uchafswm yw 9);
nid yw cywasgu statig (ffeiliau mewn storfa) yn defnyddio nodweddion ychwanegol (er enghraifft, zopfi neu brotli gyda gradd 11)
nid oes cefnogaeth ar gyfer cywasgu brotli effeithlon (arbed tua 20% o'i gymharu â gzip).

Os ydych chi'n defnyddio CDN, mae'n werth gwirio'r ychydig bwyntiau hyn: cymerwch y ffeil a ddaeth o'r CDN, cofnodwch ei faint cywasgedig a'i gywasgu â llaw i'w gymharu (gallwch ddefnyddio rhywfaint o wasanaeth ar-lein gyda chefnogaeth brotli, er enghraifft vsszhat.rf).

2. Gosod penawdau caching cleient

Hefyd yn nodwedd gyflymu syml: ychwanegu penawdau ar gyfer caching cynnwys gan y cleient (porwr). Y pennawd mwyaf cyfredol yw rheolaeth cache, mae'r un hen ffasiwn yn dod i ben. Yn ogystal, gellir defnyddio Etag. Y prif beth yw bod uchafswm oedran rheoli cache yn ddigon mawr (o fis neu fwy) Os ydych chi'n barod i storio'r adnodd mor galed â phosib, gallwch chi ychwanegu'r opsiwn na ellir ei gyfnewid.

Gall CDNs ostwng y gwerth oedran uchaf, gan orfodi'r defnyddiwr i ail-lwytho cynnwys statig yn amlach. Nid yw'n glir beth mae hyn yn gysylltiedig ag ef: yr awydd i gynyddu traffig ar y rhwydwaith neu gynyddu cydnawsedd â gwefannau nad ydynt yn gwybod sut i ailosod y storfa. Er enghraifft, yr amser cache pennawd Cloudflare rhagosodedig yw 1 awr, sy'n isel iawn ar gyfer data sefydlog na ellir ei gyfnewid.

3. Optimeiddio delwedd

Gan fod y CDN yn ymgymryd â swyddogaethau storio a gweini delweddau, byddai'n rhesymegol eu optimeiddio ar yr ochr CDN a'u gwasanaethu i ddefnyddwyr yn y ffurflen hon. Gadewch i ni archebu ar unwaith bod y nodwedd hon ar gael ar gyfer mathau CDN 2, 3 a 5 yn unig.

Gallwch optimeiddio delweddau mewn amrywiaeth o ffyrdd: gan ddefnyddio fformatau cywasgu datblygedig (fel WebP), amgodyddion mwy effeithlon (MozJPEG), neu lanhau metadata diangen.

Yn gyffredinol, mae dau fath o optimeiddiadau o'r fath: gyda cholli ansawdd a heb golli ansawdd. Mae CDNs fel arfer yn ymdrechu i ddefnyddio optimeiddio di-golled er mwyn osgoi cwynion posibl gan gwsmeriaid am newidiadau mewn ansawdd delwedd. Mewn amodau o'r fath, bydd y cynnydd yn fach iawn. Mewn gwirionedd, yn aml mae lefel ansawdd JPEG yn llawer uwch na'r angen a gallwch chi ail-gywasgu'n ddiogel â lefel ansawdd is heb gyfaddawdu ar brofiad y defnyddiwr. Ar y llaw arall, mae'n anodd pennu lefel yr ansawdd a'r gosodiadau yn gyffredinol ar gyfer pob rhaglen we bosibl, felly mae CDNs yn defnyddio gosodiadau mwy ceidwadol o gymharu â'r rhai y gellir eu cymhwyso gan ystyried y cyd-destun (diben delweddau, math o raglen we , ac ati)

4. Optimeiddio'r cysylltiad TLS

Mae'r rhan fwyaf o draffig heddiw yn teithio dros gysylltiadau TLS, sy'n golygu ein bod yn treulio amser ychwanegol ar negodi TLS. Yn ddiweddar, datblygwyd technolegau newydd i gyflymu'r broses hon. Er enghraifft, mae hyn yn cryptograffeg EC, TLS 1.3, cache sesiwn a thocynnau, cyflymiad amgryptio caledwedd (AES-NI), ac ati Gall gosod TLS yn gywir leihau amser cysylltiad i 0-1 RTT (ddim yn cyfrif DNS a TCP).

Gyda meddalwedd modern, nid yw'n anodd gweithredu arferion o'r fath ar eich pen eich hun.

Nid yw pob CDN yn gweithredu arferion gorau TLS; gallwch wirio hyn trwy fesur yr amser cysylltu TLS (er enghraifft, yn Webpagetest). Yn ddelfrydol ar gyfer cysylltiad newydd - 1RTT, 2RTT - lefel gyfartalog, 3RTT a mwy - drwg.

Dylid nodi hefyd, hyd yn oed wrth ddefnyddio TLS ar lefel CDN, bod yn rhaid i'r gweinydd gyda'n cymhwysiad gwe hefyd brosesu TLS, ond o'r ochr CDN, oherwydd bod y traffig rhwng y gweinydd a'r CDN yn pasio ar y rhwydwaith cyhoeddus. Yn yr achos gwaethaf, byddwn yn cael oedi dwbl cysylltiad TLS (y cyntaf i'r gwesteiwr CDN, yr ail rhyngddo a'n gweinydd).

Ar gyfer rhai cymwysiadau, mae'n werth rhoi sylw i faterion diogelwch: mae traffig fel arfer yn cael ei ddadgryptio ar nodau CDN, ac mae hwn yn gyfle posibl ar gyfer rhyng-gipio traffig. Mae'r opsiwn o weithio heb ddatgeliad traffig fel arfer yn cael ei gynnig mewn cynlluniau tariff uchaf am ffi ychwanegol.

5. Lleihau oedi cysylltiad

Prif fudd CDN y mae pawb yn siarad amdano: hwyrni isel (llai o bellter) rhwng y gwesteiwr CDN a'r defnyddiwr. Wedi'i gyflawni trwy greu pensaernïaeth rhwydwaith wedi'i ddosbarthu'n ddaearyddol, lle mae gwesteiwyr wedi'u lleoli mewn mannau crynodiad o ddefnyddwyr (dinasoedd, pwyntiau cyfnewid traffig, ac ati)

Yn ymarferol, gall blaenoriaethau ar gyfer gwahanol rwydweithiau fod mewn rhanbarthau penodol. Er enghraifft, bydd gan CDNs Rwsia fwy o bwyntiau presenoldeb yn Rwsia. Bydd y rhai Americanaidd yn gyntaf oll yn datblygu'r rhwydwaith yn UDA. Er enghraifft, dim ond 2 bwynt sydd gan un o'r CDN Cloudflare mwyaf yn Rwsia - Moscow a St Petersburg. Hynny yw, gallwn arbed uchafswm o tua 10 ms o hwyrni o'i gymharu â lleoliad uniongyrchol ym Moscow.

Nid oes gan y mwyafrif o CDNs Gorllewinol bwyntiau yn Rwsia o gwbl. Trwy gysylltu â nhw, dim ond i'ch cynulleidfa Rwsia y gallwch chi gynyddu'r oedi.

6. Optimeiddio cynnwys (lleihau, newidiadau strwythurol)

Y pwynt mwyaf cymhleth a thechnolegol ddatblygedig. Gall newid cynnwys wrth ei gyflwyno fod yn beryglus iawn. Hyd yn oed os ydym yn cymryd miniification: gall lleihau'r cod ffynhonnell (oherwydd lleoedd ychwanegol, strwythurau dibwys, ac ati) effeithio ar ei berfformiad. Os byddwn yn siarad am newidiadau mwy difrifol - symud y cod JS i ddiwedd yr HTML, uno ffeiliau, ac ati - mae'r risg o amharu ar ymarferoldeb y wefan hyd yn oed yn uwch.

Felly, dim ond rhai CDNs math 5 sy'n gwneud hyn. Wrth gwrs, ni fydd yn bosibl awtomeiddio'r holl newidiadau sydd eu hangen i gyflymu pethau - mae angen dadansoddi â llaw ac optimeiddio. Er enghraifft, mae tynnu cod heb ei ddefnyddio neu god dyblyg yn dasg â llaw.

Fel rheol, mae pob optimeiddiad o'r fath yn cael ei reoli gan osodiadau ac mae'r rhai mwyaf peryglus yn cael eu hanalluogi yn ddiofyn.

Cefnogaeth ar gyfer galluoedd cyflymu yn ôl math CDN

Felly gadewch i ni edrych ar ba gyfleoedd cyflymu posibl y mae'r gwahanol fathau o CDNs yn eu darparu.

Er hwylustod, rydym yn ailadrodd y dosbarthiad.

CDN am ddim ar gyfer dosbarthu llyfrgelloedd JS (MaxCDN, Google. Yandex).
CDN o wasanaethau ar gyfer optimeiddio cleientiaid (er enghraifft, Google Fonts ar gyfer ffontiau, Cloudinary, Cloudimage ar gyfer delweddau).
CDN ar gyfer optimeiddio statig ac adnoddau yn CMS (ar gael yn Bitrix, WordPress ac eraill).
CDN pwrpas cyffredinol (StackPath, CDNVideo, NGENIX, Megafon).
CDN ar gyfer cyflymiad gwefan (Cloudflare, Imperva, Airi).

Nawr, gadewch i ni gymharu'r nodweddion a'r mathau o CDN.

Cyfle
Math 1
Math 2
Math 3
Math 4
Math 5

Cywasgu testun
+–
-
+–
+–
+

Penawdau Cache
+
+
+
+
+

Lluniau
-
+–
+–
-
+

TLS
-
-
-
+–
+

Oedi
-
-
-
+
+

Cynnwys
-
-
-
-
+

Yn y tabl hwn, defnyddir “+” i nodi cefnogaeth lawn, “–” yw dim cefnogaeth, a “+–” yw cefnogaeth rannol. Wrth gwrs, efallai y bydd gwyriadau o'r tabl hwn mewn gwirionedd (er enghraifft, bydd rhywfaint o CDN pwrpas cyffredinol yn gweithredu nodweddion ar gyfer optimeiddio delweddau), ond ar gyfer syniad cyffredinol mae'n ddefnyddiol.

Canlyniadau

Gobeithio, ar ôl darllen yr erthygl hon, bydd gennych ddarlun cliriach o'r argymhelliad “defnyddio CDN” i gyflymu'ch gwefannau.

Fel mewn unrhyw fusnes, ni allwch gredu addewidion marchnata unrhyw wasanaeth. Mae angen mesur a phrofi'r effaith o dan amodau real. Os ydych eisoes yn defnyddio CDN, gwiriwch ef am effeithiolrwydd gan ddefnyddio'r meini prawf a ddisgrifir yn yr erthygl.

Mae'n bosibl bod defnyddio CDN ar hyn o bryd yn arafu amser llwytho eich gwefan.

Fel argymhelliad cyffredinol, gallwn ganolbwyntio ar y canlynol: astudiwch eich cynulleidfa, pennwch ei chwmpas daearyddol. Os yw'ch prif gynulleidfa wedi'i chrynhoi o fewn radiws o 1-2 mil cilomedr, nid oes angen CDN arnoch ar gyfer ei brif bwrpas - lleihau hwyrni. Yn lle hynny, gallwch chi osod eich gweinydd yn agosach at eich defnyddwyr a'i ffurfweddu'n iawn, gan gael y rhan fwyaf o'r optimizations a ddisgrifir yn yr erthygl (am ddim ac yn barhaol).

Rhag ofn bod eich cynulleidfa wedi'i dosbarthu'n wirioneddol yn ddaearyddol (radiws o fwy na 3000 cilomedr), bydd defnyddio CDN o safon yn ddefnyddiol iawn. Fodd bynnag, mae angen i chi ddeall ymlaen llaw beth yn union y gall eich CDN ei gyflymu (gweler y tabl galluoedd a'u disgrifiad). Fodd bynnag, mae cyflymu gwefan yn dal i fod yn dasg gymhleth na ellir ei datrys trwy gysylltu CDN. Yn ogystal â'r optimeiddiadau uchod, mae'r dull cyflymu mwyaf effeithiol yn parhau i fod y tu ôl i'r CDN: optimeiddio rhan y gweinydd, newidiadau datblygedig i ran y cleient (tynnu'r cod nas defnyddiwyd, optimeiddio'r broses rendro, gweithio gyda chynnwys, ffontiau, gallu i addasu, ac ati. )

Ffynhonnell: hab.com

[Peidiwch â] defnyddio CDN