[Ne] använd CDN

I nästan varje artikel eller verktyg för att optimera hastigheten på webbplatser finns det en diskret punkt "använd CDN". Generellt sett är CDN en förkortning för content delivery network eller innehållsleveransnätverk. På företaget "Metod Lab" stöter vi ofta på frågor från kunder kring detta ämne, där vissa själva aktiverar CDN. Syftet med denna artikel är att förstå vad CDN kan bidra med avseende på webbplatsens laddningstid, vilka problem som kan uppstå samt i vilka fall användningen av CDN är motiverad.

De cirkulerade fördröjningarna i bilden orsakas av användningen av CDN.

Lite historia

Som många teknologier uppstod CDN av behov. Med utvecklingen av internetkanaler hos nätanvändare, dök tjänster för onlinevideo upp. Det är uppenbart att videoinnehåll kräver avsevärt större bandbredd jämfört med vanlig webbplatsinnehåll (bilder, text samt CSS eller JS-kod).

Vid försök att parallellt sända en videoström till många kunder från en enda server blir serverns internetkanal förmodligen en flaskhals. I regel räcker det med några tusen strömmar för att överbelasta en typisk serverkanal. Naturligtvis kan det också finnas andra begränsningar av resurser, men dessa är inte viktiga just nu. Det är också viktigt att notera att det är alltför dyrt (och ibland omöjligt) att utöka serverkanalen, och det kan även vara oekonomiskt. Belastningen på kanalen vid sändningar kommer att ha en cyklisk karaktär.

CDN löser utmärkt problemet med begränsningen av en enskild servers kanal. Kunder kopplar inte direkt till servern, utan till noder i CDN-nätverket. I en perfekt situation levererar servern en ström till CDN-noden, och sedan använder nätverket egna resurser för att distribuera denna ström till många användare. Ur ett ekonomiskt perspektiv betalar vi bara för de resurser vi faktiskt använder (det kan vara bandbredd eller trafik) och får utmärkt skalbarhet för vår tjänst. Användning av CDN för leverans av tungt innehåll är helt motiverat och logiskt. Det bör dock noteras att de största aktörerna inom detta område (till exempel Netflix) bygger sina egna CDN istället för att använda stora kommersiella CDN (Akamai, Cloudflare, Fastly osv.).

I takt med att webben utvecklas har själva webbapplikationerna blivit mer komplexa och tyngre. Problemet med laddningstid har hamnat i centrum. Hastighetentusiaster har snabbt identifierat flera centrala problem som leder till långsamma webbplatser. Ett av dessa var nätverksfördröjningar (RTT – round trip time eller pingtid). Fördröjningarna påverkar många processer i webbplatsens laddning: etablering av TCP-anslutning, start av TLS-session, laddning av varje enskild resurs (bilder, JS-filer, HTML-dokument osv.)

Problemet förvärrades av att vid användning av HTTP/1.1-protokollet (fram till introduktionen av SPDY, QUIC och HTTP/2 var detta det enda alternativet) öppnar webbläsarna högst 6 TCP-anslutningar till en värd. Allt detta ledde till att anslutningar stod stilla och ineffektiv användning av bandbredd. Problemet delvis löstes genom domänsharding – skapande av ytterligare värdar för att överbrygga gränsen för antalet anslutningar.

Här kommer den andra funktionen av CDN in – att minska fördröjningarna (RTT) genom ett stort antal punkter och närheten av noder till användaren. Avståndet spelar en avgörande roll här: ljusets hastighet är begränsad (ungefär 200 000 km/s i fiberoptik). Det betyder att varje 1000 km väg tillför 5 ms fördröjning eller 10 ms i RTT. Detta är minimi-tidstapp på överföringen, eftersom det ytterligare finns fördröjningar i mellanliggande utrustning. Eftersom CDN vanligtvis kan cacha objekt på sina servrar, kan vi dra nytta av att ladda sådana objekt via CDN. Nödvändiga villkor för detta är: närvaron av objektet i cachen, närhet av CDN-punkten till användaren jämfört med webbapplikationens server (origin server). Det är viktigt att förstå: geografisk närhet av CDN-noden garanterar inte låga fördröjningar. Routen mellan klienten och CDN kan vara sådan att klienten kopplar upp sig mot en värd i ett annat land, kanske till och med på en annan kontinent. Här spelar relationerna mellan teleoperatörerna och CDN-tjänsten roll (cirkelkoppling, närvaro av kopplingar, deltagande i IX etc.) samt trafikroutningens politik hos själva CDN. Till exempel garanterar Cloudflare, vid användning av de två grundplanerna (den kostnadsfria och den billiga), inte att innehållet levereras från den närmaste noden – valet av värd kommer att göras för att uppnå lägsta kostnad.

