Multimediatechnieken Prof. Peter De Neve academiejaar 2004-2005 Contentnetwerken Multimediatechnieken Prof. Peter De Neve academiejaar 2004-2005

Inhoud van de les Het klassieke Internetmodel Data- en contentswitching Contentnetwerken Waarom en voordelen Verschillende types afhankelijk van de eigenaar Netwerkoperatoren Contentleveranciers Gebruikers Case study Akamai

Het klassieke Internetmodel

World Wide Web URL Beperking URL-verwijzing naar pagina bevat altijd verwijzing naar host URL wijst slechts naar 1 host soms wenselijk (vaak geraadpleegde data): gebruik van spiegels ("mirrors") probleem: hoe spiegelversies beheren ? (behoud van dataconsistentie)

Het klassieke Internetmodel - Beschrijving Huidige Internetarchitectuur is gebaseerd op het “end-to-end” principe Om functionaliteit tussen client en server te garanderen moet alles in de hosts worden uitgevoerd, niet in het tussenliggende netwerk Transport- en applicatielaag worden enkel aangesproken in client en server In het netwerk zelf wordt de TCP/IP stack slechts tot op laag 3 opgebouwd (routing)

Data- en contentswitching In deze context beperkt tot de zogenaamde layer 4 en 7 switching

Layer 4 switching – Algemeen principe Layer 4 = transportlaag (TCP of UDP) De switch voert een “content-blind routing” uit, ook wel “immediate binding” genoemd Switch doet zich voor als de eindserver (end-host) bij aankomst van het eerste TCP SYN pakket Switch gebruikt informatie uit de transportlaag om traffiek gericht te switchen/routeren (+ binding table) Efficiënte routering, maar niet voor het dispatchen van content (geen kennis van de HTTP content die de client aanvraagt) In de transportlaag wordt de poort informatie gebruikt om bepaalde applicaties te identificeren (TCP poort 80 voor HTTP, TCP poort 20/21 voor FTP, …)

Layer 4 – TCP connectie

Layer 4 switching – Voorbeeld HTTP FTP server FTP Internet Web server SMTP Layer 4 switch SMTP server HTTP

Layer 7 switching – Algemeen principe Layer 7 = applicatielaag (bv. HTTP) De switch voert een “content-aware routing” uit, ook wel “delayed binding” genoemd Switch doet zich eveneens voor als de eindserver maar zet een complete TCP-connectie op met client (3-way handshake) Client pakketten worden door de switch dus ontleed tot in de applicatielaag en dan afgeleid naar server Minder snelle routering wegens ontleding tot op layer 7 Uitstekende kennis voor het dispatchen van content want kennis van de HTTP content die de client aanvraagt

Layer 7 – TCP connectie

Layer 7 switching – Voorbeeld http://news.site.org Web server sports.site.org http://sports.site.org Internet Web server news.site.org Layer 7 web switch IP: 212.100.190.238 http://www.site.org http://news.site.org Web server www.site.org In DNS (voorbeeld) 212.100.190.238 A sports.site.org 212.100.190.238 A news.site.org 212.100.190.238 A www.site.org

Contentswitching apparatuur Vaak wordt er geen onderscheid gemaakt in “Layer 4” and “Layer 7” switches omdat de meeste apparatuur beide aankan Deze switches worden “contentswitches” genoemd Ook aangeduid als “Layer 4-7 switches” De pioniers in content switches Nortel Networks (Alteon WebSystems) Cisco Systems F5 Networks Foundry networks Extreme Networks Connectiviteit op basis van Ethernet poorten, deze switches bevatten typsich geen interfaces om WAN technologie connecties te termineren ATM, G.SHDSL, E1, MFE1, ...

Contentnetwerken

Contentnetwerken Laatste jaren: groeiende interesse Diverse systemen en technologieën mogelijk Hebben allemaal het volgende doel Mogelijkheid om gebruikers toegang te verlenen tot bepaalde objecten op een locatie-onafhankelijke manier Betekent een fundamenteel verschillende manier van communicatie op het Internet URL’s zijn niet geschikt om objecten te identificeren die op verschillende locaties in het netwerk beschikbaar zijn Objecten op verschillende locaties publiceren door replicatie van data

Motivatie Oplossing vinden voor opstoppingen (congestion) van IP-lijnen (vooral accesslijnen) op het Internet Webservers raken soms overbelast door een overvloed aan requests Directe communicatie met de originele servers kan resulteren in bepaalde vertragingen Bescherming tegen “flash crowds” : vaak is content heel populair op een korte tijdspanne Bv. Verkiezingsuitslagen, film trailers, breaking news, 9/11, Columbia accident, … Noodzaak om content te distribueren op basis van geografische locatie Voorbeeld: CNN specifieke servers in Europa voor het Europese nieuws, specifieke servers in US voor het lokale (domestic) nieuws

