Transcript Document

Proxies y CDN
• Distribución:
– Proxy Cachés
– Content Distribution Networks
Web caches (proxy server)
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
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"
Campos
Department of Computer Architecture has the
following structure:
http://www.ac.upc.es
Netscape: View -> Page Info
http://www.ac.upc.es/
Form 1:
Location:
http://www.ac.upc.es/
File MIME Type:
Action URL: http://www.ac.upc.es/cgibin/perlfect/search/search.pl
Encoding: application/x-www-formurlencoded (default)
text/html
Friday, 07-Nov-03 02:39:28 Local time
Last Modified:
Friday, 07-Nov-03 01:39:28
GMT
Method: Get
Image:
http://www.ac.upc.es/imatges/dacTitle,en.gif
Image: http://www.ac.upc.es/imatges/logo.gif
Content Length:
Image:
http://www.ac.upc.es/imatges/selectLang,en.gif
5283
Image:
http://www.ac.upc.es/imatges/mapaButton,en.gif …
Expires:
No date given
…..
Cacheability
http://www.ac.upc.es
(image/gif)
Expires
-
Cache-Control
-
Last-Modified
ETag
Content-Length
Server
7 hr 57 min ago (Mon, 03 Nov 2003 01:15:57 GMT) validated
"37e4c-13ce-3fa5ac4d"
5.0K (5070)
Apache
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.
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>
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.0
User-agent: Mozilla/4.0
Accept: text/html, image/gif, image/jpeg
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
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
Servidor
Origen
HTTP
Proxy
Proxy
Proxy
Navegador
Proxy
Proxy
ICP
Parent 
Proxy
Sibling 
Web caching
• Cache acts as both client
and server
• Cache can do up-to-date
check using Ifmodified-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”
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.
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 servidor
Summary by Month
Daily Avg
Month
Hits
Files
Pages
Monthly Totals
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
5883848
94952
188269
1127404
1284990
Totals
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 server
in S. America CDN server
in Europe
CDN server
in Asia
CDNs, datos
• 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
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 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)
HTTP request for
www.foo.com/sports/sports.html
CDN example
Origin server
1
2
3
DNS query for www.cdn.com
CDNs authoritative
DNS server
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 ?
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
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)
Esquemas de funcionamiento
Petición de un documento web cliente/servidor
1. Usuario pide URL
Cliente
2. Servidor devuelve HTML con URL
de gráficos incluídos en página
Servidor
3. Cliente pide gráficos u otro contenido
4. Contenido servido (la mayoría de los bytes de la página)
Petición a CDN
Cliente
1.a Elección de la mejor réplica según
1. Usuario pide URL IP origen, estado red, ubicación réplicas, etc.
2. Servidor devuelve HTML con URL
de gráficos incluídos en la página
Servidor
redirigidos a una réplica
3. Cliente pide gráficos u otro contenido a réplica próxima
4. Contenido servido más rápido desde réplica
3.a Posible redirección con DNS
reparto carga en cluster de servidores
Réplica
Ejemplo: Redirección por DNS*
Server Origen
111.222.100.1
GET index.html
<HTML> …
<HTML>
10.20.30.1
10.20.30.1 (no 111.222.100.1)
www.yahoo.com/GET index.html
IP de yahoo.com
10.20.30.4
10.20.30.2
10.20.30.3
Servidor DNS
controlado por CDN
Empresas CDN: Adero (Full), Akami and Digital Island (Partial)
* Full Site DNS redirection
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
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
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