1 / 47

Proxies y CDN

Proxies y CDN . Distribución: Proxy Cachés Content Distribution Networks. 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.

sally
Download Presentation

Proxies y CDN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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 Web caches (proxy server) Goal: satisfy client request without involving origin server origin server 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 RossAddison-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. ServidorOrigen Proxy Proxy Navegador 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

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

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

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

  8. Campos 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 Netscape: 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 …..

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

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

  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 http://proxy.ac.upc.es:8080 GET http://www.ac.upc.es/docencia/ HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif, image/jpeg

  13. ServidorOrigen Proxy Proxy Proxy Proxy Proxy Proxy Navegador 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 HTTP Parent  Sibling  ICP

  14. 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 Web caching Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith RossAddison-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 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“

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

  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 http://counter.li.org. Más información en: http://counter.li.org/slashdot/

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

  21. 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 caso …

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

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

  24. Summary by Month Month Daily Avg Monthly Totals Hits Files Pages 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 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 5883848 94952 188269 1127404 1284990 Estadística carga en servidor

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

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

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

  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. 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 Content distribution networks (CDNs) origin server in North America CDN distribution node CDN server in S. America CDN server in Asia CDN server in Europe

  30. CDNs, datos • CDNs: • Adero, Akamai, Digitalisland, Fasttude, Speedera, ... • CDNs se usan? 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 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

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

  34. 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 Origin server 1 DNS query for www.cdn.com 2 CDNs authoritative DNS server 3 HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif Nearby CDN server CDN example CDN company • cdn.com • distributes gif files • uses its authoritative DNS server to route redirect requests Content distribution networks are coordinated caching systems ?

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

  36. 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 (1H) -> www.microsoft.akadns.net type = CNAME, class = IN, dlen = 30 canonical name = www.microsoft.com.edgesuite.net ttl = 300 (5M) -> www.microsoft.com.edgesuite.net 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 = 63.208.194.14 ttl = 20 (20S) -> a562.cd.akamai.net type = A, class = IN, dlen = 4 internet address = 63.208.194.16 ttl = 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)

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

  38. GET index.html <HTML> … <HTML> 10.20.30.1 (no 111.222.100.1) IP de yahoo.com Ejemplo: Redirección por DNS* Server Origen 111.222.100.1 10.20.30.1 www.yahoo.com/GET index.html 10.20.30.4 10.20.30.2 Servidor DNS controlado por CDN 10.20.30.3 Empresas CDN: Adero (Full), Akami and Digital Island (Partial) * Full Site DNS redirection

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

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

  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 CDN Objetivo: Evaluar 1) Se reduce la latencia percibida en un cliente (navegador) cuando utiliza una CDN ? 2) CDN elige “bien” ? • 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. Setup del experimento: Fuente: K. Johnson et al. “The Measured Performance of Content Distribution Networks. 2000.

  43. Where We Measured

  44. Resultados Akamai, 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. . http://www.terena.nl/conf/wcw/Proceedings/S4/S4-1.pdf

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

  47. 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 More about CDNs

More Related