Proxies y CDN. Distribución: Proxy Cachés Content Distribution Networks UNIVERSITAT POLITÈCNICA DE CATALUNYA

Transcripción

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

2 Índice La evolución de HTTP Proxy Caches Validación de la cache Características del tráfico Web Problemas de los Proxy Caches

3 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 Threeway handshake cada vez Muy lento TCP empieza con Slow Start

4 La evolución de HTTP Las transferencias pequeñas son ineficientes con TCP Slow Start Muchas conexiones en el servidor Debe gestionarlas todas (estado)

5 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

6 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

7 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

8 Índice La evolución de HTTP Proxy Caches Validación de la cache Características del tráfico Web Problemas de los Proxy Caches

9 Proxy Caches

10 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

11 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 Caches Goal: satisfy client request without involving origin server Computer Networking: A Top Down Approach Featuring the Internet, 2 nd edition. Jim Kurose, Keith Ross client client Proxy server origin server origin server Addison-Wesley, July 2002.

12 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 (rfc2168,2187) Cache-Digest: Intercambio periódico de hash contenido caché. Proxy puede redirigir petición a caché adecuada (probable)

13 Distribución: Proxy UNIVERSITAT POLITÈCNICA DE CATALUNYA 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

14 C Tier-2 ISP OC Tier-1 s ISP OC C C C C Internet Topology Tier-2 ISP Core 20 ASes [30] Ases [28] -More than 50% have more than one link [43] Transit Core 129 ASes [30] Outer Core 897 ASes [30] Small ISPs 971 ASes [30] Customers 8898 ASes [30] -The Internet has a certain hierarchy [30] -Connectivity across levels is not strictly hierarchical [30]

15 Índice La evolución de HTTP Proxy Caches Validación de la cache Características del tráfico Web Problemas de los Proxy Caches

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

17 Ejemplo cabecera respuesta Servidor origen: HTTP/1.1 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

18 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

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

20 Proxies en HTTP/1.1 UNIVERSITAT POLITÈCNICA DE CATALUNYA Cache-Control: Public Private Petición Respuesta Private= cabc No-cache No-cache= cabc No-store No-transform No-cache Cliente origen (cachés se inhiben) No-store Max-age=sgs Max-stale Max-stale=sgs Min-fresh=sgs Only-if-cached Se puede cachear por proxies y cliente Sólo caché cliente Todos pueden excepto cabecera cabc: sólo caché cliente Cacheable pero solo si antes se valida correctamente Obliga a validar solo cabc Nadie puede almacenar los datos, ni cliente ni proxy Proxies no pueden transformar el contenido Proxy no debe almacenar permanentemente Petición/respuesta Máx "edad" aceptable obj en cachés Se aceptan objs viejos Se aceptan objs sgs segundos viejos Obj ha de quedarle sgs de vida Petición si sólo está en caché Must-revalidate Max-age Revalidar (con origen) si es necesario (solo si caducado) Margen de tiempo de vida de la caché en segundos

21 Servidor origen UNIVERSITAT POLITÈCNICA DE CATALUNYA 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 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 <Files index.html> Header append Cache-Control "public, must-revalidate" </Files>

22 Índice La evolución de HTTP Proxy Caches Validación de la cache Características del tráfico Web Problemas de los Proxy Caches

23 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

24 Tráfico en los servidores UNIVERSITAT POLITÈCNICA DE CATALUNYA 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.

25 Efecto Slashdot UNIVERSITAT POLITÈCNICA DE CATALUNYA 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:

26 Efecto Slashdot (II) UNIVERSITAT POLITÈCNICA DE CATALUNYA On Thursday, February 25, 1999, at 11:07 their time, they did it again. Una semana: Slashdot I & II

27 Demanda sigue Ley de Zipf UNIVERSITAT POLITÈCNICA DE CATALUNYA George 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/i a, 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

28 Un caso UNIVERSITAT POLITÈCNICA DE CATALUNYA Número de visitas de las páginas de ordenadas por popularidad. Se ajusta bastante a una distribución de Zipf.

29 Índice La evolución de HTTP Proxy Caches Validación de la cache Características del tráfico Web Problemas de los Proxy Caches

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

31 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

32 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

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

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

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

36 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

37 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

38 Algo de historia

39 Proxy Caches Algo de historia 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

40 Algo de historia

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

42 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

43 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

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

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

46 CDNs Content Distribution Networks: Proporcionan control sobre el contenido Evitan cuellos de botella Evitan flash crowds Eliminan problemas de escalabilidad Aumentan la seguridad

47 CDNs Las CDNs se usan para: Servir contenido a los usuarios por parte de grandes proveedores de contenidos Minimizar flash crowds Disminuir el BW

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

49 CDNs

50 A DNS-redirecting CDN example.com? Client B DNS redirector Network Model GET HTTP server HTTP server HTTP server A B C

51 CDN example origin server distributes HTML Replaces: with Origin server CDNs authoritative DNS server Nearby CDN server HTTP request for DNS query for HTTP request for CDN company cdn.com distributes gif files uses its authoritative DNS server to route redirect requests Content distribution networks are coordinated caching systems?

52 nslookup UNIVERSITAT POLITÈCNICA DE CATALUNYA nslookup Server: Address: #53 Non-authoritative answer: canonical name = toggle. canonical name = g. canonical name = lb1. Name: lb1. Address: Name: lb1. Address: Name: lb1. Address: Name: lb1. Address: Name: lb1. Address:

53 Ejemplo: Redirección parcial por DNS / Reescritura URL index.html <HTML> <BODY> <A HREF= /about_us.html > About Us </A> <IMG SRC= > <IMG SRC= > <IMG SRC= / > </BODY> </HTML>

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

55 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 servidores en 40 países Sirven texto/imágenes/video 2000$ Mbps/mes

56 Akamai: Funcionamiento Sistema hibrido Primero reescritura de URL Después redirección por DNS

57 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

58 Cómo evita Akamai las Flash Crowds?

59 Cómo evita Akamai las Flash Crowds?

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

61 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 servidores es difícil y costoso.

62 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

63 Aspectos: Rendimiento de CDNs 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)

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

65 Experimento: Evaluar la selección de servidor CDN UNIVERSITAT POLITÈCNICA DE CATALUNYA 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-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

66 Our location name A/X B/Y C/Z Where We Measured Geographic location Waltham, Massachusetts, USA Cambridge, Massachusetts, USA Boulder, Colorado, USA OS RedHat Linux 5.1 SunOS BSDI 3.1 Narrowest bandwidth to Internet T1 10 Mb/s Ethernet T1

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

68 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