Las grandes empresas de distribución de contenidos tienen servidores repartidos por todo el mundo en sistemas llamados Content Delivery Network (CDN). Un buen ejemplo de esto es, por ejemplo, Akamai, que sirve de almacén de ficheros para terceras empresas.
Si suponemos que las CDN tienen un servidor exclusivo para dar servicio a un país con todos los contenidos disponibles replicados, la gran ventaja que se obtiene respecto a tenerlo todo centralizado en una única ubicación es que en teoría se minimiza el tiempo de acceso a los contenidos (la latencia) ya que, por ejemplo un usuario en Sevilla, en lugar de comunicarse con la central de Estados Unidos, lo hará con el servidor que tienen en España.
Para conseguir esto, las CDN utilizan un sistema de DNS que, en base a la dirección IP del ordenador que realiza la petición, puede averiguar su procedencia y responder con la IP del servidor de contenidos más cercano a ese país o zona.
Sin embargo, esto deja de ser ideal cuando no son pocos, y cada vez son más, los usuarios de la red que no utilizan las DNS que les proporciona su operador y configuran en su ordenador unas públicas, como las de Google u OpenDNS, por nombrar los dos ejemplos implicados en el artículo.
Mejorando el rendimiento de DNS al acceder a CDNs
El problema de los sistemas DNS para CDN tradicionales que mencionábamos es el siguiente: como la negociación DNS para obtener la IP del destino deseado la realiza el servidor intermedio, las CDN detectan como origen de la petición los servidores DNS de Google, que están en Estados Unidos. Ante esto, la CDN responde con la IP de sus servidores para Estados Unidos y no para España. Perdemos rendimiento porque se incrementa la latencia.
Para solventarlo, se ha ideado una modificación del protocolo DNS que aprovecha las extensiones propuestas en la RFC 2671 para dotar de mayor inteligencia a la resolución de nombres.
La idea, que recibe el nombre de The Global Internet Speedup y todavía se encuentra en fase de borrador, se ayuda en la dirección original del cliente, que añade como un campo de datos más a la petición ("edns-client-subnet").
Aunque realmente, para mantener la privacidad del usuario lo que se envía es parte de la dirección IP pública del usuario (se eliminan bits del final), con lo que en lugar de mandar 1.2.3.4 (si esta fuese la IP pública del usuario), se trunca por 1.2.3.0 (todos los servidores DNS intermedios podrán leer esta información), acompañada por una máscara de red de 24 bits.
Con ello, no importa que se utilicen las DNS de Google, ya que al ir la información del usuario adjunta como datos en la petición, si el servidor destino es compatible con esta nueva iniciativa podrá determinar correctamente desde dónde se quiere acceder realmente a sus contenidos y contestar con el servidor más cercano al cliente, minimizando la latencia y, por tanto, mejorando la velocidad de navegación.
Para aquellos que sean más recelosos de su privacidad, se puede configurar para que no se envíe ninguna parte de la dirección IP del usuario (se envía 0.0.0.0/0). En estos casos entendemos que el servicio funcionaría como las DNS tradicionales en CDN. Es decir, al no tener pista alguna sobre su procedencia real, la CDN respondería con la IP más cercana al servidor DNS que hace la petición.
Por el momento, tanto Google como OpenDNS ya han instalado en sus sistemas esta nueva función, que han desarrollado junto a CDNetworks, EdgeCast, BitGravity y la propia Akamai, que ha echado una mano en la redacción del borrador.
Aunque todavía parece no estar claro cuánto impacto tendrá esto en el rendimiento real de la red, no es para nada descabellado que el IETF acabe adoptando esta técnica como un estándar que podrían adoptar también operadores, ya sea en su versión actual de borrador, o en la final.
Fuente: Banda Ancha
Deje su comentario