🥇[Använd inte] CDN

Nästan varje artikel eller verktyg för att optimera webbplatsens hastighet har en blygsam klausul "använd ett CDN." I allmänhet är CDN ett innehållsleveransnätverk eller innehållsleveransnätverk. Vi på Method Lab stöter ofta på frågor från kunder om detta ämne, några av dem aktiverar sitt eget CDN. Syftet med den här artikeln är att förstå vad ett CDN kan ge när det gäller webbplatsladdningshastighet, vilka problem som kan uppstå och i vilka fall användningen av ett CDN är motiverad.

Förseningarna som är inringade i bilden orsakas av användningen av ett CDN.

Lite historia

Liksom många tekniker uppstod CDN av nödvändighet. Med utvecklingen av internetkanaler bland internetanvändare dök onlinevideotjänster upp. Naturligtvis kräver videoinnehåll storleksordningar mer bandbredd jämfört med vanligt webbplatsinnehåll (bilder, text och CSS- eller JS-kod).

När man försöker sända en videoström parallellt till många klienter från en server kommer serverns internetkanal med största sannolikhet att bli flaskhalsen. Som regel räcker några tusen trådar för att täppa till en typisk serverkanal. Naturligtvis kan det finnas andra resursbegränsningar, men de är inte viktiga just nu. Det är också viktigt att utöka serverkanalen är för dyrt (och ibland omöjligt), och dessutom opraktiskt. Belastningen på kanalen under sändningar kommer att vara cyklisk.

Problemet med att begränsa kanalen för en enskild server är perfekt löst av CDN. Klienter ansluter inte direkt till servern utan till noder i CDN-nätverket. I en idealisk situation skickar servern en ström till CDN-noden, och sedan använder nätverket sina egna resurser för att leverera denna ström till många användare. Ur ekonomisk synvinkel betalar vi endast för de resurser som faktiskt förbrukas (detta kan vara bandbredd eller trafik) och får utmärkt skalbarhet för vår tjänst. Att använda ett CDN för att leverera tungt innehåll är helt berättigat och logiskt. Även om det är värt att notera att de största spelarna i det här utrymmet (t.ex. Netflix) bygger sina egna CDN istället för att använda stora kommersiella CDN (Akamai, Cloudflare, Fastly, etc.)

I takt med att webben har utvecklats har webbapplikationerna i sig blivit mer komplexa och komplexa. Problemet med lastningshastigheten kom i förgrunden. Webbplatshastighetsentusiaster identifierade snabbt flera stora problem som fick webbplatser att laddas långsamt. En av dem var nätverksförseningar (RTT – tur och returtid eller pingtid). Förseningar påverkar många processer vid laddning av webbplatsen: upprättande av en TCP-anslutning, start av en TLS-session, laddning av varje enskild resurs (bild, JS-fil, HTML-dokument, etc.)

Problemet förvärrades av det faktum att när man använder HTTP/1.1-protokollet (före tillkomsten av SPDY, QUIC och HTTP/2 var detta det enda alternativet), öppnar webbläsare inte mer än 6 TCP-anslutningar till en värd. Allt detta ledde till avbrott i anslutningen och ineffektiv användning av kanalbandbredd. Problemet löstes delvis genom domänskärning - skapandet av ytterligare värdar för att övervinna gränsen för antalet anslutningar.

Det är här den andra förmågan hos CDN dyker upp - reducering av latens (RTT) på grund av det stora antalet punkter och närheten av noder till användaren. Avståndet spelar här en avgörande roll: ljusets hastighet är begränsad (cirka 200 000 km/sek i optisk fiber). Detta innebär att varje 1000 km av resan lägger till 5 ms fördröjning eller 10 ms till RTT. Detta är den minsta tid som krävs för överföring, eftersom det även finns förseningar på mellanutrustningen. Eftersom ett CDN vanligtvis vet hur man cachelagrar objekt på sina servrar, kan vi dra nytta av att ladda sådana objekt genom ett CDN. Nödvändiga villkor för detta: närvaron av objektet i cachen, närheten till CDN-punkten till användaren i jämförelse med webbapplikationsservern (ursprungsservern). Det är viktigt att förstå att en CDN-nods geografiska närhet inte garanterar låg latens. Routing mellan klienten och CDN kan byggas på ett sådant sätt att klienten ansluter till en värd i ett annat land, och eventuellt på en annan kontinent. Det är här förhållandet mellan teleoperatörer och CDN-tjänsten (peering, anslutningar, deltagande i IX, etc.) och själva CDN:s trafikdirigeringspolicy kommer in i bilden. Till exempel, Cloudflare, när du använder två initiala planer (gratis och billig), garanterar inte leverans av innehåll från närmaste värd - värden kommer att väljas för att uppnå lägsta kostnad.

