# CDN ## Vad det är Ett CDN är en flotta av maskiner utspridda över många städer, som står mellan läsarna och den server där en webbplats faktiskt körs, ursprungsservern, och lämnar ut kopior av det som ursprungsservern publicerar. Förkortningen står för content delivery network, och på svenska kallas samma sak ibland innehållsnätverk eller innehållsleveransnätverk. En läsare i Sydney som ber om en sida vars ursprungsserver står i Toronto får den från en maskin i eller nära Sydney, och begäran behöver kanske aldrig korsa Stilla havet. Två mekanismer styr varje läsare till en server i närheten. Vissa nätverk ger olika DNS-svar beroende på var frågan kommer ifrån. Andra annonserar samma IP-adress från varje plats och låter internets routning bära varje paket till den närmaste. Hur det än går till avslutar servern som svarar oftast TLS för webbplatsens räkning. Den har alltså ett certifikat för domänen och läser varje begäran i klartext innan den bestämmer vad den ska göra med den. Det som händer sedan är jobbet för en delad cache. Har den redan en färsk kopia svarar den direkt, och det kallas en träff. Har den ingen hämtar den svaret från ursprungsservern, behåller en kopia och svarar, och det kallas en miss. Hur länge en kopia räknas som färsk är ursprungsserverns beslut, och det står i svarshuvuden som standarden för HTTP-cachning definierar: ```text # En stilmall med fingeravtryck: ändras aldrig under det här namnet. Cache-Control: public, max-age=31536000, immutable # En sida: webbläsare frågar varje gång, CDN:et behåller den tio minuter. Cache-Control: no-cache CDN-Cache-Control: max-age=600 # En kontosida: ingen cache får behålla en kopia. Cache-Control: private, no-store ``` `max-age` anger en livslängd i sekunder. `immutable` säger åt webbläsaren att inte validera svaret på nytt under den tiden. `no-cache` låter en cache lagra ett svar men tvingar den att stämma av med ursprungsservern innan svaret återanvänds, medan `private` håller svaret borta från delade cachar helt och hållet. `CDN-Cache-Control` läses bara av CDN:er, så en webbplats kan låta kanten, alltså nätverkets servrar närmast läsarna, behålla en sida längre än webbläsarna gör. Samma maskineri bär numera mycket mer än statiska filer. De flesta CDN:er fungerar också som proxy för begäranden som inte går att cacha och skickar dem vidare till ursprungsservern, tar emot flodvågor av fientlig trafik och kör små program vid kanten. Därför täcker ordet ett brett spektrum av tjänster, som alla utgår från samma idé: att servera kopior nära läsaren. ## Varför det spelar roll Avstånd kostar latens som ingen trimning av servern kan vinna tillbaka. Ljus i fiber färdas ungefär tvåhundra kilometer per millisekund, så en tur och retur mellan Europa och Australien tar en bra bit över hundra millisekunder innan någon server har gjort något arbete alls, och en ny säker anslutning lägger en eller två sådana rundor på att komma igång innan den första begäran ens skickas. Att servera från en kopia i närheten tar bort det mesta av den väntan för varje läsare som befinner sig långt från ursprungsservern. Last är det andra skälet. När de flesta begäranden är träffar ser ursprungsservern bara en liten del av trafiken, och en plötslig topp landar på ett nätverk som är byggt för toppar i stället för på en enda maskin. Med `stale-if-error` kan kanten fortsätta servera den senaste fungerande kopian medan ursprungsservern ligger nere, så att ett kort avbrott förblir osynligt för många läsare. Kostnaden är mindre uppenbar än fakturan. Ett CDN framför en webbplats är ytterligare ett företag mitt i varje besök. Det ser varje läsares IP-adress, varje URL som läsaren begär och, eftersom det avslutar TLS, innehållet i hela utbytet, och det hanterar allt detta enligt sin egen policy. Det är också ett delat beroende: när en stor leverantör har en dålig timme har tusentals webbplatser som inte har något med varandra att göra den dåliga timmen tillsammans. Det gamla argumentet för att ladda bibliotek och typsnitt från ett populärt publikt CDN har också försvagats. Webbläsare håller numera en separat cache för varje webbplats, så en fil som hämtats för en webbplats hämtas på nytt för nästa, och den delade kopian för med sig en begäran till en tredje part utan någon cachevinst att visa upp. En webbplats vars läsare mest finns i en region, och som serveras från en snabb maskin i just den regionen, behöver kanske helt enkelt inget CDN. En webbplats med en världsvid publik, tunga medier eller trafik som kommer i skurar behöver oftast ett. ## Så ser det ut i praktiken På den här webbplatsen avgjordes frågan om CDN genom att prova ett och stänga av det igen. Företagets arbete med DNS dokumenterar att [proxning av de två publika webbplatserna genom leverantörens innehållsnätverk](/sv/portfolio/reconciled-a-dns-zone-declaratively-118/) byggdes, fungerade och sedan stängdes av. Med proxyn på plats hanterade ett annat företag varje besökares adress och varje URL som besökaren bad om, innan webbplatsen själv gjorde det och enligt det företagets policy i stället för den här webbplatsens. För en verksamhet vars utmärkande påstående är att ingen tittar bedömer sidan det som ett sämre byte än de attacker som proxyn skyddar mot, och resonemanget är nedskrivet så att ingen öppnar frågan igen av misstag. Samma hållning syns i vad sidorna laddar. Kolofonen räknar upp de fem sorters filer som når en läsares webbläsare och förklarar varför typsnitten kommer från webbplatsens egen maskin: [ett webbtypsnitt från någon annans CDN är en tredje part som ser dig läsa](/sv/credits/). Cloudflare besvarar webbplatsens DNS och gör ingenting mer, webbplatsen går medvetet inte via deras proxy, och en läsare som öppnar webbläsarens nätverkspanel räknar en enda värd. Där ett CDN gör nytta säger anteckningarna det. Anteckningen om blixtreor bygger på att [ett nej till köparen måste vara det billigaste svar systemet ger](/sv/notes/selling-limited-stock-without-overselling/). Med en miljon köpare och tiotusen enheter måste 990 000 begäranden misslyckas. Bland sätten som den räknar upp för att göra sig av med dem tidigt finns ett väntrum, en grind som är dimensionerad efter lagret, en hastighetsbegränsning per konto och en `sold_out`-flagga som CDN:et lämnar ut utan att fråga något som står bakom det. Rådet om lasttester gör samma poäng från andra hållet: när vägen för slutsålt är 99 % av trafiken hör den trafiken hemma vid kanten. ## Var det går fel Kanten gör exakt det som svarshuvudena och dess konfiguration säger, och det är inte alltid det som var meningen. - En annan persons sida serveras till nästa besökare. Ett svar som visar ett konto, en varukorg eller en hälsning cachas eftersom ingenting markerade det som privat. Att sätta en kaka stoppar inte cachningen, vilket standarden för HTTP-cachning påpekar, så nästa läsare får den första läsarens sida. Märk varje svar som är unikt för en användare med `private` eller `no-store`, och be CDN:et gå förbi sin cache när begäran bär en kaka för en session. - En driftsättning hänger på en rensning. Ny HTML går live medan vissa platser i nätverket fortfarande håller den gamla stilmallen, eller tvärtom, och sidorna renderas trasiga tills varje kopia har gått ut. En rensning (purge) tar tid att nå varje plats och fungerar olika hos olika leverantörer. Lägg en hash av innehållet i varje fils namn, cacha de filerna i ett år som `immutable` och låt bara HTML-sidorna leva kort. - Cachenyckeln är fel åt det ena eller det andra hållet. Spårningsparametrar som `utm_source` gör varje delad länk till en egen post i cachen, och träffkvoten rasar. Ett huvud som ändrar svaret, som `Accept-Language`, men som lämnas utanför nyckeln gör att en läsares språk serveras till alla. Ta bort parametrar som ursprungsservern ignorerar, och namnge i `Vary` de huvuden som den läser. - Ett populärt objekt går ut och ursprungsservern dränks. Tusentals läsare missar i samma ögonblick, och varenda en av de begärandena går hela vägen fram. Sammanslagning av begäranden i CDN:et (request collapsing) och `stale-while-revalidate`, som serverar den gamla kopian medan en enda begäran hämtar den nya, håller lasten på ursprungsservern jämn. - Ursprungsservern svarar vem som helst som hittar den. Skyddet vid kanten betyder lite om angripare kan nå ursprungsserverns adress direkt, och gamla DNS-poster, huvuden i e-post eller en bortglömd underdomän röjer den ofta. Ta bara emot trafik på ursprungsservern från CDN:et, filtrerat på nätverkets adressintervall eller genom en autentiserad anslutning. ## Läs mer - [RFC 6707, section 1.1: CDN terminology](https://www.rfc-editor.org/rfc/rfc6707#section-1.1) — definitionerna från IETF av ett CDN, dess surrogatservrar och hur begäranden styrs till dem. - [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111) — vad delade cachar får lagra, hur länge och vad `private` betyder. - [RFC 9213: Targeted HTTP Cache Control](https://www.rfc-editor.org/rfc/rfc9213) — fältet `CDN-Cache-Control`, som bara vänder sig till CDN:er. - [RFC 5861: HTTP Cache-Control Extensions for Stale Content](https://www.rfc-editor.org/rfc/rfc5861) — `stale-while-revalidate` och `stale-if-error`. - [RFC 8246: HTTP Immutable Responses](https://www.rfc-editor.org/rfc/rfc8246) — hur en fil med fingeravtryck slipper bli kontrollerad igen.