Les fournisseurs de contenu ptimisation du transport de contenu 4 - Content Delivery Networks Christophe Deleuze Grenoble INP EIAR Décembre 014 veulent : rendre le contenu accessible capacité serveur capacité réseau distribution géographique garder le contrôle fraicheur comptage etc web dynamique gestion de site 1 / 55 / 55 Content Delivery Network Qu'est-ce qu'un CDN? surrogate placé près des clients géré par le fournisseur de contenu + charge origine + débit réseau + délai client + stats origine + fraicheur rapprocher le contenu des clients quatre systèmes delivery serveurs surrogates redirection distribution transport comptabilité distribution redirection comptabilité delivery 3 / 55 4 / 55
Qu'est-ce qu'un CDN? Qu'est-ce qu'un CDN? n content delivery network (CDN) est un fournisseur de services de communications électroniques dont l'une des activités consiste à optimiser l'acheminement de données. Cette optimisation peut concerner aussi bien les performances (latence, débit, etc.) que les coûts d'acheminement. Pour y parvenir, un CDN dispose d'un ensemble de serveurs dits serveurs (de) cache proches de l'internaute, dans lesquels sont stockés des copies des données à acheminer. Les données en question ne sont donc acheminées qu'une seule fois depuis leur lieu de production jusqu'au serveur cache, ce qui permet d'économiser des coûts de transport / transit ; par ailleurs, la distance d'acheminement dans la partie terminale (depuis le serveur jusqu'à l'internaute) est raccourcie, si bien que les performances sont améliorées. Les clients principaux des CDN sont les FCA. 1 Rapport au Parlement et au Gouvernement sur la neutralité de l'internet, ARCEP, septembre 01. fournisseur de contenu consommateurs opérateur réseau (IP) opérateur CDN $ F $ contenu service CDN $ BP IP C C 1. Fournisseurs de contenus et d'applications 5 / 55 6 / 55 pérateurs de CDN Redirection (request routing) Akamai : 150k serveurs Limelight Level 3 Communications Amazon Cloudfront... services connexes de gestion de contenu monitoring reporting DRM identication des utilisateurs spécialiser/segmenter les contenus géolocalisation trouver le meilleur surrogate (équilibrage de charge + distance au client) surrogate = f(consommateur, contenu, état réseau, états surrogates) routage de requête routage (construction des tables) relayage (forwarding) transparent pour le client... diérentes méthodes pour le relayage 7 / 55 9 / 55
Redirection DN hiérarchique Redirection DN hiérarchique www.content.com fournisseur de contenu content.com N D1 opérateur de CDN cdn.com N D paris.cdn.com N D3 londres.cdn.com N D4 D1 TTL = 1j 1 R C 3 D D3 LNDRE TTL = 10s TTL = 0s PARI à D1 www.content.com A? www.content.com CNAME content.cdn.com D répond en fct de l'adresse de R content.cdn.com A? content.cdn.com CNAME paris.content.cdn.com D3 répond en fct de la charge des surrogates paris.content.cdn.com A? paris.content.cdn.com CNAME s1.paris.content.cdn.com s1.paris.content.cdn.com A a.b.c.d 10 / 55 11 / 55 Problèmes de la redirection DN basée sur l'adresse du résolveur historiquement et normalement, proche de l'utilisateur que faire si elle est 8.8.8.8 (Google DN)? au fait, où est votre résolveur? whoami.akamai.net resolver-identity.cloudfront.net self.myresolver.info http://www.myresolver.info 1 / 55
Redirection : application redirect Réécriture HTTP 30 Found + on voit adresse client RL contenu l'rl du document change! connexion vers l'origine mais une fois sut... GET url C 30 newurl 1 GET newurl 00 K 1 D 3 pop1 a pop a pop3 b a b C1 pop1 C pop C3 pop3 14 / 55 15 / 55 Réécriture HTTP pour C1 Réécriture HTTP pour C GET /content.html Host: provider.com 30 Found Location: http://pop1.cdn.net/provider.com/content.html D pop1 a pop a pop3 b pop1.cdn.net A? pop1.cdn.net CNAME a a A a.b.c.d 1 a b GET /provider.com/content.html Host: pop1.cdn.net 00 K... <a href="pop1.cdn.net/provider.com/news.html">news!</a> C1 pop1 3 C pop C3 pop3 16 / 55 17 / 55
Réécriture HTTP pour C Extension DN pour localiser le client GET /content.html Host: provider.com 30 Found Location: http://pop.cdn.net/provider.com/content.html pop.cdn.net A? pop.cdn.net CNAME a a A a.b.c.d GET /provider.com/content.html Host: pop.cdn.net 00 K... <a href="pop.cdn.net/provider.com/news.html">news!</a> une bonne solution rfc6891 Extension Mechanisms for DN (EDN(0)) apr 13, obsoletes rfc671 aug 99 Client ubnet in DN Requests draft-vandergaast-edns-client-subnet-00/../0 jan 11/apr 13 draft-ietf-dnsop-edns-client-subnet-00 nov 14 (Akamai/Google) permet au résolveur d'indiquer l'adr du client permet au serveur d'indiquer la portée de la réponse 1 résolveur inclut src IP et taille masque dans requête serveur inclut src IP et taille masque dans réponse 3 résolveur cache réponse associée à IP/masque 18 / 55 19 / 55 Extension DN pour localiser le client Redirection : routage C 1 www.example.com A? 1 R 4 3 www.example.com A? [client-subnet = 19.168.130.1/4] 3 www.example.com A 19.168.1.1 [client-subnet = 19.168.0.0/16] 4 www.example.com A 19.168.1.1 D requête client pour document ensemble des gtes ayant le document charge (CP, nb. connexions...) distance au client (hops, délai, débit...) réponse rapide + infos à jour méthode passive (IGP/BGP...) méthode active (sondes) à la demande à l'avance Akamai secret sauce trouver un surrogate raisonnable 0 / 55 1 / 55
Redirection, cas simple : routage intra A Redirection, cas plus compliqué approche active/à l'avance décision centralisée clusters de surrogates pop (agrégats de clients) charge des services dans chaque cluster chaque cluster probe tous les pops association (pop, service) cluster associations pop { réseaux } (ex. proto. routage) cluster pop décision probe rapport construire topologie de l'internet graphe de réseaux tout client est dans un de ces réseaux types de liens données historiques et temps réel position des clusters ajouter les infos de : charge des clusters classe de trac maintenir le graphe à jour / 55 3 / 55 Passive infos des protocoles de routage intra-domaine PF topologie RIP distances en nb de n uds BGP A path length traces de trac géo-localisation Active latence : echo ICMP (ping) pertes... débit packet pair : débit lien goulot packet train : débit disponible ource des données Débit d'un chemin : Packet pair I 1 lien à 100 Mb/s j'envoie paquets de 1500 octets, dos-à-dos tps de transmission 1,5 103 8 100 10 6 = 1 ms lien goulot à 1 Mb/s tps de transmission 1,5 103 8 10 6 = 100 ms 3 retour sur lien à 100 Mb/s les paquets sont espacés...... mais impact possible d'autres paquets 4 / 55 5 / 55
Débit d'un chemin : Packet pair II ne méthode originale : DN boomerang 1 P P1 100 ms 100 ms P P1 1 ms 1 ms ou Flash DN ou DN ooding les clusters répondent 1ère arrivée gagne proximité réseau DN 1 B 3 P 1 ms 100 ms P1 1 ms si serveurs chargés retarder la réponse routage très simple! R 3 3 B C 6 / 55 7 / 55 Distribution : réplication Réplication : copie Réplication copie push pull synchronisation (cohérence) Push multicast? problème de la abilité contrôle de ux (hétérogénéité) support du multicast... Pull où chercher le contenu? origine voisins hiérarchie forme de routage déterminer les routes possibles choisir la meilleure (distance réseau + charge serveur)? 8 / 55 9 / 55
Réplication : ex d'akamai EI - contrôle des surrogates hiérarchie de clusters documents chauds dans les clusters feuilles documents froids dans les parents choisis selon l'état du réseau répartition dans chaque cluster optimise espace cache augmente performances pb : dynamisme (charge/crash) consistent hashing Edge ide Includes Akamai/racle/... '01 extension au protocole HTTP (nouveaux en-têtes) requête urrogate-capabilities: s'identie et indique ses capabilities réponse urrogate-control: indique à comment traiter le contenu de la réponse Cntl: max-age=60;s1, max-age=300 Cap: s="urrogate/1.0"; s1="urrogate/1.0, EI/1.0" Cap: s="urrogate/1.0" 1 30 / 55 31 / 55 Réplication : synchronisation EI invalidation protocol maintenir la cohérence des surrogates avec l'origine surrogate = serveur ayant autorité invalidation de contenu mises à jour multicast content signaling tentatives échouées WCIP Web Cache Invalidation Protocol '01 (IETF/Cisco) RP Resource pdate Protocol '0 (IETF) EI invalidation protocol requête HTTP PT avec doc XML (port 4001) PT... msg-inv-xml 00 K msg-result-xml invalidation par RI préxe regexp RI et en-tête... PT msg-inv-xml 3 / 55 33 / 55
PT /x-invalidate HTTP/1.0 Authorization: Basic aw5ywxpzgf0b3i6aw5ywxpzgf0b3i= Content-Length: 17 <?xml version="1.0"?> <!DCTYPE INVALIDATIN YTEM "invalidation.dtd"> <INVALIDATIN VERIN="WC-1.0"> <BJECT> <BAICELECTR RI="/cache.htm" /> </BJECT> </INVALIDATIN> HTTP/1.1 00 K... Content-Length: 84 <?xml version="1.0"?> <!DCTYPE INVALIDATINRELT YTEM "invalidation.dtd"> <INVALIDATINRELT VERIN="WC-1.0"> <BJECTRELT> <BAICELECTR RI="/cache.htm" /> <RELT ID="1" TAT="CCE " NMINV="1"/> </BJECTRELT> </INVALIDATINRELT> Leases (Baux) gestion classique, choix entre : côté serveur (invalidation) états côté client (revalidation systématique) msgs compromis : lease (bail) {obj,,d} s'engage à notier des modifs de obj pendant d Lease-Control: Grant-Lease Renew-Lease... cohérence forte Invalidate-Lease:... Invalidate-Ack:... attend les ACK ou n du bail pour modier obj 35 / 55 Distribution de stream tream live : les problèmes stream : non élastique contraintes temporelles internes l'application gère un tampon délai de démarrage acceptable stream à la demande juste un chier...... oui mais gros... et occupe longtemps le serveur prex caching puis transfert élastique de la suite segmentation des chiers et répartition sur les surrogates le serveur est surchargé son réseau d'accès est saturé la traversée de l'internet est longue et dangereuse... encodeur E surcharge congestion délais/pertes 36 / 55 37 / 55
tream live : architecture tream live : qualité du middle mile surrogates sont des serveurs de stream groupés en clusters last mile entry point rst mile serveurs de transport : set reectors encodeur E R first mile EP set reflector entry point pb : perte de paquets TCP pas adapté (contrôle de congestion, tempo de retransmission) DP avec ajout correction de perte paquet de redondance tolère un paquet perdu parmi k duplication (donc 4 niveaux) contourne routage BGP corrige les pertes stream servers XR bit à bit paquet 1 paquet paquet k redondant last mile 38 / 55 39 / 55 tream live : qualité du middle mile Middle mile : coupure réseau retransmission au mieux émetteur garde les n derniers paquets en tampon récepteur envoie NAK si détecte perte reçu n o n+k, toujours pas reçu n o n, émetteur retransmet si tjs dans le tampon diversité : multipath R1 800 880 900 980 R 800 880 900 980 ER élu ne récoit plus subscribe 800 880 900 980 880 980 bascule sur un autre R prebursting émettre plus vite au début donc depuis le passé (tampon de retransmission du R) rattrape les pertes! 40 / 55 41 / 55
Application delivery network ites Web dynamiques, applications web... la plupart des documents ne sont pas cachables Deux stratégies : 1 optimiser l'acheminement délais quantité données déplacer (une partie de) l'application en bordure transport bidirectionnel ne cache pas, mais permet : optimisation du chemin (routage à la couche application) optimisation du protocole de transport connexions persistantes contrôle de ux/congestion retransmissions rapides optimisation de la couche application pré-charge les objets embarqués compression ptimiser l'acheminement TCP non persist. congestion TCP persistant TCP persistant T T transport opt. app server transport server transport opt. 4 / 55 43 / 55 Déplacer l'application Répartir l'application ex Akamai EdgeComputing plateforme pour exécuter des (composants d') Applications JavaEE Certaines applications peuvent facilement être déplacées/dupliquées aggrégation/transformation de contenus (portails) BD statiques (catalogue, recherche sur un site, liste de boutiques...) collecte de données (formulaires) Les applications avec transactions temps réel ne peuvent pas être complètement déplacées. Archi classique MVC : Model le c ur de l'appli (règles, BD) View représentation (sortie) Controller entrées déplacer la partie interface (view et controller) réduire les échanges au minimum nécessaire agréger/minimiser les échanges avec le modèle eg l'origine génère une page dynamique qui référence des composants cachables. 44 / 55 45 / 55
Edge ide Includes (contrôle des surrogates, protocole d'invalidation) assemblage dynamique de fragments en bordure fragment paramétres de cohérence partagés par les utilisateurs template template + fragments assemblage dynamique inclusion (fragments ont leurs propres métadonnées cachabilité etc) EI I variables (basés sur attributs de la requête HTTP, à la CGI) traitement conditionnel exception, gestion des erreurs (ressources alternatives ou par défaut) <esi:include src="http://example.com/1.html" alt="http://bak.example.com/.html" onerror="continue"/ <esi:include src="http://example.com/search?query=$(qery_tring{query})"/> <esi:inline name="ri" fetchable="yes no"> fragment to be stored within an EI processor </esi:inline> 46 / 55 47 / 55 EI II Comptabilité <esi:choose> <esi:when test="...">... </esi:when> <esi:when test="...">... </esi:when> <esi:otherwise>... </esi:otherwise> </esi:choose> les logs sont répartis dans tous les surrogates besoin de générer une vision globale pour le fournisseur de contenu pour l'opérateur de CDN scalabilité? structure hiérachique (multicast inverse) 48 / 55 49 / 55
;; QETIN ECTIN: ;www.microsoft.com. IN A Qui utilise des CDN? I ;; ANWER ECTIN: www.microsoft.com. 1996 IN CNAME toggle.www.ms.akadns.net. toggle.www.ms.akadns.net. 614 IN CNAME g.www.ms.akadns.net. g.www.ms.akadns.net. 614 IN CNAME lb1.www.ms.akadns.net. lb1.www.ms.akadns.net. 1169 IN A 64.4.11.4 ;; QETIN ECTIN: ;www.apple.com. IN A ;; ANWER ECTIN: www.apple.com. 590 IN CNAME www.isg-apple.com.akadns.net. www.isg-apple.com.akadns.net. 590 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 590 IN CNAME e3191.dscc.akamaiedge.net. e3191.dscc.akamaiedge.net. 151 IN A 9.13.9.15 ;; QETIN ECTIN: ;www.yahoo.com. IN A Qui utilise des CDN? II ;; ANWER ECTIN: www.yahoo.com. 535 IN CNAME fd-fp3.wg1.b.yahoo.com. fd-fp3.wg1.b.yahoo.com. 535 IN CNAME ds-fp3.wg1.b.yahoo.com. ds-fp3.wg1.b.yahoo.com. 535 IN CNAME ds-eu-fp3-lfb.wa1.b.yahoo.com. ds-eu-fp3-lfb.wa1.b.yahoo.com. 535 IN CNAME ds-eu-fp3.wa1.b.yahoo.com. ds-eu-fp3.wa1.b.yahoo.com. 708 IN A 87.48.1.1 ds-eu-fp3.wa1.b.yahoo.com. 708 IN A 87.48.11.181 ;; QETIN ECTIN: ;www.fda.gov. IN A ;; ANWER ECTIN: www.fda.gov. 6 IN CNAME www.fda.gov.edgesuite.net. www.fda.gov.edgesuite.net. 6 IN CNAME a1715.dscb.akamai.net. a1715.dscb.akamai.net. 6 IN A 13.15.6.11 a1715.dscb.akamai.net. 6 IN A 13.15.6.98 ;; QETIN ECTIN: 50 / 55 51 / 55 Qui utilise des CDN? III CDN / caches web ;blog.lemonde.fr. IN A ;; ANWER ECTIN: blog.lemonde.fr. 919 IN CNAME blog.lemonde.fr.-01-71d-000c.cdx.cedexis.net. blog.lemonde.fr.-01-71d-000c.cdx.cedexis.net. 955 IN CNAME wac.3604.edgecastcdn.net. wac.3604.edgecastcdn.net. 1895 IN CNAME gp1.wac.edgecastcdn.net. gp1.wac.edgecastcdn.net. 1896 IN A 93.184.0.0 qu'est-ce qui les diérencie? redirection? mais caches transparents push? systèmes hybrides Émergence des Telco CDN? fédération de CDNs IETF cdni WG, créé en juin 11 http://datatracker.ietf.org/wg/cdni/ Content Networks 5 / 55 53 / 55
Qu'est-ce qu'un CDN? Quelques sources Les CDN... 1 partagent dynamiquement l'infrastructure de réplication utilisent les RL classiques 3 fournissent un espace de noms adapté et 3 paraissent contradictoires n CDN est : une infrastructure de réplication un changement de sémantique de l'espace de noms RL les RFC mentionnés Akamai facts : http://www.akamai.com/html/about/facts_figures.html Nygren (Erik), itaraman (Ramesh K.) et un (Jennifer). The akamai network: A platform for high-performance internet applications. ACM IGP perating ystems Review, vol. 44, n 3, 010. Kontothanassis (Leonidas), itaraman (Ramesh), Wein (Joel), Hong (Duke), Kleinberg (Robert), Mancuso (Brian), haw (David) et todolsky. (Daniel). A transport layer for live streaming in a content delivery network. Proceedings of the IEEE, pecial Issue on Evolution of Internet Technologies, vol. 9, n 9, septembre 004, pp. 14081419. 54 / 55 55 / 55