[Brug ikke] et CDN

Næsten hver artikel eller værktøj til optimering af webstedshastighed har en beskeden klausul "brug et CDN." Generelt er CDN et indholdsleveringsnetværk eller indholdsleveringsnetværk. Vi hos Method Lab støder ofte på spørgsmål fra kunder om dette emne; nogle af dem aktiverer deres eget CDN. Formålet med denne artikel er at forstå, hvad et CDN kan give med hensyn til webstedsindlæsningshastighed, hvilke problemer der kan opstå, og i hvilke tilfælde brugen af ​​et CDN er berettiget.

Forsinkelserne i billedet er forårsaget af brugen af ​​et CDN.

Lidt historie

Som mange andre teknologier opstod CDN'er af nødvendighed. Med udviklingen af ​​internetkanaler blandt internetbrugere dukkede online videotjenester op. Naturligvis kræver videoindhold størrelsesordener mere båndbredde sammenlignet med almindeligt webstedsindhold (billeder, tekst og CSS- eller JS-kode).

Når man forsøger at udsende en videostream parallelt til mange klienter fra én server, vil serverens internetkanal højst sandsynligt blive flaskehalsen. Som regel er et par tusinde tråde nok til at tilstoppe en typisk serverkanal. Selvfølgelig kan der være andre ressourcebegrænsninger, men de er ikke vigtige lige nu. Det er også vigtigt, at udvidelse af serverkanalen er for dyrt (og nogle gange umuligt), og også upraktisk. Belastningen på kanalen under udsendelser vil være cyklisk.

Problemet med at begrænse kanalen for en individuel server er perfekt løst af CDN. Klienter opretter ikke direkte forbindelse til serveren, men til noder i CDN-netværket. I en ideel situation sender serveren én strøm til CDN-noden, og så bruger netværket sine egne ressourcer til at levere denne strøm til mange brugere. Fra et økonomisk synspunkt betaler vi kun for de ressourcer, der faktisk forbruges (dette kan være båndbredde eller trafik) og får fremragende skalerbarhed af vores service. At bruge et CDN til at levere tungt indhold er fuldstændig berettiget og logisk. Selvom det er værd at bemærke, at de største aktører på dette område (f.eks. Netflix) bygger deres egne CDN'er i stedet for at bruge store kommercielle CDN'er (Akamai, Cloudflare, Fastly osv.)

Efterhånden som internettet har udviklet sig, er selve webapplikationerne blevet mere komplekse og komplekse. Problemet med læssehastigheden kom i forgrunden. Hjemmesidehastighedsentusiaster identificerede hurtigt flere store problemer, der fik hjemmesider til at indlæse langsomt. En af dem var netværksforsinkelser (RTT - rundrejsetid eller pingtid). Forsinkelser påvirker mange processer i indlæsning af websteder: etablering af en TCP-forbindelse, start af en TLS-session, indlæsning af hver enkelt ressource (billede, JS-fil, HTML-dokument osv.)

Problemet blev forværret af det faktum, at når man bruger HTTP/1.1-protokollen (før fremkomsten af ​​SPDY, QUIC og HTTP/2 var dette den eneste mulighed), åbner browsere ikke mere end 6 TCP-forbindelser til én vært. Alt dette førte til nedetid for forbindelsen og ineffektiv brug af kanalbåndbredde. Problemet blev delvist løst ved domæne-sharding - oprettelsen af ​​yderligere værter for at overvinde grænsen for antallet af forbindelser.

Det er her CDN's anden evne dukker op - reduktion af latency (RTT) på grund af det store antal punkter og nærheden af ​​noder til brugeren. Afstanden spiller en afgørende rolle her: lysets hastighed er begrænset (ca. 200 km/sek. i optisk fiber). Det betyder, at hver 000 km rejse tilføjer 1000 ms forsinkelse eller 5 ms til RTT. Dette er den minimale tid, der kræves til transmission, da der også er forsinkelser på det mellemliggende udstyr. Da et CDN normalt ved, hvordan man cacher objekter på sine servere, kan vi drage fordel af at indlæse sådanne objekter gennem et CDN. Nødvendige betingelser for dette: tilstedeværelsen af ​​objektet i cachen, nærheden af ​​CDN peger på brugeren i sammenligning med webapplikationsserveren (oprindelig server). Det er vigtigt at forstå, at geografisk nærhed af en CDN-knude ikke garanterer lav latenstid. Routing mellem klienten og CDN kan bygges på en sådan måde, at klienten vil oprette forbindelse til en vært i et andet land, og muligvis på et andet kontinent. Det er her forholdet mellem teleoperatører og CDN-tjenesten (peering, forbindelser, deltagelse i IX osv.) og selve CDN'ets trafikdirigeringspolitik kommer i spil. For eksempel garanterer Cloudflare, når du bruger to indledende planer (gratis og billig), ikke levering af indhold fra den nærmeste vært - værten vil blive udvalgt for at opnå minimumsomkostningerne.

