Hva er et CDN, og når hjelper det faktisk?

Et CDN er et distribuert mellomlag foran nettstedets origin. Det kan svare fra et edge-punkt nær eller nettverksmessig gunstig for brukeren, eller sende forespørselen videre til origin.

Et CDN gjør ikke enhver side rask. Gevinsten kommer når det kan gjenbruke riktig svar, redusere avstand eller tilkoblingskostnad, og avlaste origin uten å blande data mellom brukere.

Slik går en forespørsel gjennom et CDN

1. DNS eller plattformrouting sender brukeren til CDN-et.
2. CDN-et avslutter normalt TLS-forbindelsen fra nettleseren.
3. Edge beregner en cache key og kontrollerer policyen.
4. Ved cache hit leveres et lagret, fortsatt gyldig svar.
5. Ved cache miss hentes svaret fra origin, og det lagres hvis policyen tillater det.
6. Ved bypass går forespørselen til origin uten gjenbruk, for eksempel på grunn av autentisering eller en regel.

Den første brukeren etter en miss kan fortsatt vente på origin. Det er derfor cache hit-rate, TTFB ved hit og TTFB ved miss som viser om CDN-et faktisk hjelper.

Hva er en cache key?

Cache-nøkkelen avgjør hvilke forespørsler som regnes som like. URI-en er sentral, men noen svar varierer også med blant annet språk, komprimering, enhet, cookies eller andre headere.

Hvis nøkkelen er for bred, kan feil variant eller personlig innhold vises til en annen bruker. Hvis den er for smal, får nesten hver forespørsel sin egen variant og hit-raten faller.

IETFs standard for HTTP-caching og cache keys beskriver hvordan delte og private cacher kan gjenbruke svar og hvordan Vary skiller varianter.

Ikke legg hele cookie-headeren i cache key uten å forstå konsekvensen. Mange cookies er unike per besøk og kan ødelegge gjenbruk, mens det er farlig å ignorere en cookie som faktisk endrer innholdet.

Hva bør caches?

Cache-Control lar origin uttrykke policy. Eksempler må tilpasses:

Cache-Control: public, max-age=31536000, immutable

Dette kan passe en fingeravtrykket fil som app.a1b2c3.js. Det passer ikke en fil med samme URL som overskrives i morgen.

Cache-Control: private, no-cache

Dette tillater lagring i privat cache, men krever validering før gjenbruk. Sensitivt innhold som ikke skal lagres, trenger en strengere policy som no-store. MDN forklarer forskjellen mellom max-age, s-maxage, private, no-cache og no-store .

Cacheinvalidering ved publisering

Velg en kjent strategi:

• Fingeravtrykk i filnavn: ny fil får ny URL; gamle filer kan caches lenge.
• Kort levetid: enkel, men gir hyppigere revalidering eller miss.
• Målrettet purge: fjern nøyaktige URL-er når innhold publiseres.
• Surrogate keys eller tags: purge en logisk gruppe hvis leverandøren støtter det.

Test sletting på alle edge-punkter som leverandøren bruker. Unngå «purge everything» som fast publiseringsrutine; det fjerner hit-raten og kan sende en plutselig bølge til origin.

Cache også feilresponser bevisst. En langlivet cachet 404 eller 500 kan gjøre en kort feil unødvendig varig.

Når CDN ofte hjelper

• Publikum er geografisk eller nettverksmessig spredt.
• Siden har mange gjenbrukbare bilder, filer eller offentlige sider.
• Origin har kostbare eller trege gjentatte forespørsler.
• Trafikktopper kan absorberes av edge-cache.
• Plattformen trenger reverse proxy, WAF eller trafikkstyring som del av en planlagt arkitektur.

Når gevinsten kan være liten

• Siden er liten, rask og nær hovedpublikummet allerede.
• Nesten alle svar er personlige og må til origin.
• Cache key inneholder så mange varianter at hit-raten blir lav.
• CDN-et legger til en ekstra origin, redirect eller TLS-feil.
• Teamet mangler eierskap til cache-regler, purge og feilsøking.

