1.1.

Introduccin
En esta leccin hablaremos de diversos problemas de investigacin relacionados con
Internet. En cada clase trataremos:

Cmo funciona hoy en da un determinado componente de Internet o una

tecnologa.

Cuestiones y problemas de la tecnologa actual.

Posibles nuevas lneas de investigacin.

Formulacin de problemas y soluciones concretos.

Empezaremos hablando de cmo funciona la Red hoy en da, de cules son las
cuestiones principales en cuanto a su arquitectura actual y de qu modo los servicios de
Akamai estn la estn modificando. Posteriormente, hablaremos de los retos tecnolgicos y
concluiremos con las futuras lneas de investigacin en esta rea.
La mayora de las clases incluirn un ejemplo de algn problema terico surgido a
partir de la investigacin en Akamai. El ejemplo de hoy, que veremos ms tarde, est
relacionado con la optimizacin 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. Cmo funciona la Red hoy en da

La Red, vista desde fuera, simplemente conecta a proveedores de contenidos con
usuarios finales. Lo ms importante de la Red es que usuarios de todo el mundo pueden tener
acceso a contenidos sin ningn tipo de impuestos por licencia. Cualquiera puede colgar una
pgina 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 tambin sufre de
inestabilidad y de un rendimiento impredecible. Y a medida que el nmero de sitios y de
usuarios aumenta, estos problemas se incrementarn 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 nmero de pequeos ISPs. Para
que Internet acte 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.

Leccin 1 6 de febrero de 2002

Primavera 2002

Un punto neutro es, bsicamente, 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 trfico 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 ms 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 mtodos sofisticados para determinar el mejor camino de enrutamiento
entre ellos, anlisis de topologa, ancho de banda y congestin, el BGP no. En su lugar, el
BGP determina las rutas minimizando, simplemente, el nmero de redes individuales que
han de atravesar los datos. Este enfoque, aunque escalable, no controla bien la congestin.
La arquitectura actual de Internet favorece enormemente la escalabilidad de la Red y
ha permitido que se extienda rpidamente. 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 centralizacin simplemente no funciona. Los contenidos
conectados a la red en un punto se pueden ver rpidamente colapsados ante la demanda de un
gran pblico internacional. Tradicionalmente, cada proveedor de contenidos establece un
sitio web central en una sola ubicacin, que proporciona informacin 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.

Leccin 1 6 de febrero de 2002

Primavera 2002

Con el fin de acomodar a un creciente nmero de usuarios, el proveedor de contenidos debe

comprar cada vez ms ancho de banda a su ISP; y lo que es ms importante: el ISP debe
tambin expandir continuamente su propia capacidad de red y sus iguales tambin! De este
modo, es evidente que la solucin centralizada no es escalable.

Figura 1.2. El cuello de botella de la primera milla.

Un ejemplo de este problema es el Victorias Secret Online Fashion Show (Feria de moda en
lnea de Victorias Secret), anunciado enormemente en la Super Bowl de 1999. Cuando ms
de un milln de suscriptores intentaron acceder simultneamente al webcast en vivo, los
servidores centrales no pudieron atender a tantas peticiones, por lo que el sitio se colaps y la
prctica totalidad de los espectadores se qued sin poder ver el webcast. Entre otros ejemplos
se incluyen los sitios Akamai, que ofrecan los trilers de La guerra de las galaxias, y el sitio
de la NASA, que ofreca los contenidos sobre el Mars Rover.

El problema del peering

Hoy en da, Internet es una red de redes, con puntos acceso o NAPs entre ellas (figura
1.2).
Para atravesar Internet, el trfico 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 comn la concepcin errnea de que los grandes controlan gran parte del trfico
de Internet. Si una red pudiera abarcar la mayor parte del trfico de Internet, se podran
alcanzar la mayora de los destinos dentro de esa red sin necesidad de atravesar ningn punto
de acceso. Sin embargo, no es as. En realidad, ninguna red controla por s sola ms del 6%
del trfico de Internet1. Dado que el trfico se encuentra tan repartido a lo largo de miles de
redes, ha de viajar en su mayora a travs de muchas redes diferentes y, por tanto, de
numerosos puntos neutros, que son una fuente de congestin.

Por trfico, nos referimos al nmero de bits transferidos, no al nmero de usuarios. Un gran nmero de
usuarios slo puede producir una pequea cantidad de trfico si sus conexiones son lentas, como es el caso de
AOL. El servicio de ancho de banda Excite@Home, por ejemplo, produce ms o menos el mismo trfico que
AOL, a pesar de tener muchos menos usuarios.

