🥇[Moenie] CDN gebruik nie

Byna elke artikel of hulpmiddel vir die optimalisering van werfspoed het 'n beskeie klousule "gebruik 'n CDN." Oor die algemeen is CDN 'n inhoudafleweringsnetwerk of inhoudafleweringsnetwerk. Ons by Method Lab kry gereeld vrae van kliënte oor hierdie onderwerp; sommige van hulle aktiveer hul eie CDN. Die doel van hierdie artikel is om te verstaan wat 'n CDN kan verskaf in terme van werflaaispoed, watter probleme kan opduik en in watter gevalle die gebruik van 'n CDN geregverdig is.

Die vertragings wat in die prentjie omring word veroorsaak deur die gebruik van 'n CDN.

'N bietjie geskiedenis

Soos baie tegnologieë, het CDN's uit nood ontstaan. Met die ontwikkeling van internetkanale onder internetgebruikers het aanlynvideodienste verskyn. Natuurlik benodig video-inhoud ordes van grootte meer bandwydte in vergelyking met gewone webwerf-inhoud (prente, teks en CSS- of JS-kode).

Wanneer jy probeer om 'n videostroom parallel na baie kliënte vanaf een bediener uit te saai, sal die bediener se internetkanaal heel waarskynlik die bottelnek word. As 'n reël is 'n paar duisend drade genoeg om 'n tipiese bedienerkanaal te verstop. Natuurlik kan daar ander hulpbronbeperkings wees, maar dit is nie nou belangrik nie. Dit is ook belangrik dat die uitbreiding van die bedienerkanaal te duur is (en soms onmoontlik), en ook onprakties. Die las op die kanaal tydens uitsendings sal siklies wees.

Die probleem om die kanaal van 'n individuele bediener te beperk, word perfek deur CDN opgelos. Kliënte koppel nie direk aan die bediener nie, maar aan nodusse in die CDN-netwerk. In 'n ideale situasie stuur die bediener een stroom na die CDN-nodus, en dan gebruik die netwerk sy eie hulpbronne om hierdie stroom aan baie gebruikers te lewer. Uit 'n ekonomiese oogpunt betaal ons slegs vir die hulpbronne wat werklik verbruik word (dit kan bandwydte of verkeer wees) en kry uitstekende skaalbaarheid van ons diens. Die gebruik van 'n CDN om swaar inhoud te lewer is heeltemal geregverdig en logies. Alhoewel dit opmerklik is dat die grootste spelers in hierdie ruimte (bv. Netflix) hul eie CDN's bou in plaas daarvan om groot kommersiële CDN's te gebruik (Akamai, Cloudflare, Fastly, ens.)

Soos die web ontwikkel het, het webtoepassings self meer kompleks en kompleks geword. Die probleem van laaispoed het na vore gekom. Webwerfspoed-entoesiaste het vinnig verskeie groot probleme geïdentifiseer wat veroorsaak het dat webwerwe stadig laai. Een daarvan was netwerkvertragings (RTT - heen-en-weer-rittyd of ping-tyd). Vertragings beïnvloed baie prosesse in die laai van die webwerf: vestiging van 'n TCP-verbinding, begin 'n TLS-sessie, laai elke individuele hulpbron (prent, JS-lêer, HTML-dokument, ens.)

Die probleem is vererger deur die feit dat wanneer die HTTP/1.1-protokol gebruik word (voor die koms van SPDY, QUIC en HTTP/2 was dit die enigste opsie), blaaiers nie meer as 6 TCP-verbindings na een gasheer oopmaak nie. Dit alles het gelei tot stilstand van verbindings en ondoeltreffende gebruik van kanaalbandwydte. Die probleem is gedeeltelik opgelos deur domeinversplintering – die skepping van bykomende gashere om die beperking op die aantal verbindings te oorkom.