Er zijn vier mogelijke punten van opstopping (congestion) op het Internet Internet acceslijn gebruiker Het netwerk van een ISP (backbone) Peering punten (interconnecties tussen ISP’s) Internet acceslijn en belasting web server ISP3 4 3 ISP1 3 2 1 web server ISP2 Gebruiker

1. Internet toegangslijn van de gebruiker Diverse technologieën voor toegang (access) Dial-up, xDSL, kabelmodem, gehuurde lijnen Fysische drager kan sterk verschillen (koper, glasvezel, …) Diverse capaciteiten zijn beschikbaar Al dan niet gegarandeerd met een Service Level Agreement (SLA) Al dan niet verschil tussen “download” en “upload” capaciteit Aantal gebruikers en soort traffiek op de lijn is heel belangrijk Prioritisatie van bepaalde toepassingen soms mogelijk en noodzakelijk (HTTP server traffiek, VoIP, Citrix, …) Quality of Service (QoS) – bv. Diffserv (Differentiated Services) -> aan de hand van de TOS byte in de header van een IPv4 pakket

2. Het netwerk van de ISP - Algemeen Voldoende bandbreedte moet aanwezig zijn Cruciale parameters voor de kwaliteit van het ISP netwerk zijn: Vertragingen (delay, latency, round-trip times) tussen de verschillende netwerkelementen Jitter (delay variation): bv. VoIP toepassingen zijn hier zeer gevoelig voor Pakketverlies (packet loss) typisch uitgedrukt in % Een goed ISP-netwerk is steeds gelaagd Hiërarchische structuur met goed-gedefinieerde lagen (elke laag heeft zijn eigen functie en eigenschappen) Doel is zo efficiënt mogelijke routeringspaden en dus snelle doorstroming van IP-pakketten te garanderen Vergelijkbaar met de “geheugenpiramide” in computerarchitectuur

Het netwerk van de ISP (Voorbeeld UUNET) Hoofzakelijk een 3-lagig hiërarchisch model Edge laag Dit is de laag waarin alle klanten worden aangesloten Entry point in het netwerk Typische eigenschap: veel aansluitingen (dus veel routering) van beperkte capaciteit Metro laag Dit is de eerste laag van de “backbone” of “core” van het netwerk Typische eigenschap: minder connecties, vertegenwoordigt lokale traffiek (bv. binnen België), middelmatige capaciteit Transit laag Dit is de tweede laag van de “backbone” of “core” van het netwerk en verzorgt capaciteit naar de rest netwerk/Internet Bijna geen routering (alles is al geaggregeerd in grote IP-adresblokken), pure switching, zeer hoge capaciteiten

Het netwerk van de ISP (Voorbeeld UUNET) Transit (2.4 - 10 Gbps) Metro (155 - 622 Mbps) Edge (64 kbps - 155 Mbps) Klanten

3. Peering punten Directe peering Via een Internet Exchange (bv. BNIX in België) ISP1 ISP2 BNIX ISP2 ISP1 ISP3

4. Internet toegangslijn van de server Is qua problematiek van verzadiging identiek aan punt 1 (Internet toegangslijn van de gebruiker) Additioneel moet er hier vooral rekening gehouden worden met upload traffiek, ttz. content die in de richting van het Internet vloeit Hoeveel simultane connecties naar een webserver wil men toelaten Gemiddelde grootte van de webobjecten, structuur van de websites (qua grootte in bytes) Moeten nog andere protocollen dan HTTP geprioritiseerd worden (bv. applicaties voor remote beheer) Belasting van de webserver

Contentnetwerk: de oplossing? Congestion op de accesslijn (pijnpunt 1) van de gebruiker kan niet worden aangepakt, enkel gebruiker heeft hierover zelf de controle Contentnetwerken kunnen tot op zekere hoogte wel de pijnpunten 2, 3, 4 reduceren door Content zo dicht mogelijk bij de gebruikers te brengen, namelijk op de rand (edge) van het ISP netwerk (pijnpunt 2) Content verspreiden over verschillende ISP’s (pijnpunt 3) Belasting van de web server te verminderen door content te spreiden over meerdere servers of over diverse accesslijnen (pijnpunt 4)

Contentnetwerken: Doel Beheren van replicatie van content door middel van de volgende 2 taken Distributie Garandeert het kopiëren en synchroniseren van van (een) object(en) van een originele server naar diverse replica servers Redirection (herroutering) Laat gebruikers toe om het object te vinden, liefst op de server die zich het “dichtst” bij hen bevindt “dichtst” in Internetterminologie (volgt niet noodzakelijk geografische logica), is combinatie van Minimaal aantal hops Minimale latency

Elementen van een contentnetwerk Master server Replica server Replica server Replica server ? Client

