Wat is een CDN, en hoe content delivery networks werken
Kort antwoord
Een CDN, content delivery network, is een set caching-servers verspreid over veel locaties die een kopie van je content leveren vanaf de locatie die het dichtst bij de bezoeker staat, in plaats van dat elke bezoeker die content ophaalt bij je ene origin-server. Dat verkort de laadtijd voor de bezoeker en verlaagt de belasting die je origin-server moet verwerken.
Origin vs. edge
Je origin is de server die de echte, gezaghebbende kopie van je content bevat: degene waar je naartoe uploadt en die je bijwerkt. Een CDN plaatst een laag edge-servers, ook wel edge nodes of points of presence genoemd, voor die origin, verspreid over veel geografische locaties. Vraagt een bezoeker iets op, dan gaat het verzoek naar de dichtstbijzijnde edge node in plaats van helemaal naar de origin. Heeft die edge node al een gecachete kopie, dan levert hij die direct. Zo niet, dan haalt hij de content één keer op bij de origin, levert hem, en cachet hem voor de volgende bezoeker in die regio.
Het effect is tweeledig. Bezoekers krijgen content van een server die fysiek dichterbij staat, wat meestal minder netwerklatency en een snellere laadtijd betekent. En de origin-server hoeft elk stuk content maar af en toe te serveren, om edge-caches te verversen, in plaats van bij elk afzonderlijk bezoekersverzoek. Dat vermindert de belasting en bandbreedte die hij rechtstreeks moet afhandelen.
Wat is eigenlijk cachebaar
Niet alles profiteert evenveel van een CDN. Statische assets, afbeeldingen, CSS, JavaScript, video, downloadbare bestanden, zijn de duidelijkste match: dezelfde bytes gaan naar elke bezoeker, dus cachen op de edge is eenvoudig en de cache blijft geldig tot het bestand zelf verandert.
Dynamische of gepersonaliseerde content is een ander verhaal. Een pagina die voor elke bezoeker anders is, bijvoorbeeld met accountgegevens of een gepersonaliseerde feed, is over het algemeen niet veilig om zomaar te cachen: dan loop je het risico dat de privécontent van de ene bezoeker bij een andere terechtkomt. Dat betekent niet dat dynamische content nooit achter een CDN kan staan, maar het vraagt om bewuste cacheregels, zoals cachen per gebruiker of sessie, korte verlooptijden, of bepaalde paden helemaal uitsluiten, in plaats van het standaardgedrag om alles te cachen dat prima werkt voor statische assets.
Cache-invalidatie en purging
Gecachete content blijft niet voor altijd accuraat als de origin verandert. Elke gecachete kopie heeft een verlooptijd, bepaald door hoe lang de CDN is verteld om hem te bewaren. Zodra die verlooptijd voorbij is, haalt de edge node bij de eerstvolgende opvraging een verse kopie op bij de origin. Dat werkt prima wanneer een vertraging van minuten of uren tussen het bijwerken van de origin en het moment dat bezoekers de update zien, acceptabel is.
Is dat niet acceptabel, dan is purging (ook wel cache-invalidatie genoemd) het alternatief: een expliciete instructie aan de CDN om een specifieke gecachete kopie direct te verwijderen, in plaats van te wachten tot hij vanzelf verloopt. Dit is vooral belangrijk voor content die verandert volgens een schema dat je niet van tevoren bepaalt: je publiceert een update en die moet meteen zichtbaar zijn, in plaats van pas wanneer de oude gecachete kopie toevallig verloopt.