Leccin 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 econmico
Muchos ISP restringen deliberadamente sus puntos neutros para impedir el acceso de
grandes cantidades de trfico exterior. Con frecuencia, se producen discusiones acerca de
los pagos; es habitual que los grandes ISP cobren a los pequeos por utilizar sus
estructuras, pero las grandes empresas Tier 1, generalmente, no se cobran entre ellas.
Dado que las redes pequeas tienen que pagar a las grandes por utilizar sus estructuras,
tienden a comprar slo la capacidad justa que necesitan para manejar el trfico que han
afrontar en el momento de la compra. Esto significa que los puntos de acceso operan
prcticamente al mximo de su capacidad, lo que implica prdidas de paquetes y retrasos
de los mismos. Las grandes redes, impulsadas por motivos econmicos similares, tienden
a no querer enlazarse a otras redes de gran tamao, ya que no cobran nada por ello.
En ocasiones, estas cuestiones econmicas hacen que el sistema se venga abajo.
Cable&Wireless, en una ocasin, 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 accin fragment Internet durante tres das; de ese modo, los usuarios de
PSINet no podan acceder a los contenidos hospedados en C&W y viceversa. El servicio
se restableci nicamente cuando la seccin 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 ms corta para determinar las
rutas ptimas, ignorando la congestin incluso aunque los routers puedan acceder a
informaciones como el tamao de las colas. Como consecuencia de ello, cuando los
puntos de acceso se congestionan, BGP contina envindoles trfico, incrementando el
problema.
El error humano
Los protocolos de enrutamiento tambin reciben instrucciones de operadores
humanos, lo que puede conducir a prdidas accidentales de rutas o a la introduccin de
rutas incorrectas. Por ejemplo, los operadores de los sistemas son los responsables de
establecer el nmero de saltos a otras redes. A menudo se juega a anunciar saltos
4

Leccin 1 6 de febrero de 2002

Primavera 2002

falsamente con el fin de desviar el trfico 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 trfico se dirigi hacia el Nivel 3, causando una gran congestin. Como mencionamos
anteriormente, BGP ignora la congestin a la hora de determinar las rutas ptimas, por lo
que el problema pronto afect a las tres cuartas partes de la totalidad del trfico de
Internet. El parn 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 solucionaran a medida que se consolidaran las
empresas de telecomunicaciones y se fusionaran las redes, no hay ningn indicio de que esto
est sucediendo. En realidad, el nmero 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 pginas
web, la mayora 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
trfico existente en la Red hoy en da. Actualmente, esta cuestin afecta slo a los pases
extranjeros y al acceso global. Sin embargo, a medida que el trfico de Internet aumente, se
puede volver ms urgente.

La ltima milla
El cuello de botella de la ltima milla es con el que estn familiarizados la mayor
parte de los usuarios de Internet: la velocidad limitada del mdem de 56K que les sirve de
enlace a su ISP. Una equivocacin frecuente, no obstante, es la de pensar que la introduccin
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 comunicacin
seguirn causando problemas de rendimiento: la calidad de una conexin depende de su
enlace ms dbil. De hecho, en realidad la velocidad limitada de los mdems es lo que est
salvando a Internet del colapso total: si todos los usuarios pudieran solicitar contenidos a
velocidades de banda ancha crearan tanta congestin en los otros tres tipos de cuellos de
botella que el trfico de Internet se estancara. En efecto, hoy en da, Internet est
funcionando casi al lmite 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 trfico pase a travs de mltiples 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 ms
importantes de esto son las siguientes:
Descargas lentas
Los contenidos han de atravesar mltiples estructuras (backbones), puntos neutros a
menudo congestionados y largas distancias, para llegar al usuario final. Por ello, con
frecuencia el funcionamiento es lento.

Leccin 1 6 de febrero de 2002

Primavera 2002

Funcionamiento inestable
Con frecuencia, los contenidos se pueden ver bloqueados como resultado de la
congestin 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 prdida de paquetes,
la congestin y los estrechos conductos sirven para degradar la calidad de streaming,
haciendo que la reproduccin de videos de alta resolucin en lnea bajo demanda sea
prcticamente imposible.
El ancho de banda no mejora la situacin
Como ya se ha comentado, el ancho de banda no es la solucin a los cuellos de
botella mencionados anteriormente. De hecho, servira nicamente para incrementar la
congestin de la primera milla, los problemas de peering y la congestin de las
estructuras, a medida que ms gente intenta realizar mayores descargas.

1.3. La solucin de Akamai: entregas en el borde

La solucin 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 distribucin 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 ms de 60 pases de todo el mundo, hay muchas
posibilidades de que cualquier usuario de Internet tenga un servidor de Akamai cerca.

