UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Proxies y CDN
• Distribución:
– Proxy Cachés
– Content Distribution Networks
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• La evolución de HTTP
• Proxy Caches
• Validación de la cache
• Características del tráfico Web
• Problemas de los Proxy Caches
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
La evolución de HTTP
• HTTP 0.9/1.0
– Una petición/una respuesta por conexión TCP
• Muy sencillo de implementar
• Desventajas
– Muchas conexiones por cada web Three-
way handshake cada vez
• Muy lento
– TCP empieza con “Slow Start”
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
La evolución de HTTP
• Las transferencias pequeñas son ineficientes
con TCP
– Slow Start
• Muchas conexiones en el servidor
– Debe gestionarlas todas (estado)
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
HTTP/1.1 Persistente
• HTTP/1.1 es persistente
– Permite enviar más de un objeto en una misma
conexión TCP
• Problema:
– 1 Web consiste en 1 HTML de N bits y M
imágenes de N bits cada una
– Si R es el rate al que el cliente es capaz de
enviar/recibir la información calcula el tiempo
que tardaría en descargarse la web en HTTP/1.0
y HTTP/1.1
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Evolución de HTTP
• Internet siguió creciendo exponencialmente,
tanto en número de usuarios como en la
cantidad de contenido
– Los servidores y los enlaces se saturaron
– Los usuarios se frustran
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
La evolución de HTTP
• “With 25 years of Internet experience,
we’ve learned exactly one way to deal with
the exponential growth: Caching”
– Van Jacobson, 1997
– Y de eso se trata, sólo cambia el modelo de
negocio
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• La evolución de HTTP
• Proxy Caches
• Validación de la cache
• Características del tráfico Web
• Problemas de los Proxy Caches
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Proxy Caches
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Proxy Caches
• Reducen el BW en los ISPs
• Reducen la latencia de los clientes
• Proporcionan buen rendimiento porque
– Un cliente accede repetidamente a los mismos
documentos
– Los clientes cercanos también acceden al
mismo documento
• El número de hits aumenta
logarítmicamente con el número de usuarios
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Proxy Caches
• user sets browser: Web accesses via cache
• browser sends all HTTP requests to cache
– object in cache: cache returns object
– else cache requests object from origin server, then returns object to client
Goal: satisfy client request without involving origin
server
client
Proxyserver
clientorigin server
origin server
Computer Networking: A Top Down
Approach Featuring the Internet,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2002.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Proxy
• Proxy: Intermediario en una discontinuidad, para …
– Cambiar de red (NAT), control seguridad, aprovechar peticiones
• Proxy Caché:
– Guarda copias de documentos en disco (o memoria). Disponible si se
vuelven a pedir los mismos documentos.
– Reducción de tráfico (BW) y tiempo de espera si objeto está en caché
(latencia)
– Algunos objetos no se puede cachear (privados, dinámicos, de pago): Si
tiene: WWW-Authenticate,Pragma:no-cache,Cache-
control:private,Cache-control:no-cache
– ICP: Presencia/ausencia URL en proxy /UDP (rfc2168,2187)
– Cache-Digest: Intercambio periódico de hash contenido caché. Proxy
puede redirigir petición a caché adecuada (probable)
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Distribución: Proxy• Proxy: Intermediario en una discontinuidad, para …
– Cambiar de red (NAT), control seguridad (firewall),
aprovechar peticiones (caché…)
– Acepta peticiones de clientes y las reenvía a otros
intermediarios, al servidor origen, o las sirve
directamente (ej. de su caché). Actúa como cliente y
servidor.
• Transparente: Router intercepta y redirecciona peticiones a
proxy
NavegadorServidorOrigen
Proxy Proxy
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Internet Topology
C C C C
ISP ISPISP
C
OC OC
Tier-2
Tier-1’s
Tier-2
Customers
8898 ASes[30]
Small ISPs
971 ASes[30]
Outer Core
897 ASes[30]
Transit Core
129 ASes[30]
Core
20 ASes[30]
-17.000 Ases[28]
-More than 50% have
more than one link[43]
-The Internet has a
certain hierarchy[30]
-Connectivity across
levels is not strictly
hierarchical[30]
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• La evolución de HTTP
• Proxy Caches
• Validación de la cache
• Características del tráfico Web
• Problemas de los Proxy Caches
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Validación de la Cache
• ¿Cada cuánto y cuándo debería validarse el
documento cacheado con el original?
– Cada hora/día?
– Cada sesión?
• ¿Cómo se valida el documento?
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Ejemplo cabecera respuesta
HTTP/1.1
Servidor origen:
HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: "3e86-410-3596fbbc"
Content-Length: 1040 Content-Type: text/html
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Ejemplo petición validar objeto
en caché
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Mon, 29 Jan 2001 17:54:18 GMT
If-None-Match: "7a11f-10ed-3a75ae4a"
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: www.intel-iris.net
Connection: Keep-Alive
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Ejemplo respuesta validar objeto en
caché
HTTP/1.1 304 Not Modified
Date: Tue, 27 Mar 2001 03:50:51 GMT
Server: Apache/1.3.14 (Unix) (Red-Hat/Linux)
mod_ssl/2.7.1 OpenSSL/0.9.5a DAV/1.0.2
PHP/4.0.1pl2 mod_perl/1.24
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
ETag: "7a11f-10ed-3a75ae4a"
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Proxies en HTTP/1.1• Cache-Control:
– Petición
– Respuesta
Public Se puede cachear por proxies y cliente
Private Sólo caché cliente
Private=“cabc” Todos pueden excepto cabecera cabc: sólo caché cliente
No-cache Cacheable pero solo si antes se valida correctamente
No-cache=“cabc” Obliga a validar solo cabc
No-store Nadie puede almacenar los datos, ni cliente ni proxy
No-transform Proxies no pueden transformar el contenido
Must-revalidate Revalidar (con origen) si es necesario (solo si caducado)
Max-age Margen de tiempo de vida de la caché en segundos
No-cache Cliente origen (cachés se inhiben)
No-store Proxy no debe almacenar permanentemente
Petición/respuesta
Max-age=sgs Máx "edad" aceptable obj en cachés
Max-stale Se aceptan objs viejos
Max-stale=sgs Se aceptan objs sgs segundos viejos
Min-fresh=sgs Obj ha de quedarle sgs de vida
Only-if-cached Petición si sólo está en caché
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Servidor origen
Apache: modulos
mod_expires: especificar Expires
mod_headers: especificar HTTP cabeceras
.htaccess file### activate mod_expires
ExpiresActive On
### Expire .gif's 1 month from when they're accessed
ExpiresByType image/gif A2592000
### Expire everything else 1 day from when it's last modified
### (this uses the Alternative syntax)
ExpiresDefault "modification plus 1 day"
### Apply a Cache-Control header to index.html
<Files index.html>
Header append Cache-Control "public, must-revalidate"
</Files>
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• La evolución de HTTP
• Proxy Caches
• Validación de la cache
• Características del tráfico Web
• Problemas de los Proxy Caches
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Servicio Web: Características de la demanda
• Varios problemas (World-Wide Wait):
– Proveedor: planificación de capacidad
• para dar servicio (horas punta: carga, avalancha)
– Cliente: Elección del mejor servidor (si hay más de 1)
• El original o una réplica "rápida" (o varios en ||)
– Réplica: que alguien la use (conocimiento, consistencia)
• Que mis clientes lo sepan, que el contenido sea consistente, …
– Proveedor de Red:
• Elegir el mejor camino para la petición, via routing IP, via DNS, via
cachés HTTP y evitar "hot spots" o "flash crowd“
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Tráfico en los servidores• La demanda que experimenta un servidor varía
extremadamente (comportamiento fractal, “heavy tailed”,
auto-similar, …)
– Ocurre en sistemas complejos, gran población y con
memoria
– El valor medio puede ser poco probable …
Evolución del tráfico entrante y saliente en un sitio web típico durante una semana. Puede verse la
gran variación horaria y la reducción de tráfico durante el fin de semana.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
“Efecto Slashdot”
Efecto “slashdot” en http://counter.li.org.
Más información en: http://counter.li.org/slashdot/
On February 23, 1999, around 15:43 European Time, the Linux Counter was listed on Slashdot,
causing a breakdown of services.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
“Efecto Slashdot” (II)On Thursday, February 25, 1999, at 11:07 their time, they did it again.
Una semana:
Slashdot I & II
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Demanda sigue Ley de Zipf
• George Kingsley Zipf (1902-1950)
– La frecuencia de ocurrencia de cierto evento (P) como función del rango (i) cuando el rango viene determinado por la frecuencia de ocurrencia, es una función potencial Pi ~1/ia, con el exponente a cercano a la unidad.
– Frecuencia de palabras en Inglés. En 423 artículos de la revista TIME (245.412 palabras), “the” es la que más aparece: 15.861, “of” en segundo lugar: 7239 veces, “to” en tercer lugar: 6331 veces
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Un caso …
– Número de visitas de las páginas de www.sun.com ordenadas por
popularidad. Se ajusta bastante a una distribución de Zipf.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• La evolución de HTTP
• Proxy Caches
• Validación de la cache
• Características del tráfico Web
• Problemas de los Proxy Caches
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Problemas técnicos de las cachés
• Objetos no cacheables
– Datos dinámicos: Bolsa, precios…
– Resultadods depende de parámetros (CGIs)
– Datos Cifrados (SSL)
• Transferencias canceladas
• Objetos que caducan antes de ser re-
utilizados
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
¿Por qué no Proxy Caches?
• HTTP evolucionó para soportar caches
• Sin embargo, las web caches se
desarrollaron desde la prespectiva de un ISP
– El ISP lo despliega
– El objetivo del ISP es reducir BW
• Sin embargo el BW es barato
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
El punto de vista de los
Content Providers
• Los proveedores de contenidos se preocupan por:
– La latencia de sus usuarios
– Evitar “flash crowds”
– Minimizar BW en su red
– Tener estadísticas de acceso
• En un mundo ideal, las caches de los ISPs
cooperarían…
• Los proveedores de contenidos respondieron a las
cachés con “No-Cache”
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
¿Cómo reaccionaron inicialmente
los Content Providers?
• Inicialmente usaron red con mirrors:
– Pero prefieren ceder el control a otra empresa
• Las Content Distribution Networks
construyen una red overlay de caches que
proporcionan un acceso rápido, barato y
fiable.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Proxies y CDN
• Distribución:
– Proxy Cachés
– Content Distribution Networks
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• Problema a resolver y algo de historia
• ¿Qué tienen de malo los Proxy Caches?
• Content Distribution Networks
• Un ejemplo práctico: Akamai
• Futuro de las CDNs
• Rendimiento de las CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
El Problema
• Internet ha crecido exponencialmente, tanto
en número de usuarios como en la cantidad
de contenido
– Los servidores y los enlaces se saturaron
– Los usuarios se frustran
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Algo de historia…
• “With 25 years of Internet experience,
we’ve learned exactly one way to deal with
the exponential growth: Caching”
– Van Jacobson, 1997
– Y de eso se trata, sólo cambia el modelo de
negocio
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Algo de historia…
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Algo de historia…
• Proxy Caches
• Reducen el BW en los ISPs, reducen la latencia de los
clientes y evitan “flash crowths”
• Proporcionan buen rendimiento porque
• Un cliente accede repetidamente a los mismos
documentos
• Los clientes cercanos también acceden al mismo
documento
• El número de hits aumenta logarítmicamente con el
número de usuarios
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Algo de historia…
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• Problema a resolver y algo de historia
• ¿Qué tienen de malo los Proxy Caches?
• Content Distribution Networks
• Un ejemplo práctico: Akamai
• Futuro de las CDNs
• Rendimiento de las CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
¿Por qué no Proxy Caches?
• HTTP evolucionó para soportar caches
• Sin embargo, las web caches se
desarrollaron desde la prespectiva de un ISP
– El ISP lo despliega
– El objetivo del ISP es reducir BW
• Sin embargo el BW es barato
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
El punto de vista de los
Content Providers
• Los proveedores de contenidos se preocupan por:
– La latencia de sus usuarios
– Evitar “flash crowds”
– Minimizar BW en su red
– Tener estadísticas de acceso
• En un mundo ideal, las caches de los ISPs
cooperarían…
• Los proveedores de contenidos respondieron a las
cachés con “No-Cache”
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
¿Cómo reaccionaron inicialmente
los Content Providers?
• Inicialmente usaron red con mirrors:
– Pero prefieren ceder el control a otra empresa
• Las Content Distribution Networks
construyen una red overlay de caches que
proporcionan un acceso rápido, barato y
fiable.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• Problema a resolver y algo de historia
• ¿Qué tienen de malo los Proxy Caches?
• Content Distribution Networks
• Un ejemplo práctico: Akamai
• Futuro de las CDNs
• Rendimiento de las CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
CDNs
• Content Distribution Networks:
– Proporcionan control sobre el contenido
– Evitan cuellos de botella
– Evitan “flash crowds”
– Eliminan problemas de escalabilidad
– Aumentan la seguridad
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
CDNs
• Las CDNs se usan para:
– Servir contenido a los usuarios por parte de
grandes proveedores de contenidos
– Minimizar “flash crowds”
– Disminuir el BW
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
CDNs: Cómo Funcionan
• 2 técnicas para redirigir peticiones a servidores CDN:
– Redirección por DNS
Servidor DNS controlado por la infraestructura CDN. Distribuye las peticiones a servidores CDN según diferentes políticas (al menos cargado, al mas “próximo” al cliente (topología o geograficamente)
– Reescribir URL
Pagina principal viene de servidor origen, pero URL de objetos como gráficos está reescrita y apunta al servidor CDN.
(También se usan esquemas híbidos)
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
A DNS-redirecting CDN
DNS
redirector
Client
HTTP
server
HTTP
server
HTTP
serverA
B
C
example.com ?
B
GET http://example.com/foo
http://example.com/foo
Network
Model
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
CDN example
origin server
• www.foo.com
• distributes HTML
• Replaces:
http://www.foo.com/sports.ruth.gif
with
http://www.cdn.com/www.foo.com/sports/ruth.gif
HTTP request for
www.foo.com/sports/sports.html
DNS query for www.cdn.com
HTTP request for
www.cdn.com/www.foo.com/sports/ruth.gif
1
2
3
Origin server
CDNs authoritative
DNS server
Nearby
CDN server
CDN company
• cdn.com
• distributes gif files
• uses its authoritative DNS
server to route redirect requests
Content distribution networks are coordinated caching systems ?
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
nslookup
acabello@ranci:~$ nslookup www.microsoft.com
Server: 147.83.130.132
Address: 147.83.130.132#53
Non-authoritative answer:
www.microsoft.com
canonical name = toggle.www.ms.akadns.net.toggle.www.ms.akadns.net
canonical name = g.www.ms.akadns.net.g.www.ms.akadns.net
canonical name = lb1.www.ms.akadns.net.
Name: lb1.www.ms.akadns.net
Address: 207.46.18.30
Name: lb1.www.ms.akadns.net
Address: 207.46.20.30
Name: lb1.www.ms.akadns.net
Address: 207.46.20.60
Name: lb1.www.ms.akadns.net
Address: 207.46.198.30
Name: lb1.www.ms.akadns.net
Address: 207.46.198.60
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Ejemplo: Redirección parcial por DNS /
Reescritura URL
index.html
<HTML>
<BODY>
<A HREF=“/about_us.html”> About Us </A>
<IMG SRC=“www.clearway1.net/www.yahoo.com/img1.gif”>
<IMG SRC=“www.clearway2.net/www.yahoo.com/img2.gif”>
<IMG SRC=“10.20.30.2/www.yahoo.com/img3.gif”>
</BODY>
</HTML>
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• Problema a resolver y algo de historia
• ¿Qué tienen de malo los Proxy Caches?
• Content Distribution Networks
• Un ejemplo práctico: Akamai
• Futuro de las CDNs
• Rendimiento de las CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Un ejemplo concreto: Akamai
• Akamai (AH kuh my) es una palabra
Hawaiana que significa inteligente y “cool”.
• Se fundó en 1999 por estudiantes del MIT
• Se considera el primer CDN
• Más de 1250 proveedores de contenidos lo
suan. Tienen 14000 servidores en 40 países
• Sirven texto/imágenes/video
– 2000$ Mbps/mes
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Akamai: Funcionamiento
• Sistema hibrido
– Primero reescritura de URL
– Después redirección por DNS
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Akamai: Más información
• Hoy en día no se usa reescritura por URL
– Los proveedores de contenidos prefieren usar
técnicas de redirección por DNS para evitar
tener que gestionar los servidores
• Evolución:
– Ficheros/Streaming
– Páginas seguras
– Aplicaciones Distribuidas
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Cómo evita Akamai las Flash Crowds?
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Cómo evita Akamai las Flash Crowds?
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• Problema a resolver y algo de historia
• ¿Qué tienen de malo los Proxy Caches?
• Content Distribution Networks
• Un ejemplo práctico: Akamai
• Futuro de las CDNs
• Rendimiento de las CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Futuros retos de las CDNs
• Distribuir contenido web ha sido más sencillo de
lo esperado
– El BW y los servidores cada vez son más baratos
– P2P se está convirtiendo en una alternativa seria a
CDNs
• El contenido local tiene cada vez más importancia
• Gestionar 14000 servidores es difícil y costoso.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
El futuro de las CDNs
• Cada vez los ISPs se conectan más
directamente a los Content Providers
• Las CDNs aún tienen que crecer en paises
donde el BW es escaso
• Es previsible que P2P se quede con algo del
negocio de las CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Rendimiento de CDNs
Aspectos:
• Latencia percibida por cliente (navegador)
selección del servidor
• Balanceo de carga entre servidores CDN
• Carga de peticiones asumida por servidores
CDN (librando carga servidor origen)
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Índice
• Problema a resolver y algo de historia
• ¿Qué tienen de malo los Proxy Caches?
• Content Distribution Networks
• Un ejemplo práctico: Akamai
• Futuro de las CDNs
• Rendimiento de las CDNs
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Experimento: Evaluar la selección de servidor CDN
• CDN Akamai (redirección parcial por DNS)
• Utilizar cliente en tres ubicaciones diferentes en EEUU
• Experimento
– Obtener direcciones IP de servidores CDN
– Identificar fichero GIF (3-4KB). Obtener este GIF de cada servidor CDN
25 veces. Guardar tiempos.
– Obtener el mismo fichero GIF de CDN . Guardar tiempos.
Objetivo: Evaluar
1) Se reduce la latencia percibida en un cliente (navegador)
cuando utiliza una CDN ?
2) CDN elige “bien” ?
Setup del experimento:
Fuente: K. Johnson et al. “The Measured Performance of Content Distribution Networks. 2000.
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Where We Measured
Our location
name
Geographic
location
OS Narrowest
bandwidth to
Internet
A/X Waltham, Massachusetts,
USA
RedHat
Linux 5.1
T1
B/Y Cambridge, Massachusetts,
USA
SunOS
5.5.1
10 Mb/s
Ethernet
C/Z Boulder, Colorado, USA
BSDI 3.1 T1
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Resultados
• No elige el mejor servidor CDN
• En >90% de los casos elección buena
del servidor respecto a ubicación del
cliente.
• En 10% elección aleatorio del servidor
hubiera sido mejor. .
http://www.terena.nl/conf/wcw/Proceedings/S4/S4-1.pdf
Akamai, location A
UN
IVE
RS
ITA
T P
OL
ITÈ
CN
ICA
DE
CA
TA
LU
NY
A
Resultados (II)Akamai, location B Akamai, location C
• Rendimiento de CDN depende de ubicación del cliente: A bien, B muy bien, C
regular
• Conclusion: CDN no elige el mejor servidor CDN, pero evita elegir
servidores CDN de poco rendimiento