Classificatie Verschillende manieren om contentnetwerken te classificeren Lokale / Globale distributie applicatieservers DNS-gebaseerde / Applicatieserver gebaseerde routeringsmechanismen … Op basis van wie de eigenaar is van het contentnetwerk en het beheert (deze les) Contentnetwerken beheerd door de netwerkoperatoren (ISP’s) Contentnetwerken beheerd door de contentleveranciers Contentnetwerken beheerd door de gebruikers

1. Contentnetwerken beheerd door de netwerkoperatoren Netwerkoperatoren = Internet Service Providers (ISP’s) Maken gebruik van caching proxies om bandbreedte (en dus cost!) in de backbone te besparen (is minder een issue nu dan in de jaren ’90 – grote prijserosie) Proxies kunnen Recursief gebruikt worden, betekent dat ze gebruik kunnen maken van ouderproxies indien nodig Hiërarchische boomstructuur van proxies kan worden opgebouwd Voor aanvraag van minder populaire objecten zal ongetwijfeld vertraging optreden Werkt niet ideaal als de originele servers niet dicht zitten bij de proxies uit de boomstructuur

Modellen voor webcaching Explicit caching Het gebruik van proxies kan vrij door de gebruiker bepaald worden in de browser (aan/uit) Moet ondersteund worden door de ISP Forced explicit caching Sommige ISP’s forceren het gebruik van proxies bij hun klanten HTTP-traffiek wordt niet doorgelaten indien het geen proxy server van de ISP passeert (typisch blokkeren op TCP poort 80 naar andere dan IP-adressen proxy) Transparent caching Traffiek naar TCP poort 80 kan door de ISP worden afgeleid naar een proxyserver zonder expliciete configuratie in browser van de gebruiker

Algemeen principe van gebruik proxyserver Client TCP: CONNECT proxy.isp.com HTTP: GET www.site.org/index.html Ingeval van een “cache hit” Ingeval van een “cache miss” TCP: CONNECT www.site.org HTTP: GET index.html Content server Caching server

Squid Squid caching proxy (www.squid.org) Werkt op basis van hiërarchische boomstructuur Moeder proxy zal een query lanceren op basis van de domeinnaam van de gekozen URL Matchen met lijsten van URL’s in de proxy boomstructuur Eventueel direct aan originele server vragen Configuratie is omvangrijk Niet triviaal omdat domeinnamen niet noodzakelijk overeenkomen met de netwerktopology Is zelfs bijna nooit het geval Geen relatie tussen de IP-adresblokken in de IPv4 adresruimte en de erin gebruikte domeinnamen)

Web Cache Communication Protocol (WCCP) Proxies moeten door gebruikers ingesteld worden in hun browsers Om configuraties of problemen met configuraties te vermijden, kan men gebruik maken van zogenaamde interception of redirection proxies Maakt gebruik van transparent caching Netwerkelementen (routers) geconfigureerd met WCCP zullen HTTP-traffiek afleiden naar proxy servers zonder dat de gebruikers dit merken Volledige transparantie voor de gebruikers WCCP bevat ook een fail-safe mechanisme: betekent dat als de web cache niet bereikbaar is, er geen afleiding van HTTP traffiek gebeurt naar de web cache

Web Cache Communication Protocol – Figuur

2. Contentnetwerken beheerd door de contentleveranciers Contentleveranciers zijn organisaties die grote hoeveelheden content publiceren op het Internet Voorbeeld: CNN, Yahoo!, … Drijfveer voor contentleveranciers Content zo wijd mogelijk beschikbaar stellen bij de gebruikers Controle houden over de content Zonder al te zware investeringen te doen in netwerken en bandbreedte Opdeling A. Lokale server topologieën A.1 Clustergebaseerd websysteem (webcluster) A.2 Gedistribueerd websysteem B. Mirror sites C. Content-Delivery netwerken (CDN)

A. Lokale server topologieën A.1 Webclusters De contentservers maskeren hun IP-adressen voor de clients De client ziet 1 “virtual IP” (VIP) adres dat gerelateerd is aan een device vóór de contentservers Device: “contentswitch”, ook “webswitch” genoemd (Layer 4 of Layer 7)

Webclusters - illustratie

A. Lokale server topologieën A.2 Gedistribueerde web systemen De contentservers tonen hun IP-adres aan de clients Sturing gebeurt niet vanuit een contentswitch In lokale server topologieën komt A.1 het vaakst voor, A.2 is ouder qua technologie en komt vaker voor bij geografisch verspreide web server systemen (vooral bij DNS-gebaseerde routering)

Gedistribueerde websystemen - illustratie

A.1 Webclusters Gebaseerd op EN Layer 4 switching Layer 7 switching EN Gebaseerd op client/server dataflow (vooral dan wat betreft het terugkeerpad) One-way architectuur De contentserver antwoordt direct naar de client Two-way architectuur De contentserver antwoordt aan de contentswitch, die vervolgens antwoordt aan de client

