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