Dit is waar die tweede vermoë van CDN verskyn - die vermindering van latensie (RTT) as gevolg van die groot aantal punte en die nabyheid van nodusse aan die gebruiker. Afstand speel hier 'n deurslaggewende rol: die spoed van lig is beperk (sowat 200 000 km/sek in optiese vesel). Dit beteken dat elke 1000 km se reis 5 ms se vertraging of 10 ms by RTT voeg. Dit is die minimum tyd wat benodig word vir uitsending, aangesien daar ook vertragings op die tussentoerusting is. Aangesien 'n CDN gewoonlik weet hoe om voorwerpe op sy bedieners te kas, kan ons baat by die laai van sulke voorwerpe deur 'n CDN. Noodsaaklike voorwaardes hiervoor: die teenwoordigheid van die voorwerp in die kas, die nabyheid van die CDN-punt na die gebruiker in vergelyking met die webtoepassingsbediener (oorsprongbediener). Dit is belangrik om te verstaan dat geografiese nabyheid van 'n CDN-nodus nie lae latensie waarborg nie. Roetering tussen die kliënt en die CDN kan op so 'n manier gebou word dat die kliënt sal koppel aan 'n gasheer in 'n ander land, en moontlik op 'n ander kontinent. Dit is hier waar die verhouding tussen telekommunikasie-operateurs en die CDN-diens (peering, verbindings, deelname aan IX, ens.) en die verkeersroetebeleid van die CDN self ter sprake kom. Byvoorbeeld, Cloudflare, wanneer twee aanvanklike planne (gratis en goedkoop) gebruik word, waarborg nie die aflewering van inhoud vanaf die naaste gasheer nie - die gasheer sal gekies word om die minimum koste te bereik.

Baie vooraanstaande internetmaatskappye lok openbare belangstelling (webontwikkelaars en dienseienaars) na die onderwerp van laaispoed en webwerfprestasie. Onder hierdie maatskappye is Yahoo (Yslow-instrument), AOL (WebPageTest) en Google (Page Speed Insights-diens), wat hul eie aanbevelings ontwikkel om webwerwe te bespoedig (dit hou hoofsaaklik verband met kliëntoptimalisering). Later verskyn nuwe nutsmiddels vir spoedtoetsing vir webwerf, wat ook wenke gee om webwerfspoed te verhoog. Elkeen van hierdie dienste of inproppe het 'n konsekwente aanbeveling: "Gebruik 'n CDN." Die vermindering in netwerkvertraging word gewoonlik aangehaal as 'n verduideliking vir die effek van CDN. Ongelukkig is nie almal gereed om presies te verstaan hoe die versnellingseffek van CDN bereik word en hoe dit gemeet kan word nie, dus word die aanbeveling op geloof geneem en as 'n postulaat gebruik. Trouens, nie alle CDN's is gelyk geskep nie.

Gebruik vandag 'n CDN

Om die bruikbaarheid van die gebruik van CDN'e te bepaal, moet hulle geklassifiseer word. Wat kan nou in die praktyk gevind word (die voorbeelde tussen hakies is natuurlik nie volledig nie):

Gratis CDN vir die verspreiding van JS-biblioteke (MaxCDN, Google. Yandex).
CDN van dienste vir kliëntoptimalisering (byvoorbeeld Google Fonts for fonts, Cloudinary, Cloudimage vir beelde).
CDN vir statiese en hulpbronoptimalisering in CMS (beskikbaar in Bitrix, WordPress en ander).
Algemene doel CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN vir webwerfversnelling (Cloudflare, Imperva, Airi).

