Hast elk artikel of ark foar it optimalisearjen fan sidesnelheid hat in beskieden klausule "brûk in CDN." Yn 't algemien is CDN in netwurk foar levering fan ynhâld as netwurk foar levering fan ynhâld. Wy by Method Lab faak tsjinkomme fragen fan kliïnten oer dit ûnderwerp guon fan harren ynskeakelje harren eigen CDN. It doel fan dit artikel is om te begripen wat in CDN kin leverje yn termen fan side-laden snelheid, hokker problemen kinne ûntstean, en yn hokker gefallen it gebrûk fan in CDN rjochtfeardige is.
![[Net] in CDN brûke](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
De fertragingen dy't op 'e foto rûn binne, wurde feroarsake troch it brûken fan in CDN.
In bytsje skiednis
Lykas in protte technologyen ûntstiene CDN's út need. Mei de ûntwikkeling fan ynternetkanalen ûnder ynternetbrûkers ferskynden online fideotsjinsten. Fansels fereasket fideo-ynhâld oarders fan grutte mear bânbreedte yn ferliking mei gewoane webside-ynhâld (ôfbyldings, tekst en CSS- as JS-koade).
As jo besykje in fideostream parallel út te stjoeren nei in protte kliïnten fan ien server, sil it ynternetkanaal fan 'e server nei alle gedachten de knelpunt wurde. As regel binne in pear tûzen triedden genôch om in typysk serverkanaal te blokkearjen. Fansels kinne d'r oare boarnebeperkingen wêze, mar se binne no net wichtich. It is ek wichtich dat it útwreidzjen fan it serverkanaal te djoer is (en soms ûnmooglik), en ek ûnpraktysk. De lading op it kanaal tidens útstjoerings sil syklysk wêze.
It probleem fan it beheinen fan it kanaal fan in yndividuele tsjinner wurdt perfekt oplost troch CDN. Kliïnten ferbine net direkt mei de tsjinner, mar nei knopen yn it CDN-netwurk. Yn in ideale situaasje stjoert de tsjinner ien stream nei it CDN-knooppunt, en dan brûkt it netwurk syn eigen boarnen om dizze stream oan in protte brûkers te leverjen. Ut in ekonomysk eachpunt betelje wy allinich foar de boarnen dy't wirklik konsumearre binne (dit kin bânbreedte as ferkear wêze) en krije poerbêste skalberens fan ús tsjinst. It brûken fan in CDN om swiere ynhâld te leverjen is folslein rjochtfeardige en logysk. Hoewol it de muoite wurdich op te merken is dat de grutste spilers yn dizze romte (bgl. Netflix) har eigen CDN's bouwe ynstee fan grutte kommersjele CDN's te brûken (Akamai, Cloudflare, Fastly, ensfh.)
As it web is evoluearre, binne webapplikaasjes sels komplekser en komplekser wurden. It probleem fan laadsnelheid kaam nei foaren. Entûsjasters fan webside snelheid identifisearre fluch ferskate grutte problemen dy't feroarsake websiden om stadich te laden. Ien fan harren wie netwurk fertraging (RTT - round trip tiid of ping tiid). Fertragingen beynfloedzje in protte prosessen yn it laden fan webside: it oprjochtsjen fan in TCP-ferbining, it starten fan in TLS-sesje, it laden fan elke yndividuele boarne (ôfbylding, JS-bestân, HTML-dokumint, ensfh.)
It probleem waard fergrutte troch it feit dat by it brûken fan it HTTP/1.1-protokol (foar de komst fan SPDY, QUIC en HTTP/2 dit de ienige opsje wie), browsers iepenje net mear as 6 TCP-ferbiningen nei ien host. Dit alles late ta ferbining downtime en ineffisjint gebrûk fan kanaalbânbreedte. It probleem waard foar in part oplost troch domein sharding - it meitsjen fan ekstra hosts om de limyt op it oantal ferbiningen te oerwinnen.
Dit is wêr't de twadde mooglikheid fan CDN ferskynt - fermindering fan latency (RTT) fanwege it grutte oantal punten en de tichtby fan knopen foar de brûker. De ôfstân spilet hjir in beslissende rol: de ljochtsnelheid is beheind (sa'n 200 km/sek yn glêstried). Dit betsjut dat elke 000 km fan reizen 1000 ms fertraging of 5 ms oan RTT tafoege. Dit is de minimale tiid dy't nedich is foar oerdracht, om't d'r ek fertragingen binne op 'e tuskenapparatuer. Sûnt in CDN meastentiids wit hoe te cache foarwerpen op syn tsjinners, kinne wy profitearje fan it laden fan sokke objekten fia in CDN. Needsaaklike betingsten foar dit: de oanwêzigens fan it objekt yn 'e cache, de tichtby fan' e CDN-punt nei de brûker yn ferliking mei de webapplikaasje-tsjinner (originele tsjinner). It is wichtich om te begripen dat geografyske tichtby fan in CDN-knooppunt gjin lege latency garandearret. Routing tusken de kliïnt en de CDN kin op sa'n manier boud wurde dat de kliïnt ferbine sil mei in host yn in oar lân, en mooglik op in oar kontinint. Dit is wêr't de relaasje tusken telekomoperators en de CDN-tsjinst (peering, ferbinings, dielname oan IX, ensfh.) en it ferkearsroutingbelied fan 'e CDN sels yn it spul komme. Bygelyks, Cloudflare, by it brûken fan twa earste plannen (fergees en goedkeap), garandearret net de levering fan ynhâld fan 'e tichtstbye host - de host sil wurde selektearre om de minimale kosten te berikken.
In protte liedende ynternetbedriuwen lûke publike belangstelling (webûntwikkelders en tsjinsteigners) nei it ûnderwerp fan laden snelheid en websideprestaasjes. Under dizze bedriuwen binne Yahoo (Yslow-ark), AOL (WebPageTest) en Google (Page Speed Insights-tsjinst), dy't har eigen oanbefellings ûntwikkelje foar it rapperjen fan siden (foaral relatearje se oan klantoptimalisaasje). Letter ferskine nije ark foar testen foar websidesnelheid, dy't ek tips jouwe oer it ferheegjen fan websidesnelheid. Elk fan dizze tsjinsten of plugins hat in konsekwinte oanbefelling: "Brûk in CDN." De fermindering fan netwurklatinsje wurdt meastentiids oanhelle as in ferklearring foar it effekt fan CDN. Spitigernôch is net elkenien ree om krekt te begripen hoe't it fersnellingseffekt fan CDN wurdt berikt en hoe't it kin wurde mjitten, sadat de oanbefelling wurdt nommen op leauwen en brûkt as postulaat. Yn feite binne net alle CDN's gelyk oanmakke.
Mei help fan in CDN Hjoed
Om it nut fan it brûken fan CDN's te beoardieljen, moatte se klassifisearre wurde. Wat is no yn de praktyk te finen (de foarbylden tusken heakjes binne fansels net útputtend):
- Fergees CDN foar it fersprieden fan JS-biblioteken (MaxCDN, Google. Yandex).
- CDN fan tsjinsten foar klantoptimalisaasje (bygelyks Google Lettertypen foar lettertypen, Cloudinary, Cloudimage foar ôfbyldings).
- CDN foar statyske en boarneoptimalisaasje yn CMS (beskikber yn Bitrix, WordPress en oaren).
- Algemiene doel CDN (StackPath, CDNVideo, NGENIX, Megafon).
- CDN foar websidefersnelling (Cloudflare, Imperva, Airi).
It wichtichste ferskil tusken dizze typen is hoefolle fan it ferkear troch de CDN giet. Typen 1-3 binne de levering fan mar in diel fan 'e ynhâld: fan ien fersyk oant ferskate tsientallen (meastentiids foto's). Typen 4 en 5 binne folsleine proxying fan ferkear fia in CDN.
Yn 'e praktyk betsjut dit it oantal ferbiningen dat brûkt wurdt om de side te laden. Mei HTTP/2 brûke wy in inkele TCP-ferbining mei de host om elk oantal oanfragen te ferwurkjen. As wy boarnen ferdiele yn 'e haadhost (oarsprong) en CDN, dan is it nedich om oanfragen oer ferskate domeinen te fersprieden en ferskate TCP-ferbiningen te meitsjen. It slimste gefal is: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Dizze formule hâldt gjin rekken mei fertragingen yn mobile netwurken foar aktivearring fan it radiokanaal fan it apparaat (as it net aktyf wie) en fertragingen op 'e seltoer.
Hjir is hoe't it derút sjocht op 'e laadwetterfal fan' e side (latencies foar ferbining mei it CDN wurde markearre op RTT 150 ms):
As de CDN alle sideferkear beslacht (útsein foar tsjinsten fan tredden), dan kinne wy in inkele TCP-ferbining brûke, wêrtroch fertragingen besparje op ferbining mei ekstra hosts. Fansels jildt dit foar HTTP/2-ferbiningen.
Fierdere ferskillen wurde bepaald troch de funksjonaliteit fan in bepaalde CDN - foar it earste type is it gewoan it hostjen fan in statyske bestân, foar de fyfde feroaret it ferskate soarten side-ynhâld foar it doel fan optimisaasje.
CDN-mooglikheden foar websidefersnelling
Litte wy it folsleine oanbod fan CDN-mooglikheden beskriuwe foar it fersnellen fan siden, sûnder rekken te hâlden mei de funksjonaliteit fan yndividuele soarten CDN, en sjoch dan wat yn elk fan har is ymplementearre.
1. Kompresje fan tekst boarnen
De meast basale en begryplike funksje, mar faaks min ymplementearre. Alle CDN's ferklearje de oanwêzigens fan kompresje as har fersnellingsfunksje. Mar as jo yn mear detail sjogge, wurde tekoarten dúdlik:
- lege graden foar dynamyske kompresje kinne brûkt wurde - 5-6 (bygelyks foar gzip is it maksimum 9);
- statyske kompresje (bestannen yn cache) brûkt gjin ekstra funksjes (bygelyks zopfi of brotli mei graad 11)
- der is gjin stipe foar effisjinte brotli kompresje (saving oer 20% ferlike mei gzip).
As jo in CDN brûke, is it de muoite wurdich om dizze pear punten te kontrolearjen: nim it bestân dat fan 'e CDN kaam, registrearje de komprimearre grutte en komprimearje it manuell foar fergeliking (jo kinne bygelyks wat online tsjinst brûke mei brotli-stipe, bygelyks ).
2. Setting client caching headers
Ek in ienfâldige snelheidsfunksje: kopteksten tafoegje foar ynhâld-caching troch de kliïnt (browser). De meast aktuele koptekst is cache-kontrôle, de ferâldere is ferrint. Derneist kin Etag brûkt wurde. It wichtichste is dat de maksimale leeftyd fan cache-kontrôle grut genôch is (fan in moanne of mear as jo ree binne om de boarne sa hurd mooglik te cache, kinne jo de ûnferoarlike opsje tafoegje).
CDN's kinne de maksimale leeftydswearde ferleegje, wêrtroch't de brûker twingt om statyske ynhâld faker opnij te laden. It is net dúdlik wêrmei dit ferbûn is: de winsk om ferkear op it netwurk te fergrutsjen of kompatibiliteit te fergrutsjen mei siden dy't net witte hoe't jo de cache weromsette. Bygelyks, de standert Cloudflare header-cache-tiid is 1 oere, wat heul leech is foar ûnferoarlike statyske gegevens.
3. Image optimalisaasje
Sûnt de CDN de funksjes fan it caching en it tsjinjen fan ôfbyldings oernimt, soe it logysk wêze om se op 'e CDN-kant te optimalisearjen en se te tsjinjen oan brûkers yn dizze foarm. Litte wy fuortendaliks reservearje dat dizze funksje allinich beskikber is foar CDN-typen 2, 3 en 5.
Jo kinne ôfbyldings op ferskate manieren optimalisearje: avansearre kompresjeformaten brûke (lykas WebP), effisjintere encoders (MozJPEG), of gewoan ûnnedige metadata opromje.
Yn 't algemien binne d'r twa soarten fan sokke optimisaasjes: mei kwaliteitsferlies en sûnder kwaliteitsferlies. CDN's stribje gewoanlik om optimisaasje sûnder ferlies te brûken om mooglike klachten fan klanten oer feroaringen yn ôfbyldingskwaliteit te foarkommen. Yn sokke betingsten sil de winst minimaal wêze. Yn 'e realiteit is it JPEG-kwaliteitsnivo faaks folle heger dan nedich en jo kinne feilich opnij komprimearje mei in legere kwaliteitsnivo sûnder de brûkersûnderfining te kompromittearjen. Oan 'e oare kant is it lestich om it nivo fan kwaliteit en ynstellingen universeel te bepalen foar alle mooglike webapplikaasjes, sadat CDN's mear konservative ynstellings brûke yn ferliking mei dyjingen dy't kinne wurde tapast mei rekkening mei de kontekst (doel fan ôfbyldings, type webapplikaasje , ensfh.)
4. Optimalisearjen fan de TLS ferbining
De measte ferkear hjoed reizget oer TLS ferbinings, wat betsjut dat wy besteegje ekstra tiid op TLS ûnderhannelings. Koartlyn binne nije technologyen ûntwikkele om dit proses te fersnellen. Bygelyks, dit is EC kryptografy, TLS 1.3, sesje-cache en kaartsjes, hardware fersifering fersnelling (AES-NI), ensfh Korrekt ynstelle TLS kin ferminderjen ferbining tiid ta 0-1 RTT (net telle DNS en TCP).
Mei moderne software is it net dreech om sokke praktiken op jo eigen te ymplementearjen.
Net alle CDN's implementearje TLS best practices, jo kinne dit kontrolearje troch de TLS-ferbiningstiid te mjitten (bygelyks yn Webpagetest). Ideaal foar in nije ferbining - 1RTT, 2RTT - gemiddelde nivo, 3RTT en mear - min.
It moat ek opmurken wurde dat sels by it brûken fan TLS op it CDN-nivo, de server mei ús webapplikaasje ek TLS moat ferwurkje, mar fan 'e CDN-kant, om't it ferkear tusken de server en de CDN trochgiet op it iepenbiere netwurk. Yn it slimste gefal krije wy dûbele TLS-ferbiningfertragingen (de earste nei de CDN-host, de twadde tusken har en ús server).
Foar guon applikaasjes is it wurdich omtinken te jaan oan feiligensproblemen: ferkear wurdt normaal ûntsifere op CDN-knooppunten, en dit is in potinsjele kâns foar ferkearsûnderskepping. De opsje om te wurkjen sûnder iepenbiering fan ferkear wurdt normaal oanbean yn toptariefplannen foar in ekstra fergoeding.
5. Ferminderje ferbining fertragingen
It wichtichste foardiel fan CDN dêr't elkenien oer praat: lege latency (minder ôfstân) tusken de CDN-host en de brûker. Berikke troch it meitsjen fan in geografysk ferspraat netwurkarsjitektuer, wêryn hosts lizze yn punten fan konsintraasje fan brûkers (stêden, ferkearsútwikselingspunten, ensfh.)
Yn 'e praktyk kinne prioriteiten foar ferskate netwurken yn spesifike regio's wêze. Bygelyks, Russyske CDN's sille mear punten fan oanwêzigens hawwe yn Ruslân. De Amerikaanske sille earst it netwurk yn 'e FS ûntwikkelje. Bygelyks, ien fan 'e grutste CDN Cloudflare hat mar 2 punten yn Ruslân - Moskou en St. Dat is, wy kinne maksimaal sawat 10 ms fan latency besparje yn ferliking mei direkte pleatsing yn Moskou.
De measte westlike CDN's hawwe hielendal gjin punten yn Ruslân. Troch ferbining te meitsjen mei har, kinne jo de fertragingen allinich fergrutsje foar jo Russyske publyk.
6. Optimalisaasje fan ynhâld (minifikaasje, strukturele feroarings)
De meast komplekse en technologysk avansearre punt. It feroarjen fan ynhâld by levering kin heul risikofolle wêze. Sels as wy minifikaasje nimme: it ferminderjen fan de boarnekoade (fanwege ekstra spaasjes, ûnwichtige struktueren, ensfh.) kin de prestaasjes beynfloedzje. As wy prate oer mear serieuze wizigingen - it ferpleatsen fan de JS-koade nei it ein fan 'e HTML, gearfoegjen fan triemmen, ensfh - is it risiko fan fersteuring fan' e funksjonaliteit fan 'e side noch heger.
Dêrom dogge allinich guon type 5 CDN's dit. Fansels sil it net mooglik wêze om alle wizigingen te automatisearjen dy't nedich binne om dingen te fersnellen - manuele analyze en optimisaasje binne fereaske. Bygelyks, it fuortsmiten fan net brûkte of dûbele koade is in hânmjittich taak.
As regel wurde al sokke optimalisaasjes regele troch ynstellings en de gefaarlikste binne standert útskeakele.
Stipe foar fersnellingsmooglikheden troch CDN-type
Litte wy dus ris sjen hokker potensjele fersnellingsmooglikheden de ferskate soarten CDN's leverje.
Foar gemak werhelje wy de klassifikaasje.
- Fergees CDN foar it fersprieden fan JS-biblioteken (MaxCDN, Google. Yandex).
- CDN fan tsjinsten foar klantoptimalisaasje (bygelyks Google Lettertypen foar lettertypen, Cloudinary, Cloudimage foar ôfbyldings).
- CDN foar statyske en boarneoptimalisaasje yn CMS (beskikber yn Bitrix, WordPress en oaren).
- Algemiene doel CDN (StackPath, CDNVideo, NGENIX, Megafon).
- CDN foar websidefersnelling (Cloudflare, Imperva, Airi).
Litte wy no de funksjes en soarten CDN fergelykje.
kâns
Type 1
Type 2
Type 3
Type 4
Type 5
Tekst kompresje
+–
-
+–
+–
+
Cache-headers
+
+
+
+
+
Ofbyldings
-
+–
+–
-
+
TLS
-
-
-
+–
+
Fertragingen
-
-
-
+
+
ynhâld
-
-
-
-
+
Yn dizze tabel wurdt "+" brûkt om folsleine stipe oan te jaan, "–" is gjin stipe, en "+–" is foar in part stipe. Fansels kinne d'r yn 'e realiteit ôfwikingen wêze fan dizze tabel (bygelyks guon algemiene doelen CDN sille funksjes útfiere foar it optimalisearjen fan ôfbyldings), mar foar in algemien idee is it nuttich.
Resultaten
Hooplik sille jo nei it lêzen fan dit artikel in dúdliker byld hawwe oangeande de oanbefelling "gebrûk in CDN" om jo siden te fersnellen.
Lykas yn elk bedriuw, kinne jo de marketingbeloften fan elke tsjinst net leauwe. It effekt moat wurde mjitten en hifke ûnder echte omstannichheden. As jo al in CDN brûke, kontrolearje it dan op effektiviteit mei de kritearia beskreaun yn it artikel.
It is mooglik dat it brûken fan in CDN op it stuit de laadtiid fan jo side fertraget.
As algemiene oanbefelling kinne wy rjochtsje op it folgjende: studearje jo publyk, bepale har geografyske omfang. As jo haadpublyk konsintrearre is yn in straal fan 1-2 tûzen kilometer, hawwe jo gjin CDN nedich foar har haaddoel - it ferminderjen fan latency. Ynstee kinne jo jo server tichter by jo brûkers pleatse en it goed konfigurearje, en krije de measte optimalisaasjes beskreaun yn it artikel (fergees en permanint).
As jo publyk wirklik geografysk ferdield is (radius fan mear dan 3000 kilometer), sil it brûken fan in kwaliteits-CDN echt nuttich wêze. Jo moatte lykwols fan tefoaren begripe wat krekt jo CDN kin fersnelle (sjoch de tabel mei mooglikheden en har beskriuwing). De fersnelling fan 'e webside bliuwt lykwols noch in komplekse taak dy't net oplost wurde kin troch it ferbinen fan in CDN. Neist de boppesteande optimisaasjes bliuwe de meast effektive middels fan fersnelling efter de CDN: optimisaasje fan it serverdiel, avansearre wizigingen oan it kliïntdiel (net brûkte koade fuortsmite, it renderingsproses optimalisearje, wurkje mei ynhâld, lettertypen, oanpassingsfermogen, ensfh. )
Boarne: www.habr.com