A.1 – Taxonomie voor webclusters Twee aspecten zijn belangrijk: A.1.1 Routeringsmechanismen A.1.2 Dispatching algoritme voor de selectie van de beste server (bv. load balancing) Bepalen hoe de request bij de contentserver(s) terechtkomt Bepalen bij welke content server de request terechtkomt

A.1.1 – Oplossingen op basis van Layer 4 switches (two-way architecturen)

A.1.1 – Oplossingen op basis van Layer 4 switches (two-way architecturen) Packet double-rewriting is gebaseerd op Network Address Translation (NAT) Zowel voor ingaande als uitgaande pakketten moet de TCP en IP header worden herschreven + checksum herberekenen Ingaand Web switch herschrijft het publieke IP-adres naar het private IP-adres van de content server Uitgaand Pakketten van de content server naar de client passeren terug de web switch Web switch herschrijft het bronadres van het private IP-adres naar het publieke van de web switch

A.1.1 – Oplossingen op basis van Layer 4 switches (one-way architecturen)

A.1.1 – Oplossingen op basis van Layer 4 switches (one-way architecturen) Packet single-rewriting Web switch vervangt het VIP adres door IP adres van de contentserver + herberekent IP en TCP checksum De contentserver antwoordt rechtstreeks aan client maar gebruikt als bron IP-adres het VIP-adres Packet tunneling (ook IP encapsulation) Techniek om een IP datagram te encapsuleren in een ander IP diagram Webswitch tunnelt het inkomende pakket naar de contentserver door het te encapsuleren in een nieuw IP datagram (met bron IP = VIP en destinatie IP = IP contentserver) Contentserver stript het IP datagram eraf en ziet dat het pakket origineel bestemd was aan het VIP-adres Contentserver antwoordt rechtstreeks aan de client maar gebruikt als bron IP-adres het VIP adres

A.1.1 – Oplossingen op basis van Layer 4 switches (one-way architecturen) Packet forwarding Het VIP adres wordt gedeeld door de webswitch en de contentservers door het gebruik van primaire en secundaire IP-adressen Contentservers hebben een primair IP-adres en als secundair IP-adres het VIP-adres (bv. via loopback interface) ARP mechanisme moet worden uitgeschakeld op de contentservers Packet forwarding gebeurt doordat de web switch in het inkomende pakket het MAC-adres vervangt door dat van de contentserver Er gebeurt dus een transformatie op layer 2 niveau, “MAC address translation” Wanneer de contentserver het pakket ontvangt ziet het eruit als een pakket voor zichzelf, aangezien hij het VIP-adres deelt De contentserver kan rechtstreeks antwoorden aan de client zonder modificatie van het IP datagram

A.1.1 – Oplossingen op basis van Layer 7 switches (two-way architecturen)

A.1.1 – Oplossingen op basis van Layer 7 switches (two-way architecturen) TCP gateway Webswitch bevat een applicatielaag proxyserver die alle binnenkomende connecties accepteert De proxyserver onderhoudt “TCP persistent” connecties met alle contentservers Proxyserver stuurt de client request door naar de contentserver via de “TCP persistent” connectie Het antwoord komt via de “TCP persistent” connectie terug bij webswitch die het doorstuurt naar de client Eenvoudige techniek (“TCP persistent” sessies kunnen want alles staat lokaal) Grootste nadeel: Zowel de inkomende als uitgaande data flows lopen via de webswitch op applicatielaagniveau TCP splicing Cfr volgende slide(s)

TCP splicing (I)

TCP splicing (II)

A.1.1 – Oplossingen op basis van Layer 7 switches (one-way architecturen)

A.1.1 – Oplossingen op basis van Layer 7 switches (one-way architecturen) TCP handoff Client heeft sessie opgezet met webswitch Op moment dat web switch de contentserver heeft gekozen -> “handoff” van de TCP connectie Het “handoff” algoritme is actief tussen transport- en applicatielaag en impliceert veranderingen in de besturingssytemen van de beide componenten (nadeel !) Het mechanisme blijft transparant voor de client TCP connection hop Is een proprietary oplossing van het bedrijf Resonate Op moment dat web switch de contentserver heeft gekozen -> webswitch “hopt” de TCP connectie naar de contentserver Gebeurt door het encapsuleren van het IP-pakket in een RPX pakket (proprietary) Het mechanisme blijft transparant voor de client (ook voor acknowledgement informatie verstuurd door de client)

A.1.2 Dispatching algoritmes voor web clusters Gebaseerd op Layer 4 switches (content-blind dispatching) Layer 7 switching (content-aware dispatching) EN Statische algoritmes Snelste oplossing om bottlenecks in de web switch te vermijden Houden geen rekening met de actuele status van de webservers Dynamische algoritmes Presteren beter dan statische algoritmes door het nemen van intelligente beslissingen Het capteren en analyseren van status informatie van de webservers zorgt voor een niet te verwaarlozen overhead op de performantie van de webswitch