Leccin 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 relacin al establecido. Al
eliminar el punto central a travs del cual se acceda a los datos, esta solucin evita el cuello
de botella de la primera milla. Los contenidos se sirven desde ubicaciones prximas al
usuario final, y no desde un servidor central geogrficamente 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 mltiples servidores, su capacidad ya no se ve limitada por la velocidad
de cada enlace de red. El sistema es tambin ms fiable, puesto que no hay ninguna
posibilidad de fallo. Si se cae un servidor de Akamai, sus usuarios son automticamente
dirigidos a otro.
El sistema de entrega en el borde resuelve tambin los problemas de peering. Ya no
es necesario que los datos atraviesen mltiples redes ni pasen por puntos neutros
congestionados. Cada usuario los puede obtener directamente de su propia red, lo que supone
descargas ms rpidas. Por supuesto, esto supone que todas (o casi todas) las redes debern
tener un servidor local de Akamai. Adems, puesto que los contenidos se entregan desde el
borde de la red, la demanda de capacidad de estructura se ve tambin 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 ms cerca de los usuarios
finales y de resolver los tres problemas presentes en anteriores tramos de la comunicacin,
permite introducir con xito la banda ancha.
La mejora de rendimiento lograda por Akamai se puede observar en la figura 1.5.
Esta grfica muestra la media de los tiempo de acceso globales a un sitio web con y sin el
modelo de Akamai. Obsrvese que los tiempos de acceso son significativamente ms largos
en los das 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,

Leccin 1 6 de febrero de 2002

Primavera 2002

en algunos casos, hasta un 800%; en segundo lugar, el rendimiento del sitio web es mucho
ms 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 estticos, como banners e imgenes. 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 cdigo 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 congestin y la topologa de la
red. El servidor de Akamai proporciona entonces la mayora de los datos necesarios
para descargar la pgina. Esto reduce enormemente la comunicacin 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
difusin 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 prximos a ellos. Para dar soporte al streaming en vivo, Akamai transmite
mltiples 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 congestin o la calidad de
transmisin. Akamai utiliza esta tecnologa tambin para ofrecer aplicaciones de
streaming, tales como Akamai Forum y Akamai Conference.

Leccin 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 estndar. Proporciona streaming de audio y vdeo
en vivo y otros elementos interactivos.

Akamai Forum es una solucin que gestiona la totalidad del proceso de produccin y
difusin de eventos de los medios con streaming. Permite a las empresas producir
webcast en vivo e interactivos. El foro no requiere ningn software especial de cliente,
permite el feedback y la participacin del pblico en vivo diapositivas de presentacin
sincronizadas.

FirstPoint es un servicio de gestin de trfico global para proveedores de contenidos

con mltiples sitios espejo. FirstPoint monitoriza el trfico y la congestin de la red y
conecta a los usuarios finales con los mejores sitios espejo mediante DNS. FirstPoint
est diseado para interaccionar con otros servicios de Akamai.

EdgeScape permite a los proveedores de contenidos personalizar los contenidos de su

sitio en funcin del ancho de banda de la conexin, la direccin IP del usuario y su
situacin geogrfica. Por ejemplo, esto permite a los sitios ajustar automticamente 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
ubicacin. El sistema EdgeScape consiste en bases de datos locales alojadas en
servidores de la red de Akamai. Estos servidores personalizan las pginas web
basndose en los datos recogidos sobre el usuario: una vez ms la entrega de contenidos
se produce en el borde, los servidores gestionan las peticiones de los usuarios
directamente y slo contactan con el servidor central del proveedor de contenidos para
actualizar sus bases de datos.

El DPS (Digital Parcel Service): hoy en da, 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
lnea. Se trata de una completa solucin para la distribucin digital, la presentacin de
informes y la gestin de derechos.

El Reporter y el Traffic Analyzer proporcionan datos histricos y en tiempo real de la

utilizacin de la pgina. Estas potentes herramientas permiten un data mining
personalizado y el visionado en tiempo real del trfico de clientes. De este modo, el
cliente puede medir la eficacia de sus campaas publicitarias y de marketing, la
popularidad de sus eventos de streaming, etc.

El Content Storage (almacn de contenidos) de Akamai: es un servicio que permite a

los clientes almacenar archivos en servidores de Akamai situados estratgicamente.
Estos archivos son posteriormente entregados al usuario final mediante DPS, FreeFlow,
FreeFlow Streaming, etc.

EdgeSuite es la ltima generacin del servicio de entrega en el borde; la mayora de los

