🥇[Ikke] brug CDN

I næsten enhver artikel eller værktøj til optimering af webstedshastighed findes der et beskedent punkt "brug CDN". Generelt er en CDN en content delivery network eller netværk til levering af indhold. I virksomheden "Metod Lab" møder vi ofte spørgsmål fra kunder om dette emne; nogle aktiverer selv CDN. Målet med denne artikel er at undersøge, hvad CDN kan give med hensyn til webstedets indlæsningstid, hvilke problemer der kan opstå, og i hvilke tilfælde brugen af CDN er berettiget.

De markerede forsinkelser på billedet skyldes brugen af CDN.

Lidt historie

Som med mange teknologier opstod CDN ud af nødvendighed. Med udviklingen af internetkanaler for brugerne, opstod der online video tjenester. Det står klart, at videoindhold kræver væsentligt større båndbredde sammenlignet med almindeligt indhold fra websteder (billeder, tekst og CSS eller JS-kode).

Ved forsøg på parallelt at streame video til mange kunder fra én server vil flaskehalsen sandsynligvis blive serverens internetkanal. Som regel er det tilstrækkeligt med nogle tusinde streams til at overbelaste en typisk serverkanal. Selvfølgelig kan der være andre ressourcebegrænsninger, men de er ikke relevante nu. Det er også vigtigt, at udvidelse af serverens båndbredde er for dyrt (og nogle gange umuligt) og ikke hensigtsmæssigt. Belastningen på kanalen under streaming vil have en cyklisk karakter.

Problemet med begrænsningen af en enkelt servers kanal løses fremragende af CDN. Kunderne tilsluttes ikke direkte til serveren, men til knudepunkterne i CDN-netværket. I den ideelle situation sender serveren ét stream til CDN-knydepunkterne, hvorefter netværket benytter sine egne ressourcer til at levere denne stream til mange brugere. Set fra et økonomisk perspektiv betaler vi kun for de faktisk forbrugte ressourcer (det kan være båndbredde eller trafik) og opnår en fremragende skalerbarhed for vores service. Brug af CDN til levering af tungt indhold er helt berettiget og logisk. Det skal bemærkes, at de største aktører på dette område (f.eks. Netflix) bygger deres egne CDN i stedet for at bruge store kommercielle CDN (Akamai, Cloudflare, Fastly osv.).

Efterhånden som internettet har udviklet sig, er webapplikationer blevet mere komplekse og krævende. Et af de vigtigste problemer er indlæsningshastigheden. Webspeedentusiaster har hurtigt identificeret flere centrale problemer, der fører til langsom indlæsning af hjemmesider. En af dem er netværksforsinkelser (RTT – round trip time eller ping-tid). Forsinkelser påvirker mange processer i indlæsningen af en hjemmeside: oprettelse af TCP-forbindelse, etablering af TLS-session, indlæsning af hver enkelt ressource (billeder, JS-filer, HTML-dokumenter osv.).

Problemet blev forværret af, at når man bruger protokollen HTTP/1.1 (indtil SPDY, QUIC og HTTP/2 kom frem, var dette den eneste mulighed), åbner browsere ikke mere end 6 TCP-forbindelser til en enkelt vært. Alt dette førte til inaktivitet i forbindelsen og ineffektiv udnyttelse af båndbredde. Problemet blev delvist løst gennem domænesharding – oprettelse af ekstra værter for at omgå begrænsningen af antallet af forbindelser.

Her kommer den anden evne af CDN ind i billedet – reduktion af forsinkelser (RTT) gennem et stort antal punkter og nærhed af noder til brugeren. Afstanden spiller en afgørende rolle: lysets hastighed er begrænset (omkring 200.000 km/s i fiberoptisk kabel). Det betyder, at hver 1000 km rute tilføjer 5 ms i forsinkelser eller 10 ms i RTT. Dette er den minimale tidsomkostning for transmission, da der stadig er forsinkelser på det mellemliggende udstyr. Da CDN normalt kan cache objekter på sine servere, kan vi drage fordel af at hente sådanne objekter via CDN. Nødvendige betingelser for dette er: objektet skal være i cachen, og nærheden af CDN-punktet til brugeren sammenlignet med oprindelsesserveren. Det er vigtigt at forstå: geografisk nærhed af CDN-node garanterer ikke lave forsinkelser. Rutevalget mellem klienten og CDN kan blive sådan, at klienten forbinder til en vært i et andet land, muligvis også på en anden kontinent. Her træder relationerne mellem telekommunikationsoperatører og CDN-service (peering, tilgængelighed af forbindelser, deltagelse i IX osv.) og trafikstyringspolitikken for selve CDN ind i spil. For eksempel, når det kommer til Cloudflare, så garanterer de ikke at levere indhold fra den nærmeste node, når de bruger de to indledende planer (gratis og billige); valget af vært vil blive foretaget for at opnå de laveste omkostninger.

