Proxy Caches

Transcripción

Proxy Caches

UNIVERSITAT POLITÈCNICA DE CATALUNYA
Proxies y CDN
• Distribución:
– Proxy Cachés
– Content Distribution Networks
Índice
•
•
•
•
•
La evolución de HTTP
Proxy Caches
Validación de la cache
Características del tráfico Web
Problemas de los Proxy Caches
• 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”
• Las transferencias pequeñas son ineficientes
con TCP
– Slow Start
• Muchas conexiones en el servidor
– Debe gestionarlas todas (estado)
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
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
• “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
Índice
•
•
•
•
•
Proxy Caches
Proxy Caches
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
Proxy Caches
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,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2002.
origin
server
client
client
Proxy
server
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 (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
Proxy
Navegador
Proxy
Servidor
Origen
Internet Topology
-17.000 Ases[28]
Core
20 ASes[30]
-More than 50% have
more than one link[43]
Tier-1’s
Tier-2
Tier-2
OC
OC
ISP ISP
C
C
C
ISP
C
C
Transit Core -The Internet has a
129 ASes[30] certain hierarchy[30]
Outer Core -Connectivity across
897 ASes[30] levels is not strictly
Small ISPs hierarchical[30]
971 ASes[30]
Customers
8898 ASes[30]
Índice
•
•
•
•
•
Proxy Caches
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?
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.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
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"
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
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>
Índice
•
•
•
•
•
Proxy Caches
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”
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.
Índice
•
•
•
•
•
Proxy Caches
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
¿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
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”
¿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.
Proxies y CDN
• Distribución:
– Proxy Cachés
– Content Distribution Networks
Í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
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
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
Algo de historia…
Algo de historia…
• Proxy Caches
• 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
Algo de historia…
Índice
•
•
•
•
•
•
Futuro de las CDNs
¿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
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”
¿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.
Índice
•
•
•
•
•
•
Futuro de las CDNs
CDNs
• Content Distribution Networks:
–
–
–
–
–
Proporcionan control sobre el contenido
Evitan cuellos de botella
Evitan “flash crowds”
Eliminan problemas de escalabilidad
Aumentan la seguridad
CDNs
• Las CDNs se usan para:
– Servir contenido a los usuarios por parte de
grandes proveedores de contenidos
– Minimizar “flash crowds”
– Disminuir el BW
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)
CDNs
A DNS-redirecting CDN
DNS
redirector
example.com ?
Network
Model
B
Client
GET http://example.com/foo
http://example.com/foo
HTTP
server
A
HTTP
server
B
HTTP
server
C
HTTP request for
www.foo.com/sports/sports.html
CDN example
1
2
Origin server
DNS query for www.cdn.com
CDNs authoritative
DNS server
3
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 ?
nslookup
acabello@ranci:~$ nslookup www.microsoft.com
Server:
147.83.130.132
Address:
147.83.130.132#53
Non-authoritative answer:
www.microsoft.com
canonical name = toggle.www.ms.akadns.net.toggle.www.ms.akadns.net
canonical name = g.www.ms.akadns.net.g.www.ms.akadns.net
canonical name = lb1.www.ms.akadns.net.
Name:
lb1.www.ms.akadns.net
Address: 207.46.18.30
Name:
Address: 207.46.20.30
Name:
Address: 207.46.20.60
Name:
Address: 207.46.198.30
Name:
Address: 207.46.198.60
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>
Índice
•
•
•
•
•
•
Futuro de las CDNs
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 14000 servidores en 40 países
• Sirven texto/imágenes/video
– 2000$ Mbps/mes
Akamai: Funcionamiento
• Sistema hibrido
– Primero reescritura de URL
– Después redirección por DNS
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
Cómo evita Akamai las Flash Crowds?
Cómo evita Akamai las Flash Crowds?
Índice
•
•
•
•
•
•
Futuro de las CDNs
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 14000 servidores es difícil y costoso.
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
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)
Índice
•
•
•
•
•
•
Futuro de las CDNs
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-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. 2000.
Where We Measured
Our location
name
Geographic
location
OS
Narrowest
bandwidth to
Internet
A/X
Waltham,
RedHat
Linux 5.1
T1
SunOS
5.5.1
10 Mb/s
Ethernet
BSDI 3.1
T1
Massachusetts,
USA
B/Y
Cambridge,
Massachusetts,
USA
C/Z
Boulder,
Colorado, USA
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
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

Proxy Caches

Transcripción

Documentos relacionados

Análisis del error humano

La ilustración del libro chino durante la Dinastía Ming