Optimisation du transport de contenu 4

Les fournisseurs de contenu
Optimisation du transport de contenu
veulent :
4 - Content Delivery Networks
•
rendre le contenu accessible
•
•
•
Christophe Deleuze
Grenoble INP ESISAR
•
capacité réseau
distribution géographique
garder le contrôle
•
•
•
•
Décembre 2014
capacité serveur
fraicheur
comptage etc
web dynamique
gestion de site
1 / 55
2 / 55
Content Delivery Network
Qu'est-ce qu'un CDN ?
O
O
surrogate
•
placé près des clients géré par le
+ charge origine
•
+ débit réseau
•
+ délai client
•
+ stats origine
•
+ fraicheur
distribution
clients
fournisseur de contenu
•
rapprocher le contenu des
•
• delivery
• serveurs
•
•
S
U
redirection
surrogates
redirection
distribution
•
•
U
comptabilité
quatre systèmes
S
S
transport
comptabilité
U
3 / 55
S
delivery
4 / 55
Qu'est-ce qu'un CDN ?
Qu'est-ce qu'un CDN ?
Un content delivery network (CDN) est un fournisseur de services de
•
fournisseur de contenu
optimiser l'acheminement de données. Cette optimisation peut
•
consommateurs
concerner aussi bien les performances (latence, débit, etc.) que les
•
opérateur réseau (ISP)
•
opérateur CDN
communications électroniques dont l'une des activités consiste à
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
$
C
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
service
jusqu'à l'internaute) est raccourcie, si bien que les performances sont
améliorées. Les clients principaux des CDN sont les FCA.
contenu
F
distance d'acheminement dans la partie terminale (depuis le serveur
C
$
1
CDN
$
Rapport au Parlement et au Gouvernement sur la neutralité de
l'internet, ARCEP, septembre 2012.
BP
ISP
1. Fournisseurs de contenus et d'applications
5 / 55
6 / 55
Opérateurs de CDN
•
Akamai : 150k serveurs
•
Limelight
•
Level 3 Communications
•
Amazon Cloudfront
•
...
•
services connexes de gestion de contenu
Redirection
•
(request routing)
trouver le meilleur surrogate (équilibrage de charge +
distance au client)
•
surrogate = f(consommateur, contenu, état réseau, états
surrogates)
•
•
•
•
•
monitoring
•
géolocalisation
•
•
reporting
•
DRM
routage (construction des tables)
relayage
(forwarding)
transparent pour le client...
•
identication des utilisateurs
•
routage de requête
diérentes méthodes pour le relayage
spécialiser/segmenter les contenus
7 / 55
9 / 55
Redirection DNS hiérarchique
www.content.com
à D1
O
D1
⇒ www.content.com A ?
⇐ www.content.com CNAME content.cdn.com
LONDRES
fournisseur de contenu
• content.com NS D1
Redirection DNS hiérarchique
TTL = 1j
1
D2
2
D2 répond en fct de l'adresse de R
⇒ content.cdn.com A ?
⇐ content.cdn.com CNAME paris.content.cdn.com
TTL = 10s
opérateur de CDN
• cdn.com NS D2
• paris.cdn.com NS
D3
• londres.cdn.com
NS D4
R
3
TTL = 0s
D3
C
S
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
PARIS
S
10 / 55
Problèmes de la redirection DNS
•
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 DNS) ?
au fait, où est votre résolveur ?
• whoami.akamai.net
• resolver-identity.cloudfront.net
• self.myresolver.info
• http://www.myresolver.info
12 / 55
11 / 55
Redirection :
application redirect
Réécriture HTTP
D
O
• ⇐ 302 Found
• + on voit
•
•
302 newurl
GET url
•
l'URL du document change !
•
connexion vers l'origine
•
2
adresse client
URL contenu
pop1 − Sa
pop2 − Sa
pop3 − Sb
1
l
r
wu
ET
Sa
ne
G
mais une fois sut...
1
S
00
K
O
3
2
C
Sb
2
C1
C2
pop1
pop2
C3
pop3
14 / 55
15 / 55
Réécriture HTTP pour C1
Réécriture HTTP pour C2
⇒ GET /content.html
Host: provider.com
⇐ 302 Found
Location: http://pop1.cdn.net/provider.com/content.html
⇒ pop1.cdn.net A ?
⇐ pop1.cdn.net CNAME Sa
Sa A a.b.c.d
D
pop1 − Sa
pop2 − Sa
pop3 − Sb
2
1
Sa
⇒ GET /provider.com/content.html
Host: pop1.cdn.net
⇐ 200 OK
...
<a href="pop1.cdn.net/provider.com/news.html">News!</a>
16 / 55
Sb
3
C1
pop1
C2
pop2
C3
pop3
17 / 55
Réécriture HTTP pour C2
Extension DNS pour localiser le client
⇒ GET /content.html
Host: provider.com
⇐ 302 Found
Location: http://pop2.cdn.net/provider.com/content.html
une bonne solution
•
•
•
⇒ pop2.cdn.net A ?
⇐ pop2.cdn.net CNAME Sa
Sa A a.b.c.d
rfc6891 Extension Mechanisms for DNS (EDNS(0))
apr 13, obsoletes rfc2671 aug 99
Client Subnet in DNS Requests
draft-vandergaast-edns-client-subnet-00/../02 jan
11/apr 13 draft-ietf-dnsop-edns-client-subnet-00 nov
14 (Akamai/Google)
⇒ GET /provider.com/content.html
Host: pop2.cdn.net
⇐ 200 OK
...
<a href="pop2.cdn.net/provider.com/news.html">News!</a>
•
•
permet au résolveur d'indiquer l'adr du client
1
2
3
résolveur inclut src IP et taille masque dans requête
permet au serveur d'indiquer la portée de la réponse
serveur inclut src IP et taille masque dans réponse
résolveur cache réponse associée à IP/masque
18 / 55
19 / 55
Extension DNS pour localiser le client
R
Redirection : routage
•
2
•
•
•
1
4
3
D
•
C
1
2
3
4
document
charge (CPU, nb. connexions...)
distance au client (hops, délai, débit ...)
méthode passive (IGP/BGP...)
méthode active (sondes)
•
•
20 / 55
pour
ensemble des Sgtes ayant le document
réponse rapide + infos à jour
•
•
www.example.com A ?
www.example.com A ? [client-subnet =
192.168.130.1/24]
www.example.com A 192.168.1.1 [client-subnet =
192.168.0.0/16]
www.example.com A 192.168.1.1
client
requête
à la demande
à l'avance
à secret sauce
•
Akamai
•
trouver un
surrogate
raisonnable
21 / 55
Redirection, cas simple : routage intra AS
•
approche active/à l'avance
•
décision centralisée
•
clusters de
•
pop (agrégats de clients)
•
charge des services dans chaque
Redirection, cas plus compliqué
•
•
surrogates
• 6=
•
chaque cluster probe tous les pops
•
association
à
associations pop
{ réseaux } (ex.
proto. routage)
cluster
pop
probe
rapport
•
données historiques et temps réel
position des clusters
ajouter les infos de :
•
•
cluster
à
•
tout client est dans un de ces réseaux
types de liens
•
•
(pop, service)
graphe de réseaux
•
cluster
•
construire topologie de l'internet
charge des clusters
classe de trac
maintenir le graphe à jour
décision
22 / 55
23 / 55
Source des données
Débit d'un chemin : Packet pair I
1 lien à 100 Mb/s
Passive
•
•
infos des protocoles de routage
•
•
•
•
•
intra-domaine
BGP
OSPF
RIP
à
à
à
2 lien goulot à 1 Mb/s
topologie
•
distances en nb de n÷uds
traces de trac
•
géo-localisation
tps de transmission
12,5·103 ×8
106
= 100
ms
3 retour sur lien à 100 Mb/s
AS path length
•
j'envoie 2 paquets de 12500 octets, dos-à-dos
12,5·103 ×8
tps de transmission
100·106 = 1 ms
•
les paquets sont espacés...
... mais impact possible d'autres paquets
Active
latence : echo ICMP (ping)
pertes ...
débit
• packet pair : débit lien goulot
• packet train : débit disponible
24 / 55
25 / 55
Débit d'un chemin : Packet pair II
P2
Une méthode originale : DNS boomerang
DNS
P1
1
2
1 ms 1 ms
ou Flash DNS ou DNS ooding
•
P2
2
•
P1
100 ms
100 ms
P2
S
1ère arrivée gagne
•
proximité réseau
•
si serveurs chargés
S
1
à
3
retarder la
réponse
P1
3
1 ms
B
2
les clusters répondent
•
1 ms
routage très simple !
B
3
R
100 ms
S
C
26 / 55
27 / 55
Distribution : réplication
•
Réplication : copie
Réplication
•
•
Pull
copie
•
•
•
push
synchronisation (cohérence)
•
multicast ?
•
•
•
où chercher le contenu ?
•
•
•
pull
Push
•
O
contrôle de ux (hétérogénéité)
hiérarchie
28 / 55
?
déterminer les routes possibles
choisir la meilleure (distance réseau +
charge serveur)
support du multicast...
S
voisins
forme de routage
•
•
problème de la abilité
origine
S
S
29 / 55
Réplication : ex d'Akamai
ESI - contrôle des surrogates
O
Edge Side Includes
Akamai/Oracle/... '01
SCntl: max-age=60;s1, max-age=300
hiérarchie de clusters
•
documents chauds dans les clusters feuilles
•
documents froids dans les parents
•
•
extension au protocole HTTP
•
choisis selon l'état du réseau
requête
S s'identie et indique ses
optimise espace cache
S1
SCap: s2="Surrogate/1.0"
capabilities
augmente performances
pb : dynamisme (charge/crash)
•
s1="Surrogate/1.0, ESI/1.0"
Surrogate-Capabilities:
répartition dans chaque cluster
•
•
•
SCap: s2="Surrogate/1.0";
(nouveaux en-têtes)
•
réponse
S2
Surrogate-Control:
consistent hashing
O indique à S comment
traiter le contenu de la
réponse
U
30 / 55
31 / 55
Réplication : synchronisation
maintenir la cohérence des
• surrogate
•
•
•
surrogates
ESI invalidation protocol
O
avec l'origine
= serveur ayant autorité
•
invalidation de contenu
mises à jour
⇐ POST ... msg-inv-XML
⇒ 200 OK msg-result-XML
multicast
•
Web Cache Invalidation Protocol '01
Resource Update Protocol '02 (IETF)
WCIP
RUP
POST msg-inv-xml
XML (port 4001)
• content signaling
• tentatives échouées
•
•
requête HTTP POST avec doc
•
invalidation par
•
•
•
•
(IETF/Cisco)
ESI invalidation protocol
S
URI
préxe
regexp URI et en-tête
...
U
32 / 55
33 / 55
O⇒S POST /x-invalidate HTTP/1.0
Authorization: Basic aW52YWxpZGF0b3I6aW52YWxpZGF0b3I=
Content-Length: 217
Leases (Baux)
<?xml version="1.0" ?>
<!DOCTYPE INVALIDATION SYSTEM "invalidation.dtd">
<INVALIDATION VERSION="WCS-1.0">
<OBJECT>
<BASICSELECTOR URI="/cache.htm" />
</OBJECT>
</INVALIDATION>
•
gestion classique, choix entre :
•
•
•
à
états
côté client (revalidation systématique)
compromis :
•
S⇐O HTTP/1.1 200 OK
...
Content-Length: 284
côté serveur (invalidation)
lease
à
msgs
(bail) {obj,S,d}
O s'engage à notier S des modifs de obj pendant d
⇐ Lease-Control: Grant-Lease | Renew-Lease ...
•
<?xml version="1.0"?>
<!DOCTYPE INVALIDATIONRESULT SYSTEM "invalidation.dtd">
<INVALIDATIONRESULT VERSION="WCS-1.0">
<OBJECTRESULT>
<BASICSELECTOR URI="/cache.htm" />
<RESULT ID="1" STATUS="SUCCESS " NUMINV="1"/>
</OBJECTRESULT>
</INVALIDATIONRESULT>
Distribution de
cohérence forte
⇐ Invalidate-Lease: ...
⇒ Invalidate-Ack: ...
O attend les ACK ou n du bail pour modier obj
35 / 55
stream
Stream live : les problèmes
encodeur
• stream
•
•
•
•
contraintes temporelles internes
congestion
l'application gère un tampon
délai de démarrage acceptable
stream à la demande
•
•
•
à
surcharge
E
: non élastique
juste un chier...
... oui mais gros
le serveur est surchargé
•
son réseau d'accès est saturé
•
la traversée de l'internet est longue
délais/pertes
et dangereuse...
... et occupe longtemps le serveur
• prex caching puis transfert
• segmentation des chiers et
•
élastique de la suite
répartition sur les surrogates
U
36 / 55
U
U
U
37 / 55
Stream live : architecture
middle mile
Stream live : qualité du
encodeur
first mile
•
E
surrogates sont des serveurs de
entry point
EP
stream
•
•
pb : perte de paquets
•
TCP pas adapté (contrôle de congestion, tempo de
retransmission)
groupés en clusters
last mile
•
• entry point à rst mile
• serveurs de transport : set reectors
•
•
•
•
SR
UDP avec ajout correction de perte
•
•
set reflector
paquet de redondance
tolère un paquet perdu parmi k
XOR bit à bit
duplication (donc 4 niveaux)
stream servers
contourne routage BGP
SS
corrige les pertes
SS
SS
paquet 1
paquet 2
paquet k
redondant
last mile
U
U
U
U
38 / 55
Stream live : qualité du
middle mile
Middle mile : coupure réseau
SR1
retransmission au mieux
•
émetteur garde les n derniers paquets en tampon
•
récepteur envoie NAK si détecte perte
• reçu no n+k, toujours pas reçu no n,
•
émetteur retransmet
diversité :
multipath
39 / 55
880 − 900
980
800
SR2
880 − 900
980
800
•
ER élu ne récoit plus
à
•
subscribe
880 −980
si tjs dans le tampon
bascule sur un autre SR
prebursting
•
•
émettre plus vite au début
donc depuis le passé
(tampon de
retransmission du SR)
880 − 900
980
800
• à
rattrape les pertes !
SS
40 / 55
41 / 55
Application delivery network
Optimiser l'acheminement
transport
bidirectionnel
S ne cache pas, mais permet :
•
(routage à la couche
la plupart des documents ne sont pas cachables
application)
•
•
•
•
•
délais
T
transport server
TCP non persist.
optimisation du protocole de
transport
1 optimiser l'acheminement
TCP persistant
optimisation du chemin
Sites Web dynamiques, applications web...
Deux stratégies :
O
transport opt.
congestion
connexions persistantes
contrôle de
T
ux/congestion
quantité données
•
2 déplacer (une partie de) l'application en bordure
•
retransmissions rapides
transport opt.
optimisation de la couche
S
application
•
S pré-charge les objets
embarqués
•
app server
U
compression
TCP persistant
42 / 55
43 / 55
Déplacer l'application
Répartir l'application
Les applications avec transactions temps réel ne peuvent pas être
ex Akamai EdgeComputing
•
complètement déplacées.
Archi classique MVC :
plateforme pour exécuter des (composants d') Applications
Java2EE
Model le c÷ur de l'appli (règles, BD)
View représentation (sortie)
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
Controller entrées
boutiques...)
•
•
déplacer la partie interface (view et controller)
•
réduire les échanges au minimum nécessaire
•
•
collecte de données (formulaires)
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 Side Includes
ESI I
•
inclusion (fragments ont leurs propres métadonnées cachabilité etc)
•
(contrôle des surrogates, protocole d'invalidation)
•
•
assemblage dynamique de fragments en bordure
•
variables (basés sur attributs de la requête HTTP, à la CGI)
fragment
•
traitement conditionnel
•
exception, gestion des erreurs (ressources alternatives ou par
•
•
paramétres de cohérence
partagés par les utilisateurs
défaut)
• template
U
<esi:include src="http://example.com/1.html"
alt="http://bak.example.com/2.html" onerror="continue"/
<esi:include
src="http://example.com/search?query=$(QUERY_STRING{query})"/>
template + fragments
O
S
U
<esi:inline name="URI" fetchable="yes | no">
fragment to be stored within an ESI processor
</esi:inline>
assemblage
dynamique
46 / 55
47 / 55
ESI 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
•
besoin de générer une vision globale
•
•
48 / 55
surrogates
•
pour le fournisseur de contenu
pour l'opérateur de CDN
•
scalabilité ?
•
structure hiérachique (multicast inverse)
49 / 55
Qui utilise des CDN ? I
;; QUESTION SECTION:
;www.microsoft.com.
IN
A
;; ANSWER SECTION:
www.microsoft.com.
1996
toggle.www.ms.akadns.net. 614
g.www.ms.akadns.net.
614
lb1.www.ms.akadns.net. 1169
IN
IN
IN
IN
CNAME
CNAME
CNAME
A
;; QUESTION SECTION:
;www.apple.com.
IN
A
;; ANSWER SECTION:
www.apple.com.
590
IN
www.isg-apple.com.akadns.net. 590 IN
www.apple.com.edgekey.net. 590 IN
e3191.dscc.akamaiedge.net. 1521 IN
CNAME
CNAME
CNAME
A
Qui utilise des CDN ? II
;; QUESTION SECTION:
;www.yahoo.com.
toggle.www.ms.akadns.net.
g.www.ms.akadns.net.
lb1.www.ms.akadns.net.
64.4.11.42
;; ANSWER SECTION:
www.yahoo.com.
535
fd-fp3.wg1.b.yahoo.com. 535
ds-fp3.wg1.b.yahoo.com. 535
ds-eu-fp3-lfb.wa1.b.yahoo.com.
ds-eu-fp3.wa1.b.yahoo.com. 708
ds-eu-fp3.wa1.b.yahoo.com. 708
;; QUESTION SECTION:
;www.fda.gov.
www.isg-apple.com.akadns.net.
www.apple.com.edgekey.net.
e3191.dscc.akamaiedge.net.
92.123.229.15
IN
IN
IN
IN
535 IN
IN
IN
IN
;; ANSWER SECTION:
www.fda.gov.
226
IN
www.fda.gov.edgesuite.net. 226 IN
a1715.dscb.akamai.net. 226
IN
a1715.dscb.akamai.net. 226
IN
A
CNAME
CNAME
CNAME
CNAME
A
A
fd-fp3.wg1.b.yahoo.com.
ds-fp3.wg1.b.yahoo.com.
ds-eu-fp3-lfb.wa1.b.yahoo.com.
ds-eu-fp3.wa1.b.yahoo.com.
87.248.122.122
87.248.112.181
A
CNAME
CNAME
A
A
www.fda.gov.edgesuite.net.
a1715.dscb.akamai.net.
213.152.6.112
213.152.6.98
;; QUESTION SECTION:
50 / 55
51 / 55
Qui utilise des CDN ? III
CDN / caches web
qu'est-ce qui les diérencie ?
;blog.lemonde.fr.
IN
A
;; ANSWER SECTION:
blog.lemonde.fr.
919
IN
CNAME
blog.lemonde.fr.2-01-271d-000c.cdx.cedexis.net.
wac.3604.edgecastcdn.net. 1895 IN
CNAME
gp1.wac.edgecastcdn.net. 1896 IN
A
blog.lemonde.fr.2-01-271d-000c.cdx.cedexis.net.
955 IN CNAME wac.3604.edgecastcdn.net.
gp1.wac.edgecastcdn.net.
93.184.220.20
•
redirection ? mais caches transparents
•
push ?
•
systèmes hybrides
•
Émergence des Telco CDN ?
7→
fédération de CDNs
cdni WG, créé en juin 11
http://datatracker.ietf.org/wg/cdni/
IETF
Content Networks
52 / 55
53 / 55
Qu'est-ce qu'un CDN ?
Quelques sources
Les CDN...
1 partagent dynamiquement l'infrastructure de réplication
•
les RFC mentionnés
•
Akamai facts :
http://www.akamai.com/html/about/facts_figures.html
2 utilisent les URL classiques
Nygren (Erik), Sitaraman (Ramesh K.) et Sun (Jennifer). 3 fournissent un espace de noms adapté
The akamai network: A platform for high-performance internet
2 et 3 paraissent contradictoires
applications. ACM SIGOPS Operating Systems Review, vol. 44, n 3, 2010.
Un CDN est :
Kontothanassis (Leonidas), Sitaraman (Ramesh), Wein (Joel), Hong
•
une infrastructure de réplication
•
un changement de sémantique de l'espace de noms URL
(Duke), Kleinberg (Robert), Mancuso (Brian), Shaw (David) et Stodolsky.
(Daniel). A transport layer for live streaming in a content delivery network.
Proceedings of the IEEE, Special Issue on Evolution of Internet
Technologies,
54 / 55
vol. 92, n 9, septembre 2004, pp. 14081419.
55 / 55