Mål før og etter fra faktiske markeder. «Nærmeste datasenter» betyr ikke alltid korteste total responstid; ruting, cache status, origin og tilkoblingsgjenbruk påvirker resultatet.

Skal CDN-et redusere belastning eller kostnad hos origin, mål trafikk etter bytes i tillegg til antall cachetreff. Båndbreddeguiden skiller nettleser-, CDN- og origin-trafikk .

CDN er ikke det samme som backup eller failover

Cachede ressurser kan i noen oppsett leveres mens origin har en kort feil, men dette er policy- og leverandøravhengig. Innlogging, utsjekk, skjema og cache misses kan fortsatt feile.

Reell failover krever minst en alternativ, oppdatert origin, helsesjekk, trygg trafikkstyring og test av dataavhengigheter. Backup handler om å gjenopprette data og konfigurasjon; et CDN erstatter ikke dette. Se hva DNS-failover faktisk kan og ikke kan løse før en reserve annonseres som tilgjengelighet.

Sikkerhet krever beskyttet origin

En reverse proxy kan filtrere trafikk, dempe angrep og skjule origin-adressen i normal DNS. Men hvis angriperen kjenner origin-IP-en og serveren fortsatt tar imot alle direkte forbindelser, kan CDN-laget omgås.

Planlegg:

• gyldig TLS også mellom CDN og origin
• autentisering eller nettverksbegrensning på origin
• riktig klient-IP i logger uten å stole på headere fra vilkårlige kilder
• separate opprinnelser for tjenester som kan røpe webserveradressen
• overvåking av både edge- og origin-feil
• tilgangsstyring og endringslogg for CDN-regler

Cloudflare dokumenterer selv at en kjent origin kan angripes direkte, og anbefaler å begrense origin til betrodde proxyforbindelser eller bruke andre origin-kontroller . Tilsvarende prinsipp gjelder andre reverse proxy-løsninger.

WAF og DDoS-beskyttelse varierer med leverandør, plan, protokoll og konfigurasjon. Ikke anta at ordet CDN betyr at alle angrep eller porter er dekket.

Personvern og logger

Et CDN kan se IP-adresser, URL-er, headere og trafikkmetadata, og noen løsninger inspiserer innhold for sikkerhetsregler. Kartlegg databehandlerrolle, logglagring, behandlingssteder, underleverandører og tilgang før aktivering.

Unngå tokens og personopplysninger i URL-er. URL-er kan havne i edge-logger, analyser, nettleserhistorikk og referer-headere selv om svaret ikke caches.

Utrullingsplan

1. Mål TTFB, LCP, trafikk og origin-belastning uten CDN.
2. Kartlegg offentlige, personlige og administrative ruter.
3. Start med versjonerte statiske ressurser.
4. Verifiser hit, miss, bypass, cache key og response-headere.
5. Test innlogging, skjema, handlekurv, preview og flerspråk.
6. Koble purge til publiseringsløpet.
7. Beskytt origin og test at direkte tilgang avvises når det er målet.
8. Aktiver offentlig HTML-cache bare for dokumenterte ruter.
9. Overvåk hit-rate, origin-feil, kostnad og Core Web Vitals.
10. Dokumenter rollback uten å endre domene eller miste TLS.

Bruk ytelsesguiden for å avgjøre om CDN er riktig tiltak, og HTTP/2 mot HTTP/3 når transportprotokollen skal vurderes separat.

CDN og Vymo

Vymos standardtilbud er én enkel nettside som Vymo setter opp og hoster. Kunden får foreløpig ikke et selvbetjent CDN-panel eller egne cache- og WAF-regler, og Vymo lover ikke en bestemt CDN-leverandør eller serverplassering som del av standardtilbudet.

Har virksomheten krav til edge-cache, WAF, global levering eller beskyttet origin, beskriv trafikk, ruter og sikkerhetskrav før bestilling. For en enkel lokal bedriftsside kan standardtilbudet være nok uten at kunden administrerer et eget CDN.