A.1.2 - Oplossingen op basis van Layer 4 switches (statische algoritmes) Willekeurig (Random) Verdeelt de binnenkomende aanvragen uniform met een gelijke probabiliteit over de verschillende webservers Round Robin (RR) Gebruikt een circulaire lijst en een pointer die verwijst naar de laatst geselecteerde webserver om een beslissing te maken Statische Weighted Round Robin (voor heterogene webservers) Een variatie op RR, waarbij elke server een bepaald gewicht krijgt toegekend, afhankelijk van zijn capaciteit Merk op: capaciteit is een instelbare maar statische parameter voor een server (niet real-time)

A.1.2 - Oplossingen op basis van Layer 4 switches (dynamische algoritmes) Afhankelijk van de client Statische partitionering van de webservers Elke server krijgt een groep van clients toegewezen (groepen op basis van bv. client IP-adres) Afhankelijk van de server status De server met de actueel laagste belasting (op basis van welke parameter? Welke index?) De server met het actueel minst aantal actieve connecties De server met de actueel snelste response tijd Dynamische Weighted Round Robin Variatie van statische weighted RR, waarbij elke web server nu een dynamisch gewicht krijgt toegekend evenredig met zijn capaciteit (volgens het platform) en de belasting van de server op dat moment

A.1.2 - Oplossingen op basis van Layer 4 switches (dynamische algoritmes) Afhankelijk van de client en server status Combinatie van client informatie en server status informatie resulteert in een bepaalde client affiniteit In plaats van elke nieuwe connectie naar een webserver enkel toe te kennen op basis van de server status en niet op basis van vorige assignaties Opteren om opeenvolgende connecties van dezelfde client door dezelfde webserver te laten behandelen Voorbeeld: Omwille van performantieredenen, opeenvolgende SSL connecties van dezelfde client door dezelfde server te laten behandelen gedurende de geldigheidsduur van de SSL sleutel (vermijden van sleutelcreatie en negotiatie) Ander voorbeeld: FTP connecties (gebruiken 2 TCP poorten)

A.1.2 Oplossingen op basis van Layer 7 switches (dynamische algoritmes) Een grote diversiteit aan zeer gespecialiseerde oplossingen op basis van client info, server status of combinatie van beide Afhankelijk van de client Bv. Service partitioning = Web servers segmenteren naar types van aanvraag (dynamische inhoud, statische beelden, video, ...) Afhankelijk van de server status Bv. Web switch bepaalt de grootte van het gevraagde object en en selecteert de web server op basis hiervan (elke server krijgt evenveel bandbreedte traffiek) Afhankelijk van de client en server status

A.2 Gedistribueerde web systemen DNS-gebaseerde routeringsmechanismen Origineel ontworpen voor lokaal gedistribueerde websystemen, maar tegenwoordig meer gebruikt in geografisch gedistribueerde websystemen (cfr. CDN’s) Webserver gebaseerde routeringsmechanismen Routering en eventuele verwijzingen gebeuren op de contentserver Dispatching voor gedistribueerde websystemen is geen apart topic want is geïntegreerd in de routeringsmechanismen

A.2 - Oplossing op basis van DNS-gebaseerde routeringsmechanismen Treedt in werking tijdens de DNS-lookup fase bij het begin van de websessie Mapping naam website en IP-adres contentserver De authorative DNS server voor de zone waartoe de hostnaam van de website behoort Selecteert een verschillende server (A-records) voor elke lookup die het moet beantwoorden Antwoordt met een paar (IP-adres, TTL) IP-adres van één van de content servers Time-To-Live (TTL) record dat bepaalt hoelang de caching DNS server deze informatie bijhoudt Pas op met adres caching in de caching DNS-servers, leggen een hypotheek op dit mechanisme -> Enige oplossing is te werken met heel lage TTL’s

A.2 - Oplossing op basis van web server gebaseerde routeringsmechanismen Triangulation Client stuurt pakketten naar eerst gecontacteerde content server, die ze doorstuurt naar de tweede content server Routering is gebaseerd op pakket tunneling (zoals beschreven in A.1.1) -> origineel datagram wordt geëncapsuleerd in een nieuw IP datagram De tweede content server herkent dat het IP-datagram werd geherrouteerd en antwoordt rechtstreeks naar de client na vervanging van zijn IP-adres met dat van de eerste content server Alle volgende pakketten blijven het traject “client -> eerste content server -> tweede content server” volgen

A.2 - Oplossing op basis van web server gebaseerde routeringsmechanismen HTTP redirection HTTP protocol standaard (vanaf versie 1.0) laat toe dat een web server antwoordt aan de client met een bepaalde status code om de request opnieuw uit te sturen naar een andere host Status code 301 (“Moved permanently”) Duidt aan dat de aangevraagde resource locator (URL) definitief is verplaatst naar een andere URL Status code 302 (“Moved temporarily”) Duidt aan dat de aangevraagde resource locator (URL) tijdelijk onder een andere URL verblijft Voordeel: mechanisme op heel fijn niveau, tot op niveau individuele webpagina’s Nadeel: extra latency