Mange førende internetfirmaer vækker offentlighedens interesse (webudviklere og servicetilbydere) for emnet om indlæsningens hastighed og websteder. Blandt disse virksomheder er Yahoo (Yslow værktøj), AOL (WebPageTest) og Google (Page Speed Insights service), som udvikler deres anbefalinger til at fremskynde websteder (primært fokuseret på klientoptimering). Senere kommer der nye testværktøjer til hastighed, som også giver råd om at øge hastigheden på websteder. I hver af disse tjenester eller plugins er der en uændret anbefaling: "Brug CDN". Som forklaring på effekten af CDN nævnes der normalt reduktion af netværkslatens. Desværre er ikke alle villige til at forstå, hvordan effekten af acceleration fra CDN opnås, og hvordan den kan måles, så anbefalingen accepteres i tro og bruges som et postulat. Faktisk er langt fra alle CDN'er lige nyttige.

Brugen af CDN i dag

For at vurdere nyttigheden af at bruge CDN skal de klassificeres. Hvad kan man møde i praksis (eksemplerne i parentes er selvfølgelig ikke udtømmende):

Gratis CDN til levering af JS-biblioteker (MaxCDN, Google, Yandex).
CDN-tjenester til klientoptimering (f.eks. Google Fonts til skrifttyper, Cloudinary, Cloudimage til billeder).
CDN til statiske filer og optimering af ressourcer i CMS (tilgængelige i Bitrix, WordPress og andre).
CDN til generelt formål (StackPath, CDNVideo, NGENIX, MegaFon).
CDN til webstedsacceleration (Cloudflare, Imperva, Airi).

Den væsentlige forskel mellem disse typer består i følgende: hvilken del af trafikken der passerer gennem CDN. Typerne 1-3 er kun levering af en del af indholdet: fra én anmodning til flere dusin (normalt billeder). Typerne 4 og 5 indebærer fuld proxy-trafik gennem CDN.

I praksis betyder dette antallet af forbindelser, der bruges til at indlæse webstedet. Når vi bruger HTTP/2, bruger vi én TCP-forbindelse til værten til at håndtere et ubegribeligt antal anmodninger. Hvis vi opdeler ressourcer på hovedværten (origin) og CDN, er det nødvendigt at sprede anmodningerne over flere domæner og oprette flere TCP-forbindelser. I værste fald er dette: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. I denne formel tages der ikke hensyn til forsinkelser i mobilnetværkene ved aktivering af radioforbindelsen på enheden (hvis den ikke har været aktiv) og forsinkelser ved mobilmaster.

Sådan ser det ud på webstedets indlæsningsvandfald (forsinkelserne for opkoblingen til CDN er fremhævet ved RTT 150 ms):

Hvis CDN dækker al trafik til webstedet (undtagen tredjepartstjenester), kan vi bruge en enkelt TCP-forbindelse, hvilket sparer forsinkelser ved opkobling til ekstra værter. Dette gælder naturligvis for HTTP/2-forbindelser.

Yderligere forskelle bestemmes af funktionaliteten i den specifikke CDN – for den første type er det blot hosting en statisk fil, mens den femte type ændrer flere typer af webindhold med henblik på optimering.

CDN-muligheder til at accelerere webstedet

Lad os beskrive det fulde spektrum af muligheder, som CDN tilbyder til at accelerere websteder, uden at se på funktionaliteten af de enkelte CDN-typer, og derefter se, hvad der er implementeret i hver af dem.

1. Komprimering af tekstressourcer

Den mest grundlæggende og enkle funktion, men ofte dårlig implementeret. Alle CDN annoncerer komprimering som en funktion til at accelerere. Men hvis man ser nærmere på det, viser det sig, at der er mangler:

de kan anvende lave grader til dynamisk komprimering – 5-6 (for eksempel er maksimum for gzip — 9);
der anvendes ikke yderligere muligheder i statisk komprimering (filer i cachen) (for eksempel zopfi eller brotli med grad 11)
der er ingen støtte til effektiv komprimering med brotli (ca. 20% besparelse sammenlignet med gzip).