Många ledande internetföretag lockar allmänhetens intresse (webbutvecklare och tjänsteägare) till ämnet laddningshastighet och webbprestanda. Bland dessa företag finns Yahoo (Yslow-verktyget), AOL (WebPageTest) och Google (Page Speed Insights-tjänsten), som utvecklar sina egna rekommendationer för att snabba upp sajter (främst handlar de om klientoptimering). Senare dyker det upp nya verktyg för testning av webbplatshastighet, som också ger tips om hur du kan öka webbplatsens hastighet. Var och en av dessa tjänster eller plugins har en konsekvent rekommendation: "Använd ett CDN." Minskningen av nätverkslatens brukar nämnas som en förklaring till effekten av CDN. Tyvärr är inte alla redo att förstå exakt hur accelerationseffekten av CDN uppnås och hur den kan mätas, så rekommendationen tas på tro och används som ett postulat. Faktum är att inte alla CDN skapas lika.

Använder CDN idag

För att bedöma användbarheten av att använda CDN måste de klassificeras. Vad kan man hitta nu i praktiken (exemplen inom parentes är naturligtvis inte uttömmande):

Gratis CDN för distribution av JS-bibliotek (MaxCDN, Google. Yandex).
CDN för tjänster för klientoptimering (till exempel Google Fonts för typsnitt, Cloudinary, Cloudimage för bilder).
CDN för statisk optimering och resursoptimering i CMS (tillgänglig i Bitrix, WordPress och andra).
CDN för allmänt bruk (StackPath, CDNVideo, NGENIX, Megafon).
CDN för webbacceleration (Cloudflare, Imperva, Airi).

Den viktigaste skillnaden mellan dessa typer är hur mycket av trafiken som går genom CDN. Typ 1-3 är leverans av endast en del av innehållet: från en begäran till flera dussin (vanligtvis bilder). Typerna 4 och 5 är full proxy av trafik via ett CDN.

I praktiken betyder detta antalet anslutningar som används för att ladda sajten. Med HTTP/2 använder vi en enda TCP-anslutning till värden för att behandla valfritt antal förfrågningar. Om vi delar upp resurser i huvudvärden (origin) och CDN, då är det nödvändigt att distribuera förfrågningar över flera domäner och skapa flera TCP-anslutningar. Det värsta fallet är: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Denna formel tar inte hänsyn till förseningar i mobilnät för aktivering av enhetens radiokanal (om den inte var aktiv) och förseningar på mobiltornet.

Så här ser det ut på webbplatsens laddningsvattenfall (fördröjningar för anslutning till CDN markeras vid RTT 150 ms):

Om CDN täcker all webbplatstrafik (förutom tredjepartstjänster) kan vi använda en enda TCP-anslutning, vilket sparar förseningar vid anslutning till ytterligare värdar. Detta gäller naturligtvis HTTP/2-anslutningar.

Ytterligare skillnader bestäms av funktionaliteten hos ett visst CDN - för den första typen är det bara värd för en statisk fil, för den femte ändrar det flera typer av webbplatsinnehåll i syfte att optimera.

CDN-funktioner för webbacceleration

Låt oss beskriva hela utbudet av CDN-funktioner för att accelerera webbplatser, utan hänsyn till funktionaliteten hos enskilda typer av CDN, och sedan se vad som är implementerat i var och en av dem.

1. Komprimering av textresurser

Den mest grundläggande och begripliga funktionen, men ändå ofta dåligt implementerad. Alla CDN deklarerar närvaron av kompression som deras accelerationsfunktion. Men om du tittar mer i detalj blir bristerna tydliga:

låga grader för dynamisk komprimering kan användas - 5-6 (till exempel för gzip är max 9);
statisk komprimering (filer i cache) använder inte ytterligare funktioner (till exempel zopfi eller brotli med grad 11)
det finns inget stöd för effektiv brotli-komprimering (sparar cirka 20% jämfört med gzip).

Om du använder ett CDN är det värt att kontrollera dessa få punkter: ta filen som kom från CDN, registrera dess komprimerade storlek och komprimera den manuellt för jämförelse (du kan använda någon onlinetjänst med brotli-stöd, till exempel vsszhat.rf).