Die belangrikste verskil tussen hierdie tipes is hoeveel van die verkeer deur die CDN gaan. Tipes 1-3 is die aflewering van slegs 'n deel van die inhoud: van een versoek tot 'n paar dosyn (gewoonlik foto's). Tipes 4 en 5 is volledige volmag van verkeer via 'n CDN.

In die praktyk beteken dit die aantal verbindings wat gebruik word om die webwerf te laai. Met HTTP/2 gebruik ons 'n enkele TCP-verbinding met die gasheer om enige aantal versoeke te verwerk. As ons hulpbronne verdeel in die hoofgasheer (oorsprong) en CDN, dan is dit nodig om versoeke oor verskeie domeine te versprei en verskeie TCP-verbindings te skep. Die ergste geval is: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Hierdie formule neem nie vertragings in mobiele netwerke vir aktivering van die toestel se radiokanaal (as dit nie aktief was nie) en vertragings op die selfoontoring in ag nie.

Hier is hoe dit op die werf se laaiwaterval lyk (vertragings vir koppeling aan die CDN word uitgelig by RTT 150 ms):

As die CDN alle werfverkeer dek (behalwe vir derdeparty-dienste), kan ons 'n enkele TCP-verbinding gebruik, wat vertragings bespaar om aan bykomende gashere te koppel. Dit geld natuurlik vir HTTP/2-verbindings.

Verdere verskille word bepaal deur die funksionaliteit van 'n spesifieke CDN - vir die eerste tipe is dit net die gasheer van 'n statiese lêer, vir die vyfde is dit om verskeie tipes webwerf-inhoud te verander vir die doel van optimalisering.

CDN-vermoëns vir webwerfversnelling

Kom ons beskryf die volle reeks CDN-vermoëns om werwe te versnel, sonder inagneming van die funksionaliteit van individuele tipes CDN, en kyk dan wat in elkeen van hulle geïmplementeer word.

1. Kompressie van teksbronne

Die mees basiese en verstaanbare kenmerk, maar dikwels swak geïmplementeer. Alle CDN's verklaar die teenwoordigheid van kompressie as hul versnellingskenmerk. Maar as jy in meer besonderhede kyk, word tekortkominge duidelik:

lae grade vir dinamiese kompressie kan gebruik word - 5-6 (byvoorbeeld, vir gzip is die maksimum 9);
statiese kompressie (lêers in kas) gebruik nie bykomende kenmerke nie (byvoorbeeld zopfi of brotli met graad 11)
daar is geen ondersteuning vir doeltreffende brotli-kompressie nie (wat ongeveer 20% bespaar in vergelyking met gzip).

As jy 'n CDN gebruik, is dit die moeite werd om hierdie paar punte na te gaan: neem die lêer wat van die CDN af gekom het, teken sy saamgeperste grootte aan en druk dit met die hand saam vir vergelyking (jy kan byvoorbeeld een of ander aanlyndiens met brotli-ondersteuning gebruik vsszhat.rf).

2. Die opstel van kliëntkasopskrifte

Ook 'n eenvoudige versnellingsfunksie: voeg opskrifte by vir inhoudkas deur die kliënt (blaaier). Die mees huidige kopskrif is kasbeheer, die verouderde een verval. Daarbenewens kan Etag gebruik word. Die belangrikste ding is dat die maksimum ouderdom van kasbeheer groot genoeg is (vanaf 'n maand of meer).As jy gereed is om die hulpbron so hard as moontlik te cache, kan jy die onveranderlike opsie byvoeg.

CDN's kan die maksimum ouderdomswaarde verlaag, wat die gebruiker dwing om statiese inhoud meer gereeld te herlaai. Dit is nie duidelik waarmee dit verband hou nie: die begeerte om verkeer op die netwerk te verhoog of versoenbaarheid te verhoog met werwe wat nie weet hoe om die kas terug te stel nie. Byvoorbeeld, die verstek Cloudflare-kop-kastyd is 1 uur, wat baie laag is vir onveranderlike statiese data.

3. Beeldoptimalisering

Aangesien die CDN die funksies van kas en diens van beelde oorneem, sal dit logies wees om dit aan die CDN-kant te optimaliseer en dit in hierdie vorm aan gebruikers te bedien. Kom ons maak dadelik 'n bespreking dat hierdie kenmerk slegs beskikbaar is vir CDN tipes 2, 3 en 5.

Jy kan beelde op 'n verskeidenheid maniere optimaliseer: deur gevorderde kompressieformate (soos WebP), doeltreffender enkodeerders (MozJPEG) te gebruik, of bloot onnodige metadata op te ruim.

