[Ikke] bruk et CDN

Nesten hver artikkel eller verktøy for å optimalisere nettstedhastigheten har en beskjeden klausul "bruk et CDN." Generelt er CDN et innholdsleveringsnettverk eller innholdsleveringsnettverk. Vi i Method Lab møter ofte spørsmål fra kunder om dette emnet; noen av dem aktiverer sitt eget CDN. Hensikten med denne artikkelen er å forstå hva et CDN kan gi når det gjelder lastehastighet for nettstedet, hvilke problemer som kan oppstå, og i hvilke tilfeller bruken av et CDN er berettiget.

Forsinkelsene som er ringt inn i bildet er forårsaket av bruk av et CDN.

En bit av historien

Som mange andre teknologier dukket CDN-er opp av nødvendighet. Med utviklingen av Internett-kanaler blant Internett-brukere, dukket online videotjenester opp. Naturligvis krever videoinnhold størrelsesorden større båndbredde sammenlignet med vanlig nettstedinnhold (bilder, tekst og CSS- eller JS-kode).

Når du prøver å kringkaste en videostrøm parallelt til mange klienter fra én server, vil serverens internettkanal mest sannsynlig bli flaskehalsen. Som regel er noen tusen tråder nok til å tette en typisk serverkanal. Selvfølgelig kan det være andre ressursbegrensninger, men de er ikke viktige akkurat nå. Det er også viktig at utvidelse av serverkanalen er for dyrt (og noen ganger umulig), og også upraktisk. Belastningen på kanalen under sendinger vil være syklisk.

Problemet med å begrense kanalen til en individuell server er perfekt løst av CDN. Klienter kobler seg ikke direkte til serveren, men til noder i CDN-nettverket. I en ideell situasjon sender serveren én strøm til CDN-noden, og deretter bruker nettverket sine egne ressurser for å levere denne strømmen til mange brukere. Fra et økonomisk synspunkt betaler vi kun for ressursene som faktisk forbrukes (dette kan være båndbredde eller trafikk) og får utmerket skalerbarhet av tjenesten vår. Å bruke et CDN for å levere tungt innhold er fullstendig berettiget og logisk. Selv om det er verdt å merke seg at de største aktørene på dette området (f.eks. Netflix) bygger sine egne CDN-er i stedet for å bruke store kommersielle CDN-er (Akamai, Cloudflare, Fastly, etc.)

Etter hvert som nettet har utviklet seg, har webapplikasjonene i seg selv blitt mer komplekse og komplekse. Problemet med lastehastighet kom i forgrunnen. Nettstedhastighetsentusiaster identifiserte raskt flere store problemer som førte til at nettsteder lastet sakte. En av dem var nettverksforsinkelser (RTT – rundturstid eller pingtid). Forsinkelser påvirker mange prosesser ved lasting av nettsider: etablering av en TCP-tilkobling, start av en TLS-økt, lasting av hver enkelt ressurs (bilde, JS-fil, HTML-dokument, etc.)

Problemet ble forverret av det faktum at når du bruker HTTP/1.1-protokollen (før bruken av SPDY, QUIC og HTTP/2 var dette det eneste alternativet), åpner nettlesere ikke mer enn 6 TCP-tilkoblinger til en vert. Alt dette førte til tilkoblingsstans og ineffektiv bruk av kanalbåndbredde. Problemet ble delvis løst ved domenedeling - opprettelsen av flere verter for å overvinne grensen for antall tilkoblinger.

Det er her den andre evnen til CDN dukker opp - å redusere latens (RTT) på grunn av det store antallet punkter og nærheten av noder til brukeren. Avstanden spiller en avgjørende rolle her: lyshastigheten er begrenset (ca. 200 000 km/sek i optisk fiber). Dette betyr at hver 1000 km med reise legger til 5 ms forsinkelse eller 10 ms til RTT. Dette er minimumstiden som kreves for overføring, siden det også er forsinkelser på mellomutstyret. Siden et CDN vanligvis vet hvordan man cacher objekter på sine servere, kan vi dra nytte av å laste slike objekter gjennom et CDN. Nødvendige betingelser for dette: tilstedeværelsen av objektet i hurtigbufferen, nærheten til CDN-punktet til brukeren sammenlignet med nettapplikasjonsserveren (opprinnelsesserveren). Det er viktig å forstå at geografisk nærhet til en CDN-node ikke garanterer lav latenstid. Ruting mellom klienten og CDN kan bygges på en slik måte at klienten kobler seg til en vert i et annet land, og muligens på et annet kontinent. Det er her forholdet mellom teleoperatører og CDN-tjenesten (peering, tilkoblinger, deltakelse i IX osv.) og trafikkrutingspolitikken til selve CDN spiller inn. For eksempel, Cloudflare, når du bruker to innledende planer (gratis og billig), garanterer ikke levering av innhold fra nærmeste vert - verten vil bli valgt for å oppnå minimumskostnaden.