Mange førende internetvirksomheder tiltrækker offentlig interesse (webudviklere og tjenesteejere) til emnet indlæsningshastighed og webstedsydelse. Blandt disse virksomheder er Yahoo (Yslow tool), AOL (WebPageTest) og Google (Page Speed ​​​​Insights service), som er ved at udvikle deres egne anbefalinger til at fremskynde websteder (primært relaterer de sig til klientoptimering). Senere dukker der nye værktøjer til test af hjemmesidehastighed, som også giver tips til at øge hjemmesidehastigheden. Hver af disse tjenester eller plugins har en konsekvent anbefaling: "Brug et CDN." Reduktionen i netværksforsinkelse nævnes normalt som en forklaring på effekten af ​​CDN. Desværre er det ikke alle, der er klar til at forstå præcis, hvordan accelerationseffekten af ​​CDN opnås, og hvordan den kan måles, så anbefalingen tages på tro og bruges som et postulat. Faktisk er ikke alle CDN'er skabt lige.

Bruger CDN i dag

For at vurdere nytten af ​​at bruge CDN'er skal de klassificeres. Hvad kan man nu finde i praksis (eksemplerne i parentes er naturligvis ikke udtømmende):

1. Gratis CDN til distribution af JS-biblioteker (MaxCDN, Google. Yandex).
2. CDN af tjenester til klientoptimering (for eksempel Google Fonts til skrifttyper, Cloudinary, Cloudimage til billeder).
3. CDN til statisk optimering og ressourceoptimering i CMS (tilgængelig i Bitrix, WordPress og andre).
4. Generelt CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN til hjemmesideacceleration (Cloudflare, Imperva, Airi).

Den vigtigste forskel mellem disse typer er, hvor meget af trafikken der går gennem CDN. Type 1-3 er levering af kun en del af indholdet: fra en anmodning til flere dusin (normalt billeder). Type 4 og 5 er fuld proxying af trafik via et CDN.

I praksis betyder det antallet af forbindelser, der bruges til at indlæse siden. Med HTTP/2 bruger vi en enkelt TCP-forbindelse til værten til at behandle et vilkårligt antal anmodninger. Hvis vi opdeler ressourcer i hovedværten (origin) og CDN, så er det nødvendigt at distribuere anmodninger på tværs af flere domæner og oprette flere TCP-forbindelser. Det værste tilfælde er: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Denne formel tager ikke højde for forsinkelser i mobilnetværk for aktivering af enhedens radiokanal (hvis den ikke var aktiv) og forsinkelser på mobiltårnet.

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

Hvis CDN'et dækker al trafik på webstedet (undtagen tredjepartstjenester), så kan vi bruge en enkelt TCP-forbindelse, hvilket sparer forsinkelser ved tilslutning til yderligere værter. Det gælder selvfølgelig HTTP/2-forbindelser.

Yderligere forskelle bestemmes af funktionaliteten af ​​et bestemt CDN - for den første type er det bare hosting af en statisk fil, for den femte er det at ændre flere typer webstedsindhold med henblik på optimering.

CDN-funktioner til websiteacceleration

Lad os beskrive hele rækken af ​​CDN-funktioner til at accelerere websteder, uden hensyn til funktionaliteten af ​​individuelle typer af CDN, og derefter se, hvad der er implementeret i hver af dem.

1. Komprimering af tekstressourcer

Den mest grundlæggende og forståelige funktion, men dog ofte dårligt implementeret. Alle CDN'er erklærer tilstedeværelsen af ​​kompression som deres accelerationsfunktion. Men hvis du ser mere detaljeret, bliver manglerne tydelige:

• lave grader til dynamisk komprimering kan bruges - 5-6 (for eksempel for gzip er maksimum 9);
• statisk komprimering (filer i cache) bruger ikke yderligere funktioner (for eksempel zopfi eller brotli med grad 11)
• der er ingen understøttelse af effektiv brotli-komprimering (besparelse omkring 20% ​​sammenlignet med gzip).