servicios de Akamai se han incorporado a modo de paquete en EdgeSuite. Lanzado al
mercado en el 2001, EdgeSuite ofrece servicios de gestin, entrega y almacenaje de
contenidos desde el borde de la Red. Gracias a l, un servidor ubicado en el borde
puede almacenar y entregar pginas de un conjunto de elementos variables, dirigiendo
tan slo cada pgina al individuo que ha solicitado los datos. A medida que los sitios se
vuelven cada vez ms personalizados e interactivos, la capacidad para almacenar
pginas web en el borde de la red sin tener que referirse continuamente al servidor

Leccin 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 aplicacin tenan lugar en el servidor central: los servidores del ncleo ejecutaban las
aplicaciones y preparaban el HTML para transmitirlo al usuario final. El aumento de
velocidad se obtuvo mediante la obtencin de objetos ms grandes y pesados, tales como
grficos 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 mayora de las aplicaciones en Internet se almacenen y se entreguen desde el borde,
facilitando as la personalizacin dinmica y un funcionamiento mucho ms rpido.
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 informacin meteorolgica. Esta
informacin se puede guardar fcilmente en la cach hasta unos 15 minutos sin que se quede
obsoleta. Este perodo de tiempo, despus 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 peticin. Cuando otro
usuario solicite el tiempo de Nueva York, ese contenido se almacenar tambin en la cach.
Si, a continuacin, 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 pgina adecuada y responder directamente. En el caso de muchos usuarios,
esta tcnica puede reducir enormemente la carga en el servidor central, ya que el servidor del
borde slo necesitar volver a ponerse en contacto con la base de datos del servidor central
cuando el TTL haya expirado.
Al igual que haca 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 ms contenidos desde el borde, dando lugar a un rendimiento an mejor.

1.4. Visin general de la tecnologa

Ofreceremos una amplia visin general del funcionamiento del sistema de Akamai. En
lecciones posteriores, tendremos en cuenta los detalles de su tecnologa 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 direccin IP de web.mit.edu. Esto se realiza por medio del
Domain Name Service (DNS), que funciona a modo de pginas amarillas de Internet. En
un nivel superior, el DNS localiza la direccin IP 18.7.21.77 como la correspondiente a la
familiar web.mit.edu. Una vez que el DNS devuelve la direccin IP, el navegador contacta
con el servidor de esa direccin y solicita la pgina. El servidor web devuelve cdigo HTML,
con los enlaces a otros objetos incorporados, tales como imgenes. Entonces, el navegador
deber repetir el proceso para cada objeto incorporado, solicitndolo y recuperndolo. En la
10

Leccin 1 6 de febrero de 2002

Primavera 2002

prctica, los navegadores pueden abrir mltiples conexiones simultneas para recuperar
pginas completas algunos objetos, como las imgenes, se ven aparecer poco a poco en la
pgina en funcin del orden en el que se van obteniendo.

Figura 1.6. Obtencin de una pgina por el medio tradicional.

1. El DNS busca www.xyz.com.
2. Devuelve la direccin IP correspondiente a www.xyz.com.
3. El navegador solicita el HTML al servidor de la direccin IP 10.10.123.8.
4. El servidor devuelve el HTML, incluidos los links incorporados.
5. El navegador realiza la bsqueda 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. Bsquedas en el DNS a la manera tradicional

El proceso de bsqueda 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 direccin como web.mit.edu, el navegador consulta primero su propia
cach, con el fin de determinar si ya ha averiguado antes la direccin IP correspondiente a
dicho dominio. De no ser as, consultar al sistema operativo, que tambin 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 bsqueda recursiva. Al final, la consulta puede llegar a la mxima
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 direccin IP del servidor DNS que aloja
el dominio mit.edu.

11

Leccin 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 direccin IP, que puede almacenar en su cach y
devolver al sistema operativo de la mquina que inici todo el proceso quien, finalmente, la
entrega al navegador.

Figura 1.7. Bsqueda 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 direccin 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 direccin IP de www.xyz.com.
8. La direccin IP se entrega al sistema operativo de la mquina 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 mtodo 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 direccin IP mediante DNS.
Sin embargo, en este caso la direccin que devuelve el DNS es la de un servidor de Akamai
vlido. El navegador contacta entonces con el servidor de Akamai para pedir el HTML. El

12

Leccin 1 6 de febrero de 2002

Primavera 2002

servidor de Akamai monta la pgina web, estableciendo conexiones con el servidor central de
Yahoo! para obtener contenidos dinmicos como las personalizaciones, en caso de que sea
necesario. A continuacin 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 direccin 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. Obtencin de una pgina web mediante el sistema de Akamai

