Latencia con los DNS de Google e impacto en la navegación web

El pasado 3 de diciembre Google anunciaba el lanzamiento de un nuevo proyecto llamado Google Public DNS, que, como su propio nombre indica, es un nuevo servidor DNS público que sigue la estela marcada por OpenDNS. De esta manera, disponemos de una alternativa más a la hora de configurar nuestros DNS que además es muy fácil de recordar: 8.8.8.8 y 8.8.4.4. La noticia ha sido acogida con entusiasmo por la blogosfera: Google se ha impuesto como meta acelerar la navegación web, y apuesta por los estándares, la neutralidad de la red, la seguridad y la privacidad, compromiso que viene avalado por una trayectoria (hasta el momento) impecable.

Hasta aquí son todo ventajas. Tan sólo hay una gran pega que se le podría poner: su situación geográfica. Y es que, al parecer, recalco, al parecer, los DNS de Google se encuentran en su sede de Mountain View (California). Cruzar el charco y todo el continente americano para hacer una petición de resolución de nombre no parece muy buena idea, desde luego. Pero recuerden: al parecer.

Me he propuesto hacer una pequeña comparativa del retardo introducido por el DNS del ISP (en este caso Telefónica, luego utilizo el típico 80.58.61.250), el de OpenDNS (208.67.222.222) y el nuevo de Google (8.8.8.8). También he introducido en la comparativa la dirección del router ADSL (192.168.1.1), ya que mucha gente tiene configurada la conexión con esa dirección en el DNS. En esos casos, el router tiene configurado el DNS del ISP al fin y al cabo y, por lo tanto, el retardo debería ser equivalente. Sucede así en los datos recogidos, pero he comprobado que depende mucho del router: si es muy lento, puede introducir un retardo adicional muy grande.

Para la recogida de datos, he elaborado un pequeño script en Bash. Los gurús de la programación en Bash verán que no es muy académico que digamos, pero funciona, que es lo importante (si alguien me propone mejoras, estaré encantado de aprender).

[code lang=»bash»]#!/bin/bash

muestras=100
servers=(80.58.61.250 192.168.1.1 8.8.8.8 208.67.222.222)
for n in {0..3}
do
server=${servers[@]:n:1}
for ((i=1; i<=muestras; i++))
do
a=$(dig @${server} enchufa2.es | grep "Query time")
echo ${a:15:${#a}-20} >> $server
done
done[/code]

Lo que hace este script es realizar 100 peticiones por cada DNS que vamos a analizar y guardar los tiempos de respuesta en sendos archivos. Y con dichos archivos y Gnuplot he obtenido la siguiente gráfica:

Como podemos ver, el retardo introducido por los DNS del ISP es de unos 60 ms. De este tiempo, la mayor parte es debido al modo interleaved de la conexión ADSL, pero eso ya es otra historia (es un método para lograr mayor protección contra errores en el que los bits de las tramas se van entrelazando de manera que se recibe el primer bit de varias tramas, luego el segundo bit de todas ellas, etc.; resumiendo, no recibes el bit N de una trama hasta que no has recibido los N-1 bits de su «grupo» de tramas, por lo que aumenta el retardo considerablemente).

También observamos que OpenDNS y Google rondan los 100 ms (OpenDNS parece que gana, de media, por poquito). Por lo tanto, el retardo adicional que introducen tanto OpenDNS como Google Public DNS es de 40 ms.

No he hecho un estudio exhaustivo sobre el número de peticiones DNS que se realizan al cargar páginas web, pero por el puñado de pruebas que he hecho, diría que se realizan normalmente menos de 10 (no cuento aquí la resolución de todos los enlaces incluidos en el documento HTML, puesto que esto se hace después de la carga de la página y no repercute en la experiencia del usuario). ¿Esto qué supone? Pues un retardo adicional de menos de medio segundo en páginas que tardan en cargar 3, 4, 5, 6 segundos… Por lo tanto, la latencia no se verá muy afectada.

Por otra parte, ¿no os chirrían un poco esos 100 ms junto con la localización en la costa oeste de los EEUU? Si hacemos un ping a haha.nu (servidor situado por el centro de EEUU), descubrimos un tiempo de respuesta de 170 ms, y si lo hacemos con enchufa2.es (situado hacia la costa este de EEUU), tenemos 180 ms. Más raro todavía: si hacemos un traceroute a 8.8.8.8 descubrimos que uno de los saltos está en París con un tiempo de respuesta de 95-100 ms y que ¡el siguiente salto está en California con un tiempo de 95-100 ms! Probad también con OpenDNS; sucede algo parecido.

Conclusión: o bien han inventado los enlaces transoceánicos y transcontinentales instantáneos y yo no me he enterado, o tanto OpenDNS como Google Public DNS tienen servidores en Europa.