Hvis du bruger et CDN, er det værd at tjekke disse få punkter: tag filen, der kom fra CDN, optag dens komprimerede størrelse og komprimer den manuelt til sammenligning (du kan bruge en online-tjeneste med brotli-support, f.eks. vsszhat.rf).

2. Indstilling af klient-cache-headere

Også en simpel speedup-funktion: Tilføj headers til indholdscache af klienten (browser). Den mest aktuelle header er cache-kontrol, den forældede udløber. Derudover kan Etag bruges. Det vigtigste er, at max-alderen for cache-kontrol er stor nok (fra en måned eller mere).Hvis du er klar til at cache ressourcen så hårdt som muligt, kan du tilføje den uforanderlige mulighed.

CDN'er kan sænke den maksimale aldersværdi, hvilket tvinger brugeren til at genindlæse statisk indhold oftere. Det er ikke klart, hvad dette er forbundet med: ønsket om at øge trafikken på netværket eller øge kompatibiliteten med websteder, der ikke ved, hvordan man nulstiller cachen. For eksempel er standard Cloudflare header cache-tid 1 time, hvilket er meget lavt for uforanderlige statiske data.

3. Billedoptimering

Da CDN'et påtager sig funktionerne som caching og servering af billeder, ville det være logisk at optimere dem på CDN-siden og servere dem til brugerne i denne form. Lad os tage en reservation med det samme, at denne funktion kun er tilgængelig for CDN type 2, 3 og 5.

Du kan optimere billeder på en række forskellige måder: ved at bruge avancerede komprimeringsformater (såsom WebP), mere effektive indkodere (MozJPEG) eller simpelthen at rydde op i unødvendige metadata.

Generelt er der to typer af sådanne optimeringer: med kvalitetstab og uden kvalitetstab. CDN'er stræber normalt efter at bruge tabsfri optimering for at undgå mulige kundeklager over ændringer i billedkvalitet. Under sådanne forhold vil gevinsten være minimal. I virkeligheden er JPEG-kvalitetsniveauet ofte meget højere end nødvendigt, og du kan trygt komprimere med et lavere kvalitetsniveau uden at gå på kompromis med brugeroplevelsen. På den anden side er det vanskeligt at bestemme niveauet for kvalitet og indstillinger universelt for alle mulige webapplikationer, så CDN'er bruger mere konservative indstillinger sammenlignet med dem, der kan anvendes under hensyntagen til konteksten (formål med billeder, type webapplikation , etc.)

4. Optimering af TLS-forbindelsen

Det meste trafik i dag kører over TLS-forbindelser, hvilket betyder, at vi bruger ekstra tid på TLS-forhandling. For nylig er der udviklet nye teknologier for at fremskynde denne proces. Dette er f.eks. EC-kryptering, TLS 1.3, sessionscache og billetter, hardwarekrypteringsacceleration (AES-NI) osv. Korrekt indstilling af TLS kan reducere forbindelsestiden til 0-1 RTT (ikke medregner DNS og TCP ).

Med moderne software er det ikke svært at implementere sådan praksis på egen hånd.

Ikke alle CDN'er implementerer TLS bedste praksis; du kan kontrollere dette ved at måle TLS-forbindelsestiden (f.eks. i Webpagetest). Ideel til en ny forbindelse - 1RTT, 2RTT - gennemsnitsniveau, 3RTT og mere - dårligt.

Det skal også bemærkes, at selv ved brug af TLS på CDN-niveau, skal serveren med vores webapplikation også behandle TLS, men fra CDN-siden, fordi trafikken mellem serveren og CDN'et passerer på det offentlige netværk. I værste tilfælde vil vi få dobbelte TLS-forbindelsesforsinkelser (den første til CDN-værten, den anden mellem den og vores server).

For nogle applikationer er det værd at være opmærksom på sikkerhedsproblemer: Trafik dekrypteres normalt på CDN-noder, og dette er en potentiel mulighed for trafikaflytning. Muligheden for at arbejde uden trafikoplysning tilbydes normalt i toptakstplaner mod et ekstra gebyr.

5. Reducer forbindelsesforsinkelser

Den største fordel ved CDN, som alle taler om: lav latenstid (mindre afstand) mellem CDN-værten og brugeren. Opnås ved at skabe en geografisk distribueret netværksarkitektur, hvor værter er placeret i koncentrationspunkter af brugere (byer, trafikudvekslingspunkter osv.)

I praksis kan prioriteringer for forskellige netværk være i specifikke regioner. For eksempel vil russiske CDN'er have flere tilstedeværelsespunkter i Rusland. De amerikanske vil først og fremmest udvikle netværket i USA. For eksempel har en af ​​de største CDN Cloudflare kun 2 point i Rusland - Moskva og St. Petersborg. Det vil sige, at vi maksimalt kan spare omkring 10 ms latency sammenlignet med direkte placering i Moskva.