Mange ledende Internett-bedrifter tiltrekker offentlig interesse (webutviklere og tjenesteeiere) til temaet lastehastighet og nettsideytelse. Blant disse selskapene er Yahoo (Yslow-verktøyet), AOL (WebPageTest) og Google (Page Speed ​​​​Insights-tjenesten), som utvikler sine egne anbefalinger for å øke hastigheten på nettsteder (de gjelder først og fremst klientoptimalisering). Senere dukker det opp nye verktøy for testing av nettstedhastighet, som også gir tips om å øke hastigheten på nettstedet. Hver av disse tjenestene eller pluginene har en konsekvent anbefaling: "Bruk et CDN." Reduksjonen i nettverkslatens er vanligvis nevnt som en forklaring på effekten av CDN. Dessverre er ikke alle klare til å forstå nøyaktig hvordan akselerasjonseffekten av CDN oppnås og hvordan den kan måles, så anbefalingen tas på tro og brukes som et postulat. Faktisk er ikke alle CDN-er skapt like.

Bruker CDN i dag

For å vurdere nytten av å bruke CDN-er, må de klassifiseres. Hva kan bli funnet nå i praksis (eksemplene i parentes er selvfølgelig ikke uttømmende):

1. Gratis CDN for distribusjon av JS-biblioteker (MaxCDN, Google. Yandex).
2. CDN av tjenester for klientoptimalisering (for eksempel Google Fonts for fonter, Cloudinary, Cloudimage for bilder).
3. CDN for statisk og ressursoptimalisering i CMS (tilgjengelig i Bitrix, WordPress og andre).
4. Generell CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN for nettstedakselerasjon (Cloudflare, Imperva, Airi).

Hovedforskjellen mellom disse typene er hvor mye av trafikken som går gjennom CDN. Type 1-3 er levering av bare deler av innholdet: fra én forespørsel til flere dusin (vanligvis bilder). Type 4 og 5 er full proxying av trafikk via et CDN.

I praksis betyr dette antall tilkoblinger som brukes til å laste siden. Med HTTP/2 bruker vi en enkelt TCP-tilkobling til verten for å behandle et hvilket som helst antall forespørsler. Hvis vi deler ressurser inn i hovedverten (opprinnelsen) og CDN, så er det nødvendig å distribuere forespørsler på tvers av flere domener og opprette flere TCP-forbindelser. Det verste tilfellet er: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Denne formelen tar ikke hensyn til forsinkelser i mobilnettverk for aktivering av enhetens radiokanal (hvis den ikke var aktiv) og forsinkelser på mobiltårnet.

Slik ser det ut på nettstedets lastefoss (forsinkelser for tilkobling til CDN er uthevet ved RTT 150 ms):

Hvis CDN dekker all nettstedtrafikk (bortsett fra tredjepartstjenester), kan vi bruke en enkelt TCP-tilkobling, noe som sparer forsinkelser ved tilkobling til flere verter. Dette gjelder selvfølgelig HTTP/2-tilkoblinger.

Ytterligere forskjeller bestemmes av funksjonaliteten til et bestemt CDN - for den første typen er det bare vert for en statisk fil, for den femte endrer det flere typer nettstedinnhold med det formål å optimalisere.

CDN-funksjoner for nettstedakselerasjon

La oss beskrive hele spekteret av CDN-funksjoner for å akselerere nettsteder, uten hensyn til funksjonaliteten til individuelle typer CDN, og deretter se hva som er implementert i hver av dem.

1. Komprimering av tekstressurser

Den mest grunnleggende og forståelige funksjonen, men ofte dårlig implementert. Alle CDN-er erklærer tilstedeværelsen av kompresjon som deres akselerasjonsfunksjon. Men hvis du ser mer detaljert, blir mangler tydelige:

• lave grader for dynamisk komprimering kan brukes - 5-6 (for eksempel for gzip er maksimum 9);
• statisk komprimering (filer i cache) bruker ikke tilleggsfunksjoner (for eksempel zopfi eller brotli med grad 11)
• det er ingen støtte for effektiv brotli-komprimering (sparer ca. 20 % sammenlignet med gzip).

