1 Proxies y CDN Distribución: Proxy Cachés Content Distribution Networks
2 Web caches (proxy server)Goal: satisfy client request without involving origin server 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 Proxy server HTTP request HTTP request client HTTP response HTTP response HTTP request HTTP response client Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002. origin server
3 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)
4 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 Proxy Navegador Servidor Origen
5 Ejemplo cabecera respuesta HTTP/1.1Servidor origen: HTTP/ OK Date: Fri, 30 Oct :19:41 GMT Server: Apache/1.3.3 (Unix) Cache-Control: max-age=3600, must-revalidate Expires: Fri, 30 Oct :19:41 GMT Last-Modified: Mon, 29 Jun :28:12 GMT ETag: "3e fbbc" Content-Length: 1040 Content-Type: text/html
6 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 :54:18 GMT If-None-Match: "7a11f-10ed-3a75ae4a" User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Host: Connection: Keep-Alive
7 Ejemplo respuesta validar objeto en cachéHTTP/ Not Modified Date: Tue, 27 Mar :50:51 GMT Server: Apache/ (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"
8 Campos http://www.ac.upc.es Netscape: View -> Page InfoDepartment of Computer Architecture has the following structure: Form 1: Action URL: Encoding: application/x-www-form-urlencoded (default) Method: Get Image: Image: Image: Image: … Netscape: View -> Page Info Location: 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 …..
9 Cacheability (image/gif) http://www.ac.upc.es - 7 hr 57 min ago (Mon, 03 Nov :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.
10 Proxies en HTTP/1.1 Cache-Control: Petición Respuesta No-cacheCliente 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
11 Servidor origen Apache: 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 accessed ExpiresByType image/gif A ### 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
12 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 /docencia/ HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg Forwarded: by GET HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg
13 Relación entre proxiesICP: 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 Servidor Origen HTTP Proxy Proxy Proxy Parent Proxy Proxy Proxy Sibling Navegador ICP
14 Web caching Why Web caching? Cache acts as both client and serverCache 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.
15 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
16 Servicio Web: Características de la demandaVarios 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“
17 Tráfico en los servidoresLa 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.
18 “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 Más información en:
19 “Efecto Slashdot” (II)On Thursday, February 25, 1999, at 11:07 their time, they did it again. Una semana: Slashdot I & II
20 Demanda sigue Ley de ZipfGeorge Kingsley Zipf ( ) 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 ( palabras), “the” es la que más aparece: , “of” en segundo lugar: 7239 veces, “to” en tercer lugar: 6331 veces
21 Un caso … Número de visitas de las páginas de ordenadas por popularidad. Se ajusta bastante a una distribución de Zipf.
22 Perfil típico de demanda WebEl 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
23 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 Surge genera peticiones Web con características estadístiscas que simulan con mucha precisión la demanda típica de un servidor web Microsoft Web Application Stress o WAS Prueba un sitio con IIS + ASP
24 Estadística carga en servidorSummary by Month Month Daily Avg Monthly Totals Hits Files Pages Visits Sites KBytes 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 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 2998 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 Totals 94952 188269
25 Visualización de cargaAnalizadores de logs del servidor web Logs dan información algo imprecisa (segs, nivel aplicación)
26 Servidores replicadosCuando 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 Tuvo que usar 4 servidores replicados para satisfacer la demanda. Julio de 1993 ( peticiones/semana) y Abril de 1994 ( peticiones/semana).
27 Reparto de carga entre varios servidoresVarios “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.
28 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, …
29 Content distribution networks (CDNs)origin server in North America 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 CDN distribution node CDN server in S. America CDN server in Asia CDN server in Europe
30 CDNs, datos CDNs se usan? CDNs:Adero, Akamai, Digitalisland, Fasttude, Speedera, ... CDNs se usan? Nov. 1999 1-2% out of ~670 sitios Web conocidos Dec. 2000 HotMM127: (39 de 127)31% (37 usan Akamai: 98%) URL588-MM500: (177 de 1030)17% (165 usan Akamai: 85%) Pq? Mejorar “servicio Web” a sus clientes
31 Objetivos CDN Reducir latencia percibida en el cliente (navegador)Conseguir gestión de la capacidad del servidor origen Efecto lateral: Cache
32 Problema técnico a resolverComo 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
33 Solución: Redirección de la petición2 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)
34 CDN example origin server www.foo.com distributes HTML Replaces:HTTP request for DNS query for 1 2 3 Origin server CDNs authoritative DNS server Nearby CDN server origin server distributes HTML Replaces: with CDN company cdn.com distributes gif files uses its authoritative DNS server to route redirect requests Content distribution networks are coordinated caching systems ?
35 A DNS-redirecting CDN DNS redirector Network Model example.com ? A B BHTTP server A B C B Client GET
36 nslookup QUESTIONS: www.microsoft.com, type = A, class = IN ANSWERS:type = CNAME, class = IN, dlen = 26 canonical name = ttl = 3600 (1H) -> type = CNAME, class = IN, dlen = 30 canonical name = ttl = 300 (5M) -> type = CNAME, class = IN, dlen = 17 canonical name = a562.cd.akamai.net ttl = 900 (15M) -> a562.cd.akamai.net type = A, class = IN, dlen = 4 internet address = ttl = 20 (20S) internet address = …… AUTHORITY RECORDS: -> cd.akamai.net type = NS, class = IN, dlen = 7 nameserver = n8cd.akamai.net ttl = 1117 (1117) nameserver = n0cd.akamai.net nameserver = n1cd.akamai.net nameserver = n2cd.akamai.net
37 Esquemas de funcionamientoPetición de un documento web cliente/servidor Cliente Servidor 1. Usuario pide URL 2. Servidor devuelve HTML con URL de 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) Cliente Servidor 1. Usuario pide URL 2. 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 DNS reparto 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
38 Ejemplo: Redirección por DNS*Server Origen GET index.html … (no ) IP de yahoo.com index.html Servidor DNS controlado por CDN Empresas CDN: Adero (Full), Akami and Digital Island (Partial) * Full Site DNS redirection
39 Ejemplo: Redirección parcial por DNS / Reescritura URLindex.html About Us 
40 Ejemplo: Akamai Más de 13.000 puntos de servicio en todo el mundoContenido “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.
41 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)
42 Experimento: Evaluar la selección de servidor CDNObjetivo: 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-4KB). 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
43 Where We Measured A/X Waltham, Massachusetts, USA RedHat Linux 5.1 T1Our 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
44 Resultados http://www.terena.nl/conf/wcw/Proceedings/S4/S4-1.pdfAkamai, location A 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. .
45 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
46 Tipo de contenido servido por CDNsPeticiones 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.
47 More about CDNs not just Web pages streaming stored audio/videostreaming real-time audio/video CDN nodes create application-layer overlay network 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