Más datos sobre el funcionamiento de Google Public DNS

En la anotación anterior, llegamos a la conclusión de que no es cierto que Google tenga sus servidores DNS en Mountain View, sino que ya los ha distribuido por todo el mundo —sería estúpido por su parte no hacerlo así—, así que la disponibilidad geográfica está más que garantizada. Otra opción para comprobar que, efectivamente, existen multitud de DNS utilizando direccionamiento anycast, es seguir esta URL donde se hace un ping desde varios puntos del mundo y se nos muestra el RTT.

En los comentarios, un lector nos apuntaba que otro análisis interesante sería realizar peticiones de dominios que no estuvieran cacheados —por lo que tendrían que realizar una petición a un DNS superior en la jerarquía—, para ver con qué velocidad se desenvuelven en ese escenario. Así pues, he modificado el script y ha quedado de esta manera:

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

dic="dictionary.txt"
dominios="dominios_comunes.txt"
servers=(80.58.61.250 192.168.1.1 8.8.8.8 208.67.222.222)
muestras=50
for n in {0..3}
do
server=${servers[@]:n:1}
while read dominio
do
a=$(dig @${server} ${dominio} | grep "Query time")
echo ${a:15:${#a}-20} >> "${server}_conocidos"
done < $dominios

for ((i=1; i<=muestras; i++))
do
rand=$(shuf -n 1 $dic)
rand=${rand:0:${#rand}-1}
dominio="$rand.com"
a=$(dig @${server} ${dominio} | grep "Query time")
echo ${a:15:${#a}-20} >> "${server}_raros"
done
done[/code]

El primer bucle interior lo que hace es leer del archivo «dominios_comunes.txt» unos dominios que a mí me han parecido bastante comunes, y por lo tanto con una alta probabilidad de estar cacheados en todos los servidores DNS a estudiar. La gráfica resultante es muy parecida, por consiguiente, a la obtenida el otro día. Tan sólo hay un cambio: esta vez disponía de un router viejo y podemos apreciar que los tiempos que nos ofrece el DNS del router por defecto (192.168.1.1) son muy malos —más de 50 ms por encima de Google y OpenDNS y 100 ms peor que el DNS del ISP—.

latencia-dom-conocidos

El segundo bucle interior hace uso del archivo «dictionary.txt». Se me ha ocurrido que la mejor manera de dar con dominios raros que no estuviesen cacheados —dado que pones cualquier palabra en inglés en el navegador, añades «.com», y existe—, era utilizar un diccionario de inglés, extraer una palabra aleatoriamente, y añadir el punto com. Eso es precisamente lo que hace ese pedazo de código. Aquí va la gráfica:

latencia-dom-raros

Y aquí ya sí que se aprecian diferencias significativas. Veamos los tiempos medios para aclararnos un poco:

  • DNS del ISP (80.58.61.250): 624 ms de media.
  • DNS del ISP router mediante (192.168.1.1): 802 ms de media.
  • OpenDNS (208.67.222.222): 370 ms de media.
  • Google Public DNS (8.8.8.8): 415 ms de media.

Vemos que el DNS del ISP consigue tiempos mediocres con dominios no cacheados. Google Public DNS todavía tiene camino por recorrer y mucho que aprender de su competidor OpenDNS, pero obtiene un meritorio segundo puesto teniendo en cuenta que es un servicio recién aparecido.

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:

latencia-dns

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.

‘Cosmopoliet’ tango Op.4 de Arie Maasland

La obra que os traigo hoy es un tango; es bonito y está bien hecho, pero no tiene mayor trascendencia. Fue compuesto en 1937 por Arie Maasland, un acordeonista y compositor holandés. Al parecer, cuando presentó el tango al editor, decidieron cambiar el nombre de ambos (compositor y obra) por algo más comercial. Así, Arie Maasland pasó a llamarse Arie Malando, que suena más latino, y Cosmopoliet pasaría finalmente a la historia como Olé guapa.

Pero lo realmente interesante del siguiente vídeo es el maravilloso arreglo para quinteto de viento clásico (flauta, oboe, clarinete, trompa y fagot) —que por cierto, estoy intentando pasar a partitura; si alguien me echa un cable…—, así como la gran interpretación a cargo de los solistas de la Orquesta Filarmónica de Berlín: Andreas Blau (flauta), Albrecht Mayer (oboe), Wenzel Fuchs (clarinete), Stefan Schweigert (fagot) y Radek Baborak (tuba wagneriana).

Ver vídeo

Aprovecho para recomendar el canal de Youtube de la Orquesta Filarmónica de Berlín, de donde he sacado el vídeo.

La importancia de poner tildes

En la aclamada última edición de los premios «Terrorista Ortográfico», no han faltado detractores de las tildes que insisten en que no son necesarias para la correcta comprensión de nuestra rica lengua. En uno de los comentarios, Pedro nos dejaba una buena aportación que muestra por qué son tan importantes las tildes. Cito:

Yo calculo que el calculo que calculo el arbitro que arbitro, desanimo al prospero medico que prospero siendo critico con quien critico a quien le medico por un palpito tras un resbalon por un liquido. Y el domine, sin su habito, rotulo en publico el modulo en el que habito.

Tras esto, creo que queda bastante claro que no usar tildes puede hacer que la lectura se convierta en un auténtico infierno. Pero aún diría más, puede hacer que se pierda totalmente el significado. Por ejemplo:

quepiensa

¿Se os ocurren más ejemplos?