Hvis du bruker et CDN, er det verdt å sjekke disse få punktene: ta filen som kom fra CDN, registrer den komprimerte størrelsen og komprimer den manuelt for sammenligning (du kan bruke en nettjeneste med brotli-støtte, for eksempel vsszhat.rf).

2. Sette klientbufringshoder

Også en enkel speedup-funksjon: legg til overskrifter for innholdsbufring av klienten (nettleseren). Den mest aktuelle overskriften er cache-kontroll, den utdaterte utløper. I tillegg kan Etag brukes. Hovedsaken er at maks-alderen for cache-kontroll er stor nok (fra en måned eller mer) Hvis du er klar til å cache ressursen så hardt som mulig, kan du legge til det uforanderlige alternativet.

CDN-er kan senke maks-aldersverdien, og tvinge brukeren til å laste statisk innhold på nytt oftere. Det er ikke klart hva dette er forbundet med: ønsket om å øke trafikken på nettverket eller øke kompatibiliteten med nettsteder som ikke vet hvordan de skal tilbakestille cachen. For eksempel er standard Cloudflare header cache-tid 1 time, noe som er veldig lavt for uforanderlige statiske data.

3. Bildeoptimalisering

Siden CDN tar på seg funksjonene som bufring og servering av bilder, ville det være logisk å optimalisere dem på CDN-siden og vise dem til brukere i denne formen. La oss ta en reservasjon med en gang at denne funksjonen kun er tilgjengelig for CDN type 2, 3 og 5.

Du kan optimalisere bilder på en rekke måter: ved å bruke avanserte komprimeringsformater (som WebP), mer effektive kodere (MozJPEG), eller rett og slett rydde opp i unødvendige metadata.

Generelt er det to typer slike optimaliseringer: med kvalitetstap og uten kvalitetstap. CDN-er streber vanligvis etter å bruke tapsfri optimalisering for å unngå mulige kundeklager på endringer i bildekvalitet. Under slike forhold vil gevinsten være minimal. I virkeligheten er ofte JPEG-kvalitetsnivået mye høyere enn nødvendig, og du kan trygt komprimere med et lavere kvalitetsnivå uten å gå på bekostning av brukeropplevelsen. På den annen side er det vanskelig å bestemme nivået på kvalitet og innstillinger universelt for alle mulige nettapplikasjoner, så CDN-er bruker mer konservative innstillinger sammenlignet med de som kan brukes under hensyntagen til konteksten (formål med bilder, type nettapplikasjon , etc.)

4. Optimalisering av TLS-tilkoblingen

Mest trafikk i dag går over TLS-forbindelser, noe som betyr at vi bruker ekstra tid på TLS-forhandling. Nylig har det blitt utviklet nye teknologier for å fremskynde denne prosessen. Dette er for eksempel EC-kryptering, TLS 1.3, sesjonsbuffer og billetter, maskinvarekrypteringsakselerasjon (AES-NI), etc. Riktig innstilling av TLS kan redusere tilkoblingstiden til 0-1 RTT (ikke medregnet DNS og TCP ).

Med moderne programvare er det ikke vanskelig å implementere slik praksis på egenhånd.

Ikke alle CDN-er implementerer TLS-beste praksis; du kan sjekke dette ved å måle TLS-tilkoblingstiden (for eksempel i Webpagetest). Ideell for en ny tilkobling - 1RTT, 2RTT - gjennomsnittlig nivå, 3RTT og mer - dårlig.

Det skal også bemerkes at selv ved bruk av TLS på CDN-nivå, må serveren med vår nettapplikasjon også behandle TLS, men fra CDN-siden, fordi trafikken mellom serveren og CDN går på det offentlige nettverket. I verste fall vil vi få doble TLS-tilkoblingsforsinkelser (den første til CDN-verten, den andre mellom den og serveren vår).

For noen applikasjoner er det verdt å ta hensyn til sikkerhetsproblemer: trafikk dekrypteres vanligvis på CDN-noder, og dette er en potensiell mulighet for trafikkavlytting. Muligheten for å jobbe uten trafikkavsløring tilbys vanligvis i topptariffplaner mot en ekstra avgift.

5. Reduser tilkoblingsforsinkelser

Hovedfordelen med CDN som alle snakker om: lav latens (mindre avstand) mellom CDN-verten og brukeren. Oppnås ved å lage en geografisk distribuert nettverksarkitektur, der verter er plassert i konsentrasjonspunkter av brukere (byer, trafikkutvekslingspunkter, etc.)