Oor die algemeen is daar twee tipes sulke optimaliserings: met kwaliteitsverlies en sonder kwaliteitsverlies. CDN'e streef gewoonlik daarna om verlieslose optimalisering te gebruik om moontlike klagtes van klante oor veranderinge in beeldkwaliteit te vermy. In sulke toestande sal die wins minimaal wees. In werklikheid is die JPEG-gehaltevlak dikwels baie hoër as wat nodig is, en jy kan veilig herkomprimeer met 'n laer gehaltevlak sonder om die gebruikerservaring in te boet. Aan die ander kant is dit moeilik om die vlak van kwaliteit en instellings universeel vir alle moontlike webtoepassings te bepaal, dus gebruik CDN'e meer konserwatiewe instellings in vergelyking met dié wat toegepas kan word met inagneming van die konteks (doel van beelde, tipe webtoepassing , ens.)

4. Optimalisering van die TLS-verbinding

Die meeste verkeer reis vandag oor TLS-verbindings, wat beteken dat ons ekstra tyd aan TLS-onderhandeling bestee. Onlangs is nuwe tegnologieë ontwikkel om hierdie proses te bespoedig. Dit is byvoorbeeld EC-kriptografie, TLS 1.3, sessiekas en kaartjies, hardeware-enkripsieversnelling (AES-NI), ens. Korrekte instelling van TLS kan verbindingstyd tot 0-1 RTT verminder (sonder DNS en TCP in).

Met moderne sagteware is dit nie moeilik om sulke praktyke op jou eie te implementeer nie.

Nie alle CDN'e implementeer TLS beste praktyke nie; jy kan dit kontroleer deur die TLS-verbindingstyd te meet (byvoorbeeld in Webpagetest). Ideaal vir 'n nuwe verbinding - 1RTT, 2RTT - gemiddelde vlak, 3RTT en meer - sleg.

Daar moet ook op gelet word dat selfs wanneer TLS op die CDN-vlak gebruik word, die bediener met ons webtoepassing ook TLS moet verwerk, maar vanaf die CDN-kant, omdat die verkeer tussen die bediener en die CDN op die publieke netwerk deurgaan. In die ergste geval sal ons dubbele TLS-verbindingsvertragings kry (die eerste na die CDN-gasheer, die tweede tussen dit en ons bediener).

Vir sommige toepassings is dit die moeite werd om aandag te skenk aan sekuriteitskwessies: verkeer word gewoonlik op CDN-nodusse gedekripteer, en dit is 'n moontlike geleentheid vir verkeersonderskepping. Die opsie om sonder verkeersopenbaarmaking te werk, word gewoonlik in toptariefplanne aangebied teen 'n bykomende fooi.

5. Verminder verbinding vertragings

Die grootste voordeel van CDN waaroor almal praat: lae latensie (minder afstand) tussen die CDN-gasheer en die gebruiker. Bereik deur 'n geografies verspreide netwerkargitektuur te skep, waarin gashere geleë is in punte van konsentrasie van gebruikers (stede, verkeersuitruilpunte, ens.)

In die praktyk kan prioriteite vir verskillende netwerke in spesifieke streke wees. Byvoorbeeld, Russiese CDN's sal meer punte van teenwoordigheid in Rusland hê. Die Amerikaanse sal eerstens die netwerk in die VSA ontwikkel. Byvoorbeeld, een van die grootste CDN Cloudflare het slegs 2 punte in Rusland - Moskou en St. Petersburg. Dit wil sê, ons kan 'n maksimum van ongeveer 10 ms se latensie bespaar in vergelyking met direkte plasing in Moskou.

Die meeste Westerse CDN's het glad nie punte in Rusland nie. Deur aan hulle te koppel, kan jy net die vertragings vir jou Russiese gehoor verhoog.

6. Inhoudoptimering (minifikasie, strukturele veranderinge)

Die mees komplekse en tegnologies gevorderde punt. Die verandering van inhoud tydens aflewering kan baie riskant wees. Selfs al neem ons minifikasie: die vermindering van die bronkode (as gevolg van ekstra spasies, onbelangrike strukture, ens.) kan die werkverrigting daarvan beïnvloed. As ons praat oor meer ernstige veranderinge - die verskuiwing van die JS-kode na die einde van die HTML, die samevoeging van lêers, ens. - die risiko om die funksionaliteit van die webwerf te ontwrig is selfs groter.