1. El DNS busca www.xyz.com.
2. Obtiene la direccin 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 travs 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 direccin 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 conexin se establece a travs de Internet, por el mtodo tradicional,
ha de enfrentarse a todas las dificultades y problemas descritos previamente. Por ltimo, el
servidor de Akamai tiene que preparar y entregar la pgina. A continuacin, trataremos estas
cuestiones de una en una.

13

Leccin 1 6 de febrero de 2002

Primavera 2002

1.4.4. Bsqueda DNS con un sistema Akamai

Segn el enfoque de Akamai, el servidor DNS debe devolver la direccin del servidor de
Akamai adecuado. Esto requiere algunos cambios en el sistema DNS existente. En concreto,
la direccin www.xyz.com no se ha de transcribir directamente por 18.7.21.70, sino que se le
ha de asignar como apodo una direccin intermedia de Akamai; por ejemplo,
a212.g.akamai.net, para la que, posteriormente, se averiguar un servidor adecuado.
Examinemos el proceso de bsqueda del DNS con el sistema de Akamai. Los
primeros pasos de la bsqueda son exactamente los mismos, Al igual que antes, el servidor
local es, en algn momento, dirigido al servidor DNS xyz.com. Sin embargo, en esta ocasin,
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 direccin IP, sino un nombre
intermedio de DNS a partir del cual se obtendr la direccin IP de www.xyz.com. Un
ejemplo de CNAME en el modelo de Akamai podra ser a212.g.akamai.net.
El servidor local se enfrenta entonces a la habitual tarea de averiguar una direccin de
DNS. Para ello, lleva a cabo su consulta recursiva de DNS en akamai.net, obteniendo as la
direccin IP de un servidor DNS de nivel superior de Akamai. Se contacta con este servidor
para realizar la bsqueda de g.akamai.net. Llegados a este punto, el servidor DNS de nivel
superior realiza una serie de clculos geogrficos elementales con el fin de determinar la
direccin IP que se debera obtener para g.akamai.net. Esta direccin 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 ms sofisticado que tenga en cuenta la congestin
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 solucin a a212.g.akamai.net y, finalmente, recibe la direccin IP del servidor de Akamai
que hospeda los contenidos del sitio web que se haban 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 direccin 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 direccin 15.15.125.6 como solucin para akamai.net.
10. El servidor local contacta con el servidor DNS de nivel superior de Akamai en la
direccin 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
clculos geogrficos y direcciona la consulta del servidor local a la direccin
20.20.123.56, correspondiente a un servidor DNS de bajo nivel mejor situado
geogrficamente.

14

Leccin 1 6 de febrero de 2002

Primavera 2002

Figura 1.9. Bsqueda DNS con el sistema de Akamai.

12. El servidor local contacta con el servidor DNS de bajo nivel de Akamai para pedir
una solucin a a212.g.akamai.net.
13. El servidor DNS de bajo nivel (LLDNS) devuelve la direccin IP del servidor de
Akamai adecuado.
14. Se entrega la direccin IP al sistema operativo de la mquina 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 peticin del HTML.

1.4.5. Jerarqua de servidores y tiempo de vida

Anteriormente mencionamos que los registros almacenados en la cach de los DNS caducan
despus de un cierto tiempo llamado tiempo de vida (TTL). Un mayor TTL implica un
menor nmero de bsquedas recursivas, ya que la informacin almacenada en la cach ser
vlida durante ms tiempo. El peligro de un mayor TTL est en que cambie la direccin IP de
un sitio web, ya que entonces no se podr acceder a l hasta que la direccin almacenada en
la cach caduque.
Con el sistema de Akamai, tan slo 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 colapsaran. En su lugar, el servidor DNS de nivel superior realiza los
clculos geogrficos 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

Leccin 1 6 de febrero de 2002

Primavera 2002

cul 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 vlido para un determinado usuario
durante, al menos, una parte del da, dado que los parmetros de red de alto nivel y
geogrficos no varan con rapidez. De este modo, cuando un usuario es direccionado hacia un
servidor LLDNS concreto, el tiempo que su direccin IP permanece almacenada en la cach
puede ser de hasta una hora. Esto reduce todava ms 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 congestin de la red y la carga del servidor dentro de una zona geogrfica. Puesto que
estas condiciones varan con rapidez, una vez que un servidor LLDNS direcciona a un cliente
hacia un servidor web concreto, la direccin se almacena slo 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 decisin, los algoritmos tienen en
cuenta la situacin geogrfica, la congestin 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 funcin 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 dinmicos en el borde