Många ledande internetföretag väcker intresset hos allmänheten (webbutvecklare och tjänsteägare) för frågan om laddningshastighet och webbplatsernas funktion. Bland dessa företag finns Yahoo (verktyget Yslow), AOL (WebPageTest) och Google (tjänsten Page Speed Insights), som utvecklar sina egna rekommendationer för att snabba upp webbplatser (framför allt handlar det om klientoptimering). Senare dyker det upp nya verktyg för att testa webbplatshastighet, som också ger råd om hur man ökar hastigheten på webbplatser. I varje av dessa tjänster eller plugins finns den oförändrade rekommendationen "Använd CDN". Som förklaring till effekten av CDN anges vanligtvis minskade nätverksfördröjningar. Tyvärr är inte alla beredda att förstå hur uppaccelereringen från CDN egentligen uppnås och hur den kan mätas, varför rekommendationen tas emot på tro och används som ett postulat. I själva verket är inte alla CDN lika användbara.

Användning av CDN idag

För att bedöma nyttan av CDN måste de kategoriseras. Vad som kan ses i dagsläget (exemplen inom parentes är självklart inte uttömmande):

1. Gratis CDN för distribution av JS-bibliotek (MaxCDN, Google, Yandex).
2. CDN av tjänster för klientoptimering (till exempel Google Fonts för typsnitt, Cloudinary, Cloudimage för bilder).
3. CDN för statiska resurser och optimering i CMS (finns i Bitrix, WordPress och andra).
4. Allmänna CDN (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN för att snabba upp webbplatser (Cloudflare, Imperva, Airy).

Den huvudsakliga skillnaden mellan dessa typer är följande: vilken del av trafiken som går genom CDN. Typerna 1-3 handlar om leverans av endast en del av innehållet: från en begäran till ett par dussin (vanligtvis bilder). Typerna 4 och 5 handlar om fullständig proxytjänst av trafiken genom CDN.

I praktiken innebär detta antalet anslutningar som används för att ladda en webbplats. Vid användning av HTTP/2 använder vi en TCP-anslutning till värden för att hantera vilket antal begärningar som helst. Om vi skiljer resurser mellan den primära värden (origin) och CDN, måste vi sprida begärningar över flera domäner och skapa flera TCP-anslutningar. I värsta fall är detta: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. I denna formel beaktas inte fördröjningar i mobila nätverk för att aktivera en radio-kanal på enheten (om den inte varit aktiv) och fördröjningar vid mobilmaster.

Så här ser det ut på nedladdningsvattnet för webbplatsen (fördröjningar för anslutning till CDN vid RTT 150 ms är markerade):

Om CDN täcker all webbplatstrafik (utom externa tjänster) kan vi använda en enda TCP-anslutning, vilket sparar fördröjningar vid anslutning till ytterligare värdar. Självklart gäller detta HTTP/2-anslutningar.

Ytterligare skillnader bestäms av funktionaliteten hos den specifika CDN – för den första typen handlar det endast om hosting en statisk fil, medan den femte handlar om ändringar av flera typer av webbplatsinnehåll för att optimera.

CDNs möjligheter att påskynda webbplatsen

Låt oss beskriva hela spektrumet av CDN:s möjligheter att påskynda webbplatser, utan att ta hänsyn till funktionaliteten hos individuella CDN-typer, och sedan se vad som har implementerats i vart och ett av dem.

1. Komprimering av textresurser

Den mest grundläggande och förståeliga möjligheten, men ändå ofta implementerad dåligt. Alla CDN deklarerar att de har komprimering som en funktion för att påskynda, men vid en närmare granskning framgår det brister:

• låga grader kan användas för dynamisk komprimering – 5-6 (till exempel för gzip är max — 9);
• i statisk komprimering (filer i cachen) används inte ytterligare möjligheter (till exempel zopfi eller brotli med nivå 11)
• det finns inget stöd för effektiv brotli-komprimering (besparing på cirka 20 % jämfört med gzip).

Om du använder CDN, är det värt att kontrollera dessa punkter: ta en fil som kommit från CDN, notera dess storlek i komprimerad form och omkomprimera manuellt för att jämföra (du kan använda någon online-tjänst som stöder brotli, till exempel всёсжать.рф).

2. Ställa in klientens cachehuvuden

Även en enkel funktion för att påskynda: ställ in rubriker för att cacha innehållet hos klienten (webbläsaren). Den mest aktuella rubriken är cache-control, den föråldrade är expires. Etag kan också användas. Det viktiga är att max-age i cache-control är tillräckligt stort (från en månad och mer). Om du vill cacha resursen maximalt strikt kan du lägga till alternativet immutable.

CDN kan sänka värdet av max-age, vilket tvingar användaren att ladda om statiska filer oftare. Anledningen till detta: om det handlar om att öka trafiken på nätverket eller för att öka kompatibiliteten med webbplatser som inte kan rensa cache – är oklart. Till exempel är standardvärdet för cache-tid i Cloudflare-rubriker 1 timme, vilket är mycket lite för oförändrad statik.

3. Bildoptimering

Eftersom CDN hanterar caching och leverans av bilder, är det logiskt att optimera dem på CDN-sidan och leverera dem till användarna på det sättet. Vi påpekar att denna möjlighet endast är tillgänglig för CDN av typerna 2, 3 och 5.

Bilder kan optimeras på olika sätt: genom att använda avancerade komprimeringsformat (till exempel WebP), mer effektiva kodare (MozJPEG) eller helt enkelt genom att rensa bort överflödig metadata.

Det finns i stort sett 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 klagomål från kunder angående förändrad bildkvalitet. Under sådana förhållanden blir vinsten minimal. I verkligheten överstiger ofta JPEG-kvalitetsnivån kraftigt det som krävs, och det går bra att utföra rekodning med en lägre kvalitetsnivå utan att påverka användarnas upplevelse. Å andra sidan är det svårt att fastställa kvalitetsnivån och inställningarna universellt för alla möjliga webblösningar, så CDN använder mer konservativa inställningar jämfört med de som kan tillämpas med hänsyn till kontext (ändamålet med bilderna, typ av webbapplikation etc.)

4. Optimering av TLS-anslutning

Den största delen av trafiken idag överförs via TLS-anslutningar, vilket betyder att vi spenderar extra tid på TLS-handledning. Nya teknologier för att påskynda denna process har utvecklats nyligen. Till exempel, detta inkluderar EC-kryptografi, TLS 1.3, sessionscache och biljetter (session tickets), hårdvaruhastighet av kryptering (AES-NI) osv. Rätt konfiguration av TLS kan minska anslutningstiden till 0-1 RTT (exklusive DNS och TCP).

Det är inte svårt att implementera sådana metoder med modern programvara på egna resurser.

Inte alla CDN implementerar bästa praxis för TLS; detta kan kontrolleras genom att mäta tiden för TLS-anslutningen (t.ex. i Webpagetest). Idealiskt för en ny anslutning är 1 RTT, 2 RTT är en genomsnittlig nivå, 3 RTT och mer – dåligt.

Det är också värt att notera att även när TLS används på CDN-nivå, måste servern med vår webbapplikation också hantera TLS, men från CDN:s sida, eftersom trafiken mellan servern och CDN passerar genom ett offentligt nätverk. I värsta fall får vi dubbla fördröjningar i TLS-anslutningen (den första till CDN-värden, den andra mellan den och vår server).

För vissa tillämpningar är det viktigt att beakta säkerhetsfrågor: vanligtvis dekrypteras trafiken vid CDN-noder, vilket utgör en potentiell möjlighet för trafikavlyssning. Alternativet att arbeta utan att avslöja trafiken erbjuds vanligtvis i de högsta abonnemangen mot en extra avgift.

5. Minskning av anslutningens fördröjningar

Huvudfördelen med CDN som alla pratar om: låg fördröjning (kortare avstånd) mellan CDN-värden och användaren. Detta uppnås genom att skapa en geografiskt distribuerad nätverksarkitektur där värdar placeras i användarkoncentrationspunkter (städer, trafikbytespunkter osv.)

I praktiken kan prioriteringar för olika nätverk finnas i specifika regioner. Till exempel kommer ryska CDN att ha fler närvaropunkter i Ryssland. Amerikanska kommer främst att utveckla sitt nätverk i USA. Till exempel har en av de största CDN:erna, Cloudflare, bara 2 punkter i Ryssland – Moskva och Sankt Petersburg. Så maximalt kan vi spara cirka 10 ms fördröjning jämfört med direkt placering i Moskva.

De flesta västerländska CDN har överhuvudtaget inga punkter i Ryssland. Genom att ansluta till dem kan du bara öka fördröjningarna för din ryska publik.

6. Optimering av innehåll (minifiering, strukturella förändringar)

Den mest komplicerade och tekniska punkten. Ändring av innehåll vid leverans kan vara mycket riskabelt. Även om vi tar minifiering som exempel: att minska koden (genom att ta bort onödiga mellanslag, irrelevanta konstruktioner osv.) kan påverka dess funktionalitet. När det gäller mer betydande ändringar – såsom att flytta JS-koden till slutet av HTML, sammanfoga filer och liknande – är risken för att störa webbplatsens funktionalitet ännu större.

Därför är det bara vissa CDN av typ 5 som sysslar med detta. Självklart går det inte att automatisera alla förändringar som behövs för att öka hastigheten – det krävs manuell analys och optimering. Till exempel, att ta bort oanvänd eller duplicerad kod är en manuell uppgift.

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

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

Så låt oss titta på vilka potentiella accelerationsmöjligheter de olika typerna av CDN erbjuder.

För enkelhetens skull, låt oss repetera klassificeringen.

1. Gratis CDN för distribution av JS-bibliotek (MaxCDN, Google, Yandex).
2. CDN av tjänster för klientoptimering (till exempel Google Fonts för typsnitt, Cloudinary, Cloudimage för bilder).
3. CDN för statiska resurser och optimering i CMS (finns i Bitrix, WordPress och andra).
4. Allmänna CDN (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN för att snabba upp webbplatser (Cloudflare, Imperva, Airy).

Nu ska vi matcha funktioner och CDN-typer.

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

Textkompression
+–
–
+–
+–
+

Cachehuvuden
+
+
+
+
+

Bilder
–
+–
+–
–
+

TLS
–
–
–
+–
+

Fördröjningar
–
–
–
+
+

Innehåll
–
–
–
–
+

I den här tabellen används ‘+’ för att indikera fullt stöd, ‘–’ för avsaknad, och ‘+–’ för partiellt stöd. Självklart kan det förekomma avvikelser från denna tabell i verkligheten (till exempel kan en allmän CDN implementera bildoptimeringsfunktioner), men för en övergripande förståelse är den användbar.

Sammanfattning

Jag hoppas att efter att ha läst denna artikel kommer ni att få en klarare bild av rekommendationen ‚använd CDN‘ för att snabba upp webbplatser.

Som med allt bör man inte tro på marknadsföringslöften från någon tjänst. Effekten bör mätas och kontrolleras under verkliga förhållanden. Om ni redan använder en viss CDN, kontrollera dess effektivitet baserat på kriterierna beskrivna i artikeln.

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

Som en allmän rekommendation kan man stanna vid följande: Studera din publik, definiera dess geografiska ramar. Om din huvudpublik är koncentrerad inom en radie av 1-2 tusen kilometer, behöver du inte en CDN för det primära syftet – att minska fördröjningar. Istället kan du placera din server närmare användarna och konfigurera den på rätt sätt, vilket ger de flesta optimeringar som beskrivs i artikeln (gratis och kontinuerligt).

Om din publik verkligen är geografiskt spridd (en radie på mer än 3000 kilometer), kan användningen av ett högkvalitativt CDN vara mycket fördelaktigt. Det är dock viktigt att först förstå vad exakt som ditt CDN kan påskynda (se tabell över funktioner och deras beskrivningar). Att påskynda en webbplats förblir ändå en komplex uppgift som inte löses enbart genom att ansluta ett CDN. Förutom de nämnda optimeringarna kvarstår de mest effektiva medlen för acceleration: optimering av serverdelen, avancerade ändringar av klientdelen (borttagning av oanvänd kod, optimering av renderingsprocessen, arbete med innehåll, typsnitt, responsivitet osv.)

Källa: habr.com