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