A.2 - Oplossing op basis van web server gebaseerde routeringsmechanismen

A.2 - Oplossing op basis van web server gebaseerde routeringsmechanismen URL rewriting In dit geval zal de eerst gecontacteerde content server dynamisch de linken van de ingebedde objecten in de webpagina veranderen Fundamenteel verschillend met HTTP redirection dat een statische techniek is Vaak in combinatie met intelligente DNS-gebaseerde routering wordt deze techniek tegenwoordig vaak gebruikt in Content Delivery Netwerken (CDN’s) -> zie verder Grootste probleem van deze techniek is de bijkomende load van server resources en bijkomende latency geïntroduceerd door dit mechanisme

B. Mirror sites Dit zijn contentnetwerken waarbij men een verzameling van servers verspreidt over het Internet (slaves), en die allemaal een exacte replica zijn van de master server op de hoofdlocatie De master-slave synchronisatie gebeurt doorgaans niet in real-time maar op periodieke tijdstippen Redirection gebeurt typisch door de gebruikers Gebruiker gaat op hoofdsite en krijgt een lijst met slave servers te zien, samen met hun geografische info (kan misleidend zijn!) Proces kan geautomatiseerd worden bv. door gebruik van cookies om keuze van de gebruiker weg te schrijven -> initieert dan een “HTTP redirection” Het principe van mirror servers wordt heel vaak toegepast voor FTP-servers

Mirror sites (Voorbeeld)

C. Content-delivery netwerken (CDN) Veel contentleveranciers hebben niet de middelen om een wereldwijd netwerk van mirror sites uit te bouwen Operatoren van CDN’s Bouwen een wereldwijde replicatie-infrastructuur uit en stellen die ter beschikking Wordt betaald door contentleveranciers die hun content ter beschikking stellen Business model (financieel) Voor CDN operatoren: Gedeelde infrastructuur, verschillende gebruikers betalen ervoor Voor contentleveranciers: Groot geografisch bereik aan beperkte cost