2. Ställa in klientcachehuvuden

Också en enkel snabbhetsfunktion: lägg till rubriker för innehållscache av klienten (webbläsaren). Den senaste rubriken är cache-kontroll, den föråldrade löper ut. Dessutom kan Etag användas. Huvudsaken är att maxåldern för cache-kontroll är tillräckligt stor (från en månad eller mer) Om du är redo att cache resursen så hårt som möjligt kan du lägga till det oföränderliga alternativet.

CDN kan sänka maxåldervärdet, vilket tvingar användaren att ladda om statiskt innehåll oftare. Det är inte klart vad detta är kopplat till: önskan att öka trafiken på nätverket eller öka kompatibiliteten med sajter som inte vet hur man återställer cachen. Till exempel är den förinställda Cloudflare header-cachetiden 1 timme, vilket är mycket lågt för oföränderlig statisk data.

3. Bildoptimering

Eftersom CDN tar på sig funktionerna att cache och betjäna bilder, skulle det vara logiskt att optimera dem på CDN-sidan och servera dem till användare i denna form. Låt oss omedelbart reservera att den här funktionen endast är tillgänglig för CDN-typerna 2, 3 och 5.

Du kan optimera bilder på en mängd olika sätt: genom att använda avancerade komprimeringsformat (som WebP), effektivare kodare (MozJPEG) eller helt enkelt rensa upp onödiga metadata.

I allmänhet finns det två typer av sådana optimeringar: med kvalitetsförlust och utan kvalitetsförlust. CDN strävar vanligtvis efter att använda förlustfri optimering för att undvika eventuella kundklagomål om förändringar i bildkvalitet. Under sådana förhållanden kommer vinsten att vara minimal. I verkligheten är JPEG-kvalitetsnivån ofta mycket högre än nödvändigt och du kan säkert komprimera om med en lägre kvalitetsnivå utan att kompromissa med användarupplevelsen. Å andra sidan är det svårt att bestämma nivån på kvalitet och inställningar universellt för alla möjliga webbapplikationer, så CDN:er använder mer konservativa inställningar jämfört med de som kan tillämpas med hänsyn till sammanhanget (syfte med bilder, typ av webbapplikation , etc.)

4. Optimera TLS-anslutningen

Den mesta trafiken idag går över TLS-anslutningar, vilket innebär att vi lägger extra tid på TLS-förhandlingar. Nyligen har ny teknik utvecklats för att påskynda denna process. Detta är till exempel EC-kryptering, TLS 1.3, sessionscache och biljetter, hårdvarukrypteringsacceleration (AES-NI), etc. Korrekt inställning av TLS kan reducera anslutningstiden till 0-1 RTT (exklusive DNS och TCP).

Med modern programvara är det inte svårt att implementera sådana metoder på egen hand.

Inte alla CDN:er implementerar TLS bästa praxis; du kan kontrollera detta genom att mäta TLS-anslutningstiden (till exempel i Webpagetest). Perfekt för en ny anslutning - 1RTT, 2RTT - medelnivå, 3RTT och mer - dålig.

Det bör också noteras att även vid användning av TLS på CDN-nivå måste servern med vår webbapplikation också bearbeta TLS, men från CDN-sidan, eftersom trafiken mellan servern och CDN:n går vidare på det publika nätverket. I värsta fall kommer vi att få dubbla TLS-anslutningsfördröjningar (den första till CDN-värden, den andra mellan den och vår server).

För vissa applikationer är det värt att uppmärksamma säkerhetsfrågor: trafik dekrypteras vanligtvis på CDN-noder, och detta är en potentiell möjlighet för trafikavlyssning. Möjligheten att arbeta utan trafikinformation erbjuds vanligtvis i topptariffplaner mot en extra avgift.

5. Minska anslutningsfördröjningar

Den största fördelen med CDN som alla pratar om: låg latens (mindre avstånd) mellan CDN-värden och användaren. Uppnås genom att skapa en geografiskt distribuerad nätverksarkitektur, där värdar är placerade i koncentrationspunkter för användare (städer, trafikutbytespunkter, etc.)

I praktiken kan prioriteringar för olika nätverk ligga i specifika regioner. Till exempel kommer ryska CDN:er att ha fler närvaropunkter i Ryssland. De amerikanska kommer först och främst att utveckla nätverket i USA. Till exempel, en av de största CDN Cloudflare har bara 2 poäng i Ryssland - Moskva och St. Petersburg. Det vill säga vi kan maximalt spara cirka 10 ms latens jämfört med direktplacering i Moskva.