De fleste vestlige CDN'er har slet ikke point i Rusland. Ved at oprette forbindelse til dem kan du kun øge forsinkelserne for dit russiske publikum.

6. Indholdsoptimering (minificering, strukturelle ændringer)

Det mest komplekse og teknologisk avancerede punkt. Ændring af indhold under levering kan være meget risikabelt. Selv hvis vi tager minifikation: at reducere kildekoden (på grund af ekstra mellemrum, uvigtige strukturer osv.) kan påvirke dens ydeevne. Hvis vi taler om mere seriøse ændringer – flytning af JS-koden til slutningen af ​​HTML, fletning af filer osv. – er risikoen for at forstyrre webstedets funktionalitet endnu højere.

Derfor er det kun nogle type 5 CDN'er, der gør dette. Det vil selvfølgelig ikke være muligt at automatisere alle de ændringer, der er nødvendige for at fremskynde tingene - der kræves manuelle analyser og optimering. For eksempel er det en manuel opgave at fjerne ubrugt eller dublet kode.

Som regel styres alle sådanne optimeringer af indstillinger, og de farligste er deaktiveret som standard.

Understøttelse af accelerationsmuligheder efter CDN-type

Så lad os tage et kig på, hvilke potentielle accelerationsmuligheder de forskellige typer CDN'er giver.

For nemheds skyld gentager vi klassificeringen.

1. Gratis CDN til distribution af JS-biblioteker (MaxCDN, Google. Yandex).
2. CDN af tjenester til klientoptimering (for eksempel Google Fonts til skrifttyper, Cloudinary, Cloudimage til billeder).
3. CDN til statisk optimering og ressourceoptimering i CMS (tilgængelig i Bitrix, WordPress og andre).
4. Generelt CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN til hjemmesideacceleration (Cloudflare, Imperva, Airi).

Lad os nu sammenligne funktionerne og typerne af CDN.

Opportunity
Type 1
Type 2
Type 3
Type 4
Type 5

Tekstkomprimering
+–
-
+–
+–
+

Cache-overskrifter
+
+
+
+
+

billeder
-
+–
+–
-
+

TLS
-
-
-
+–
+

Forsinkelser
-
-
-
+
+

Indhold
-
-
-
-
+

I denne tabel bruges "+" til at angive fuld understøttelse, "–" er ingen understøttelse, og "+–" er delvis understøttelse. Selvfølgelig kan der være afvigelser fra denne tabel i virkeligheden (for eksempel vil nogle generelle CDN'er implementere funktioner til optimering af billeder), men for en generel idé er det nyttigt.

Resultaterne af

Forhåbentlig vil du, efter at have læst denne artikel, have et klarere billede af anbefalingen "brug et CDN" for at fremskynde dine websteder.

Som i enhver virksomhed kan du ikke tro på markedsføringsløfterne fra nogen tjeneste. Effekten skal måles og testes under virkelige forhold. Hvis du allerede bruger et CDN, skal du kontrollere det for effektivitet ved hjælp af kriterierne beskrevet i artiklen.

Det er muligt, at brugen af ​​et CDN lige nu sænker dit websteds indlæsningstid.

Som en generel anbefaling kan vi fokusere på følgende: Undersøg dit publikum, bestem dets geografiske omfang. Hvis dit hovedpublikum er koncentreret inden for en radius på 1-2 tusinde kilometer, behøver du ikke et CDN til dets hovedformål - at reducere latens. I stedet kan du placere din server tættere på dine brugere og konfigurere den korrekt, og få de fleste af de optimeringer, der er beskrevet i artiklen (gratis og permanent).

Hvis dit publikum virkelig er geografisk fordelt (radius på mere end 3000 kilometer), vil det virkelig være nyttigt at bruge et kvalitets-CDN. Du skal dog på forhånd forstå, hvad præcis din CDN kan fremskynde (se tabellen over funktioner og deres beskrivelse). Websiteacceleration er dog stadig en kompleks opgave, som ikke kan løses ved at forbinde et CDN. Ud over ovenstående optimeringer forbliver de mest effektive midler til acceleration bag CDN: optimering af serverdelen, avancerede ændringer af klientdelen (fjernelse af ubrugt kode, optimering af gengivelsesprocessen, arbejde med indhold, skrifttyper, tilpasningsevne osv.). )

Kilde: www.habr.com