Una de las opciones que no son muy conocidas de nuestras redes y de INTERNET, son los servidores de tiempo o NTP, por eso hoy dedico unos minutos a explicarlo.
En internet es muy importante el sincronismo y que todos los servidores tengan los horarios correctos y en lo posible sincronizados. Como cuando vemos en las películas, que los actores dicen, «SINCRONICEMOS LOS RELOJES», es para que cuando realicen una tarea sea lo más coordinada posible. Bueno esto mismo necesitan los equipos de internet, cuando se realizan tareas o solo para llevar un control o una monitorización de cualquier dato de servicios o conexión, es muy importante tener la hora correcta, ya que por sí solo sin depender de NTPs los equipos de red siempre poseen una diferencia de segundos en los mejores casos.
Un caso útil.
1º Por ejemplo si tenemos mal el horario de nuestro ordenador, y queremos acceder a cualquier web que posea control de acceso y autenticación de COOKIES, como por ejemplo nuestro BANCO, o cualquier web que necesite autenticación, tendremos muchos problemas y en muchos casos, no podremos conectarnos. Para solucionar esto es bueno que nuestro ordenador siempre tenga la hora correcta. Esto lo conseguimos configurando los NTP de nuestro sistema.
2º Imaginemos que deseamos saber quien estaba navegando en nuestro servidor web, y tenemos el registro de usuarios y acceso, pero si tenemos mal sincronizado el reloj de nuestro servidor esto sería una tarea más que agobiante.
3º Teniendo otro ejemplo, más factible o común. Si tenemos mal la hora de nuestro ordenador y por basarnos en este reloj llegamos tarde a esa cita tan importante… bueno esto se puede resolver con las configuraciones de NTP (NETWORKS TIME SERVERs), o en espanglish, servidores de tiempo de red.
NOTA: En Windows tenemos esta configuración dentro del reloj, ese que vemos a la derecha de la barra de tareas de Windows, le damos doble click al reloj y luego vamos a la oreja que dice (HORA DE INTERNET), aquí es donde pondremos la dirección POOL del servidor de tiempo recomendado. En nuestro caso (0.es.pool.ntp.org)
à
¿Cómo FUNCIONAN?
Estos servidores se conectan entre sí, y a la vez a relojes atómicos de acceso público, por tal motivo todos manejan tiempos «casi» perfectos, con variaciones de menos de 1 segundo en 5 años, lo cual es más que suficiente para nuestras aplicaciones.
Hoy en día existen varios servicios públicos, los cuales ofrecen sincronismo para los relojes de nuestros ordenadores o equipos en red.
Lo primero que necesitamos averiguar es ¿qué servidores tenemos cerca? (Cerca= geográficamente, para tener el menor retardo en los sincronismos).
En mi caso, que estoy en MADRID y para todos los españoles, existen granjas de servidores llamadas POOLes, los cuales podemos usar gratuitamente.
NOTA: Los pooles de servidores son un grupo de equipos, conectados e identificados por un solo nombre de red, por ejemplo:
0.es.pool.ntp.org
¿En que nos ayuda esto?, Evitan la necesidad de configurar uno a uno las direcciones de cada uno de estos servidores de tiempo, porque por ejemplo detrás de una dirección pool puede haber 10, 100 o 1000 servidores de tiempo.
¿Y para qué queremos 10, 100 o 1000 servidores de tiempo?, para poder tener redundancia en cuanto a nuestra pregunta, ya que siempre habrá un servidor para respondernos.
Esta es la lista que utilizo en los servidores y ordenadores de mi red.
Este es el recomendado para España (detrás de este nombre de pool hay 13 servidores de tiempo):
0.es.pool.ntp.org
Estos son los recomendados para cualquier parte de Europa (detrás de estos nombres hay 1264 servidores de tiempo):
0.europe.pool.ntp.org
1.europe.pool.ntp.org
2.europe.pool.ntp.org
3.europe.pool.ntp.org
¿Y porque utilizar los de España si son tan pocos? Si pensamos en el número de usuarios que pueden hacer uso de estos servidores, tendremos nuestra respuesta, Ya que si dividimos los 13 servidores existentes para España entre los internautas Españoles, obtendremos un número mayor de la tarta, que si dividiéramos los 1264 para todos los internautas de EUROPA. Es lógico elegir los exclusivos españoles. Además a la hora de respuesta, se supone que un servidor ubicado geográficamente más cerca, tendrá menos saltos de distancia para llegar a nosotros.
Grafico de crecimiento de servidores en EUROPA, cualquiera que posea un servidor NTP con dirección publica, puede incluirse dentro de los pooles libres, con solo registrarse.
Pruebas de retardo:
Las siguientes pruebas son para determinar que servidor es preferible para nuestra red.
Desde cualquier consola o terminal realizamos un PING (envío de paquetes a una dirección de internet) a cada uno de los POOLes de servidores de tiempo. El que posea menos retardo en el tiempo de respuesta usaremos para nuestros servidores.
Como vemos el servidor español como es lógico es el más recomendable con una respuesta promedio, por debajo de 100milisegundos.
[sourcecode language=»c»]
C:\Documents and Settings\walterleonardo>ping 0.es.pool.ntp.org
Haciendo ping a 0.es.pool.ntp.org [163.117.131.239] con 32 bytes de datos:
Respuesta desde 163.117.131.239: bytes=32 tiempo=72ms TTL=52
Respuesta desde 163.117.131.239: bytes=32 tiempo=80ms TTL=52
Respuesta desde 163.117.131.239: bytes=32 tiempo=76ms TTL=52
Respuesta desde 163.117.131.239: bytes=32 tiempo=92ms TTL=52
Estadísticas de ping para 163.117.131.239:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 72ms, Máximo = 92ms, Media = 80ms
C:\Documents and Settings\walterleonardo>ping 0.europe.pool.ntp.org
Haciendo ping a 0.europe.pool.ntp.org [193.65.58.58] con 32 bytes de datos:
Respuesta desde 193.65.58.58: bytes=32 tiempo=146ms TTL=40
Respuesta desde 193.65.58.58: bytes=32 tiempo=133ms TTL=40
Respuesta desde 193.65.58.58: bytes=32 tiempo=154ms TTL=40
Respuesta desde 193.65.58.58: bytes=32 tiempo=145ms TTL=40
Estadísticas de ping para 193.65.58.58:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 133ms, Máximo = 154ms, Media = 144ms
C:\Documents and Settings\walterleonardo>ping 1.europe.pool.ntp.org
Haciendo ping a 1.europe.pool.ntp.org [213.249.66.35] con 32 bytes de datos:
Respuesta desde 213.249.66.35: bytes=32 tiempo=194ms TTL=50
Respuesta desde 213.249.66.35: bytes=32 tiempo=206ms TTL=50
Respuesta desde 213.249.66.35: bytes=32 tiempo=209ms TTL=50
Respuesta desde 213.249.66.35: bytes=32 tiempo=630ms TTL=50
Estadísticas de ping para 213.249.66.35:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 194ms, Máximo = 630ms, Media = 309ms
C:\Documents and Settings\walterleonardo>ping 2.europe.pool.ntp.org
Haciendo ping a 2.europe.pool.ntp.org [213.133.98.164] con 32 bytes de datos:
Respuesta desde 213.133.98.164: bytes=32 tiempo=111ms TTL=48
Respuesta desde 213.133.98.164: bytes=32 tiempo=128ms TTL=48
Respuesta desde 213.133.98.164: bytes=32 tiempo=103ms TTL=48
Respuesta desde 213.133.98.164: bytes=32 tiempo=115ms TTL=48
Estadísticas de ping para 213.133.98.164:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 103ms, Máximo = 128ms, Media = 114ms
C:\Documents and Settings\walterleonardo>ping 3.europe.pool.ntp.org
Haciendo ping a 3.europe.pool.ntp.org [91.121.67.180] con 32 bytes de datos:
Respuesta desde 91.121.67.180: bytes=32 tiempo=107ms TTL=50
Respuesta desde 91.121.67.180: bytes=32 tiempo=106ms TTL=50
Respuesta desde 91.121.67.180: bytes=32 tiempo=100ms TTL=50
Respuesta desde 91.121.67.180: bytes=32 tiempo=104ms TTL=50
Estadísticas de ping para 91.121.67.180:
Paquetes: enviados = 4, recibidos = 4, perdidos = 0
(0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 100ms, Máximo = 107ms, Media = 104ms
[/sourcecode]
OTRA PRUEBA QUE PODEMOS HACER:
Es saber la cantidad de saltos que posee un servidor. (Los saltos corresponden a los ruteadores que necesitamos atravesar en el camino desde nuestra red hasta los servidores de tiempo.)
Esto con el comando:
En Windows (ventana DOS): tracert «nombre servidor»
En LINUX, SUN y APPLE: traceroute «nombre servidor»
Al servidor para España (respuesta de 9 saltos)
[sourcecode language=»c»]
root@waliiap:~# traceroute 0.es.pool.ntp.org
traceroute: warning: 0.es.pool.ntp.org has multiple addresses; using 138.100.11.74
traceroute to 0.es.pool.ntp.org (138.100.11.74), 30 hops max, 38 byte packets
1 10.202.112.1 (10.202.112.1) 7.926 ms 7.871 ms 7.261 ms
2 10.127.44.49 (10.127.44.49) 52.949 ms 20.452 ms 10.121 ms
3 mad-b1-link.telia.net (213.248.90.85) 10.518 ms 9.897 ms 9.046 ms
4 dante-ic-125710-mad-b1.c.telia.net (213.248.81.26) 11.001 ms 8.720 ms 8.811 ms
5 NAC.XE0-1-0.EB-Madrid0.red.rediris.es (130.206.250.22) 9.935 ms 9.205 ms 8.695 ms
6 upm-router.red.rediris.es (130.206.215.210) 11.318 ms 9.370 ms 10.525 ms
7 * * *
8 * * *
9 www.clip.dia.fi.upm.es (138.100.11.74) 12.200 ms 11.528 ms 12.825 ms
root@waliiap:~#
Al servidor para Europa (respuesta variable entre 10 y 15 saltos) *depende el camino que tome.
root@waliiap:~# traceroute 0.europe.pool.ntp.org
traceroute: warning: 0.europe.pool.ntp.org has multiple addresses; using 85.31.187.67
traceroute to 0.europe.pool.ntp.org (85.31.187.67), 30 hops max, 38 byte packets
1 10.202.112.1 (10.202.112.1) 8.048 ms 11.748 ms 7.560 ms
2 10.127.44.53 (10.127.44.53) 8.817 ms 8.933 ms 19.406 ms
3 te4-3.mpd01.mad04.atlas.cogentco.com (149.6.80.109) 8.472 ms 9.754 ms 8.948 ms
4 te7-1.ccr01.mad05.atlas.cogentco.com (130.117.51.13) 8.393 ms te7-4.ccr01.mad05.atlas.cogentco.com (130.117.2.57) 7.256 ms te7-1.ccr01.mad05.atlas.cogentco.com (130.117.51.13) 9.316 ms
5 te7-1.ccr01.par01.atlas.cogentco.com (130.117.0.22) 33.853 ms te4-6.ccr01.par01.atlas.cogentco.com (130.117.3.46) 32.606 ms te7-1.ccr01.par01.atlas.cogentco.com (130.117.0.22) 33.292 ms
6 te3-7.ccr01.lon01.atlas.cogentco.com (130.117.2.162) 40.489 ms 40.803 ms 43.520 ms
7 linx1.teleglobe.net (195.66.224.51) 41.532 ms 47.381 ms 52.835 ms
8 Vlan1685.icore1.AD1-Amsterdam.as6453.net (195.219.150.73) 52.081 ms 48.685 ms 53.393 ms
9 Vlan81.icore1.FR1-Frankfurt.as6453.net (195.219.150.14) 57.950 ms 50.335 ms 51.432 ms
10 Vlan1656.icore1.F2C-Frankfurt.as6453.net (195.219.180.106) 53.301 ms 50.555 ms 51.761 ms
11 ix-13-15.icore1.F2C-Frankfurt.as6453.net (195.219.148.58) 74.231 ms 71.179 ms 82.833 ms
12 hawk2-vl1610-10GE.jena1a.routers.as35366.net (81.7.0.1) 59.497 ms 60.918 ms 62.041 ms
13 alpha.rueckgr.at (85.31.187.67) 58.592 ms 58.676 ms 57.545 ms
root@waliiap:~#
[/sourcecode]
NOTA: recordemos que este es un servidor de tiempo que necesitamos que sea lo más exacto posible, si la pregunta que realiza nuestro ordenador parda mucho tiempo, este tiempo es sumado a la diferencia entre nuestro reloj y en reloj atómico que ofrece el tiempo a estos servidores.
En nuestro caso nuestra hora con respecto a la hora de los servidores de tiempo, tendrá una diferencia de 80Milisegundos, la cual es inapreciable como factor de error.
La prueba que pones para determinar la distancia a un servidor con dominio «.pool.ntp.org» tal como expones en el ejemplo es inútil ya que estos servidores cambian cada hora. Podéis leer el funcionamiento de estos servidores en:
http://www.pool.ntp.org/es/use.html
Establecer el servidor más cercano sólo es válido en otros casos cuando sabes que el servidor no cambia pero es verdad que lo ideal para hacer un buen uso de este servicio y no saturar los servidores sería que cada uno se pusiera el servidor que mas cerca tiene.
Si … en eso tienes razón cambia continuamente… pero en el momento de necesitar estos servidores, deberías hacer la prueba… si luego cambian no importa… ya que la función es actualizar la hora… y estos paquetes no consumen mucho trafico… tampoco es necesario ser muy quisquilloso, con tener configurado alguno… ya está.