Servidor de tiempo NTP - DTS 4135

SNTP (Simple Network Time Protocol) y NTP (Network Time Protocol) describen exactamente el mismo formato de paquete de red, las diferencias se encuentran en la forma en que un sistema trata el contenido de estos paquetes para sincronizar su hora. Básicamente son dos formas diferentes de tratar la sincronización horaria.

Mientras que un servidor o -cliente NTP completo alcanza un nivel de precisión muy elevado y evita en la medida de lo posible las marcas de tiempo abruptas mediante el uso de diferentes métodos matemáticos y estadísticos y ajustes suaves de la velocidad del reloj, SNTP sólo puede recomendarse para aplicaciones sencillas, en las que los requisitos de precisión y fiabilidad no son demasiado exigentes.

Al no tener en cuenta los valores de deriva y utilizar formas simplificadas de métodos de ajuste del reloj del sistema (a menudo un simple paso de tiempo), SNTP sólo consigue una sincronización horaria de baja calidad en comparación con una implementación NTP completa. La versión 4 de SNTP se define en RFC2030, donde dice

«Se recomienda encarecidamente utilizar SNTP sólo en los extremos de la subred de sincronización. Los clientes SNTP deben operar sólo en las hojas (estrato más alto) de la subred y en configuraciones en las que ningún cliente NTP o SNTP dependa de otro cliente SNTP para la sincronización. Los servidores SNTP deberían operar sólo en la raíz (estrato 1) de la subred y sólo en configuraciones en las que no se disponga de otra fuente de sincronización que no sea un servicio fiable de hora por radio o módem. El grado completo de fiabilidad que normalmente se espera de los servidores primarios sólo es posible utilizando las fuentes redundantes, las diversas rutas de subred y los algoritmos elaborados de una implementación NTP completa.»

Por lo tanto, el término «servidor de tiempo NTP» o «cliente compatible NTP» puede -por definición- describir un sistema con un NTP totalmente implementado, así como cualquier otro producto que utilice y comprenda el protocolo NTP pero que alcance niveles mucho peores de fiabilidad, precisión y seguridad.

Si una conexión a Internet funciona correctamente, NTP puede determinar y contabilizar los retrasos en la transmisión de paquetes de forma bastante fiable. Sin embargo, si la conexión a internet está al límite de su capacidad, la sincronización horaria puede degradarse significativamente debido a la gran dispersión en los retrasos de transmisión de paquetes. Los motivos pueden ser ataques de piratas informáticos, que no deben dirigirse a su propia red, o nuevos virus que provoquen una gran avalancha de correos electrónicos, como ya ha ocurrido en el pasado. Un servidor NTP propio no puede ser fácilmente comprometido fuera de Internet.

Existen básicamente dos formas de tener en cuenta el segundo bisiesto en su propio sistema horario informático. La primera solución (DTS4160, DTS4210) consiste en que el segundo bisiesto se lee automáticamente a través del receptor GPS y el servidor de tiempo puede implementarlo en el sello de tiempo NTP que se emite. El trasfondo de este automatismo del dispositivo es que los operadores de los satélites GPS suelen tener en cuenta en consecuencia la especificación IERS, que está garantizada por el preaviso y el propio segundo intercalar. Sólo sobre la base de ambos componentes pueden los receptores GPS y los servidores de tiempo procesar el segundo bisiesto correctamente y en el momento exacto e implementarlo también en términos de tecnología del sistema.

Por otra parte, algunos operadores de infraestructuras críticas prefieren el procedimiento manual porque existe un cierto riesgo residual en lo que respecta a la recepción segura de los dos componentes mencionados y, de todos modos, el segundo intercalar suele tener que seguirse por separado para otros sistemas informáticos. Además, la definición de los segundos intercalares no es un procedimiento estándar, por lo que esto también puede hablar de un proceso consciente, y luego manual, por parte del usuario. Con esta solución alternativa de ajuste manual, puede realizar a tiempo el ajuste correspondiente con nuestros dispositivos DTS, por ejemplo a través de MOBA NMS o Telnet SSH, con lo que el servidor horario DTS procesa entonces de forma segura el segundo bisiesto y lo implementa en consecuencia.

Normalmente es < 1ms, cuando no se tiene en cuenta la red y el número de peticiones de los clientes por segundo.

El retardo de la red puede variar mucho en función de la carga de tráfico. Por eso los paquetes NTP contienen dos marcas de tiempo (paquete de salida y paquete de entrada). Así se puede calcular y compensar el tiempo de respuesta.

Conclusión:

Para el NTP estándar, el retardo de la red (tiempo de respuesta) no es relevante para la precisión de la sincronización del cliente.

Excepto, cuando el retraso sea muy elevado, entonces la alcanzabilidad del servidor NTP podría degradarse.