I praksis kan prioriteringer for ulike nettverk være i bestemte regioner. For eksempel vil russiske CDN-er ha flere tilstedeværelsespunkter i Russland. De amerikanske skal først og fremst utvikle nettverket i USA. For eksempel har en av de største CDN Cloudflare bare 2 poeng i Russland - Moskva og St. Petersburg. Det vil si at vi maksimalt kan spare ca. 10 ms ventetid sammenlignet med direkte plassering i Moskva.

De fleste vestlige CDN-er har ikke poeng i Russland i det hele tatt. Ved å koble til dem kan du bare øke forsinkelsene for ditt russiske publikum.

6. Innholdsoptimalisering (minifisering, strukturelle endringer)

Det mest komplekse og teknologisk avanserte punktet. Det kan være svært risikabelt å endre innhold under levering. Selv om vi tar minifisering: å redusere kildekoden (på grunn av ekstra mellomrom, uviktige strukturer osv.) kan påvirke ytelsen. Hvis vi snakker om mer alvorlige endringer - flytting av JS-koden til slutten av HTML, sammenslåing av filer osv. - er risikoen for å forstyrre funksjonaliteten til nettstedet enda høyere.

Derfor er det bare noen type 5 CDN-er som gjør dette. Selvfølgelig vil det ikke være mulig å automatisere alle endringene som trengs for å få fart på ting – manuell analyse og optimalisering er nødvendig. For eksempel er det en manuell oppgave å fjerne ubrukt eller duplisert kode.

Som regel styres alle slike optimaliseringer av innstillinger, og de farligste er deaktivert som standard.

Støtte for akselerasjonsmuligheter etter CDN-type

Så la oss ta en titt på hvilke potensielle akselerasjonsmuligheter de forskjellige typene CDN gir.

For enkelhets skyld gjentar vi klassifiseringen.

1. Gratis CDN for distribusjon av JS-biblioteker (MaxCDN, Google. Yandex).
2. CDN av tjenester for klientoptimalisering (for eksempel Google Fonts for fonter, Cloudinary, Cloudimage for bilder).
3. CDN for statisk og ressursoptimalisering i CMS (tilgjengelig i Bitrix, WordPress og andre).
4. Generell CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN for nettstedakselerasjon (Cloudflare, Imperva, Airi).

La oss nå sammenligne funksjonene og typene av CDN.

Opportunity
Type 1
Type 2
Type 3
Type 4
Type 5

Tekstkomprimering
+–
-
+–
+–
+

Bufferoverskrifter
+
+
+
+
+

bilder
-
+–
+–
-
+

TLS
-
-
-
+–
+

Forsinkelser
-
-
-
+
+

Innhold
-
-
-
-
+

I denne tabellen brukes "+" for å indikere full støtte, "–" er ingen støtte, og "+–" er delvis støtte. Selvfølgelig kan det være avvik fra denne tabellen i virkeligheten (for eksempel vil noen generelle CDN implementere funksjoner for å optimalisere bilder), men for en generell idé er det nyttig.

Resultater av

Forhåpentligvis vil du etter å ha lest denne artikkelen ha et klarere bilde angående "bruk et CDN"-anbefaling for å øke hastigheten på sidene dine.

Som i enhver bedrift kan du ikke tro markedsføringsløftene til noen tjeneste. Effekten må måles og testes under reelle forhold. Hvis du allerede bruker et CDN, sjekk det for effektivitet ved å bruke kriteriene beskrevet i artikkelen.

Det er mulig at bruk av et CDN akkurat nå reduserer lastetiden til nettstedet ditt.

Som en generell anbefaling kan vi fokusere på følgende: studer publikum, bestem dets geografiske omfang. Hvis hovedpublikummet ditt er konsentrert innenfor en radius på 1-2 tusen kilometer, trenger du ikke et CDN for hovedformålet - å redusere latens. I stedet kan du plassere serveren din nærmere brukerne og konfigurere den riktig, og få de fleste optimaliseringene beskrevet i artikkelen (gratis og permanent).

I tilfelle publikum er virkelig geografisk fordelt (radius på mer enn 3000 kilometer), vil det virkelig være nyttig å bruke et kvalitets-CDN. Du må imidlertid forstå på forhånd hva akkurat din CDN kan øke hastigheten på (se tabellen over funksjoner og deres beskrivelse). Nettstedakselerasjon er imidlertid fortsatt en kompleks oppgave som ikke kan løses ved å koble til et CDN. I tillegg til de ovennevnte optimaliseringene forblir de mest effektive akselerasjonsmidlene bak CDN: optimalisering av serverdelen, avanserte endringer i klientdelen (fjerning av ubrukt kode, optimalisering av gjengivelsesprosessen, arbeid med innhold, fonter, tilpasningsevne, etc.). )

Kilde: www.habr.com