proxies y cdn distribución: –proxy cachés –content distribution networks
TRANSCRIPT
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 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"
Campos
http://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é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 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 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
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
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 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
• 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 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