Proxies y CDN

• Distribución:– Proxy Cachés– Content Distribution Networks

Web caches (proxy server)

• 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

client

HTTP request

HTTP request

HTTP response

HTTP response

HTTP request

HTTP response

origin server

origin server

Computer Networking: A Top Down Approach Featuring the Internet,

2nd edition. Jim Kurose, Keith Ross

Addison-Wesley, July 2002.

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)

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

Navegador ServidorOrigen

Proxy Proxy

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

Ejemplo petición validar objeto en caché

GET / HTTP/1.1Accept: */*Accept-Language: en-usAccept-Encoding: gzip, deflateIf-Modified-Since: Mon, 29 Jan 2001 17:54:18 GMTIf-None-Match: "7a11f-10ed-3a75ae4a"User-Agent: Mozilla/4.0 (compatible; MSIE 5.5;

Windows NT 5.0)Host: www.intel-iris.netConnection: Keep-Alive

Ejemplo respuesta validar objeto en caché

HTTP/1.1 304 Not ModifiedDate: Tue, 27 Mar 2001 03:50:51 GMTServer: 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-AliveKeep-Alive: timeout=15, max=100ETag: "7a11f-10ed-3a75ae4a"

Camposhttp://www.ac.upc.esNetscape: View -> Page Info

Location:

http://www.ac.upc.es/

File MIME Type:

text/html

Friday, 07-Nov-03 02:39:28 Local time

Last Modified:

Friday, 07-Nov-03 01:39:28 GMT

Content Length:

5283

Expires:

No date given …..

Department of Computer Architecture has the following structure:

http://www.ac.upc.es/

Form 1:

Action URL: http://www.ac.upc.es/cgi-bin/perlfect/search/search.pl

Encoding: application/x-www-form-urlencoded (default)

Method: Get

Image: http://www.ac.upc.es/imatges/dacTitle,en.gif

Image: http://www.ac.upc.es/imatges/logo.gif

Image: http://www.ac.upc.es/imatges/selectLang,en.gif

Image: http://www.ac.upc.es/imatges/mapaButton,en.gif …

http://www.ac.upc.es

  -

  -

7 hr 57 min ago  (Mon, 03 Nov 2003 01:15:57 GMT) validated

"37e4c-13ce-3fa5ac4d"

5.0K (5070)

Apache

Expires  

Cache-Control  

Last-Modified  

ETag  

Content-Length  

Server  

This object doesn't have any explicit freshness information set, so a cache may use Last-Modified to determine how fresh it is with an adaptive TTL (at this time, it could be, depending on the adaptive percent used, considered fresh for: 1 hr 35 min (20%), 3 hr 58 min (50%), 7 hr 57 min (100%)). It can be validated with Last-Modified.

Cacheability

(image/gif)

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é

Servidor origenApache: modulos mod_expires: especificar Expiresmod_headers: especificar HTTP cabeceras

.htaccess file### activate mod_expires ExpiresActive On ### Expire .gif's 1 month from when they're accessedExpiresByType 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>

Proxy Caché:• Caché: almacén de mensajes de respuesta +

control de almacén (entrar, salir, borrar)– Reducción de tráfico (BW) y tiempo de espera si está en caché

(latencia). mejorar rendimiento (“performance”)– Algunos objetos no se puede cachear (privados, dinámicos, de

pago):• WWW-Authenticate, Cache-control:private, Pragma:no-cache,

Cache-control:no-cache, ...– Pasiva: aprovechar respuestas a peticiones de usuarios– Activa: acumular docs de interés en horas de bajo tráfico– Varios servidores de caché pueden cooperar … jerarquía

GET http://www.ac.upc.es/docencia/ HTTP/1.0User-agent: Mozilla/4.0Accept: text/html, image/gif, image/jpeg

GET /docencia/ HTTP/1.0User-agent: Mozilla/4.0Accept: text/html, image/gif, image/jpegForwarded: by http://proxy.ac.upc.es:8080

Relación entre proxies• ICP: Presencia/ausencia URL en proxy /UDP (rfc2168,2187)

–Medir tiempo respuesta de proxies–Localizar: Entre proxies pero puede usarlo el cliente…–QUERY URL : HIT, MISS, HIT_OBJ (16Kb), MISS_POINTER, ERR, DENIED

• Cache-Digest: Intercambio periódico de hash contenido caché–Proxy puede redirigir petición a caché adecuada (probable)

• CARP: función de hash (URL) se pide según URL–Añadir/quitar servidores, aumentar utilización cachés

Navegador

ServidorOrigen

Proxy Proxy Proxy

Proxy Proxy

Proxy

ICP

HTTP

Sibling Parent

Web caching• Cache acts as both client

and server• Cache can do up-to-date

check using If-modified-since HTTP header

• Typically cache is installed by ISP (university, company, residential ISP)

Why Web caching?• Reduce response time for

client request.• Reduce traffic on an

institution’s access link.• Internet dense with caches

enables “poor” content providers to effectively deliver content

Computer Networking: A Top Down Approach Featuring the Internet,

2nd edition. Jim Kurose, Keith Ross

Addison-Wesley, July 2002.

Problemas cachésObjetos no cacheables:• Datos dinámicos: bolsa, precios, ...• Resultados depende de parámetros (CGIs, ...)• Datos encriptdos (SSL)

Consistencia• objeto ha caducado (“expired”) antes de ser reutilizado (“stale”)

Necesario primer acceso al objeto

Transferencias canceladas

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“

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.

“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.

“Efecto Slashdot” (II)On Thursday, February 25, 1999, at 11:07 their time, they did it again.

Una semana:Slashdot I & II

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 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.

Perfil típico de demanda Web•El tamaño medio de objeto=10-15 Kbytes, la mediana=2-4 Kbytes. Abundan objetos pequeños aunque se encuentra una cantidad no despreciable de objetos grandes (Mbytes).•La mayoría de accesos al Web es para objetos gráficos, seguido de documentos html. El 1-10% son objetos dinámicos.•Una página html tiene media 10 imágenes y varios enlaces a otras.•Un 40% de accesos para objetos considerados no cacheables.•Popularidad de objetos web muy dispar: una pequeña fracción de objetos responsable de la mayoría de accesos, sigue la ley de Zipf•El ritmo de acceso para objetos estáticos es mucho mayor que el ritmo de modificación.•En escala de tiempo inferior al minuto, el tráfico web es a ráfagas: valores medios durante decenas de segundo muy poco fiables.•Un 5-10% de accesos al Web se cancelan antes de finalizar.•Casi todos los servidores usan el puerto 80

Generadores de carga• Puede ser necesario probar la “capacidad” de nuestro servidor con

“demanda sintética”.– Apache JMeter

• Rendimiento servidor en documentos y recursos estáticos y dinámicos (archivos, Servlets, scripts Perl, objetos Java, consultas a bases de datos, servidores FTP Servers, etc).Simula diferentes tipos de carga extrema de la red, el servidor o un cierto objeto

– http://jakarta.apache.org/jmeter– Surge

• genera peticiones Web con características estadístiscas que simulan con mucha precisión la demanda típica de un servidor web

– http://www.cs.bu.edu/faculty/crovella/links.html– Microsoft Web Application Stress o WAS

• Prueba un sitio con IIS + ASP– http://webtool.rte.microsoft.com

Estadística carga en servidorSummary by Month

MonthDaily Avg Monthly Totals

Hits Files Pages Visits Sites KBytes Visits Pages Files Hits

May 1999 6377 5570 903 455 10484 884568 14119 28004 172671 197696Apr 1999 6216 5394 858 419 10087 821968 12594 25758 161844 186504Mar 1999 7530 6582 1046 499 12128 1052978 15480 32432 204059 233445Feb 1999 4712 4128 656 321 6629 511793 8048 16419 103203 117816Jan 1999 4470 3934 607 284 8079 605694 8808 18844 121980 138571Dec 1998 2998 2673 411 197 6524 410110 6120 12769 82875 92951Nov 1998 2910 2567 400 192 4260 346705 5588 11627 74468 84403Oct 1998 3052 2668 457 202 2203 189253 2839 6399 37360 42738Sep 1998 2072 1826 345 169 3475 314492 5075 10376 54807 62165Aug 1998 1014 901 211 125 2693 196560 3890 6571 27958 31455Jul 1998 1484 1325 302 184 4041 298225 5716 9383 41102 46019Jun 1998 1707 1502 322 222 4809 251502 6675 9687 45077 51227

Totals 5883848 94952 188269 1127404 1284990

Visualización de carga• Analizadores de logs del servidor web

– http://www.mrunix.net/webalizer/ • Logs dan información algo imprecisa (segs, nivel aplicación)

Servidores replicados• Cuando la carga aumenta puede aumentarse el número de servidores (misma

ubicación: consistencia y reparto carga)– El primer web con una demanda importante fue http://www.ncsa.uiuc.edu.

Tuvo que usar 4 servidores replicados para satisfacer la demanda. Julio de 1993 (91.000

peticiones/semana)y Abril de 1994

(1.500.000 peticiones/semana).

Reparto de carga entre varios servidores

• Varios “trucos” para repartir peticiones entre varias máquinas:– “Mirrors”: un programa que redirige la petición http a la réplica mejor – DNS devuelva varias direcciones IP (el modo “round robin”). Los clientes

pueden hacer peticiones http cada vez a una dirección IP distinta.– Redirección de transporte (“L4 Switch”): un router mira los paquetes IP de

conexiones TCP hacia un servidor Web (puerto 80) y las redirige a la máquina interna menos cargada

– Redirección a nivel de aplicación (“L7 Switch”): un router que mira las conexiones http y puede decidir a qué réplica contactar en función del URL solicitado. Muy complejo.

– Mandar todas las peticiones a un proxy inverso que responda o con contenido guardado en la caché o pase la petición a uno o varios servidores internos.

• Si además las réplicas se sitúan cerca de los clientes, mejor rendimiento y más predecible. Inconveniente: difícil y caro montar servicio Web distribuido.

Servidor de web distribuido• ¿Basta 1 único servidor para cualquier "audiencia"?• Un servidor web distribuido compartido …• CDN: Redes de Distribución de Contenidos

– Propietarias o genéricas: Akamai, Digital Islands, Adero, etc…

– Servicio de “Logística”: multitud de puntos de servicio próximos (servidores “surrogate”: funcionalidad entre caché y réplica)

– Uso de enlaces vía satélite de alta capacidad (y retardo):• Objetos grandes (ej. software, audio, video)• Ibeam, SkyCache, Real Networks, …

Content distribution networks (CDNs)

• The content providers are the CDN customers.

Content replication• CDN company installs

hundreds of CDN servers throughout Internet– in lower-tier ISPs, close

to users• CDN replicates its

customers’ content in CDN servers. When provider updates content, CDN updates servers

origin server in North America

CDN distribution node

CDN serverin S. America CDN server

in Europe

CDN serverin Asia

CDNs, datos

• CDNs se usan?

Nov. 1999 1-2% out of ~670 sitios Web conocidos

Dec. 2000HotMM127: (39 de 127)31% (37 usan Akamai: 98%)URL588-MM500: (177 de 1030)17% (165 usan Akamai: 85%)

• CDNs: Adero, Akamai, Digitalisland, Fasttude, Speedera, ...

Pq?Mejorar “servicio Web” a sus clientes

Objetivos CDN

• Reducir latencia percibida en el cliente (navegador)

• Conseguir gestión de la capacidad del servidor origen

• Efecto lateral: Cache

Problema técnico a resolver

Como dirigir una petición por un objeto servido de un servidor CDN a un servidor concreto en la red del CDN?

+ como y donde replicar contenido+ como encontrar contenido replicado+ como elegir entre replicas+ como dirigir cliente hacia una replica

Solución: Redirección de la petición • 2 técnicas para redirigir peticiones a servidores CDN:

– Redirección por DNSServidor 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 URLPagina 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)

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

NearbyCDN server

CDN company• cdn.com• distributes gif files• uses its authoritative DNS

server to route redirect requests

Content distribution networks are coordinated caching systems ?

A DNS-redirecting CDN

DNSredirector

Client

HTTPserver

HTTPserver

HTTPserver A

B

C

example.com ?

B

GET http://example.com/foo

http://example.com/foo

Network Model

nslookup QUESTIONS:

www.microsoft.com, type = A, class = IN ANSWERS: -> www.microsoft.com

type = CNAME, class = IN, dlen = 26canonical name = www.microsoft.akadns.netttl = 3600 (1H)

-> www.microsoft.akadns.nettype = CNAME, class = IN, dlen = 30canonical name = www.microsoft.com.edgesuite.netttl = 300 (5M)

-> www.microsoft.com.edgesuite.nettype = CNAME, class = IN, dlen = 17canonical name = a562.cd.akamai.netttl = 900 (15M)

-> a562.cd.akamai.nettype = A, class = IN, dlen = 4internet address = 63.208.194.14ttl = 20 (20S)

-> a562.cd.akamai.nettype = A, class = IN, dlen = 4internet address = 63.208.194.16ttl = 20 (20S)

……

AUTHORITY RECORDS:

-> cd.akamai.net

type = NS, class = IN, dlen = 7

nameserver = n8cd.akamai.net

ttl = 1117 (1117)

-> cd.akamai.net

type = NS, class = IN, dlen = 7

nameserver = n0cd.akamai.net

ttl = 1117 (1117)

-> cd.akamai.net

type = NS, class = IN, dlen = 7

nameserver = n1cd.akamai.net

ttl = 1117 (1117)

-> cd.akamai.net

type = NS, class = IN, dlen = 7

nameserver = n2cd.akamai.net

ttl = 1117 (1117)

Esquemas de funcionamientoPetición de un documento web cliente/servidor

Cliente Servidor

1. Usuario pide URL

2. Servidor devuelve HTML con URLde gráficos incluídos en página

3. Cliente pide gráficos u otro contenido

4. Contenido servido (la mayoría de los bytes de la página)

ClienteServidor

1. Usuario pide URL2. Servidor devuelve HTML con URL

de gráficos incluídos en la página redirigidos a una réplica

3. Cliente pide gráficos u otro contenido a réplica próxima

Réplica

4. Contenido servido más rápido desde réplica

3.a Posible redirección con DNSreparto carga en cluster de servidores

1.a Elección de la mejor réplica según IP origen, estado red, ubicación réplicas, etc.Petición a CDN

Ejemplo: Redirección por DNS*

Empresas CDN: Adero (Full), Akami and Digital Island (Partial)

10.20.30.1

10.20.30.2

10.20.30.3

10.20.30.4

111.222.100.1

IP de yahoo.com

10.20.30.1 (no 111.222.100.1)

GET index.html

<HTML> … <HTML>

Server Origen

Servidor DNS controlado por CDN

* Full Site DNS redirection

www.yahoo.com/GET index.html

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>

Ejemplo: Akamai•Más de 13.000 puntos de servicio en todo el mundo•Contenido “Akamaizado”:

–el servidor de la empresa sirve html y devuelve los enlaces a contenidos incluídos apuntando al servidor más próximo

•Algoritmo 1: [direccionamiento geográfico] El ARL se calcula según la región del demandante, se le envía al servidor de nombres de la “zona”•Algoritmo 2: [reparto de carga en una ubicación] El ARL contiene un índice hash que permite repartir la carga (via DNS/switch nivel 4) entre varios servidores ubicados en un mismo lugar

–El usuario ve un URL normal (el de la página html)•En la ventana de estado sí se ven los ARL

–El servidor de la empresa tiene “Logs” con visitas a html, pero la mayoría del tráfico lo sirve Akamai desde la proximidad del cliente.–Akamai mantiene info de estado de la red, de los clusters, de los “surrogate”.–No siempre elige el “mejor posible” pero de los mejores, sí evita los peores.

Rendimiento de CDNsAspectos:• 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)

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.

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

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

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

Tipo de contenido servido por CDNs

• Peticiones HTTP servidas por CDNs*– Imágenes representan 96-98% del contenido o 40-60%

de los bytes servidos por CDNs– De los CDNs estudiados Akamai sirve 85-98% de los

objetos (bytes)– Tasas de hit en caches de imagenes servidas por CDNs

son 20-30% mas altas que imagenes no servidas por CDNs

* Fuente: Y. Zhang et al. “On the Use and Performance of Content Distribution Networks, 2001.

More about CDNsrouting requests• CDN creates a “map”,

indicating distances from leaf ISPs and CDN nodes

• when query arrives at authoritative DNS server:– server determines ISP from

which query originates– uses “map” to determine

best CDN server

not just Web pages• streaming stored

audio/video• streaming real-time

audio/video– CDN nodes create

application-layer overlay network