Como hemos mencionado anteriormente, EdgeSuite de Akamai pretende generar contenidos
dinmicos en el borde de la red, en lugar de tener pedirlos continuamente al servidor central.
Hoy en da, los diseadores web siguen aadiendo contenidos dinmicos a sus sitios, tales
como noticias, citas, informacin meteorolgica, elementos personalizados, etc. Para ello,
emplean ASP (Active Server Pages) u otras tecnologas similares, que permiten contenidos
web ricos y personalizados.
Sin embargo, estos contenidos dinmicos originan serios problemas en la entrega de
contenidos: el esfuerzo que supone la entrega de miles de pginas web personalizadas,
construidas en el momento, puede afectar seriamente al servidor central, que no slo debe
generar los contenidos, sino tambin despacharlos. La entrega de pginas web personalizadas
desde el borde tambin supone un reto, dado que la base de datos se encuentra en el servidor
central. Ya hemos visto cmo EdgeSuite de Akamai resuelve este problema almacenando en
la cach elementos de distintas pginas, llamados fragmentos de contenido, para luego
montarlos automticamente en funcin de la informacin de la base de datos con el fin de
formar una pgina web personalizada para el usuario final.

16

Leccin 1 6 de febrero de 2002

Primavera 2002

Figura 1.10. Comparacin 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 pginas 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 podra ser uno
de esos fragmentos, almacenado con un TTL de 15 minutos). Estos fragmentos estn
alojados en los servidores del borde de las redes de Akamai y son incorporados en el
montaje de pginas web que tiene lugar en estos servidores cuando los usuarios los solicitan.
La capacidad para construir pginas web dinmicas a partir de fragmentos individuales en el
borde de la red implica que slo es necesario obtener del servidor central los elementos que
no se pueden almacenar en la cach o los que han caducado. Adems, el montaje de la pgina
puede ser condicional, dependiendo de las cookies del usuario final o de las cabeceras de las
peticiones HTTP. Bsicamente, ESI evita tener que obtener pginas completas del servidor
central, reduciendo enormemente la carga que ste ha de soportar.

1.4.8. Conexiones entre el borde y el ncleo

Anteriormente explicamos que los servidores de Akamai montan las pginas para el usuario
final. Este proceso puede requerir informacin del servidor central del sitio que se alberga:
informacin 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 congestin de la red, los problemas de peering, etc.
Cmo 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

Leccin 1 6 de febrero de 2002

Primavera 2002

servidores distribuidos geogrficamente que posee Akamai, conectndolos entre s para

proporcionar mltiples rutas alternativas.
En lugar de enviar los datos a travs de Internet, directamente desde el servidor de
Akamai en el borde hasta el servidor central del sitio, el sistema evala un conjunto de
posibles rutas a travs de varios servidores de Akamai y elige la ms rpida. Por ejemplo, un
modo de llegar al sitio X desde el servidor A podra ser a travs 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
congestin y el trfico, 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 travs de Internet y
estn sujetos a los caprichos del BGP, los complejos algoritmos de enrutamiento de Akamai
garantizan la eleccin del mejor trayecto posible, lo que se traduce en una conexin ms
rpida y fiable entre servidor del borde y el servidor central de sus sitios.
Este mtodo de superposicin elimina los problemas de peering originados por la
negativa de una red determinada a dejar pasar el trfico a travs 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 trfico.
Por ltimo, si por algn motivo resulta imposible acceder al servidor central del sitio,
el servicio ACS de Akamai obtiene del propio sistema de Akamai una pgina por defecto. De
este modo, los usuarios recibirn el contenido de la direccin web incluso si el servidor
central del sitio est cado.

1.4.9. Una observacin sobre el streaming en vivo

El streaming de contenidos en vivo como los de vdeo 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 prcticamente 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
prdida 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 envan, entonces, por varias rutas diferentes hacia
clusters localizados de mquinas que distribuyen el flujo a su rea local. Slo es necesaria
una copia de cada subtrama para reconstruir la trama; de este modo, puesto que se envan
mltiples 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 distribucin del flujo, combinado con el mecanismo descrito
anteriormente, hace que la entrega de tramas de Akamai sea mucho ms fiable y de mayor
calidad.

18

Leccin 1 6 de febrero de 2002

Primavera 2002

1.5. Retos tecnolgicos

Los diseadores del sistema de Akamai tuvieron que enfrentarse a diversos retos
tecnolgicos a la hora de llevar a cabo su construccin. Algunos lograron superarlos,
mientras que otros continan siendo investigados. A continuacin, trataremos algunos de
estos retos.

1.5.1. Implantacin y gestin