CDN operatoren Oorspronkelijke missie van CDN operatoren was het leveren van content voor hun klanten (= content leveranciers) op een geografisch verspreide manier Tegenwoordig bieden CDN operatoren ook andere diensten aan Beschikken over zeer hoog technologische algoritmes en protocollen (bv. DNS tools) Proberen meer taken op zich te nemen (bv. scripting taken, door die niet op de originele web server van de content leverancier maar op het CDN netwerk zo dicht mogelijk bij de klant CDN’s gebruiken doorgaans het DNS om URL’s te transformeren in locatie-onafhankelijke verwijzingen

CDN operatoren CDN servers bevatten typisch niet alle content van websites, maar bepaalde selectieve objecten (in samenspraak met de content leverancier) Dergelijke servers worden surrogaten genoemd Complexe redirection systemen nodig om de gebruikers naar het juiste surrogaat te sturen Selectie van een bepaalde surrogaat op basis van netwerk metrieken Routeringsinformatie Latencies, round-trip times Belasting van bepaalde surrogaten We bekijken in meer detail het grootste CDN op het Internet in de case op het einde van de les

3. Contentnetwerken beheerd door de gebruikers Deze netwerken zijn beter gekend als “peer-to-peer” netwerken (P2P) Het dure replicatiemechanisme van de voorgaande technieken wordt vervangen door de gebruikers Stellen een deel van hun opslag- en verwerkingscapaciteit ten dienste van het P2P netwerk De meeste van deze netwerken zijn “overlay” netwerken en zijn dus niet gebonden aan een transparante integratie met bv. HTTP-technologie Voordeel ! Hebben alle vrijheid om nieuwe modellen van contentverspreiding en contentpresentatie te ontwikkelen Hebben zelfs hun eigen naamruimte -> niet gebonden aan HTTP en URL’s

P2P netwerken Basisidee van replicatie en distributie van data Hoe populairder een bestand is, hoe meer gebruikers het zullen downloaden Als gevolg hiervan wordt het dus ook meer beschikbaar gesteld in het P2P netwerk, … Redirection is evenwel een serieuze uitdaging Er moet een gedistribueerd zoekmechanisme beschikbaar zijn Netwerken als Gnutella, KaZaa, Freenet behoren tot deze klasse Napster niet, want die werkt met een gecentraliseerde directory

Redirection in P2P netwerken Algemeen principe Een node op het P2P netwerk ondervraagt naburige nodes die zelf terug naburige nodes ondervragen, … Proces gaat door totdat Een bepaalde node positief antwoordt op de aanvraag Een bepaalde zoekactie teveel resources op het netwerk verbruikt heeft (vergelijkbaar met een TTL op traceroute) Enkele aandachtspunten Dergelijke netwerken zijn heel vatbaar voor het uitvoeren van “denial-of-service” DoS aanvallen door het netwerk te overbelasten met aanvragen Men is nooit zeker dat men het document vindt, ook al staat het op een bepaalde node

Het gebruik van P2P netwerken Momenteel: vooral gebruikt voor file-sharing P2P netwerken leveren echter ook nieuwe en waardevolle concepten Diverse projecten richten zich op het “scatter/gather” distributieschema Heel interessant voor grote bestanden Een aanvrager-node downloadt fragmenten van een bestand bij verschillende andere nodes en assembleert die vervolgens Kan zelfs zover gaan dat fragmenten worden ge-upload van gebruikers (nodes) die het fragment zelf aan het downloaden zijn op dat moment Bepaalde projecten proberen P2P principes te integreren in bestaande Web technieken en protocollen (Open Content Network, BitTorrent) Te interpreteren als een combinatie van CDN’s en P2P principes

Case study Akamai CDN

Het bedrijf Wereldwijde CDN provider op het Internet, algemeen beschouwd als de marktleider Ontstaan in 1995 aan het MIT Tim Berners-Lee voorzag het probleem van netwerk congestion op het Internet Hij daagde zijn collega’s aan het MIT uit om een nieuwe en betere techniek te ontwikkelen voor de levering van content op het Internet Eerste commerciële activiteiten in 1999 Globale cijfers over aanwezigheid op het Internet (2004) Meer dan 14.000 servers Aanwezig in 1.100 networks In 65+ landen Ongeveer 1000 klanten (Yahoo!, IBM, Apple, …) http://www.akamai.com

Concept Akamai infrastuctuur is erop gericht om wanneer en waar nodig meer servers te alloceren voor websites die een zware belasting ervaren (bv. in geval van “flash crowds”) Het system stuurt client requests naar de dichtstbijgelegen beschikbare server die met waarschijnlijk de gevraagde content heeft Dichtstbijgelegen – functie van netwerktopologie en dynamische link karakteristieken (bv. latency, pakketverlies, …) Beschikbare – functie van server belasting en bandbreedte in het netwerk Waarschijnlijk – functie van welke servers de gevraagde content bevatten

Akamai DNS verwijzingsproces (mapping) Stel dat een bepaalde url (bv. www.site.org) in een webpagina verwijst naar a7.g.akamai.net Stap 0: Client DNS resolver queries de root name servers en vervolgens .net name servers voor NS-records van akamai.net -> resultaat is een Akamai Top Level (TL) DNS server Stap 1: Client DNS resolver queries de Akamai TL DNS server voor een delegatie van g.akamai.net -> resultaat is een Akamai Low Level (LL) DNS [TTL typisch 1 hour] Stap 2: Client DNS resolver queries de Akamai LL DNS server voor het host record van a7.g.akamai.net -> resultaat is een IP-adres van een Akamai edge server [TTL typisch enkele seconden tot max. 1 minuut] Stap 3: Client maakt een HTTP request naar de edge server Stap 4: Haalt de content bij een andere Akamai server Stap 5: of laat die ophalen bij de orginele server

Akamai DNS verwijzingsproces: Illustratie Het resolving proces is hetzelfde voor elke DNS naam op het Internet. Akamai name-resolving verschilt echter in de manier waarop de DNS servers zich gedragen

Criteria voor DNS verwijzingsproces om een hostnaam te mappen op het IP-adres van een content server Gevraagde dienst: bv. LL DNS server moet een aanvraag voor een Quicktime streaming video niet verwijzen naar een contentserver die enkel HTTP behandelt Toestand van server: moet up-and-running zijn zonder problemen Belasting van server: moet onder bepaalde drempelwaarde liggen (typische maten zijn CPU, disk space, RAM, netwerkgebruik) Conditie van het netwerk: Client moet server kunnen bereiken met minimaal pakketverlies Locatie van client: Server moet dicht bij client gesitueerd zijn (minimale latency of round trip time) Gevraagde content: De server moet met hoge waarschijnlijkheid de content hebben

Criteria voor DNS verwijzingsproces om een hostnaam te mappen op het IP-adres van een content server Met elk van de criteria op vorige slide wordt dus rekening gehouden in het resolving proces ! Impliceert: Sterke controle en implementatie van de DNS servers (daemons) is een van de belangrijkste onderdelen Hierin zit een groot stuk van de Akamai technologie Heel sterke kennis van het netwerk vereist via constante monitoring Aan de hand van probes die continu parameters registreren in het Akamai rapporterings- en managementsysteem Aan de hand van “agents” die overal in het netwerk peridiek clientgedrag simuleren (HTTP requests, …) Hebben dus een “tabel” van vrijwel als ISP caching name servers en de respectievelijke dichtste Akamai edge servers (Akamai is aanwezig in ongeveer 1100 netwerken)

Voorbeeld: www.yahoo.com (Enkel voor DNS-resolving, niet voor geografische content distributie) 22/04/2005 (10h) vanop het netwerk van Esko-Graphics (MCI connectiviteit) H:\>nslookup -type=A www.yahoo.com Server: begedesgc001.esko-graphics.com Address: 10.31.134.45 Non-authoritative answer: Name: www.yahoo.akadns.net Addresses: 216.109.118.68, 216.109.118.71, 216.109.118.72, 216.109.118.79, 216.109.117.109, 216.109.117.207 Aliases: www.yahoo.com 22/04/2005 (10h) vanop het netwerk van Telenet H:\>nslookup -type=A www.yahoo.com Server: roes.lyssa.telenet-ops.be Address: 195.130.130.5 Non-authoritative answer: Name: www.yahoo.akadns.net Addresses: 68.142.226.32, 68.142.226.34, 68.142.226.38, 68.142.226.39 68.142.226.42, 68.142.226.44, 68.142.226.50, 68.142.226.52 Aliases: www.yahoo.com

Belangrijkste diensten Levering van statische content over HTTP en HTTPS Levering van dynamische content over HTTP en HTTPS Levering van streaming audio en video over de volgende 3 protocollen Microsoft Windows Media Real Apple Quicktime Geavanceerde DNS-resolving technieken voor contentleveranciers (bv. voor lokale load balancing)

Andere diensten “EdgeComputing voor Java” (en .NET dit jaar). J2EE applications kunnen worden uitgevoerd op het Internet op de Akamai servers Virtual waiting room In e-shopping, om de transactie van de klant te beschermen Stel, klant koopt en heeft tal van items in zijn shopping cart Bij check-out treedt overbelasting van de site op -> kan niet verder -> alles kwijt Akamai zal de shopping cart tijdelijk in de “virtual waiting room” plaatsen en de klant notificeren zolang de congestie niet weg is Geografische landherkenning van de client voor de content leverancier

Statische content Statische webcomponenten kunnen zijn: HTML-pagina’s, figuren, executables, PDF-documenten, … Het HTTP “pull model” verandert niet met Akamai Client request wordt beantwoord vanuit de cache van de edge server (indien aanwezig) en anders vanuit de orginele server Aanvullend kunnen klanten beslissen om statische content op te slaan op de gerepliceerde Akamai NetStorage data center servers Content wordt beheerd op een gecentraliseerde locatie door de klant Wordt verspreid via een gedistribueerd netwerk aan de ganse Internet gebruikers community

Dynamische content Websites vandaag beschikken vaak over dynamische content Proxy server caches kunnen dit typisch niet aan, bv. een pagina die voor 80% statisch is, maar 20% dynamische data bevat Elk met een bepaalde TTL

Dynamische content - ESI Edge Side Includes (ESI) – www.esi.org Eenvoudige markup language (XML-gebaseerd) Beschrijving van “cacheable” en “non-cacheable” componenten op een webpagina die kunnen geaggregeerd, geassembleerd en afgeleverd worden de edge van het netwerk Laat contentleveranciers toe om een dynamische pagina op te delen in HTML-fragmenten met onafhankelijke eigenschappen voor caching Deze fragmenten worden beheerd als onafhankelijke objecten in de cache van de edge server Bij client aanvraag naar een URL die verwijst naar het Akamai CDN levert de edge server de statische fragmenten (indien niet expired) en haalt enkel de dynamische fragmenten op bij de originele web server Alles wordt samengesteld op de edge server en doorgestuurd naar de client

Dynamische content – ESI (Voorbeeld 1) ESI wordt eveneens gebruikt om bepaalde losse diensten aan te bieden Contentleverancier toont verschillende objecten (bv. Webpagina, figuren, …) op basis van land van herkomst van client of op basis van cookie informatie Akamai kan de geografische herkenning maken (tot op landniveau) ESI script wordt uitgevoerd op de edge server, NIET op de originele web server Juiste pagina wordt doorgestuurd naar de client Verschil met klassieke technologie: alle rekenkracht en processing werd uitgevoerd op het CDN van Akamai (geen belasting voor de originele webserver) en dicht bij de klant

Dynamische content – ESI (Voorbeeld 2)

Streaming media Contentleverancier levert een gecapteerde en gecodeerde “live stream” af bij een ingangsserver in het Akamai netwerk Uitdagingen (verwijderen van “single points of failure” in netwerk) ! Mechanisme nodig dat snelle fail-over garandeert De “live stream” wordt onmiddellijk gerepliceerd naar meerdere edge servers Constant rekening houdend met pakketverlies en netwerk instabiliteiten Ook de vertragingen (delay) en jitter (delay variation) worden in de gaten gehouden Ook “on-demand” clips of streams kunnen worden afgeleverd en opgeslagen in het Akamai netwerk Het netwerk zorgt voor de replicatie Aflevering bij een client request volgt het normale proces