MIT 18

Anuncio
MIT 18.996: Temas sobre informática teórica- Problemas de investigación en Internet
Primavera 2002
Clase 1 – 6 de febrero de 2002
Profesor: Tom Leighton
Copistas: Omar Aftab y Eamon Walsh
1.1. Introducción
En esta lección hablaremos de diversos problemas de investigación relacionados con
Internet. En cada clase trataremos:
•
Cómo funciona hoy en día un determinado componente de Internet o una
tecnología.
•
Cuestiones y problemas de la tecnología actual.
•
Posibles nuevas líneas de investigación.
•
Formulación de problemas y soluciones concretos.
Empezaremos hablando de cómo funciona la Red hoy en día, de cuáles son las
cuestiones principales en cuanto a su arquitectura actual y de qué modo los servicios de
Akamai están la están modificando. Posteriormente, hablaremos de los retos tecnológicos y
concluiremos con las futuras líneas de investigación en esta área.
La mayoría de las clases incluirán un ejemplo de algún problema teórico surgido a
partir de la investigación en Akamai. El ejemplo de hoy, que veremos más tarde, está
relacionado con la optimización de costes: el problema de asignar cada usuario a un servidor
óptimo minimizando, al mismo tiempo, los costes totales de ancho de banda.
1.2. Cómo funciona la Red hoy en día
La Red, vista desde fuera, simplemente conecta a proveedores de contenidos con
usuarios finales. Lo más importante de la Red es que usuarios de todo el mundo pueden tener
acceso a contenidos sin ningún tipo de impuestos por licencia. Cualquiera puede colgar una
página web y cientos de millones de personas pueden verla. No existen precedentes de algo
así en la historia de la humanidad.
A pesar de ofrecer una conectividad sin precedentes, Internet también sufre de
inestabilidad y de un rendimiento impredecible. Y a medida que el número de sitios y de
usuarios aumenta, estos problemas se incrementarán enormemente.
1.2.1. Arquitectura de la Red: una red de redes
Internet es una red de redes: actualmente, consiste en alrededor de 9.000 redes individuales,
que se comunican entre sí mediante el protocolo IP. Entre estas redes se incluyen las grandes
redes Tier I, tales como UUnet y PSINet, así como un gran número de pequeños ISPs. Para
que Internet actúe como una verdadera red global que conecte a todos, estas redes
individuales deben estar conectadas entre sí mediante enlaces denominados “puntos neutros”
o NAPs (Network Access Points) y acuerdos de peering.
1
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Un punto neutro es, básicamente, un enlace entre dos routers situados en diferentes
redes. Para que los datos pasen de una red a otra, han de atravesar este enlace. De hecho, en
la Red hay miles de puntos de este tipo y, para llegar al usuario final, los datos han de pasar
por muchas redes individuales y numerosos puntos neutros.
Actualmente, dos tipos de protocolos ayudan a direccionar el tráfico en la Red. Los
protocolos internos de pasarela (IGP), como RIP, dirigen los datos dentro de una misma red
individual. Pero a nosotros nos interesa más el protocolo externo de pasarela (EGP) conocido
como BGP, que se emplea para enrutar los datos entre redes. Mientras los IGP utilizan una
gran variedad de métodos sofisticados para determinar el mejor camino de enrutamiento
–entre ellos, análisis de topología, ancho de banda y congestión–, el BGP no. En su lugar, el
BGP determina las rutas minimizando, simplemente, el número de redes individuales que
han de atravesar los datos. Este enfoque, aunque escalable, no controla bien la congestión.
La arquitectura actual de Internet favorece enormemente la escalabilidad de la Red y
ha permitido que se extienda rápidamente. Sin embargo, hay cuatro “cuellos de botella”
inherentes a esta arquitectura que pueden llegar a afectar gravemente al rendimiento de la
Red a medida que ésta vaya creciendo. En la siguiente figura se muestran estos cuellos de
botella que, posteriormente, analizaremos uno a uno.
Figura 1.1. Problemas de la arquitectura de Internet en la actualidad.
El cuello de botella de la primera milla
El cuello de botella de la primera milla es una consecuencia directa del hecho de que
con 400 millones de usuarios, la centralización simplemente no funciona. Los contenidos
conectados a la red en un punto se pueden ver rápidamente colapsados ante la demanda de un
gran público internacional. Tradicionalmente, cada proveedor de contenidos establece un
sitio web central en una sola ubicación, que proporciona información a todo el mundo. Esto
significa que la conectividad de la primera milla –la capacidad de ancho de banda del sitio
central– limitará su rendimiento.
2
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Con el fin de acomodar a un creciente número de usuarios, el proveedor de contenidos debe
comprar cada vez más ancho de banda a su ISP; y lo que es más importante: el ISP debe
también expandir continuamente su propia capacidad de red –¡y sus iguales también! De este
modo, es evidente que la solución centralizada no es escalable.
Figura 1.2. El cuello de botella de la primera milla.
Un ejemplo de este problema es el Victoria’s Secret Online Fashion Show (Feria de moda en
línea de Victoria’s Secret), anunciado enormemente en la Super Bowl de 1999. Cuando más
de un millón de suscriptores intentaron acceder simultáneamente al webcast en vivo, los
servidores centrales no pudieron atender a tantas peticiones, por lo que el sitio se colapsó y la
práctica totalidad de los espectadores se quedó sin poder ver el webcast. Entre otros ejemplos
se incluyen los sitios Akamai, que ofrecían los tráilers de La guerra de las galaxias, y el sitio
de la NASA, que ofrecía los contenidos sobre el Mars Rover.
El problema del peering
Hoy en día, Internet es una red de redes, con puntos acceso o NAPs entre ellas (figura
1.2).
Para atravesar Internet, el tráfico debe pasar por numerosos puntos neutros entre estas
redes individuales. Incluso si el ancho de banda de ambas redes es internamente grande,
generalmente, el cuello de botella se encuentra en el punto de acceso entre ellas.
Es común la concepción errónea de que “los grandes” controlan gran parte del tráfico
de Internet. Si una red pudiera abarcar la mayor parte del tráfico de Internet, se podrían
alcanzar la mayoría de los destinos dentro de esa red sin necesidad de atravesar ningún punto
de acceso. Sin embargo, no es así. En realidad, ninguna red controla por sí sola más del 6%
del tráfico de Internet1. Dado que el tráfico se encuentra tan repartido a lo largo de miles de
redes, ha de viajar en su mayoría a través de muchas redes diferentes y, por tanto, de
numerosos puntos neutros, que son una fuente de congestión.
1
Por tráfico, nos referimos al número de bits transferidos, no al número de usuarios. Un gran número de
usuarios sólo puede producir una pequeña cantidad de tráfico si sus conexiones son lentas, como es el caso de
AOL. El servicio de ancho de banda Excite@Home, por ejemplo, produce más o menos el mismo tráfico que
AOL, a pesar de tener muchos menos usuarios.
3
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Figura 1.3. Muchas redes en Internet.
Hay tres aspectos clave en lo que se refiere a los acuerdos de peering entre redes:
El económico
Muchos ISP restringen deliberadamente sus puntos neutros para impedir el acceso de
grandes cantidades de tráfico exterior. Con frecuencia, se producen discusiones acerca de
los pagos; es habitual que los grandes ISP cobren a los pequeños por utilizar sus
estructuras, pero las grandes empresas “Tier 1”, generalmente, no se cobran entre ellas.
Dado que las redes pequeñas tienen que pagar a las grandes por utilizar sus estructuras,
tienden a comprar sólo la capacidad justa que necesitan para manejar el tráfico que han
afrontar en el momento de la compra. Esto significa que los puntos de acceso operan
prácticamente al máximo de su capacidad, lo que implica pérdidas de paquetes y retrasos
de los mismos. Las grandes redes, impulsadas por motivos económicos similares, tienden
a no querer enlazarse a otras redes de gran tamaño, ya que no cobran nada por ello.
En ocasiones, estas cuestiones económicas hacen que el sistema se venga abajo.
Cable&Wireless, en una ocasión, denegó su servicio a varias redes, a las que solicitaba
un pago por el mismo. Entre ellas estaba PSINet, otra estructura “Tier 1”, que se negó a
pagar. Esta acción fragmentó Internet durante tres días; de ese modo, los usuarios de
PSINet no podían acceder a los contenidos hospedados en C&W y viceversa. El servicio
se restableció únicamente cuando la sección de hosting de C&W se vio colapsada por las
quejas de sus propios clientes, cuyos sitios resultaban inaccesibles para los clientes de
PSINet.
Los protocolos de enrutamiento
Como ya mencionamos anteriormente, los protocolos externos de pasarela (EGP)
como BGP emplean los tradicionales algoritmos de la ruta más corta para determinar las
rutas óptimas, ignorando la congestión –incluso aunque los routers puedan acceder a
informaciones como el tamaño de las colas. Como consecuencia de ello, cuando los
puntos de acceso se congestionan, BGP continúa enviándoles tráfico, incrementando el
problema.
El error humano
Los protocolos de enrutamiento también reciben instrucciones de operadores
humanos, lo que puede conducir a pérdidas accidentales de rutas o a la introducción de
rutas incorrectas. Por ejemplo, los operadores de los sistemas son los responsables de
establecer el número de saltos a otras redes. A menudo se juega a anunciar saltos
4
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
falsamente con el fin de desviar el tráfico hacia redes en competencia y similares. Esto
puede conducir al desastre, como en el caso en el que un ingeniero de Nivel 3 anunció
por accidente rutas con un coste de -∞ a todos los puntos. Entonces, una enorme cantidad
de tráfico se dirigió hacia el Nivel 3, causando una gran congestión. Como mencionamos
anteriormente, BGP ignora la congestión a la hora de determinar las rutas óptimas, por lo
que el problema pronto afectó a las tres cuartas partes de la totalidad del tráfico de
Internet. El parón duró 45 minutos.
El peering es, por tanto, un problema inherente a la arquitectura de la Red. Aunque se ha
dicho que los problemas de peering se solucionarían a medida que se consolidaran las
empresas de telecomunicaciones y se fusionaran las redes, no hay ningún indicio de que esto
esté sucediendo. En realidad, el número de redes distintas está en aumento.
La estructura de Internet (backbone)
Otro cuello de botella es la capacidad de las grandes redes de larga distancia que
conforman la estructura de Internet. En el tradicional modelo centralizado para servir páginas
web, la mayoría de las peticiones acaban por atravesar la estructura de la red desde el usuario
final hasta el servidor central. Esto significa que las redes centrales deben manejar todo el
tráfico existente en la Red hoy en día. Actualmente, esta cuestión afecta sólo a los países
extranjeros y al acceso global. Sin embargo, a medida que el tráfico de Internet aumente, se
puede volver más urgente.
La última milla
El cuello de botella de la última milla es con el que están familiarizados la mayor
parte de los usuarios de Internet: la velocidad limitada del módem de 56K que les sirve de
enlace a su ISP. Una equivocación frecuente, no obstante, es la de pensar que la introducción
de DSL de banda ancha o cable resolverá todos los problemas de rendimiento de Internet.
Esto no es así. Las dificultades encontradas en los primeros tramos de la comunicación
seguirán causando problemas de rendimiento: la calidad de una conexión depende de su
enlace más débil. De hecho, en realidad la velocidad limitada de los módems es lo que está
salvando a Internet del colapso total: si todos los usuarios pudieran solicitar contenidos a
velocidades de banda ancha crearían tanta congestión en los otros tres tipos de cuellos de
botella que el tráfico de Internet se estancaría. En efecto, hoy en día, Internet está
funcionando casi al límite de su capacidad: es necesario resolver las otras cuestiones antes de
exponer la arquitectura a nuevos millones de usuarios de banda ancha.
1.2.2. Consecuencias de los cuellos de botella
La arquitectura actual de Internet requiere que todo el tráfico pase a través de múltiples redes
hasta llegar a los proveedores centrales de contenidos. De este modo, se debe enfrentar a los
cuatro tipos de cuellos de botella antes de llegar a su destino. Las consecuencias más
importantes de esto son las siguientes:
Descargas lentas
Los contenidos han de atravesar múltiples estructuras (backbones), puntos neutros a
menudo congestionados y largas distancias, para llegar al usuario final. Por ello, con
frecuencia el funcionamiento es lento.
5
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Funcionamiento inestable
Con frecuencia, los contenidos se pueden ver bloqueados como resultado de la
congestión o debido a problemas de peering. Un sitio que funciona perfectamente en un
momento determinado, puede resultar inaccesible al minuto siguiente.
Falta de escalabilidad
Dado que cada usuario debe obtener los datos directamente desde un servidor central,
se producen importantes problemas de escalabilidad. El uso está limitado por el ancho de
banda presente en el sitio central.
Calidad inferior de streaming (flujo)
El streaming multimedia, uno de los principales objetivos de los proveedores de
contenidos, no resulta factible bajo el modelo de servidor central. La pérdida de paquetes,
la congestión y los estrechos conductos sirven para degradar la calidad de streaming,
haciendo que la reproducción de videos de alta resolución en línea bajo demanda sea
prácticamente imposible.
El ancho de banda no mejora la situación
Como ya se ha comentado, el ancho de banda no es la solución a los cuellos de
botella mencionados anteriormente. De hecho, serviría únicamente para incrementar la
congestión de la primera milla, los problemas de peering y la congestión de las
estructuras, a medida que más gente intenta realizar mayores descargas.
1.3. La solución de Akamai: entregas en el borde
La solución de Akamai consiste en evitar los cuellos de botella proporcionando los
contenidos a los usuarios finales directamente desde sus servidores, en la última milla. Esta
alternativa a la distribución centralizada se conoce por el nombre de “entrega en el borde”
(edge delivery). En este modelo, el contenido de cada sitio web está disponible en servidores
situados en el borde de Internet: lo ideal es que el usuario pueda encontrar todos los
contenidos requeridos en un servidor de Akamai ubicado en su propia red. Con cerca de
15.000 servidores distribuidos por más de 60 países de todo el mundo, hay muchas
posibilidades de que cualquier usuario de Internet tenga un servidor de Akamai cerca.
6
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Figura 1.4. Entrega en el borde (edge delivery).
1.3.1. Ventajas
El modelo de Akamai presenta diversas ventajas con relación al establecido. Al
eliminar el punto central a través del cual se accedía a los datos, esta solución evita el cuello
de botella de la primera milla. Los contenidos se sirven desde ubicaciones próximas al
usuario final, y no desde un servidor central geográficamente distante y, por lo general,
congestionado, como se muestra en la figura 1.4. Dado que el contenido de cada sitio está
ahora disponible en múltiples servidores, su capacidad ya no se ve limitada por la velocidad
de cada enlace de red. El sistema es también más fiable, puesto que no hay ninguna
posibilidad de fallo. Si se cae un servidor de Akamai, sus usuarios son automáticamente
dirigidos a otro.
El sistema de entrega en el borde resuelve también los problemas de peering. Ya no
es necesario que los datos atraviesen múltiples redes ni pasen por puntos neutros
congestionados. Cada usuario los puede obtener directamente de su propia red, lo que supone
descargas más rápidas. Por supuesto, esto supone que todas (o casi todas) las redes deberán
tener un servidor local de Akamai. Además, puesto que los contenidos se entregan desde el
borde de la red, la demanda de capacidad de estructura se ve también reducida en gran
medida.
Si bien es cierto que el modelo de entrega en el borde no resuelve directamente el
problema de la última milla, el hecho de entregar los contenidos más cerca de los usuarios
finales y de resolver los tres problemas presentes en anteriores tramos de la comunicación,
permite introducir con éxito la banda ancha.
La mejora de rendimiento lograda por Akamai se puede observar en la figura 1.5.
Esta gráfica muestra la media de los tiempo de acceso globales a un sitio web con y sin el
modelo de Akamai. Obsérvese que los tiempos de acceso son significativamente más largos
en los días laborables, durante las horas de oficina, debido a la carga que suponen las LANs
de las empresas, con su elevado ancho de banda. Es obvio que el alojamiento de un sitio web
con Akamai tiene dos ventajas: en primer lugar, el tiempo medio de acceso global se reduce,
7
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
en algunos casos, hasta un 800%; en segundo lugar, el rendimiento del sitio web es mucho
más regular durante toda la semana.
Figura 1.5. Rendimiento del sitio web: mejoras habituales con Akamai.
1.3.2. Ofertas del servicio de Akamai
•
FreeFlow era el servicio de entrega de contenidos (Content Delivery Service) inicial de
Akamai para los objetos web estáticos, como banners e imágenes. Al igual que
EdgeSuite, el actual producto estrella de Akamai, FreeFlow sirve los contenidos al
usuario final desde los servidores de Akamai distribuidos por el borde de la red. Su
funcionamiento consiste en modificar el código HTML original del sitio para
redireccionar al usuario final hacia el servidor de Akamai adecuado, mediante el uso de
sofisticados algoritmos de red que tienen en cuenta la congestión y la topología de la
red. El servidor de Akamai proporciona entonces la mayoría de los datos necesarios
para descargar la página. Esto reduce enormemente la comunicación entre el usuario
final y el servidor central del proveedor de contenidos, asegurando la rapidez de las
descargas.
•
FreeFlow Streaming utiliza las ventajas de la entrega en el borde para proporcionar
contenidos de streaming a visitantes de todo el mundo con grandes mejoras de calidad
y fiabilidad. En caso de streaming bajo demanda, Akamai almacena copias de la
difusión de los productos audiovisuales en sus servidores del borde mejorando el
rendimiento al asegurar que las tramas se entregan a los usuarios finales desde
servidores próximos a ellos. Para dar soporte al streaming en vivo, Akamai transmite
múltiples tramas a su red de servidores de productos audiovisuales ubicada en el borde
de la Red. El evento se reajusta entonces en el servidor del borde y se vuelve a difundir
directamente al usuario final, evitando cuestiones como la congestión o la calidad de
transmisión. Akamai utiliza esta tecnología también para ofrecer aplicaciones de
streaming, tales como Akamai Forum y Akamai Conference.
8
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
•
Akamai Conference emplea medios con streaming para ampliar el alcance y la
funcionalidad de la conference call estándar. Proporciona streaming de audio y vídeo
en vivo y otros elementos interactivos.
•
Akamai Forum es una solución que gestiona la totalidad del proceso de producción y
difusión de eventos de los medios con streaming. Permite a las empresas producir
webcast en vivo e interactivos. El foro no requiere ningún software especial de cliente,
permite el feedback y la participación del público en vivo diapositivas de presentación
sincronizadas.
•
FirstPoint es un servicio de gestión de tráfico global para proveedores de contenidos
con múltiples sitios espejo. FirstPoint monitoriza el tráfico y la congestión de la red y
conecta a los usuarios finales con los mejores sitios espejo mediante DNS. FirstPoint
está diseñado para interaccionar con otros servicios de Akamai.
•
EdgeScape permite a los proveedores de contenidos personalizar los contenidos de su
sitio en función del ancho de banda de la conexión, la dirección IP del usuario y su
situación geográfica. Por ejemplo, esto permite a los sitios ajustar automáticamente sus
contenidos al ancho de banda disponible para el usuario y anunciar servicios y
productos locales, así como elimina la necesidad de que el usuario especifique su
ubicación. El sistema EdgeScape consiste en bases de datos locales alojadas en
servidores de la red de Akamai. Estos servidores personalizan las páginas web
basándose en los datos recogidos sobre el usuario: una vez más la entrega de contenidos
se produce en el borde, los servidores gestionan las peticiones de los usuarios
directamente y sólo contactan con el servidor central del proveedor de contenidos para
actualizar sus bases de datos.
•
El DPS (Digital Parcel Service): hoy en día, a muchos proveedores les preocupa colgar
contenidos en la Red ante el temor de que sean utilizados sin el debido pago. El DPS
permite que únicamente los usuarios autorizados, previo pago, accedan al material en
línea. Se trata de una completa solución para la distribución digital, la presentación de
informes y la gestión de derechos.
• El Reporter y el Traffic Analyzer proporcionan datos históricos y en tiempo real de la
utilización de la página. Estas potentes herramientas permiten un data mining
personalizado y el visionado en tiempo real del tráfico de clientes. De este modo, el
cliente puede medir la eficacia de sus campañas publicitarias y de marketing, la
popularidad de sus eventos de streaming, etc.
• El Content Storage (almacén de contenidos) de Akamai: es un servicio que permite a
los clientes almacenar archivos en servidores de Akamai situados estratégicamente.
Estos archivos son posteriormente entregados al usuario final mediante DPS, FreeFlow,
FreeFlow Streaming, etc.
• EdgeSuite es la última generación del servicio de entrega en el borde; la mayoría de los
servicios de Akamai se han incorporado a modo de paquete en EdgeSuite. Lanzado al
mercado en el 2001, EdgeSuite ofrece servicios de gestión, entrega y almacenaje de
contenidos desde el borde de la Red. Gracias a él, un servidor ubicado en el borde
puede almacenar y entregar páginas de un conjunto de elementos variables, dirigiendo
tan sólo cada página al individuo que ha solicitado los datos. A medida que los sitios se
vuelven cada vez más personalizados e interactivos, la capacidad para almacenar
páginas web en el borde de la red sin tener que referirse continuamente al servidor
9
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
central adquiere una mayor importancia: esto aligera la carga en el proveedor central de
contenidos y mejora el rendimiento de cara al usuario final.
Con las soluciones anteriores de entrega de contenidos, como FreeFlow, todos los procesos
de la aplicación tenían lugar en el servidor central: los servidores del núcleo ejecutaban las
aplicaciones y preparaban el HTML para transmitirlo al usuario final. El aumento de
velocidad se obtuvo mediante la obtención de objetos más grandes y pesados, tales como
gráficos y audiovisuales, a partir de los servidores del borde.
Por el contrario, las soluciones de entrega de contenidos reunidos en el borde, permiten que
la mayoría de las aplicaciones en Internet se almacenen y se entreguen desde el borde,
facilitando así la personalización dinámica y un funcionamiento mucho más rápido.
Mediante el almacenaje en el borde, el servidor almacena en caché los resultados de las
consultas a la base de datos, lo que reduce en gran medida la carga en el servidor central.
Imaginemos, por ejemplo, un sitio que proporciona información meteorológica. Esta
información se puede guardar fácilmente en la caché hasta unos 15 minutos sin que se quede
obsoleta. Este período de tiempo, después del cual los datos almacenados en la caché pierden
validez y han de ser actualizados, se conoce como “tiempo de vida” (TTL). Cuando un
usuario solicita el tiempo de Boston, se recuperará el contenido del servidor central y se
almacenará en la caché del servidor del borde que haya respondido a la petición. Cuando otro
usuario solicite el tiempo de Nueva York, ese contenido se almacenará también en la caché.
Si, a continuación, un tercer usuario solicitara el tiempo de Boston o el de Nueva York, el
servidor del borde ya no necesitará ponerse en contacto con el servidor central, sino que
podrá crear la página adecuada y responder directamente. En el caso de muchos usuarios,
esta técnica puede reducir enormemente la carga en el servidor central, ya que el servidor del
borde sólo necesitará volver a ponerse en contacto con la base de datos del servidor central
cuando el TTL haya expirado.
Al igual que hacía FreeFlow, EdgeSuite mejora el rendimiento de los sitios web sirviendo los
contenidos desde el borde de la Red. Sin embargo, con EdgeSuite, se montan y entregan
muchos más contenidos desde el borde, dando lugar a un rendimiento aún mejor.
1.4. Visión general de la tecnología
Ofreceremos una amplia visión general del funcionamiento del sistema de Akamai. En
lecciones posteriores, tendremos en cuenta los detalles de su tecnología y las cuestiones
relacionadas con ella.
Para empezar, compararemos el acceso a un sitio con y sin el beneficio de los
servicios de Akamai.
1.4.1. Descarga de un sitio web a la manera tradicional
Cuando un usuario solicita el acceso a un sitio web como, por ejemplo, web.mit.edu, una
serie de eventos tienen lugar tras la pantalla de nuestro navegador. En primer lugar, el
navegador ha de encontrar la dirección IP de web.mit.edu. Esto se realiza por medio del
Domain Name Service (DNS), que funciona a modo de “páginas amarillas” de Internet. En
un nivel superior, el DNS localiza la dirección IP 18.7.21.77 como la correspondiente a la
familiar web.mit.edu. Una vez que el DNS devuelve la dirección IP, el navegador contacta
con el servidor de esa dirección y solicita la página. El servidor web devuelve código HTML,
con los enlaces a otros objetos incorporados, tales como imágenes. Entonces, el navegador
deberá repetir el proceso para cada objeto incorporado, solicitándolo y recuperándolo. En la
10
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
práctica, los navegadores pueden abrir múltiples conexiones simultáneas para recuperar
páginas completas –algunos objetos, como las imágenes, se ven aparecer poco a poco en la
página en función del orden en el que se van obteniendo.
Figura 1.6. Obtención de una página por el medio tradicional.
1. El DNS busca www.xyz.com.
2. Devuelve la dirección IP correspondiente a www.xyz.com.
3. El navegador solicita el HTML al servidor de la dirección IP 10.10.123.8.
4. El servidor devuelve el HTML, incluidos los links incorporados.
5. El navegador realiza la búsqueda en el DNS de los objetos incorporados.
6. El navegador solicita al servidor los objetos incorporados.
7. El servidor entrega los objetos incorporados al navegador.
1.4.2. Búsquedas en el DNS a la manera tradicional
El proceso de búsqueda en sí en el DNS consiste en una serie de pasos. Es importante
entender este proceso porque el sistema del EdgeSuite de Akamai funciona a partir de
modificaciones de éste.
Ante una dirección como web.mit.edu, el navegador consulta primero su propia
caché, con el fin de determinar si ya ha averiguado antes la dirección IP correspondiente a
dicho dominio. De no ser así, consultará al sistema operativo, que también dispone de una
caché. Si esto tampoco tiene éxito, el navegador deberá conectar con el servidor local y
solicitar la IP de mit.edu.
El servidor local lleva un registro de las direcciones IP que ha averiguado en
ocasiones anteriores. Si mit.edu es una de ellas (y la entrada no ha caducado), simplemente
devuelve el registro. De lo contrario, el servidor local ha de consultar a una autoridad
superior, realizando una búsqueda recursiva. Al final, la consulta puede llegar a la máxima
autoridad: un servidor root DNS de InterNIC. El servidor de InterNIC lleva un registro de
todos los nombres de los dominios registrados en Internet, de modo que resuelve la consulta
realizada sobre mit.edu. Su respuesta proporciona la dirección IP del servidor DNS que aloja
el dominio mit.edu.
11
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
El servidor DNS local contacta entonces con el servidor DNS de mit.edu para
obtener la IP de web.mit.edu. Recibe una dirección IP, que puede almacenar en su caché y
devolver al sistema operativo de la máquina que inició todo el proceso quien, finalmente, la
entrega al navegador.
Figura 1.7. Búsqueda en un DNS por el medio tradicional
1. El navegador busca www.xyz.com en su caché.
2. La consulta pasa a la caché del sistema operativo.
3. Se contacta con el servidor local.
4. El servidor local realiza una llamada recursiva, que tarde o temprano acabará en un
servidor root.
5. El servidor root devolverá la dirección IP del servidor DNS de xyz.com.
6. el servidor local contactará con el servidor DNS de xyz.com.
7. El servidor de xyz.com. devolverá la dirección IP de www.xyz.com.
8. La dirección IP se entrega al sistema operativo de la máquina del usuario.
9. Éste se la pasa al navegador, que actualiza su caché
10. Comienza la solicitud del HTML.
1.4.3. Descarga de un sitio web por el método de Akamai
Cuando un usuario solicita un sitio web con el sistema de Akamai, como por ejemplo,
www.yahoo.com, tienen lugar una serie de eventos ligeramente diferentes a los anteriores. Al
igual que antes, el navegador debe, en primer lugar, averiguar la dirección IP mediante DNS.
Sin embargo, en este caso la dirección que devuelve el DNS es la de un servidor de Akamai
válido. El navegador contacta entonces con el servidor de Akamai para pedir el HTML. El
12
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
servidor de Akamai monta la página web, estableciendo conexiones con el servidor central de
Yahoo! para obtener contenidos dinámicos como las personalizaciones, en caso de que sea
necesario. A continuación se entrega el HTML al navegador.
Al igual que en el caso tradicional, este HTML puede contener enlaces a objetos
incorporados. El navegador obtiene la dirección IP de estos objetos: al igual que antes, el
servicio DNS devuelve las direcciones de los servidores Akamai que albergan cada uno de
los objetos. Finalmente, el navegador recupera los objetos incorporados a partir de estos
servidores.
Figura 1.8. Obtención de una página web mediante el sistema de Akamai
1. El DNS busca www.xyz.com.
2. Obtiene la dirección IP del servidor Akamai adecuado.
3. El navegador solicita el HTML al servidor de Akamai.
4. El servidor de Akamai contacta con el servidor central de xyz.com a través de
Internet en caso necesario.
5. El servidor de Akamai prepara el HTML y lo devuelve al navegador.
6. El navegador se encarga de los links incorporados, obteniendo las direcciones IP de
los servidores de Akamai que alojan los objetos.
7. El navegador obtiene los objetos.
En el enfoque de Akamai hay tres cuestiones importantes. El servicio DNS ha de ser
modificado para devolver la dirección del servidor de Akamai adecuado para cada usuario en
concreto. Cada servidor de Akamai debe poder conectar con el servidor central de un sitio
web determinado para acceder a los registros de la base de datos, entre otras cosas. Sin
embargo, dado que esta conexión se establece a través de Internet, por el método tradicional,
ha de enfrentarse a todas las dificultades y problemas descritos previamente. Por último, el
servidor de Akamai tiene que preparar y entregar la página. A continuación, trataremos estas
cuestiones de una en una.
13
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
1.4.4. Búsqueda DNS con un sistema Akamai
Según el enfoque de Akamai, el servidor DNS debe devolver la dirección del servidor de
Akamai adecuado. Esto requiere algunos cambios en el sistema DNS existente. En concreto,
la dirección www.xyz.com no se ha de transcribir directamente por 18.7.21.70, sino que se le
ha de asignar como apodo una dirección intermedia de Akamai; por ejemplo,
a212.g.akamai.net, para la que, posteriormente, se averiguará un servidor adecuado.
Examinemos el proceso de búsqueda del DNS con el sistema de Akamai. Los
primeros pasos de la búsqueda son exactamente los mismos, Al igual que antes, el servidor
local es, en algún momento, dirigido al servidor DNS xyz.com. Sin embargo, en esta ocasión,
en respuesta a su solicitud acerca de www.xyz.com, el servidor local recibe un apodo,
conocido en el DNS como “CNAME”. Este apodo no es una dirección IP, sino un nombre
intermedio de DNS a partir del cual se obtendrá la dirección IP de www.xyz.com. Un
ejemplo de CNAME en el modelo de Akamai podría ser a212.g.akamai.net.
El servidor local se enfrenta entonces a la habitual tarea de averiguar una dirección de
DNS. Para ello, lleva a cabo su consulta recursiva de DNS en akamai.net, obteniendo así la
dirección IP de un servidor DNS de nivel superior de Akamai. Se contacta con este servidor
para realizar la búsqueda de g.akamai.net. Llegados a este punto, el servidor DNS de nivel
superior realiza una serie de cálculos geográficos elementales con el fin de determinar la
dirección IP que se debería obtener para g.akamai.net. Esta dirección IP no es la IP de un
servidor web, sino de un servidor DNS de bajo nivel de Akamai. Este servidor DNS de bajo
nivel ejecutará un algoritmo en tiempo real más sofisticado que tenga en cuenta la congestión
de la red, las condiciones de la red local, la carga del servidor, etc.; y determinará el servidor
web adecuado para el usuario.
El servidor local contacta entonces con este servidor DNS de bajo nivel para solicitar
la solución a a212.g.akamai.net y, finalmente, recibe la dirección IP del servidor de Akamai
que hospeda los contenidos del sitio web que se habían solicitado en un principio.
1. El navegador busca www.xyz.com en su caché.
2. La consulta pasa a la caché del sistema operativo.
3. Se contacta con el servidor local.
4. El servidor local realiza una llamada recursiva, que acabará por llegar al servidor
root.
5. El servidor root devuelve la dirección IP del servidor DNS de xyz.com.
6. El servidor local contacta con el servidor DNS de xyz.com.
7. El servidor DNS de xyz.com devuelve el apodo (CNAME) a212.g.akamai.net.
8. El servidor local realiza una llamada recursiva para buscar akamai.net.
9. La consulta devuelve la dirección 15.15.125.6 como solución para akamai.net.
10. El servidor local contacta con el servidor DNS de nivel superior de Akamai en la
dirección 15.15.125.6 para hacer averiguaciones sobre g.akamai.net.
11. El servidor DNS de nivel superior (HLDNS) de Akamai realiza una serie de
cálculos geográficos y direcciona la consulta del servidor local a la dirección
20.20.123.56, correspondiente a un servidor DNS de bajo nivel mejor situado
geográficamente.
14
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Figura 1.9. Búsqueda DNS con el sistema de Akamai.
12. El servidor local contacta con el servidor DNS de bajo nivel de Akamai para pedir
una solución a a212.g.akamai.net.
13. El servidor DNS de bajo nivel (LLDNS) devuelve la dirección IP del servidor de
Akamai adecuado.
14. Se entrega la dirección IP al sistema operativo de la máquina del usuario que
inició la solicitud.
15. Éste, a su vez, pasa la IP al navegador, que actualiza su caché.
16. Por último, se inicia la petición del HTML.
1.4.5. Jerarquía de servidores y tiempo de vida
Anteriormente mencionamos que los registros almacenados en la caché de los DNS caducan
después de un cierto tiempo llamado “tiempo de vida” (TTL). Un mayor TTL implica un
menor número de búsquedas recursivas, ya que la información almacenada en la caché será
válida durante más tiempo. El peligro de un mayor TTL está en que cambie la dirección IP de
un sitio web, ya que entonces no se podrá acceder a él hasta que la dirección almacenada en
la caché caduque.
Con el sistema de Akamai, tan sólo es posible tener unos cuantos servidores DNS de
nivel superior (HLDNS), debido a las restricciones de InterNIC. Puesto que todas las
peticiones de usuario de Akamai han de ser atendidas, en un principio, por dichos servidores,
éstos se encuentran sobrecargados. Si estos servidores DNS tuvieran que determinar el
servidor web adecuado para cada usuario, teniendo en cuenta las condiciones de la red en
tiempo real, se colapsarían. En su lugar, el servidor DNS de nivel superior realiza los
cálculos geográficos preliminares y direcciona al usuario hacia un servidor DNS de bajo
nivel (LLDNS), que es el que lleva a cabo la laboriosa tarea computacional de determinar
15
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
cuál es el servidor web adecuado. Puesto que existen miles de servidores DNS de bajo nivel,
la carga está entonces bien distribuida.
Es probable que el mismo servidor DNS sea válido para un determinado usuario
durante, al menos, una parte del día, dado que los parámetros de red de alto nivel y
geográficos no varían con rapidez. De este modo, cuando un usuario es direccionado hacia un
servidor LLDNS concreto, el tiempo que su dirección IP permanece almacenada en la caché
puede ser de hasta una hora. Esto reduce todavía más la carga en los servidores HLDNS.
A su vez, los servidores DNS de bajo nivel, deben determinar el servidor web
adecuado para cada cliente, teniendo en cuenta ciertas condiciones en tiempo real, como son
la congestión de la red y la carga del servidor dentro de una zona geográfica. Puesto que
estas condiciones varían con rapidez, una vez que un servidor LLDNS direcciona a un cliente
hacia un servidor web concreto, la dirección se almacena sólo durante unos cuantos
segundos. Esto garantiza que el sistema responda con rapidez ante un cambio en las
condiciones; cada usuario será redireccionado al servidor adecuado para él en ese momento.
1.4.6. Mapas de DNS
Los servidores de Akamai son los responsables de determinar de qué servidor recibirá
finalmente el usuario los contenidos. Para tomar esta decisión, los algoritmos tienen en
cuenta la situación geográfica, la congestión de Internet, la carga del sistema, el estado del
servidor y las demandas de los usuarios. Los mapas, elaborados tras tener en cuenta todos
estos factores, se recalculan constantemente, una y otra vez, en función del TTL mencionado
anteriormente –cada hora en el caso de los servidores HLDNS y cada pocos segundos en el
de los servidores LLDNS.
1.4.7. Montaje de contenidos dinámicos en el borde
Como hemos mencionado anteriormente, EdgeSuite de Akamai pretende generar contenidos
dinámicos en el borde de la red, en lugar de tener pedirlos continuamente al servidor central.
Hoy en día, los diseñadores web siguen añadiendo contenidos dinámicos a sus sitios, tales
como noticias, citas, información meteorológica, elementos personalizados, etc. Para ello,
emplean ASP (Active Server Pages) u otras tecnologías similares, que permiten contenidos
web ricos y personalizados.
Sin embargo, estos contenidos dinámicos originan serios problemas en la entrega de
contenidos: el esfuerzo que supone la entrega de miles de páginas web personalizadas,
construidas en el momento, puede afectar seriamente al servidor central, que no sólo debe
generar los contenidos, sino también despacharlos. La entrega de páginas web personalizadas
desde el borde también supone un reto, dado que la base de datos se encuentra en el servidor
central. Ya hemos visto cómo EdgeSuite de Akamai resuelve este problema almacenando en
la caché elementos de distintas páginas, llamados fragmentos de contenido, para luego
montarlos automáticamente en función de la información de la base de datos con el fin de
formar una página web personalizada para el usuario final.
16
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Figura 1.10. Comparación del acceso tradicional a los servidores con el montaje en el borde.
EdgeSuite lo lleva acabo mediante el empleo de “EdgeSide Includes” (ESI), un lenguaje de
marcado abierto promovido en sus comienzos por Oracle y Akamai. Este lenguaje disecciona
las páginas web en distintos fragmentos, cada uno de ellos con su perfil de caché (si nos
situamos dentro del contexto de nuestro primer ejemplo, el tiempo de Boston podría ser uno
de esos fragmentos, almacenado con un TTL de 15 minutos). Estos fragmentos están
alojados en los servidores del borde de las redes de Akamai y son incorporados en el
montaje de páginas web que tiene lugar en estos servidores cuando los usuarios los solicitan.
La capacidad para construir páginas web dinámicas a partir de fragmentos individuales en el
borde de la red implica que sólo es necesario obtener del servidor central los elementos que
no se pueden almacenar en la caché o los que han caducado. Además, el montaje de la página
puede ser condicional, dependiendo de las cookies del usuario final o de las cabeceras de las
peticiones HTTP. Básicamente, ESI evita tener que obtener páginas completas del servidor
central, reduciendo enormemente la carga que éste ha de soportar.
1.4.8. Conexiones entre el borde y el núcleo
Anteriormente explicamos que los servidores de Akamai montan las páginas para el usuario
final. Este proceso puede requerir información del servidor central del sitio que se alberga:
información personalizada, preferencias del usuario, etc. El servidor de Akamai en el borde
de la red necesitará entonces ponerse en contacto con el servidor central del sitio. Para ello,
deberá hacer frente a toda la gama de problemas relacionados con la conectividad en Internet
mencionados anteriormente: la congestión de la red, los problemas de peering, etc.
¿Cómo resuelve Akamai este problema? La respuesta está en lo que se conoce como
Routing Overlay Networks (redes superpuestas de enrutamiento) o “Akaroutes”, como se les
llama dentro de Akamai. El concepto es simple: utilizar el conjunto de los casi 15.000
17
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
servidores distribuidos geográficamente que posee Akamai, conectándolos entre sí para
proporcionar múltiples rutas alternativas.
En lugar de enviar los datos a través de Internet, directamente desde el servidor de
Akamai en el borde hasta el servidor central del sitio, el sistema evalúa un conjunto de
posibles rutas a través de varios servidores de Akamai y elige la más rápida. Por ejemplo, un
modo de llegar al sitio X desde el servidor A podría ser a través de los servidores C y D, en
lugar de conectar directamente con A desde X. Por sorprendente que pueda parecer, este
enfoque indirecto realmente mejora el rendimiento.
El motivo de esto es que el sistema mantiene datos del rendimiento de cada ruta y
compara infinidad de posibles rutas para encontrar una adecuada. Para ello, tiene en cuenta la
congestión y el tráfico, algo que Internet como un todo no hace. Incluso a pesar de que los
paquetes enviados desde un servidor de Akamai al siguiente viajan a través de Internet y
están sujetos a los caprichos del BGP, los complejos algoritmos de enrutamiento de Akamai
garantizan la elección del mejor trayecto posible, lo que se traduce en una conexión más
rápida y fiable entre servidor del borde y el servidor central de sus sitios.
Este método de superposición elimina los problemas de peering originados por la
negativa de una red determinada a dejar pasar el tráfico a través de su estructura. Dado que
todas las conexiones de tunneling se consideran datos de Akamai y Akamai posee derechos
sobre todas las redes que utiliza, dichas redes no pueden rechazar el tráfico.
Por último, si por algún motivo resulta imposible acceder al servidor central del sitio,
el servicio ACS de Akamai obtiene del propio sistema de Akamai una página por defecto. De
este modo, los usuarios recibirán el contenido de la dirección web incluso si el servidor
central del sitio está caído.
1.4.9. Una observación sobre el streaming en vivo
El streaming de contenidos en vivo como los de vídeo y audio presenta sus propios retos.
Como mencionamos anteriormente, las limitaciones impuestas por la Internet tradicional
llegan hasta tal punto que el streaming fiable y de calidad es prácticamente imposible. Las
capacidades de enrutamiento distribuidas y optimizadas de Akamai mejoran las condiciones
para el streaming en vivo, reduciendo la carga de cualquier servidor dado y mejorando la
calidad de las conexiones que transmiten las tramas.
Akamai utiliza un mecanismo adicional para evitar los problemas causados por la
pérdida de paquetes. Una vez que se codifica una trama y se direcciona por el interior de la
red de Akamai, inmediatamente se duplica y se divide en una serie de subtramas
independientes. Estas subtramas se envían, entonces, por varias rutas diferentes hacia
clusters localizados de máquinas que distribuyen el flujo a su área local. Sólo es necesaria
una copia de cada subtrama para reconstruir la trama; de este modo, puesto que se envían
múltiples copias de cada subtrama a cada cluster, se pueden perder o corromper algunas de
ellas sin que se ponga, por ello, en peligro el que los clusters locales reciban la trama
completa. Esta estructura de distribución del flujo, combinado con el mecanismo descrito
anteriormente, hace que la entrega de tramas de Akamai sea mucho más fiable y de mayor
calidad.
18
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
1.5. Retos tecnológicos
Los diseñadores del sistema de Akamai tuvieron que enfrentarse a diversos retos
tecnológicos a la hora de llevar a cabo su construcción. Algunos lograron superarlos,
mientras que otros continúan siendo investigados. A continuación, trataremos algunos de
estos retos.
1.5.1. Implantación y gestión
Para que funcione la entrega en el borde, los servidores de borde han de ser implantados en
miles de redes. Más aún, estos servidores tienen que estar distribuidos geográficamente para
lograr las mejores condiciones de fiabilidad y rendimiento. El contenido debe fluir
directamente desde el proveedor de contenidos hasta cada uno de estos servidores del borde y
el servicio ha de ser capaz de manejar los contenidos a medida que éstos atraviesan múltiples
redes, lo que requiere unos algoritmos complejos y un mapeo detallado de la topología de la
Red y origina complejos problemas de seguimiento.
1.5.2. Mapeo
Cuando un usuario solicita una página web del sistema de Akamai, el sistema tiene que
decidir qué servidor utilizará. Esto presenta una serie de dificultades debido a la complejidad
de la decisión.
•
Uno de los problemas es simplemente el de la escala: hay cientos de millones de
usuarios, decenas de miles de servidores, miles de ubicaciones geográficas y otros
tantos sitios web alojados, por lo que los algoritmos se han de ejecutar en un tiempo
casi lineal.
•
Para mantener el mejor rendimiento es necesario monitorizar constantemente las
condiciones de Internet y actuar al instante ante los cambios. El problema se ve
incrementado debido a que la congestión y los fallos de Internet están muy extendidos
y son impredecibles.
•
El sistema tiene que equilibrar una carga de tráfico muy variable y optimizar muchos
recursos diferentes a la vez que minimiza el coste.
•
El sistema debe ser flexible y capaz de tolerar un gran número de fallos importantes
(como la caída de unos 1.000 servidores a la vez) sin dejar de ofrecer un servicio
constante y fiable.
•
Los algoritmos de control han de estar distribuidos a lo largo de la red y funcionar
aún con información imperfecta.
•
Los DNS deben responder en milisegundos. Esto es especialmente importante, ya que
el sistema de Akamai introduce un segundo nivel de consultas DNS.
1.5.3. Logging, elaboración de informes y facturación
Otro reto complejo está relacionado con los negocios: el logging, la elaboración de informes
y la facturación de los más de diez mil millones de hits que recibe diariamente el sistema de
Akamai. El problema es especialmente complejo, debido a que los datos se encuentran
distribuidos por más de 15.000 servidores de 60 países y se han de poder obtener en tiempo
real para que los clientes los utilicen. El sistema ha de dar soporte a los informes de datos, a
la monitorización del rendimiento y a las consultas SQL, todos ellos en tiempo real.
19
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Akamai dispone de un centro de control operacional de la red –Network Operating
Control Center (NOCC)– en sus oficinas centrales para monitorizar constantemente el estado
de todo el sistema. Los mecanismos de detección de errores originales eran relativamente
sencillos, pero con el continuo aumento en el número de servidores es necesario diseñar
sistemas de detección cada vez más complejos.
1.5.4. Operaciones
Otro de los problemas es que el gigantesco sistema distribuido de Akamai debe estar siempre
en funcionamiento. No puede dejar de estar en línea, ni siquiera por cuestiones de
mantenimiento y, por ello, ha de ser capaz de aceptar actualizaciones de software “en
marcha”. Más aún, el sistema debe ser seguro frente a posibles ataques maliciosos, así como
frente a los errores del software de terceros.
La dificultad de esto se puede ver en el ejemplo de un router de Malasia que cometió
un error en el sistema operativo Linux, causando la caída de varios servidores de Akamai.
1.5.5. Actualización y precisión de los contenidos
Akamai se compromete a proporcionar siempre contenidos actualizados. Los contenidos
desfasados no deben ser distribuidos. El sistema debe proporcionar algún modo de deshacer
rápidamente los errores de los clientes y actualizar los contenidos. Finalmente, el sistema
debe ofrecer flexibilidad y, en cierto modo, facilitar a los clientes el control de los
contenidos. Esto es un arma de doble filo ya que, al mismo tiempo, Akamai se tiene que
proteger a sí mismo de los errores cometidos por los clientes y no dejar que se extiendan a
través del sistema.
1.5.6. Gestión de streaming y webcasting en vivo
A medida que el webcasting y el streaming en vivo adquieren importancia, el sistema debería
ofrecer una serie de opciones especializadas para gestionarlos; debería ser capaz de utilizar y
difundir información para controlar, de forma inteligente, la pérdida de paquetes; y optimizar
la velocidad de conexión, eligiendo continuamente la mejor ruta de entre una serie de
posibilidades. La comunicación debería ser bidireccional dado que, a menudo, los usuarios
están interesados en sesiones interactivas de preguntas y respuestas o mensajes. También son
necesarias la agregación de datos y las consultas, así como la entrega perfectamente
sincronizada de audio, vídeo y diapositivas.
1.6. Internet es un triunfo de la teoría
Hemos visto una presentación de Akamai Forum transmitida por una red virtual privada
(VPN) hasta un portátil situado en el aula. Tras esta tecnología hay una serie de algoritmos
importantes. Resulta instructivo enumerar algunos de ellos: al hacerlo, nos damos cuenta del
impacto que la investigación teórica ha tenido sobre Internet.
1. Algoritmos de red:
Ethernet: CSMA (Carrier-Sense múltiple access).
TCP: backoff exponencial.
IP: jerarquía de direcciones.
20
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Árbol de expansión mínima: empleado por los switches para evitar los ciclos en
las LAN.
BGP: utilizado para el enrutamiento en Internet.
2. Protocolo de túnel punto a punto para las VPN (PPTP)
Hash de contraseñas y encriptación: proporciona privacidad.
Autenticación: confirma la identidad.
3. Codificación y decodificación
Códec: codifica las tramas de audio y vídeo.
Compresión: reduce el consumo de ancho de banda.
Códigos de corrección de errores: aumenta la fiabilidad.
Renderización: muestra el contenido en la pantalla.
4. Akamai
Selección del mejor servidor: requiere una optimización compleja.
Elaboración de informes y facturación: requiere acceso en tiempo real a los
datos distribuidos.
Etc.
1.7. Problema del día: optimización de costes
Un tema de investigación importante para Akamai en términos de rentabilidad es la
optimización de costes. Se trata de conectar a cada usuario con el servidor adecuado, a la vez
que se minimizan los costes globales. Cada usuario dispone de un conjunto de servidores
adecuados hacia los que puede ser dirigido y cada servidor tiene un coste asociado por su
utilización.
Examinemos el siguiente problema: hay alrededor de un millón de fuentes de carga y
miles de contenedores. Cada fuente dispone de un conjunto de contenedores adecuados.
Existe también un coste por unidad de carga asociado con cada contenedor. El problema está
en almacenar todas las cargas y, a la vez, minimizar el coste.
La solución más sencilla es un algoritmo greedy. Elegir el contenedor adecuado más
barato para cada fuente. Esto garantiza que se almacenarán todas las cargas con el mínimo
coste total. En el ejemplo anterior, los contenedores más baratos de ambas fuentes coloreadas
costaron 1$. Por tanto, el coste total es de 20 * 1$ + 10 * 1$ = 30$.
Pero examinemos, a continuación, una variante más compleja del problema.
Supongamos que hay economías de escala: el coste por utilizar un contenedor disminuye por
unidad de carga. Dado que en este caso la carga es, en realidad, el ancho de banda, el
supuesto es más realista. El algoritmo greedy del que hemos hablamos anteriormente ya no
funciona en este caso, como se muestra en el siguiente ejemplo:
21
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Figura 1.11. Ejemplo sencillo.
Figura 1.12. Fallo del algoritmo greedy.
El coste, en este caso, se produce en dos etapas. El contenedor central presenta un
coste de 1,01 dólares para la primera unidad y es gratuito para todas las unidades
posteriores. Los otros contenedores cuestan 1 dólar para cada las unidades. Podemos
observar que, al igual que entes, el algoritmo greedy selecciona los contenedores que
presentan un coste de 1 dólar para ambas fuentes. Esto supone un coste total de 2 dólares. Sin
embargo, se puede lograr un coste de tan sólo 1, 01 dólares asignando las dos fuentes al
contenedor central.
22
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
¿Existe algún algoritmo adecuado que pueda resuelva esta minimización del coste?
Por desgracia, la respuesta es no. Se trata de un problema NP-difícil y se puede reducir a un
problema de cobertura de vértices.
A continuación, se muestra un esquema conceptual de la reducción.
1.7.1. Problema de cobertura de vértices
Partimos del gráfico de la figura 1.13. que se muestra a continuación. Los vértices B y D de
la figura tienen como propiedad que en conjunto tocan todos los bordes del gráfico. Desde
estos vértices se puede llegar directamente a cualquier otro nodo del gráfico. Se dice que este
gráfico presenta una cobertura de 2 vértices. El problema de cobertura de vértices de tamaño
k consiste en determinar si un gráfico determinado presenta un conjunto de cómo mucho k
vértices, de modo que todos los bordes del gráfico tocan un vértice del conjunto. Este
problema se conoce como NP-completo.
Figura 1.13. Gráfico del ejemplo.
1.7.2. Esquema de reducción
El problema de minimización del coste se puede reducir al problema de cobertura de vértices
del siguiente modo: supongamos que tenemos un algoritmo A que, al darle un ejemplo del
problema de optimización de costes, devuelve la solución adecuada en tiempo polinómico.
Demostraremos que, de ser esto cierto, se podría resolver también en tiempo polinómico el
problema de cobertura de vértices, que es NP-difícil.
Reducimos el problema de cobertura de vértices de un gráfico G a un problema de
optimización de costes. Para ello es necesario:
1. Crear un conjunto de fuentes que correspondan a cada borde de G.
2. Crear un conjunto de contenedores que correspondan a cada vértice de G.
3. Para cada contenedor x, añadir un borde a la fuente y sí y sólo sí el vértice
correspondiente a x en G toca el borde correspondiente a y en G2.
4. Establecer la cantidad de carga originada por cada fuente para 1 unidad.
2
El “conjunto adecuado” de contenedores para una fuente está representado, en este caso, por los contenedores
conectados por medio de bordes a dicha fuente.
23
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
5. Establecer el coste de cada contenedor para que sea 1$ para la primera unidad de
carga y 0$ para las siguientes.
Llamaremos a este nuevo gráfico H. H constituye un claro ejemplo del problema de
optimización de costes tal como lo hemos descrito.
En la figura 1.14 que se muestra a continuación se puede ver un diagrama de esta
transformación para el gráfico de ejemplo anterior.
Figura 1.14. Ejemplo de reducción.
Recordemos que el coste de utilización de un contenedor es de 1$ para la primera
unidad y 0$ para las siguientes. De este modo, lo ideal desde el punto de vista local es dirigir
todas las cargas de una fuente a un solo contenedor, sin perder la generalidad. Supongamos
que una fuente dirige su primera unidad de carga hacia el contenedor A. Entonces, todas las
cargas restantes que procedan de esa fuente se podrán dirigir a A con un coste total adicional
0, lo que mantiene una solución ideal desde el punto de vista local.
Obsérvese que si H se puede resolver con un coste de k dólares, entonces todas las
fuentes de H han de ser asignadas a exactamente a k contenedores. Para comprobar esto,
obsérvese que cada contenedor utilizado cuesta 1 dólar, independientemente de la cantidad
de carga que tenga asignada. Por tanto, si se puede resolver H con k dólares, se deben haber
utilizado k contenedores.
Según la definición del problema de optimización de costes, todas las fuentes de
carga han de ser asignadas a un contenedor para formar una solución. Hemos averiguado que
k contenedores son suficientes para controlar toda la carga de H. Según esto, dichos k
contenedores han de estar conectados a cada fuente de H.
Recordemos que cada contenedor de H corresponde a un vértice de G, mientras que
cada fuente corresponde a un borde. Sin embargo, si hay k contenedores conectados a cada
24
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
fuente de H, esto significa que hay k vértices de G conectados a cada borde de G, lo que
implica que G presenta una cobertura de k vértices.
De este modo, podemos definir un algoritmo B al que, al pasarle un ejemplo del
problema de cobertura de vértices en G, construya el correspondiente problema de
optimización de costes siguiendo los pasos 1-5 anteriores, llame a A para obtener una
solución y compruebe si se están utilizando k o menos contenedores. De ser así, B sabrá que
G presenta una cobertura de vértices. Sin embargo, si A se ejecuta en tiempo polinómico, B
también lo hará. Dado que el problema de cobertura de vértices es NP-difícil, no existe un
algoritmo A semejante (conocido). Esto completa la reducción3.
3
La reducción inversa es relativamente obvia. Si G presenta una cobertura de vértices de tamaño k, es que hay
un conjunto de k vértices conectados a cada borde de G. Del mismo modo, esto significa que hay un conjunto
de k contenedores conectados a cada fuente de H. Puesto que cada contenedor cuesta 1 dólar por su uso,
independientemente de la cantidad de carga que soporta, hay una solución para H con coste un de k dólares.
25
MIT 18.996
Lección 1 – 6 de febrero de 2002
Primavera 2002
Bibliografía
[1] Whitepaper de Akamai: “Internet Bottlenecks: the Case for Edge Delivery Services”,
Cambridge, MA, 2000. Disponible en la URL:
http://www.akamai.com/en/html/services/white_paper_library.html
[2] Janiga, M; Dibner, G. Y Governali. F. “Akamai & Internet Infraestructure: Content
Delivery”, Goldman Sachs Equity Research, 2001.
[3] Leighton, Tom. Presentación: “The Challenges of Delivering Content on the Internet”,
Cambridge, MA, 2002.
26
Descargar