Para que funcione la entrega en el borde, los servidores de borde han de ser implantados en
miles de redes. Ms an, estos servidores tienen que estar distribuidos geogrficamente 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 mltiples
redes, lo que requiere unos algoritmos complejos y un mapeo detallado de la topologa de la
Red y origina complejos problemas de seguimiento.

1.5.2. Mapeo
Cuando un usuario solicita una pgina 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 decisin.

Uno de los problemas es simplemente el de la escala: hay cientos de millones de

usuarios, decenas de miles de servidores, miles de ubicaciones geogrficas 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 congestin y los fallos de Internet estn muy extendidos
y son impredecibles.

El sistema tiene que equilibrar una carga de trfico 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 nmero de fallos importantes
(como la cada 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

an con informacin 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, elaboracin de informes y facturacin

Otro reto complejo est relacionado con los negocios: el logging, la elaboracin de informes
y la facturacin de los ms 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 ms de 15.000 servidores de 60 pases 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 monitorizacin del rendimiento y a las consultas SQL, todos ellos en tiempo real.
19

Leccin 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 deteccin de errores originales eran relativamente
sencillos, pero con el continuo aumento en el nmero de servidores es necesario disear
sistemas de deteccin cada vez ms 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 lnea, ni siquiera por cuestiones de
mantenimiento y, por ello, ha de ser capaz de aceptar actualizaciones de software en
marcha. Ms an, 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 cada de varios servidores de Akamai.

1.5.5. Actualizacin y precisin de los contenidos

Akamai se compromete a proporcionar siempre contenidos actualizados. Los contenidos
desfasados no deben ser distribuidos. El sistema debe proporcionar algn modo de deshacer
rpidamente 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
travs del sistema.

1.5.6. Gestin de streaming y webcasting en vivo

A medida que el webcasting y el streaming en vivo adquieren importancia, el sistema debera
ofrecer una serie de opciones especializadas para gestionarlos; debera ser capaz de utilizar y
difundir informacin para controlar, de forma inteligente, la prdida de paquetes; y optimizar
la velocidad de conexin, eligiendo continuamente la mejor ruta de entre una serie de
posibilidades. La comunicacin debera ser bidireccional dado que, a menudo, los usuarios
estn interesados en sesiones interactivas de preguntas y respuestas o mensajes. Tambin son
necesarias la agregacin de datos y las consultas, as como la entrega perfectamente
sincronizada de audio, vdeo y diapositivas.

1.6. Internet es un triunfo de la teora

Hemos visto una presentacin de Akamai Forum transmitida por una red virtual privada
(VPN) hasta un porttil situado en el aula. Tras esta tecnologa hay una serie de algoritmos
importantes. Resulta instructivo enumerar algunos de ellos: al hacerlo, nos damos cuenta del
impacto que la investigacin terica ha tenido sobre Internet.
1. Algoritmos de red:
Ethernet: CSMA (Carrier-Sense mltiple access).
TCP: backoff exponencial.
IP: jerarqua de direcciones.

20

Leccin 1 6 de febrero de 2002

Primavera 2002

rbol de expansin mnima: empleado por los switches para evitar los ciclos en
las LAN.
BGP: utilizado para el enrutamiento en Internet.
2. Protocolo de tnel punto a punto para las VPN (PPTP)
Hash de contraseas y encriptacin: proporciona privacidad.
Autenticacin: confirma la identidad.
3. Codificacin y decodificacin
Cdec: codifica las tramas de audio y vdeo.
Compresin: reduce el consumo de ancho de banda.
Cdigos de correccin de errores: aumenta la fiabilidad.
Renderizacin: muestra el contenido en la pantalla.
4. Akamai
Seleccin del mejor servidor: requiere una optimizacin compleja.
Elaboracin de informes y facturacin: requiere acceso en tiempo real a los
datos distribuidos.
Etc.

1.7. Problema del da: optimizacin de costes

Un tema de investigacin importante para Akamai en trminos de rentabilidad es la
optimizacin 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
utilizacin.
Examinemos el siguiente problema: hay alrededor de un milln de fuentes de carga y
miles de contenedores. Cada fuente dispone de un conjunto de contenedores adecuados.
Existe tambin 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 solucin ms sencilla es un algoritmo greedy. Elegir el contenedor adecuado ms
barato para cada fuente. Esto garantiza que se almacenarn todas las cargas con el mnimo
coste total. En el ejemplo anterior, los contenedores ms baratos de ambas fuentes coloreadas
costaron 1$. Por tanto, el coste total es de 20 * 1$ + 10 * 1$ = 30$.
Pero examinemos, a continuacin, una variante ms compleja del problema.
Supongamos que hay economas 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 ms realista. El algoritmo greedy del que hemos hablamos anteriormente ya no
funciona en este caso, como se muestra en el siguiente ejemplo:

21

Leccin 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 dlares para la primera unidad y es gratuito para todas las unidades
posteriores. Los otros contenedores cuestan 1 dlar para cada las unidades. Podemos
observar que, al igual que entes, el algoritmo greedy selecciona los contenedores que
presentan un coste de 1 dlar para ambas fuentes. Esto supone un coste total de 2 dlares. Sin
embargo, se puede lograr un coste de tan slo 1, 01 dlares asignando las dos fuentes al
contenedor central.

22

Leccin 1 6 de febrero de 2002

Primavera 2002

Existe algn algoritmo adecuado que pueda resuelva esta minimizacin del coste?
Por desgracia, la respuesta es no. Se trata de un problema NP-difcil y se puede reducir a un
problema de cobertura de vrtices.
A continuacin, se muestra un esquema conceptual de la reduccin.

1.7.1. Problema de cobertura de vrtices

Partimos del grfico de la figura 1.13. que se muestra a continuacin. Los vrtices B y D de
la figura tienen como propiedad que en conjunto tocan todos los bordes del grfico. Desde
estos vrtices se puede llegar directamente a cualquier otro nodo del grfico. Se dice que este
grfico presenta una cobertura de 2 vrtices. El problema de cobertura de vrtices de tamao
k consiste en determinar si un grfico determinado presenta un conjunto de cmo mucho k
vrtices, de modo que todos los bordes del grfico tocan un vrtice del conjunto. Este
problema se conoce como NP-completo.

Figura 1.13. Grfico del ejemplo.

1.7.2. Esquema de reduccin

El problema de minimizacin del coste se puede reducir al problema de cobertura de vrtices
del siguiente modo: supongamos que tenemos un algoritmo A que, al darle un ejemplo del
problema de optimizacin de costes, devuelve la solucin adecuada en tiempo polinmico.
Demostraremos que, de ser esto cierto, se podra resolver tambin en tiempo polinmico el
problema de cobertura de vrtices, que es NP-difcil.
Reducimos el problema de cobertura de vrtices de un grfico G a un problema de
optimizacin 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 vrtice de G.
3. Para cada contenedor x, aadir un borde a la fuente y s y slo s el vrtice
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.

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

Leccin 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 grfico H. H constituye un claro ejemplo del problema de
optimizacin de costes tal como lo hemos descrito.
En la figura 1.14 que se muestra a continuacin se puede ver un diagrama de esta
transformacin para el grfico de ejemplo anterior.

Figura 1.14. Ejemplo de reduccin.

Recordemos que el coste de utilizacin 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 podrn dirigir a A con un coste total adicional
0, lo que mantiene una solucin ideal desde el punto de vista local.
Obsrvese que si H se puede resolver con un coste de k dlares, entonces todas las
fuentes de H han de ser asignadas a exactamente a k contenedores. Para comprobar esto,
obsrvese que cada contenedor utilizado cuesta 1 dlar, independientemente de la cantidad
de carga que tenga asignada. Por tanto, si se puede resolver H con k dlares, se deben haber
utilizado k contenedores.
Segn la definicin del problema de optimizacin de costes, todas las fuentes de
carga han de ser asignadas a un contenedor para formar una solucin. Hemos averiguado que
k contenedores son suficientes para controlar toda la carga de H. Segn esto, dichos k
contenedores han de estar conectados a cada fuente de H.
Recordemos que cada contenedor de H corresponde a un vrtice de G, mientras que
cada fuente corresponde a un borde. Sin embargo, si hay k contenedores conectados a cada

24

Leccin 1 6 de febrero de 2002

Primavera 2002

fuente de H, esto significa que hay k vrtices de G conectados a cada borde de G, lo que
implica que G presenta una cobertura de k vrtices.
De este modo, podemos definir un algoritmo B al que, al pasarle un ejemplo del
problema de cobertura de vrtices en G, construya el correspondiente problema de
optimizacin de costes siguiendo los pasos 1-5 anteriores, llame a A para obtener una
solucin y compruebe si se estn utilizando k o menos contenedores. De ser as, B sabr que
G presenta una cobertura de vrtices. Sin embargo, si A se ejecuta en tiempo polinmico, B
tambin lo har. Dado que el problema de cobertura de vrtices es NP-difcil, no existe un
algoritmo A semejante (conocido). Esto completa la reduccin3.

La reduccin inversa es relativamente obvia. Si G presenta una cobertura de vrtices de tamao k, es que hay
un conjunto de k vrtices 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 dlar por su uso,
independientemente de la cantidad de carga que soporta, hay una solucin para H con coste un de k dlares.

25