Hvis du bruger CDN, skal du kontrollere disse par punkter: tag en fil, der er kommet fra CDN, registrere dens størrelse i komprimeret form og komprimere den manuelt til sammenligning (du kan bruge en online service, der understøtter brotli, for eksempel altkomprimere.dk).

2. Opsætning af cache-hoveder til klienter

Også en simpel funktion til acceleration: indstille overskrifter for caching af indhold af klienten (browseren). Den mest relevante overskrift er cache-control, en forældet – expires. Yderligere kan Etag anvendes. Det vigtigste er, at max-age på cache-control er stor nok (mindst en måned eller mere); hvis du ønsker at cache ressourcen så strengt som muligt, kan du tilføje muligheden immutable.

CDN kan nedsætte værdien af max-age, hvilket tvinger brugeren til oftere at downloade statiske filer igen. Hvad dette skyldes: et ønske om at øge netværkstrafikken eller forbedre kompatibiliteten med websteder, der ikke kan rydde cachen – er uklart. For eksempel er standard cachingtiden i headers fra Cloudflare 1 time, hvilket er meget lavt for uforanderlige statiske filer.

3. Optimisering af billeder

Da CDN håndterer caching og levering af billeder, vil det være logisk at optimere dem på CDN-siden og levere dem til brugerne i denne form. Det skal straks nævnes, at denne mulighed kun er tilgængelig for CDN-typer 2, 3 og 5.

Billeder kan optimeres på forskellige måder: ved at bruge avancerede komprimeringsformater (f.eks. WebP), mere effektive kodere (MozJPEG) eller simpelthen ved at fjerne overflødige metadata.

Generelt er der to typer af sådanne optimeringer: med tab af kvalitet og uden tab af kvalitet. CDN stræber normalt efter at bruge tabsfri optimering – for at undgå eventuelle klager fra kunderne over ændringer i billedkvaliteten. Under sådanne forhold vil gevinsten være minimal. I virkeligheden overstiger JPEG-kvalitetsniveauet ofte det nødvendige, og man kan trygt udføre recompression med lavere kvalitet uden at skade brugernes opfattelse. På den anden side er det svært at bestemme kvalitetsniveauet og indstillingerne universelt for alle mulige webapplikationer, derfor bruger CDN mere konservative indstillinger sammenlignet med dem, der kan anvendes i betragtning af konteksten (billedets formål, typen af webapplikation osv.)

4. Optimering af TLS-forbindelse

Størstedelen af trafikken overføres i dag via TLS-forbindelser, hvilket betyder, at vi bruger ekstra tid på TLS-forhandling. Nye teknologier til at fremskynde denne proces er blevet udviklet for nylig. For eksempel inkluderer det EC-kryptografi, TLS 1.3, sessionscache og session tickets, hardware acceleration af kryptering (AES-NI) osv. Den korrekte konfiguration af TLS kan reducere forbindelsestiden til 0-1 RTT (uden at medregne DNS og TCP).

Med moderne software er det ikke svært at implementere sådanne praksisser på egne ressourcer.

Langt fra alle CDN implementerer bedste praksis for TLS; dette kan kontrolleres ved at måle tiden for TLS-forbindelsen (f.eks. i Webpagetest). Ideelt for en ny forbindelse er 1RTT, 2RTT er et mellem niveau, 3RTT og mere er dårligt.

Det skal også bemærkes, at selv når TLS anvendes på CDN-niveau, skal serveren med vores webapplikation også håndtere TLS, men fra CDN's side, fordi trafikken mellem serveren og CDN passerer gennem et offentligt netværk. I værste fald får vi dobbelt TLS-forbindelseslatens (den første til CDN-værten, den anden mellem det og vores server).

For nogle anvendelser er det vigtigt at være opmærksom på sikkerhedsspørgsmål: normalt bliver trafikken dekrypteret ved CDN-noderne, hvilket er en potentiel mulighed for trafikinterception. Muligheden for at arbejde uden at afsløre trafikken tilbydes typisk i topplaner mod ekstra betaling.

5. Reduktion af forbindelseslatens

Den største fordel ved CDN, som alle taler om: lav latens (kortere afstand) mellem CDN-værten og brugeren. Dette opnås ved at skabe en geografisk distribueret netværksarkitektur, hvor værterne ligger i punkter med høj brugerkoncentration (byer, trafikudvekslingspunkter osv.).

