Med mer än 12 000 servrar i över 1000 nätverk bekämpar Akamais distribuerade innehållsleveranssystem flaskhalsar och avstängningar genom att leverera innehåll från Internets kant. s webbplatser blir populära, de blir alltmer sårbara för flash crowd problem, där begära belastning överväldigar någon aspekt av webbplatsens infrastruktur, såsom frontend webbserver, nätverksutrustning, eller bandbredd, eller (på mer avancerade webbplatser) back-end transaktion-behandling infrastruktur. Den resulterande överbelastningen kan krascha en webbplats eller orsaka ovanligt höga svarstider - som båda kan översättas till förlorade intäkter eller negativa kundattityder mot en produkt eller varumärke. Vårt företag, Akamai Technologies, utvecklades ur en MIT forskning som syftar till att lösa problemet flash crowd (www.akamai.com/sv/html/about/historia.html). Vår strategi bygger på observationen att servering av webbinnehåll från en enda plats kan innebära allvarliga problem för webbplats skalbarhet, tillförlitlighet och prestanda. På så sätt skapade vi ett system för att betjäna förfrågningar från ett variabelt antal surrogatservrar vid nätverkskanten. 1 Genom att cacha innehåll vid Internets kant, minskar vi efterfrågan på webbplatsens infrastruktur och ger snabbare service för användare, vars innehåll kommer från närliggande servrar. När vi lanserade Akamai-systemet i början av 1999 levererade det endast webbobjekt (bilder och dokument). Det har sedan dess utvecklats för att distribuera dynamiskt genererade sidor och även applikationer till nätverkets kant, vilket ger kunderna med on-demand bandbredd och beräkna kapacitet. Detta minskar innehållsleverantörernas infrastrukturkrav och gör det möjligt för dem att distribuera eller utöka tjänster snabbare och enklare. Vårt nuvarande system har mer än 12.000 servrar i över 1000 nätverk. Operativa servrar på många platser innebär många tekniska utmaningar, inklusive hur man riktar användarens begäran till lämpliga servrar, hur man hanterar fel, hur man övervakar och kontrollerar servrarna, och hur man uppdaterar programvara över hela sys-tem. Här beskriver vi vårt system och hur vi har hanterat dessa utmaningar. Forskare har utforskat flera sätt att leverera innehåll på ett skalbart och tillförlitligt sätt. Lokal klusterbildning kan förbättra feltolerans och skalbarhet. Om det datacenter eller den Internetleverantör som tillhandahåller anslutning misslyckas, dock hela kluster är otillgänglig för användare. För att lösa detta problem, webbplatser kan erbjuda spegling (deploying kluster på några platser) och multihoming (med hjälp av flera Internetleverantörer för att ansluta till Internet). Clustering, spegling och multihoming är vanliga metoder för platser med stränga tillförlitlighet och skalbarhet behov. Dessa metoder löser dock inte alla konnektivitetsproblem, och de introducerar nya: I Det är svårt att skala kluster till tusentals servrar. I Med multihoming, de underliggande nätverksprotokoll - särskilt gräns gateway protokoll (BGP) 2 - inte konvergera snabbt till nya vägar när anslutningar misslyckas. I Spegeling kräver att webbplatsen synkroniseras bland speglarna, vilket kan vara svårt. I samtliga tre fall krävs överkapacitet: Med kluster måste det finnas tillräckligt många servrar på varje plats för att hantera toppbelastningar (vilket kan vara en storleksordning över genomsnittliga belastningar); med multihoming måste varje anslutning kunna bära hela trafiken; och med spegelbildning måste varje spegel kunna bära hela lasten. Var och en av dessa lösningar medför således en avsevärd kostnad, som mer än fördubblar en anläggnings initiala infrastrukturkostnader och löpande driftskostnader. Internet är ett komplext nätverk. Trängsel och misslyckanden förekommer på många olika platser, inklusive jag "första milen" (som delvis åtgärdas genom multihoming ursprungsservern), I ryggraden, Jag peering punkter mellan nätverksleverantörer, och jag "sista milen" till användaren. Genom att använda oberoende proxycache över hela Internet kan man ta itu med vissa av dessa flaskhalsar. Transit-Internetleverantörer och slutanvändarorganisationer har installerat proxycaches för att minska latens- och bandbreddskrav genom att betjäna användare direkt från en tidigare efterfrågad innehållscache. Men, Web proxy cache träffhastigheter tenderar att vara låg -25 till 40 procent - delvis eftersom webbplatser använder mer dynamiskt innehåll. Som ett resultat, proxy caches har haft begränsad framgång i att förbättra webbplatsernas skalbarhet, tillförlitlighet och prestanda. Akamai har ett nära samarbete med innehållsleverantörer för att utveckla funktioner som förbättrar servicen för deras webbplatser och för att leverera mer innehåll från nätverkskanten. Till exempel, funktioner som tillstånd, kontroll över innehåll ogiltighet, och dynamisk innehåll montering kan vi leverera innehåll som annars skulle vara ogenomförbar. Även ISP caches kan innehålla liknande funktioner, för att vara användbara skulle de vara tvungna att standardisera funktioner och deras genomförande över de flesta cache leverantörer och distributioner. Fram till dess att en sådan funktion används i stor utsträckning har innehållsleverantörerna föga incitament att använda den. Eftersom Akamai kontrollerar både sitt nätverk och sin mjukvara kan vi snabbt utveckla och distribuera funktioner. Akamais infrastruktur hanterar flashpubliker genom att tilldela fler servrar till webbplatser som upplever hög belastning, samtidigt som den betjänar alla kunder från närliggande servrar. Systemet leder klientförfrågningar till närmaste tillgängliga server som sannolikt har det begärda innehållet. Den bestämmer detta enligt följande: I Nearest är en funktion av nätverk topologi och dynamiska länkegenskaper: En server med en lägre tur och retur tid anses närmare än en med en högre tur och retur tid. På samma sätt är en server med låg paketförlust för klienten närmare än en med hög paketförlust. I Tillgänglig är en funktion av belastning och nätverksbandbredd: En server som har för mycket last eller ett datacenter som tjänar nära sin bandbreddskapacitet är inte tillgänglig för att betjäna fler kunder. I Sannolikt är en funktion av vilka servrar bär innehållet för varje kund i ett datacenter: Om alla servrar servers allt innehåll - av roundrobin DNS, till exempel - då servrarnas disk och minnesresurser skulle konsumeras av den mest populära uppsättningen av objekt. I det senare fallet, en Akamai webbplats kan hålla ett dussin eller fler servrar inom något datacenter; systemet distribuerar innehåll till det minsta antalet servrar på varje plats för att maximera systemresurser inom webbplatsen. Riktningen för förfrågningar till innehållsservrar kallas kartläggning. Akamais kartläggning tech- Content Delivery nologi använder ett dynamiskt, feltolerant DNS-system. Karteringssystemet löser ett värdnamn baserat på den begärda tjänsten, användarens plats och nätverksstatus; det använder även DNS för nätbelastningsbalansering. Sidofältet "DNS-upplösning" beskriver den vanliga DNS-upplösningsprocessen för ett Akamai edge servernamn, vilket motsvarar steg 1 och 2 i figur 1. I steg 3 gör kunden en HTTP-begäran till egg-servern, som sedan hämtar innehållet genom att begära det antingen från en annan Akamai-server (steg 4) eller innehållsleverantörens server (steg 5). Servern returnerar sedan den begärda informationen till klienten och loggar begärans färdigställande. Akamai namnservrar lösa värdnamn till IP-adresser genom att mappa förfrågningar till en server med hjälp av några eller alla av följande kriterier. Jag servar begärd. Servern måste kunna uppfylla begäran. Namnservern får inte rikta en begäran om en QuickTime-mediaström till en server som endast hanterar HTTP. Jag servar hälsa. Innehållsservern måste vara igång utan fel. Jag servar lastar. Servern måste fungera under en viss belastningströskel och därmed vara tillgänglig för ytterligare förfrågningar. Belastningsmåttet inkluderar normalt målserverns CPU, disk och nätverksanvändning. I Nätverkskondition. Kunden måste kunna nå servern med minimal paketförlust, och serverns datacenter måste ha tillräcklig bandbredd för att hantera ytterligare nätverksförfrågningar. Jag klientens plats. Servern måste vara nära kunden när det gäller åtgärder som nätverk tur och retur. Jag ville ha mitt innehåll. Servern måste sannolikt ha innehållet, enligt Akamais konsekventa hash-algoritm. Internetroutrar använder BGP-meddelanden för att utbyta information om nättillgänglighet mellan BGP-system och beräkna den bästa ruttvägen bland Internets autonoma system. 2 Akamai agenter kommunicerar med vissa gräns routrar som jämlikar; karteringssystemet använder den resulterande BGP information för att bestämma nätverket topologi. Antalet humle mellan autonoma system är ett grovt men användbart mått på nätavstånd. Kartläggningssystemet kombinerar denna information med statistik över levande nät – som t.ex. spårvägsdata 3 – för att ge en detaljerad, dynamisk bild av nätverksstruktur och kvalitetsåtgärder för olika kartläggningar. Att genomföra detta kartläggningssystem i global skala innebär flera utmaningar, som vi diskuterar senare. Vårt DNS-baserade lastbalanseringssystem övervakar kontinuerligt tjänsternas tillstånd samt deras servrar och nätverk. Var och en av innehållsservrarna - för HTTP, HTTPS och strömmande protokoll - rapporterar ofta sin last till en övervakningsprogram, som aggregerar och publicerar lastrapporter till den lokala DNS-servern. Den DNS-servern bestämmer sedan vilka IP-adresser (två eller fler) som ska returneras när DNS-namn löses. Om en servers belastning överstiger en viss tröskel, tilldelar DNS-servern samtidigt en del av serverns tilldelade innehåll till ytterligare servrar. Om belastningen överstiger ett annat tröskelvärde är serverns IP-adress inte längre tillgänglig för kunder. Servern kan därmed kasta en bråkdel av sin last när den upplever måttlig till hög belastning. Övervakningssystemet överför också data center belastning till toppnivå DNS resolver för att styra trafiken bort från överbelastade datacenter. För att övervaka hela systemets hälsa end-to-end använder Akamai agenter som simulerar slutanvändarnas beteende genom att ladda ner webbobjekt och mäta deras felfrekvenser och nedladdningstider. Akamai använder denna information för att övervaka systemets övergripande prestanda och för att automatiskt upptäcka och stänga av problematiska datacenter eller servrar. Förutom belastningsbalansering ger Akamais övervakningssystem centraliserad rapportering om innehållstjänst för varje kund och innehållsserver. Denna information är grunden för Akamai realtid kundtrafik analysator ansökan. Informationen är användbar för nätverksdrift och diagnostiska ändamål, och ger tillgång i realtid till en rad tjänsteparametrar organiserade som en databas. Programmets SQL-liknande gränssnitt stöder ad-hoc-frågor mot levande och historiska data, som låter operationspersonalen lokalisera den mest trafikerade kunden, servern använder mest minne eller diskutrymme, eller switchen eller datacenter närmast sin bandbredd gräns. Akamai servrar levererar flera typer av innehåll: statiskt och dynamiskt innehåll över HTTP och HTTPS, och strömmande ljud och video över de tre streaming protokoll som beskrivs nedan. Statisk webbinnehåll består av HTML-sidor, inbäddade bilder, körbara filer, PDF-dokument och så vidare. Akamais innehållsservrar använder innehållstyp för att tillämpa livstid och andra funktioner på statiska dokument, som har varierande cachebarhet och kan ha särskilda servicekrav. Livstiderna kan till exempel variera från noll sekunder, där eggservern validerar objektet med ursprungsservern på varje begäran, till oändlig, där innehållsservern aldrig kontrollerar objektets konsistens. Livstidsvärden för Akamai edge servrar kan också skilja sig från nedströms proxyservrar och slutanvändare. Särskilda funktioner kan inkludera möjligheten att tjäna säkert innehåll via HTTPS-protokollet, stödja alternativt innehåll och överföringskodningar, hantera cookies och så vidare. Akamai kontrollerar funktioner för varje kunds räkning med hjälp av en metadataanläggning som beskriver vilka funktioner som ska tillämpas av kunden, innehållstyp och andra kriterier. Dagens webbplatser är starkt beroende av dynamisk innehållsgenerering för att erbjuda slutanvändare rika och fängslande material. Som vi noterade tidigare, dock, proxy caches kan normalt cache dynamiskt innehåll. En proxycache kunde till exempel inte hantera en i stort sett statisk webbsida om den innehöll en annons som ändrades enligt varje användares profil. För att hantera detta använder vi Edge Side Inkluderar teknik (www.esi.org), som monterar dynamiskt innehåll på kantservrar. ESI liknar serversidan inkluderar språk, men lägger till feltoleransfunktioner (för när ursprungsservern inte är tillgänglig) och integrerar en omfattande stilmall Language Transformation (XSLT) motor för att behandla XML-data. Med hjälp av ESI kan en innehållsleverantör bryta en dynamisk sida i fragment med oberoende cacheability egenskaper. Dessa fragment underhålls som separata objekt i kantserverns cache och monteras dynamiskt på webbsidor som svar på användarens önskemål. Förmågan att montera dynamiska sidor från enskilda sidfragment innebär att servern endast får hämta icke-cachebara eller utgångna fragment från webbplatsens ursprung. Detta minskar både belastningen på webbplatsens infrastruktur för innehållsgenerering och de data som eggservern måste hämta från den centrala ursprungsservern. ESI reducerad bandbredd Innehåll Leverans Akamai edge servrar finns med hjälp av ett DNS-namn, såsom a7.g.akamai.net.En DNS-upplösning löser detta namn på det vanliga sättet, från höger till vänster, fråga DNS-namn servrar till IP-adresser för värd a7 i domänen.g.akamai.net returneras. Varje namn resolution associerar en "tid att leva" (TTL) med resolutionen, som fortskrider enligt följande: 1. Upplösaren väljer en rotnamnsserver och ber den att lösa namnet a1.g.akamai.net.Rootnamnsservern själv löser inte namnet, utan skickar istället ett domändelegeringssvar med IP-adresser till namnservrarna som hanterar.net-domänförfrågningar. 2. Utgångspunkten är följande: Upplösaren frågar sedan.net-namnservrarna, som returnerar en domändelegation (NS-poster) för.akamai.net. Dessa är Akamai toppnivå namnservrar (top-level DNS i Figur 1 ). 3. Vad är det som händer? Därefter frågar resolver en Akamai TL DNS-server, som returnerar en domändelegation för.g.akamai.net till låg nivå Akamai namnservrar (LL NS i Figur 1 ) med en TTL på cirka en timme.De lågnivånamn servrar som väljs motsvarar (och är på samma plats som) de tillgängliga kantservrar som är närmast den begärande användaren. 4. Vad är det som händer? Slutligen, löseren frågar en Akamai lågnivå DNS-server, som returnerar IP-adresser för servrar tillgängliga för att uppfylla begäran.Denna resolution har en kort TTL (flera sekunder till en minut), som uppmuntrar frekventa uppdateringar av DNS-upplösningen och tillåter Akamai att rikta förfrågningar till andra platser eller servrar som villkor ändras. En upplösning är förkonfigurerad för att veta Internet rotnamn servrar IP-adresser, som är utgångspunkterna för en DNS-upplösning om upplösningen saknar nödvändig information i sin cache. Om upplösningen har giltiga IP-adresser för.net-namnservern, hoppar den över steg 1; om den har cacheade IP-adresser för g.akamai.net-namnservrarna, hoppar den över steg 1 till 3. Upplösningsprocessen är densamma för alla DNS-namn. Akamai namn-upplösning skiljer sig dock i hur dess namn servrar beter sig. krav på dynamiskt innehåll med 95 till 99 procent på en rad dynamiska webbplatser vi studerat, inklusive portaler och finansiella webbplatser. Minskningen av den centrala infrastrukturen innebär betydande besparingar för innehållsleverantörerna. Akamais streamingnätverk stöder live- och ondemand-media i de tre stora formatenMicrosoft Windows Media, Real och Apples QuickTime. Samtidigt bygga ett strömmande leveransnätverk presenterar några tekniska frågor som liknar dem i ett webbleveransnätverk, det finns också betydande ytterligare utmaningar. För det första fångar och kodar innehållsleverantören vanligtvis en liveström och skickar den till en ingångsserver i Akamai-nätverket. Med tanke på vår princip om att ta bort alla enskilda felpunkter måste vi ha mekanismer som snabbt kommer att reagera på en misslyckad ingångspunktsserver. Specifikt, en annan entry-point server måste plocka upp live-strömmen tillräckligt snabbt att slutanvändaren upptäcker inget avbrott i strömmen. Strömmen levereras från entry-point server till flera edge servrar, som i sin tur tjänar innehållet till slutanvändare. Mediapaketleverans från ingångspunkten till kantservrarna måste vara motståndskraftig mot nätverksfel och paketförlust, och därför måste ingångspunktens server dirigera paketflöden runt överbelastade och misslyckade länkar för att nå kantservern. Dessutom måste ingångs- och kantservrar leverera paket utan betydande dröjsmål eller jitter eftersom ett sent eller out-of-order-paket är värdelöst i uppspelningen. Vid behov använder Akamai informationsspridningstekniker som låter ingångspunktens server skicka data på flera redundanta sökvägar, som låter kantservern skapa en ren kopia av strömmen även när vissa sökvägar är nere eller förlorade. Vanligtvis laddar en innehållsleverantör upp ett ondemand klipp till en Akamai innehållslagringsanläggning. Vi distribuerar lagringsanläggningen över många datacenter och kopierar automatiskt det uppladdade klippet till en delmängd av centrumen. En kantserver som tar emot en strömförfrågan laddar ner innehållet från sin optimala lagringsplats och cachar det lokalt medan den betjänar begäran. Att bygga ett globalt nätverk innebär många icke-tekniska utmaningar, bland annat utbyggnad av nätverksutrustning och serverhårdvara, upprättande av goda arbetsrelationer med nätverksleverantörer, kontroll av driftskostnader och förvärv och stöd till kunder. Även om dessa utmaningar är betydande fokuserar vi här på utmaningar relaterade till design, byggande och drift av själva systemet. Akamais nätverk måste skalas för att stödja många geografiskt distribuerade servrar, och många kunder med olika behov. Detta innebär följande utmaningar. I Övervakning och kontroll tiotusentals allmänt distribuerade servrar, samtidigt som övervakning bandbredd till ett minimum. Jag övervakar nätverksförhållandena över och mellan tusentals platser, samlar denna information, och använder den för att generera nya kartor med några sekunder. Framgång här beror på att minimera overhead läggs till DNS för att undvika långa DNS uppslagningstider; Detta låter oss utföra de beräkningar som krävs för att identifiera den optimala servern off-line, snarare än att låta användaren vänta. Jag handlar graciöst med ofullständig och föråldrad information. Detta kräver noggrann design och iterativ algoritm tuning. Jag reagerar snabbt på ändrade nätverksförhållanden och ändrade arbetsbelastningar. I Mäta Internet villkor på en fin nog granularitet för att uppnå hög sannolikhet uppskattningar av slutanvändarens prestanda. I Hantera, tillhandahålla och lösa problem för många kunder med varierande behov, varierande arbetsbelastning och varierande mängd innehåll. Jag isolerar kunder så att de inte kan påverka varandra negativt. Jag säkerställer dataintegritet över många terabyte av lagring över nätverket. Eftersom låga nivåer (filsystem eller disk) kontroller är otillräckliga för att skydda mot eventuella fel - inklusive de som orsakas av operatörer och programvara buggar vi också utföra end-to-end kontroller. I Samla in loggar med information om användarförfrågningar, behandla dessa loggar (för fakturering), och leverera korrekt, snabb fakturering information till kunder. För att möta utmaningarna med att övervaka och kontrollera innehållsservrar utvecklade Akamai en distribuerad övervakningstjänst som är motståndskraftig mot tillfällig informationsförlust. För att lösa problem för kunderna har Akamai kundfokuserade team som diagnostiserar problem och tillhandahåller faktureringstjänster.  Systemtillförlitlighet Ett distribuerat system erbjuder många möjligheter till feltolerans, men introducerar också många komponenter som kan misslyckas. Detta är delvis ett skalproblem: Systemfel måste upptäckas och korrigeras över flera mjukvaruplattformar. Det är också oundvikligt att dator hårdvara kommer att åldras, särskilt diskar och andra rörliga delar. Som ett stort nätverk utrustning åldrar, en bråkdel av enheterna kommer att misslyckas varje månad. Nätverkspersonalen måste upptäcka fel på ett tillförlitligt sätt och snabbt ta bort enheter från tjänsten så att de kan skickas till ett lager och kanske repareras och återföras till service. Akamais övervaknings- och karteringsprogram säkerställer att server- eller nätverksfel inte påverkar slutanvändare, och DNS-systemet upptäcker fel snabbt och omedelbart delar ut nya IP-adresser. För kunder som fortfarande använder cached DNS-svar, två mekanismer hjälper till att förhindra överbelastning: DNS-upplösningen kan returnera flera IP-adresser, så att klienten kan prova en annan adress, eller en liveserver på webbplatsen kan anta den misslyckade serverns IP-adress. För att förhindra problem när nätverksfel gör webbplatser oåtkomliga (på grund av router och byta problem, till exempel), kommer toppnivå (TL) DNS identifiera lokala DNS-servrar på olika webbplatser för att säkerställa att kunderna kan nå en live DNS-server. För att undvika avbrott måste vi också noga undvika enstaka brister i hela systemet. Våra kantservrar ger massiv replikering för leverans av innehåll och DNS-förfrågan. Vi undviker också enstaka felpunkter genom att replikera övervaknings- och kontrollmekanismer. Slutligen måste vi upptäcka och reparera programvarubrister. En viktig utmaning i webbinnehållstjänsten är att klientförfrågningar och serversvar inte är statiska -nya förfrågan och svarsrubriker regelbundet visas som leverantörer förbättra sina webbläsare och servrar, och kantservrar måste tolka dessa förändringar korrekt och effektivt. Eftersom sådana förbättringar kan komma när som helst, är det omöjligt att testa nya versioner på alla relevanta webbläsar- och innehållsserver-versioner; testa innehållsserver funktioner med den översta webbläsaren och innehållsserver konfigurationer ensam skapar en mycket komplex testmatris. För att möta denna utmaning skapade vi ett testverktyg som leder en kopia av en liveservers trafik till en testversion av vår programvara utan att påverka innehållstjänsten. Denna verkliga trafik gör det möjligt för oss att hitta problem innan programvara distribueras till live-nätverket. Förutom att utöka nätverkets storlek och omfattning måste mjukvaran utvecklas med nya funktioner för kunderna, förbättrad prestanda samt bättre drift- och övervakningskapacitet. För att möta denna utmaning måste vi distribuera högkvalitativ programvara till servrar på många nätverk, ibland snabbt för att anpassa en snabb affärsmodell till marknaden. Vi kan inte uppgradera mjukvaran på hela nätverket atomiskt. Om inget annat, försiktighet dikterar att vi distribuerar nya nätverk programvara i etapper så att vi kan upptäcka problem innan de har betydande inverkan. Dessutom är det osannolikt att alla kantservrar (eller till och med alla nätverk) kommer att vara tillgängliga samtidigt. Det är oundvikligt att vi missar några servrar och måste uppdatera dem vid ett senare tillfälle. Som ett resultat är det mer regel än undantaget att ha två versioner av en programvarukomponent live på nätverket samtidigt. Med tanke på detta måste vi skriva komponenter så att olika versioner kan samexistera och noggrant hantera ändringar i komponentgränssnitt. Nätverksverksamheten måste kontinuerligt övervaka nätverket och stänga av alla felaktigt inställda servrar. Servererna i Akamai-nätverket körs på operativsystemen Linux och Windows. Drift av flera OS-plattformar och -tjänster kräver en övervakningsplattform och verktyg som körs över dessa plattformar och har tillgång till servrarnas parametrar för leverans av tjänster. Denna information krävs för lastbalansering (lokal och global) samt för att stödja problemdiagnos för verksamhet och kundvård. Slutligen, att köra flera plattformar och applikationer kräver expertis på alla plattformar och servrar som stöds. Akamais nätverk distribuerar och betjänar innehåll för leverantörer, som måste behålla kontrollen över sitt innehåll när vi tjänar det vid kanten, och se information i realtid om vilket innehåll som serveras till vem och när. Att tillhandahålla denna synlighet och innehållskontroll erbjuder utmaningar i cachekonsistens, livstids- och integritetskontroll och flera andra områden. Cache-konsistens. När objekt som kantservrarna levererar är cachebara, måste vi ta itu med konsekvensen av cachet innehåll; när de är ocachebara, hög prestanda leverans är en utmaning. För att ta itu med cacheable-objekt-konsistens använder innehållsleverantörer ofta etablerade tekniker, såsom att tillämpa en "time to live" (TTL) på objekt. Vissa objekt kan vara cachebara för alltid, eller åtminstone tills de uttryckligen tas bort av en cachekontrollverktyg (för mer om detta, se "Lifetime Control" sek- IEEE INTERNET COMPUTING
Akamai REF och andra kommersiella CDNs använder DNS-omdirigering för att omdirigera kundförfrågningar till lokala kluster av maskiner genom att bygga detaljerade kartor över Internet genom en kombination av BGP-flöden och deras egna mätningar.
Globally Distributed Content Delivery
{'venue': 'IEEE Internet Computing', 'journal': None, 'mag_field_of_study': ['Computer Science']}