Proxies y CDN Distribucin Proxy Cachs Content Distribution

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

Web caches (proxy server) Goal: satisfy client request without involving origin 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 Computer Networking: A Top Down Approach Featuring the Internet, 2 nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002. origin server HT client. HTTP TP req Proxy server ues t res pon se t s ue q re P nse o T p HT es r TP T H client est u q e Pr T nse o p HT res P T HT origin server

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, Cachecontrol: private, Cache-control: no-cache – ICP: Presencia/ausencia URL en proxy /UDP (rfc 2168, 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 Proxy Navegador Proxy Servidor Origen

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: "3 e 86 -410 -3596 fbbc" Content-Length: 1040 Content-Type: text/html

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: "7 a 11 f-10 ed-3 a 75 ae 4 a" User-Agent: Mozilla/4. 0 (compatible; MSIE 5. 5; Windows NT 5. 0) Host: www. intel-iris. net Connection: Keep-Alive

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 Open. SSL/0. 9. 5 a DAV/1. 0. 2 PHP/4. 0. 1 pl 2 mod_perl/1. 24 Connection: Keep-Alive: timeout=15, max=100 ETag: "7 a 11 f-10 ed-3 a 75 ae 4 a"

Campos http: //www. ac. upc. es Netscape: View -> Page Info Department of Computer Architecture has the following structure: http: //www. ac. upc. es/ Form 1: Location: http: //www. ac. upc. es/ File MIME Type: Action URL: http: //www. ac. upc. es/cgibin/perlfect/search. pl Encoding: application/x-www-formurlencoded (default) text/html Friday, 07 -Nov-03 02: 39: 28 Local time Last Modified: Friday, 07 -Nov-03 01: 39: 28 GMT Method: Get Image: http: //www. ac. upc. es/imatges/dac. Title, en. gif Image: http: //www. ac. upc. es/imatges/logo. gif Content Length: Image: http: //www. ac. upc. es/imatges/select. Lang, en. gif 5283 Image: http: //www. ac. upc. es/imatges/mapa. Button, en. gif … Expires: No date given …. .

Cacheability http: //www. ac. upc. es (image/gif) Expires - Cache-Control - Last-Modified ETag Content-Length Server 7 hr 57 min ago (Mon, 03 Nov 2003 01: 15: 57 GMT) validated "37 e 4 c-13 ce-3 fa 5 ac 4 d" 5. 0 K (5070) Apache 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.

Proxies en HTTP/1. 1 • Cache-Control: – Petición – Respuesta 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é 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

Servidor origen Apache: modulos mod_expires: especificar Expires mod_headers: especificar HTTP cabeceras. htaccess file ### activate mod_expires Expires. Active On ### Expire. gif's 1 month from when they're accessed Expires. By. Type image/gif A 2592000 ### Expire everything else 1 day from when it's last modified ### (this uses the Alternative syntax) Expires. Default "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: nocache, 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 /docencia/ HTTP/1. 0 GET http: //www. ac. upc. es/docencia/ HTTP/1. 0 User-agent: Mozilla/4. 0 Accept: text/html, image/gif, image/jpeg Forwarded: by http: //proxy. ac. upc. es: 80

Relación entre proxies • ICP: Presencia/ausencia URL en proxy /UDP (rfc 2168, 2187) –Medir tiempo respuesta de proxies –Localizar: Entre proxies pero puede usarlo el cliente… –QUERY URL : HIT, MISS, HIT_OBJ (16 Kb), 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 Servidor Origen HTTP Proxy Navegador Proxy ICP Parent Proxy Sibling

Web caching • Cache acts as both client and server • Cache can do up-to-date check using Ifmodified-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, 2 nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002.

Problemas cachés Objetos 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

“Efecto Slashdot” On February 23, 1999, around 15: 43 European Time, the Linux Counter was listed on Slashdot, causing a breakdown of services. Efecto “slashdot” en http: //counter. li. org. Más información en: http: //counter. li. org/slashdot/

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

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 (“L 4 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 (“L 7 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 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, Sky. Cache, 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 server in S. America CDN server in Europe CDN server in Asia

CDNs, datos • CDNs: Adero, Akamai, Digitalisland, Fasttude, Speedera, . . . • CDNs se usan? Nov. 1999 1 -2% out of ~670 sitios Web conocidos Dec. 2000 Hot. MM 127: (39 de 127)31% (37 usan Akamai: 98%) URL 588 -MM 500: (177 de 1030)17% (165 usan Akamai: 85%) 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 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)

HTTP request for www. foo. com/sports. html CDN example Origin server 1 2 3 DNS query for www. cdn. com CDNs authoritative DNS server 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. cdn. com/www. foo. com/sports/ruth. gif 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 ?

A DNS-redirecting CDN DNS redirector example. com ? Network Model B Client GET http: //example. com/foo HTTP server A HTTP server B HTTP server C

nslookup QUESTIONS: www. microsoft. com, type = A, class = IN ANSWERS: -> www. microsoft. com type = CNAME, class = IN, dlen = 26 canonical name = www. microsoft. akadns. net ttl = 3600 (1 H) -> www. microsoft. akadns. net type = CNAME, class = IN, dlen = 30 canonical name = www. microsoft. com. edgesuite. net ttl = 300 (5 M) -> www. microsoft. com. edgesuite. net type = CNAME, class = IN, dlen = 17 canonical name = a 562. cd. akamai. net ttl = 900 (15 M) -> a 562. cd. akamai. net type = A, class = IN, dlen = 4 internet address = 63. 208. 194. 14 ttl = 20 (20 S) -> a 562. cd. akamai. net type = A, class = IN, dlen = 4 internet address = 63. 208. 194. 16 ttl = 20 (20 S) …… AUTHORITY RECORDS: -> cd. akamai. net type = NS, class = IN, dlen = 7 nameserver = n 8 cd. akamai. net ttl = 1117 (1117) -> cd. akamai. net type = NS, class = IN, dlen = 7 nameserver = n 0 cd. akamai. net ttl = 1117 (1117) -> cd. akamai. net type = NS, class = IN, dlen = 7 nameserver = n 1 cd. akamai. net ttl = 1117 (1117) -> cd. akamai. net type = NS, class = IN, dlen = 7 nameserver = n 2 cd. akamai. net ttl = 1117 (1117)

Esquemas de funcionamiento Petición de un documento web cliente/servidor 1. Usuario pide URL 2. Servidor devuelve HTML con URL Client de gráficos incluídos en página Servidor e 3. Cliente pide gráficos u otro contenido Contenido servido (la mayoría de los bytes de la página) 1. a Elección de la mejor réplica según 1. Usuario pide URLIP origen, estado red, ubicación réplicas, etc. 2. Servidor devuelve HTML con URL Petición a CDN de gráficos incluídos en la página Client redirigidos a una réplica Servidor e 3. Cliente pide gráficos u otro contenido a réplica próxima 4. Contenido servido más rápido desde réplica 3. a Posible redirección con DNS Réplica reparto carga en cluster de servidores

Ejemplo: Redirección por DNS* Server Origen 111. 222. 100. 1 GET index. html <HTML> … <HTML> www. yahoo. com/GET index. html 10. 20. 30. 1 (no 111. 222. 100. 1) IP de yahoo. com 10. 20. 30. 4 10. 20. 30. 2 10. 20. 3 Servidor DNS controlado por CDN Empresas CDN: Adero (Full), Akami and Digital Island (Partial) * Full Site DNS redirection

Ejemplo: Redirección parcial por DNS / Reescritura URL index. html <HTML> <BODY> <A HREF=“/about_us. html”> About Us </A> <IMG SRC=“www. clearway 1. net/www. yahoo. com/img 1. gif”> <IMG SRC=“www. clearway 2. net/www. yahoo. com/img 2. gif”> <IMG SRC=“ 10. 20. 30. 2/www. yahoo. com/img 3. 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 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)

Experimento: Evaluar la selección de servidor CDN Objetivo: Evaluar 1) Se reduce la latencia percibida en un cliente (navegador) cuando utiliza una CDN ? 2) CDN elige “bien” ? Setup del experimento: • • • 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 -4 KB). Obtener este GIF de cada servidor CDN 25 veces. Guardar tiempos. – Obtener el mismo fichero GIF de CDN. Guardar tiempos. 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, Red. Hat Linux 5. 1 T 1 Sun. OS 5. 5. 1 10 Mb/s Ethernet BSDI 3. 1 T 1 Massachusetts, USA B/Y Cambridge, Massachusetts, USA C/Z Boulder, Colorado, USA

Akamai, location 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/S 4 -1. pdf

Akamai, location B Resultados (II) 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 CDNs routing 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