I praksis kan prioriteterne for forskellige netværk være placeret i specifikke regioner. For eksempel vil russiske CDN have flere tilstedeværelsespunkter i Rusland. Amerikanske vil hovedsageligt udvikle deres netværk i USA. For eksempel har en af de største CDN'er, Cloudflare, kun 2 punkter i Rusland — Moskva og Skt. Petersborg. Det betyder, at vi maksimalt kan spare omkring 10 ms latens sammenlignet med direkte hosting i Moskva.

De fleste vestlige CDN har slet ikke nogen punkter i Rusland. Ved at tilslutte dig dem kan du kun øge latensen for dit russiske publikum.

6. Optimering af indhold (minificering, strukturelle ændringer)

Det mest komplekse og teknologisk udfordrende punkt. Ændring af indhold under levering kan være meget risikabelt. Selv når det kommer til minificering: reduktion af kildekoden (ved at fjerne unødvendige mellemrum, ubetydelige konstruktioner osv.) kan påvirke funktionaliteten. Når det handler om mere alvorlige ændringer – flytning af JS-kode til bunden af HTML, sammenlægning af filer og lignende – er risikoen for at forstyrre websidens funktionalitet endnu højere.

Derfor er der kun nogle CDN af type 5, der beskæftiger sig med dette. Selvfølgelig er det ikke muligt at automatisere alle nødvendige ændringer for at fremskynde – der kræves manuel analyse og optimering. For eksempel er fjernelse af unødvendig eller dupliceret kode en manuel opgave.

Som regel styres alle sådanne optimeringer via indstillinger, og de mest risikable er deaktiveret som standard.

Støtte til accelererende funktioner efter CDN-typer

Lad os se på, hvilke potentielle accelerationsmuligheder der tilbydes af de forskellige typer CDN.

For nemheds skyld gentager vi klassifikationen.

Gratis CDN til levering af JS-biblioteker (MaxCDN, Google, Yandex).
CDN-tjenester til klientoptimering (f.eks. Google Fonts til skrifttyper, Cloudinary, Cloudimage til billeder).
CDN til statiske filer og optimering af ressourcer i CMS (tilgængelige i Bitrix, WordPress og andre).
CDN til generelt formål (StackPath, CDNVideo, NGENIX, MegaFon).
CDN til webstedsacceleration (Cloudflare, Imperva, Airi).

Lad os nu matche funktionerne og typerne af CDN.

Mulighed
Type 1
Type 2
Type 3
Type 4
Type 5

Tekstkomprimering
+–
–
+–
+–
+

Cache-overskrifter
+
+
+
+
+

Billeder
–
+–
+–
–
+

TLS
–
–
–
+–
+

Forsinkelser
–
–
–
+
+

Indhold
–
–
–
–
+

I denne tabel bruges „+“ til at indikere fuld støtte, „–“ til fravær, og „+–“ til delvis støtte. Selvfølgelig kan der være afvigelser fra denne tabel i virkeligheden (for eksempel kan en generel CDN implementere funktioner til billedoptimering), men den er nyttig for et generelt overblik.

Resumé

Jeg håber, at efter at have læst denne artikel, får I et klarere billede af anbefalingen "brug CDN" til at fremskynde hjemmesider.

Som med alt, kan man ikke stole på marketingløfter fra nogen tjeneste. Effekten skal måles og testes under reelle forhold. Hvis du allerede bruger en CDN, skal du kontrollere dens effektivitet ud fra de kriterier, der er beskrevet i artiklen.

Det er muligt, at brugen af CDN lige nu bremser indlæsningen af din hjemmeside.

Som en generel anbefaling kan man konkludere det følgende: studer din målgruppe, bestem dens geografiske rammer. Hvis din primære målgruppe er koncentreret inden for en radius af 1-2 tusinde kilometer, har du ikke brug for en CDN for dens primære formål – reduktion af forsinkelser. I stedet kan du placere din server tættere på brugerne og konfigurere den korrekt for at opnå de fleste af de optimeringer, der er beskrevet i artiklen (gratis og kontinuerligt).

Hvis dit publikum er geografisk spredt (over 3000 kilometer), kan brugen af et kvalitets-CDN virkelig være en fordel. Men det er vigtigt at forstå på forhånd, hvad din CDN faktisk kan accelerere (se oversigten over funktioner og deres beskrivelse). At accelerere et website er stadig en kompleks opgave, der ikke løses blot ved at tilslutte et CDN. Udover de nævnte optimeringer er de mest effektive metoder til acceleration: optimering af serverdelen, avancerede ændringer på klientsiden (fjernelse af unødvendig kode, optimering af renderingsprocessen, arbejde med indhold, skrifttyper, responsivitet osv.)

Kilde: habr.com