De flesta västerländska CDN:er har inte alls poäng i Ryssland. Genom att ansluta till dem kan du bara öka förseningarna för din ryska publik.

6. Innehållsoptimering (minifiering, strukturella förändringar)

Den mest komplexa och tekniskt avancerade punkten. Att ändra innehåll under leverans kan vara mycket riskabelt. Även om vi tar minifiering: reducering av källkoden (på grund av extra utrymmen, oviktiga strukturer, etc.) kan påverka dess prestanda. Om vi pratar om mer seriösa förändringar – att flytta JS-koden till slutet av HTML, slå ihop filer etc. – är risken för att störa webbplatsens funktionalitet ännu högre.

Därför är det bara vissa typ 5 CDN som gör detta. Naturligtvis kommer det inte att vara möjligt att automatisera alla ändringar som behövs för att påskynda saker och ting – manuell analys och optimering krävs. Att ta bort oanvänd kod eller duplicerad kod är till exempel en manuell uppgift.

Som regel styrs alla sådana optimeringar av inställningar och de farligaste är inaktiverade som standard.

Stöd för accelerationsmöjligheter efter CDN-typ

Så låt oss ta en titt på vilka potentiella accelerationsmöjligheter de olika typerna av CDN ger.

För enkelhetens skull upprepar vi klassificeringen.

Gratis CDN för distribution av JS-bibliotek (MaxCDN, Google. Yandex).
CDN för tjänster för klientoptimering (till exempel Google Fonts för typsnitt, Cloudinary, Cloudimage för bilder).
CDN för statisk optimering och resursoptimering i CMS (tillgänglig i Bitrix, WordPress och andra).
CDN för allmänt bruk (StackPath, CDNVideo, NGENIX, Megafon).
CDN för webbacceleration (Cloudflare, Imperva, Airi).

Låt oss nu jämföra funktionerna och typerna av CDN.

Möjlighet
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Textkomprimering
+–
-
+–
+–
+

Cachehuvuden
+
+
+
+
+

bilder
-
+–
+–
-
+

TLS
-
-
-
+–
+

Förseningar
-
-
-
+
+

Innehåll
-
-
-
-
+

I den här tabellen används "+" för att indikera fullt stöd, "–" är inget stöd och "+–" är partiellt stöd. Naturligtvis kan det förekomma avvikelser från denna tabell i verkligheten (till exempel kommer vissa CDN för allmänna ändamål att implementera funktioner för att optimera bilder), men för en allmän idé är det användbart.

Resultat av

Förhoppningsvis har du efter att ha läst den här artikeln en tydligare bild angående rekommendationen "använd ett CDN" för att snabba upp dina webbplatser.

Som i alla företag kan du inte tro marknadsföringslöften för någon tjänst. Effekten måste mätas och testas under verkliga förhållanden. Om du redan använder ett CDN, kontrollera det för effektivitet med hjälp av kriterierna som beskrivs i artikeln.

Det är möjligt att användningen av ett CDN just nu saktar ner laddningstiden för din webbplats.

Som en allmän rekommendation kan vi fokusera på följande: studera din publik, bestämma dess geografiska omfattning. Om din huvudpublik är koncentrerad inom en radie av 1-2 tusen kilometer, behöver du inte ett CDN för dess huvudsakliga syfte - att minska latens. Istället kan du placera din server närmare dina användare och konfigurera den ordentligt och få de flesta av de optimeringar som beskrivs i artikeln (gratis och permanent).

Om din publik verkligen är geografiskt fördelad (radie på mer än 3000 kilometer), kommer det verkligen att vara användbart att använda ett kvalitets-CDN. Du måste dock förstå i förväg vad exakt ditt CDN kan påskynda (se tabellen över funktioner och deras beskrivning). Webbplatsacceleration är dock fortfarande en komplex uppgift som inte kan lösas genom att ansluta ett CDN. Utöver ovanstående optimeringar finns det mest effektiva accelerationssättet kvar bakom CDN: optimering av serverdelen, avancerade ändringar av klientdelen (ta bort oanvänd kod, optimera renderingsprocessen, arbeta med innehåll, typsnitt, anpassningsförmåga, etc. )

Källa: will.com

[Använd inte] ett CDN