Daarom doen slegs sommige tipe 5 CDN's dit. Natuurlik sal dit nie moontlik wees om al die veranderinge wat nodig is om dinge te bespoedig te outomatiseer nie - handontleding en optimalisering is nodig. Byvoorbeeld, die verwydering van ongebruikte of duplikaatkode is 'n handmatige taak.

As 'n reël word al sulke optimaliserings deur instellings beheer en die gevaarlikstes word by verstek gedeaktiveer.

Ondersteuning vir versnellingsvermoëns volgens CDN-tipe

Kom ons kyk dus na watter potensiële versnellingsgeleenthede die verskillende tipes CDN's bied.

Gerieflikheidshalwe herhaal ons die klassifikasie.

Gratis CDN vir die verspreiding van JS-biblioteke (MaxCDN, Google. Yandex).
CDN van dienste vir kliëntoptimalisering (byvoorbeeld Google Fonts for fonts, Cloudinary, Cloudimage vir beelde).
CDN vir statiese en hulpbronoptimalisering in CMS (beskikbaar in Bitrix, WordPress en ander).
Algemene doel CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN vir webwerfversnelling (Cloudflare, Imperva, Airi).

Kom ons vergelyk nou die kenmerke en tipes CDN.

Geleentheid
Tik 1
Tik 2
Tik 3
Tik 4
Tik 5

Tekskompressie
+–
-
+–
+–
+

Kasopskrifte
+
+
+
+
+

foto's
-
+–
+–
-
+

TLS
-
-
-
+–
+

Vertragings
-
-
-
+
+

Inhoud
-
-
-
-
+

In hierdie tabel word “+” gebruik om volle ondersteuning aan te dui, “–” is geen ondersteuning nie, en “+–” is gedeeltelike ondersteuning. Natuurlik kan daar in werklikheid afwykings van hierdie tabel wees (byvoorbeeld, sommige algemene doel-CDN sal funksies implementeer om beelde te optimaliseer), maar vir 'n algemene idee is dit nuttig.

Resultate van

Hopelik, nadat u hierdie artikel gelees het, sal u 'n duideliker prentjie hê oor die "gebruik 'n CDN" -aanbeveling om u werwe te bespoedig.

Soos in enige besigheid, kan jy nie die bemarkingsbeloftes van enige diens glo nie. Die effek moet in werklike toestande gemeet en getoets word. As jy reeds 'n CDN gebruik, kontroleer dit vir doeltreffendheid deur die kriteria wat in die artikel beskryf word.

Dit is moontlik dat die gebruik van 'n CDN op die oomblik jou werf se laaityd vertraag.

As 'n algemene aanbeveling kan ons op die volgende fokus: bestudeer jou gehoor, bepaal die geografiese omvang daarvan. As u hoofgehoor binne 'n radius van 1-2 duisend kilometer gekonsentreer is, het u nie 'n CDN nodig vir sy hoofdoel nie - die vermindering van latensie nie. In plaas daarvan kan jy jou bediener nader aan jou gebruikers plaas en dit behoorlik konfigureer, en kry die meeste van die optimaliserings wat in die artikel beskryf word (gratis en permanent).

As jou gehoor werklik geografies versprei is (radius van meer as 3000 kilometer), sal dit regtig nuttig wees om 'n kwaliteit CDN te gebruik. U moet egter vooraf verstaan wat presies u CDN kan bespoedig (sien die tabel van vermoëns en hul beskrywing). Webwerfversnelling bly egter steeds 'n komplekse taak wat nie opgelos kan word deur 'n CDN te koppel nie. Benewens bogenoemde optimaliserings, bly die doeltreffendste maniere van versnelling agter die CDN: optimalisering van die bedienerdeel, gevorderde veranderinge aan die kliëntdeel (verwydering van ongebruikte kode, optimalisering van die leweringsproses, werk met inhoud, lettertipes, aanpasbaarheid, ens. )

Bron: will.com

[Moenie] 'n CDN gebruik nie