02 maj 2025·5 min
Från CDN till plattform: Hur Cloudflares edge utvidgades
Lär dig hur Cloudflares edge gick från CDN‑cachning till säkerhet och utvecklartjänster i takt med att mer trafik flyttas till nätverkets perimeter.
Lär dig hur Cloudflares edge gick från CDN‑cachning till säkerhet och utvecklartjänster i takt med att mer trafik flyttas till nätverkets perimeter.
Ett edge‑nätverk är en uppsättning servrar distribuerade över många städer som sitter “nära” slutanvändare. Istället för att varje förfrågan måste resa hela vägen tillbaka till dina originsservrar (eller en molnregion) kan edge:n svara, inspektera eller vidarebefordra den förfrågan från en närliggande plats.
Tänk på det som att placera hjälpsam personal vid ingångarna till en arena istället för att hantera alla frågor i bakre kontoret. Vissa förfrågningar kan hanteras omedelbart (som att leverera en cachelagrad fil), medan andra säkert vidarebefordras.
Perimetern är gränsen där extern internettrafik först möter dina system: din webbplats, appar, API:er och de tjänster som skyddar och routar dem. Historiskt behandlade många företag perimetern som en tunn dörr (DNS och en load balancer). Idag är det där de mest trafikerade och riskfyllda interaktionerna händer—inloggningar, API‑anrop, bots, scraping, attacker och plötsliga toppar.
När mer arbete flyttar online och fler integrationer litar på API:er blir det alltmer praktiskt att samla trafik genom perimetern så att du kan tillämpa konsekventa regler—prestandaoptimeringar, säkerhetskontroller och åtkomstregler—innan förfrågningar når din kärninfrastruktur.
Den här artikeln följer en utveckling: prestanda först (CDN), sedan säkerhet vid edge (DDoS, WAF, bot‑kontroller, Zero Trust) och slutligen verktyg för utvecklare (köra kod och hantera data närmare användare).
Den är skriven för icke‑tekniska beslutsfattare—köpare som utvärderar leverantörer, grundare som väger alternativ och PM:er som behöver "varför" och "vad som ändras" utan att läsa nätverksläroböcker.
En traditionell CDN (Content Delivery Network) började med ett enkelt löfte: få webbplatser att kännas snabbare genom att leverera innehåll från en plats närmare besökaren. Istället för att varje förfrågan reser tillbaka till din originserver (ofta en enda region eller datacenter) håller CDN:en kopior av statiska filer—bilder, CSS, JavaScript, nedladdningar—på många points of presence (PoP). När en användare begär en fil kan CDN:en svara lokalt, vilket minskar latens och avlastar origin.
I grunden fokuserar ett "enbart CDN"‑upplägg på tre utfall:
Denna modell är särskilt effektiv för statiska sajter, media‑tunga sidor och förutsägbara trafikmönster där samma resurser begärs om och om igen.
I början utvärderade team CDNs med ett fåtal praktiska mått:
Dessa siffror var viktiga eftersom de översattes direkt till användarupplevelse och kostnad för infrastruktur.
Även en grundläggande CDN påverkar hur förfrågningar når din sajt. Vanligtvis införs den via DNS: din domän pekas mot CDN:en, som sedan routar besökare till en närliggande PoP. Därifrån kan CDN agera som en reverse proxy—terminera användarens anslutning och öppna en separat anslutning till din origin när det behövs.
Denna "i mitten"‑position är viktig. När en leverantör pålitligt står framför din origin och hanterar trafik vid kanten kan den göra mer än att cacha filer—den kan inspektera, filtrera och forma förfrågningar.
Många moderna produkter är inte längre mestadels statiska sidor. De är dynamiska applikationer stödda av API:er: personaliserat innehåll, realtidsuppdateringar, autentiserade flöden och frekventa skrivningar. Cachning hjälper, men kan inte lösa allt—särskilt när svar varierar per användare, beror på cookies eller headers eller kräver omedelbar origin‑logik.
Det gapet—mellan statisk acceleration och dynamiska applikationsbehov—är där övergången från "CDN" till en bredare edge‑plattform börjar.
En stor förändring i hur internet används har pressat fler förfrågningar till "kanten" (nätverksperimetern) innan de når dina originsservrar. Det handlar inte längre bara om snabbare webbplatser—det handlar om var trafiken naturligt flödar.
HTTPS överallt är en stor drivkraft. När större delen av trafiken är krypterad kan inte nätverksmiddleboxes inne i ett företagsnätverk enkelt inspektera eller optimera den. Istället föredrar organisationer att terminera och hantera TLS närmare användaren—vid en edge‑tjänst byggd för det jobbet.
API:er har också förändrat trafikens form. Moderna appar är en ständig ström av små förfrågningar från webbfrontend, mobilklienter, partnerintegrationer och mikrotjänster. Lägg till bots (både goda och onda) och plötsligt är en stor del av "användarna" inte människor alls—vilket betyder att trafik behöver filtreras och ha rate‑kontroller innan den når applikationsinfrastrukturen.
Sen finns vardagens verklighet: mobila nätverk (variabel latens, roaming, retransmissions) och ökningen av SaaS. Dina anställda och kunder är inte längre "inne" i ett enda nätverksgränssnitt, så säkerhets‑ och prestandabeslut flyttas till där användarna faktiskt kopplar upp sig.
När applikationer, användare och tjänster sprids över regioner och moln finns det färre pålitliga platser att upprätthålla regler. Traditionella kontrollpunkter—som en enda datacenter‑brandvägg—slutar vara standardvägen. Edge:n blir en av få konsekventa checkpoint:ar som de flesta förfrågningar kan routas genom.
Eftersom så mycket trafik passerar perimetern är det en naturlig plats att tillämpa delade policyer: DDoS‑filtrering, bot‑detektering, WAF‑regler, TLS‑inställningar och åtkomstkontroller. Detta minskar "beslutsfattande" vid varje origin och håller skydden konsekventa över applikationer.
Att centralisera trafik vid kanten kan dölja origin‑IP:er och minska direkt exponering, vilket är en meningsfull säkerhetsfördel. Avvägningen är beroende: edge‑tillgänglighet och korrekt konfiguration blir kritiska. Många team behandlar edge:n som en del av kärninfrastrukturen—närmare ett kontrollplan än en enkel cache.
För en praktisk checklista, se /blog/how-to-evaluate-an-edge-platform.
En traditionell CDN började som "smart cachning": den lagrade kopior av statiska filer närmare användarna och hämtade från origin vid behov. Det hjälper prestanda, men förändrar inte grundläggande vem som "äger" anslutningen.
Det stora skiftet sker när edge:n slutar vara bara en cache och blir en fullständig reverse‑proxy.
En reverse‑proxy sitter framför din webbplats eller app. Användare kopplar till proxyn, och proxyn kopplar till din origin (dina servrar). För användaren är proxyn sajten; för origin ser proxyn ut som användaren.
Den positionen möjliggör tjänster som inte är möjliga med "endast cache"‑beteende—eftersom varje förfrågan kan hanteras, modifieras eller blockeras innan den når din infrastruktur.
När edge:n terminerar TLS (HTTPS) etableras den krypterade anslutningen vid edge:n först. Det skapar tre praktiska möjligheter:
Här är mentalmodellen:
user → edge (reverse proxy) → origin
Att placera edge:n i mitten centraliserar kontroll, vilket ofta är målet: konsekventa säkerhetspolicyer, enklare rollout och färre "specialfall" vid varje origin.
Men det lägger också till komplexitet och beroende:
Detta arkitekturskifte är vad som förvandlar en CDN till en plattform: när edge:n blir proxyn kan den göra mycket mer än bara cacha.
En DDoS (Distributed Denial of Service)‑attack är helt enkelt ett försök att överbelasta en sajt eller app med så mycket trafik att riktiga användare inte kommer igenom. Istället för att "hacka in" försöker angriparen blockera uppfarten.
Många DDoS‑attacker är volymbaserade: de skickar enorma mängder data till din IP‑adress för att mätta bandbredd eller överbelasta nätverksenheter innan en förfrågan ens når din webserver. Om du väntar med att försvara dig vid origin (ditt datacenter eller molnregion) betalar du redan priset—dina upstream‑länkar kan mättas och din brandvägg eller load balancer bli flaskhalsen.
Ett edge‑nätverk hjälper eftersom det placerar skyddskapacitet närmare där trafiken går in i internet, inte bara där dina servrar bor. Ju mer distribuerad försvaret är, desto svårare blir det för angripare att "hopa upp" på en enda choke point.
När leverantörer beskriver DDoS‑skydd som att "absorbera och filtrera" menar de två saker som händer över många PoP:ar:
Huvudfördelen är att det värsta av attacken kan hanteras uppströms din infrastruktur, vilket minskar risken att ditt eget nätverk—eller moln‑nota—blir offret.
Rate limiting är ett praktiskt sätt att förhindra att en enskild källa—eller ett beteende—konsumerar för mycket resurser för snabbt. Exempelvis kan du begränsa:
Det stoppar inte alla typer av DDoS på egen hand, men fungerar som en effektiv tryckventil som minskar missbruksspikar och håller kritiska vägar användbara under en incident.
Om du utvärderar edge‑baserat DDoS‑skydd, kontrollera:
När grundläggande DDoS‑filtrering är på plats är nästa lager att skydda själva applikationen—särskilt de "normalt utseende"‑förfrågningarna som bär skadlig avsikt. Här blir en Web Application Firewall (WAF) och bot‑hantering vardagsarbetshästar vid kanten.
En WAF inspekterar HTTP/S‑förfrågningar och applicerar regler avsedda att blockera vanliga missbruks‑mönster. Klassiska exempel är:
Istället för att lita på att din app fångar varje dåligt input kan edge:n filtrera många av dessa försök innan de når origin‑servrar. Det minskar risk och minskar även bullrig trafik som slösar compute och loggutrymme.
Bots kan vara hjälpsamma (sökmotor‑crawlers) eller skadliga (credential stuffing, scraping, hoarding av inventarier). Nyckelskillnaden är inte bara automation—det är avsikt och beteende. En riktig användares session har ofta naturlig timing, navigationsflöde och webbläsar‑egenskaper. Malignt agerande tenderar att generera högvolym, repetitiva förfrågningar, undersöka endpoints eller imitera user‑agents men bete sig onaturligt.
Eftersom edge:n ser stora volymer över många sajter kan den använda bredare signaler för att fatta smartare beslut, såsom:
Ett praktiskt införande är att börja i monitor (logg)‑läge för att se vad som skulle ha blockerats och varför. Använd den datan för att finjustera undantag för kända verktyg och partners, och skärp sedan policys gradvis—från avisering till utmaningar och slutligen blockeringar för bekräftat illasinnad trafik. Detta minskar falska positiver samtidigt som säkerheten förbättras snabbt.
Ett edgenätverk är en distribuerad samling servrar (points of presence) placerade i många städer så att förfrågningar kan hanteras närmare användarna. Beroende på förfrågan kan edge:n:
Det praktiska resultatet är lägre latens samt mindre belastning och exponering för din origin‑infrastruktur.
Perimetern är gränsen där internettrafiken först når dina system—din webbplats, appar och API:er—ofta via DNS och en edge‑reverse‑proxy. Det spelar roll eftersom det är här:
Att centralisera kontroller i perimetern låter dig tillämpa konsekventa prestanda‑ och säkerhetsregler innan trafiken når dina kärntjänster.
En klassisk CDN fokuserar på cachning av statiskt innehåll (bilder, CSS, JS, nedladdningar) på edge‑platser. Den förbättrar hastigheten främst genom att minska avståndet och avlasta origin.
En modern edge‑plattform går vidare och agerar ofta som en fullständig reverse‑proxy för majoriteten av trafiken, vilket möjliggör routing, säkerhetsinspektion, åtkomstkontroller och ibland compute—oavsett om innehållet är cachebart eller inte.
DNS är ofta det enklaste sättet att placera en CDN/edge‑leverantör framför din sajt: din domän pekar mot leverantören, som sedan router besökare till en närliggande PoP.
I många konfigurationer agerar edge:n också som en reverse‑proxy, vilket betyder att användare först kopplar upp sig mot edge:n, och edge:n endast kopplar till din origin vid behov. Denna "mitt‑i‑kedjan"‑position möjliggör cachning, routing och säkerhets‑enforcement i stor skala.
När edge:n terminerar TLS etableras den krypterade HTTPS‑anslutningen vid edge‑punkten. Det möjliggör tre praktiska förmågor:
Det ökar kontrollen—men betyder också att edge‑konfiguration blir mission‑kritisk.
Du bör utvärdera en CDN med mått som kopplar till användarupplevelse och infrastrukturkostnad, till exempel:
Kombinera dessa med origin‑sidans mätvärden (CPU, förfrågningsfrekvens, egress) för att bekräfta att CDN faktiskt minskar belastningen där det spelar roll.
Edge‑mitigering är effektiv eftersom många DDoS‑attacker är volymbaserade—de försöker mätta bandbredd eller nätverksutrustning innan förfrågningar når din applikation.
En distribuerad edge kan:
Att enbart försvara sig vid origin innebär ofta att du betalar priset (saturerade länkar, överbelastade load balancers, högre molnräkningar) innan mitigering sker.
Rate limiting sätter tak för hur många förfrågningar en klient (eller ett token) kan göra inom ett tidsfönster så att en källa inte konsumerar oproportionerligt mycket resurser.
Vanliga edge‑användningsfall inkluderar:
Det löser inte alla DDoS‑scenarier, men är en stark och lättförklarad kontroll mot missbruksspikar.
En WAF inspekterar HTTP‑förfrågningar och applicerar regler för att blockera vanliga applikationsattacker (som SQLi och XSS). Bot‑hantering fokuserar på att identifiera och hantera automatiserad trafik—både goda bots (t.ex. sökmotorer) och skadliga (scraping, falska kontoregistreringar, credential stuffing).
Ett praktiskt införande är:
Zero Trust innebär att åtkomstbeslut baseras på identitet och kontext, inte på att vara “inne i nätverket”. Vid edge ser det ofta ut så här:
Ett vanligt misstag är att behandla det som en enkel VPN‑ersättning utan att skärpa behörigheter, sessionstid och enhetstester—det är dessa som gör modellen säkrare över tid.