El RFC 5905, el documento que define la versión 4 del protocolo NTP, se publicó en junio de 2010 y desde entonces fue actualizado por los RFC 7822, 8573, 9109, 9748 y 9769, aunque sigue corriendo en miles de millones de routers, servidores y teléfonos. Cada vez que un laptop se conecta a una red nueva y ajusta su reloj en milisegundos sin preguntar nada, es NTP trabajando en silencio detrás de esa sincronización.
Este artículo explica cómo funciona esa sincronización desde la jerarquía de estratos hasta el cálculo exacto del desfase entre dos relojes, con los comandos para verificarla en Linux.
TL;DR
- UDP 123 es el puerto que usa NTP para intercambiar las cuatro marcas de tiempo que calculan el desfase del reloj- chronyc tracking muestra el estrato, el offset y la deriva de frecuencia del reloj local en una sola salida- Los estratos numeran la distancia a la referencia: estrato 0 son relojes atómicos o GPS, estrato 1 los primeros servidores- RFC 8915 define NTS, la extensión que autentica la hora recibida sin exponer la clave de cifrado- systemd-timesyncd y chrony no deben correr juntos: compiten por el control del reloj del sistema
¿Qué es el protocolo NTP?
NTP es un protocolo de red que sincroniza el reloj de un dispositivo con una referencia de tiempo externa, mediante una jerarquía de servidores llamada estratos. Diseñado por David L. Mills en 1985 y descrito en el RFC 5905, el protocolo NTP corrige la desviación acumulada del reloj local frente a una fuente más precisa.
La jerarquía se organiza en estratos: el estrato 0 agrupa relojes de referencia como GPS o cesio; el estrato 1, los servidores conectados directamente a esos relojes; y así sucesivamente hasta clientes en estratos altos, que solo ajustan su propia hora sin ofrecer servicio a nadie más. El estrato 15 es el límite declarado por el estándar; el 16 marca un reloj sin sincronizar.
Por qué importa la sincronización horaria
Sin un reloj compartido, un sistema distribuido no puede ordenar eventos, firmar certificados ni replicar datos de forma consistente. El protocolo NTP resuelve ese problema de fondo: le da a cada máquina una noción de tiempo lo bastante parecida a la de sus vecinas para que los sistemas que dependen de marcas de tiempo (TLS, Kerberos, bases de datos distribuidas, blockchains con sellos de tiempo) funcionen sin fricciones.
Un certificado TLS que llega con una hora adelantada varios minutos puede aparecer como todavía no válido o ya expirado, y Kerberos rechaza directamente tickets con más de cinco minutos de diferencia respecto al servidor. La hora no es un dato cosmético, es una precondición para que la criptografía y la coordinación distribuida funcionen.
El RFC 5905, que estandariza NTPv4, se publicó en junio de 2010 y sigue vigente sin revisión mayor.
Cómo funciona NTP por dentro
NTP calcula el desfase comparando cuatro marcas de tiempo en cada intercambio con un servidor. El cliente anota T1 al enviar la solicitud; el servidor anota T2 al recibirla y T3 al responder; el cliente anota T4 al recibir la respuesta.
sequenceDiagram participant Cliente participant Servidor Cliente->>Servidor: solicitud con marca T1 Servidor-->>Cliente: responde con T2 y T3 Note over Cliente,Servidor: Cliente registra T4 al recibir Cliente->>Cliente: calcula offset con T1, T2, T3, T4 Con esas cuatro marcas, NTP obtiene el desfase (offset) y el retardo de ida y vuelta (delay) con dos fórmulas: offset = ((T2-T1)+(T3-T4))/2 y delay = (T4-T1)-(T3-T2). El offset le dice al cliente cuánto ajustar su reloj; el delay le dice cuánta confianza darle a esa muestra, porque una red congestionada infla el delay y degrada la precisión.
El cliente no corrige su reloj de golpe: aplica el ajuste gradualmente con un algoritmo de disciplina (una mezcla de PLL y FLL) para evitar saltos brutos que romperían cualquier proceso sensible al tiempo.
flowchart TD A["Reloj atomico / GPS (Estrato 0)"] --> B["Servidor NTP primario (Estrato 1)"] B --> C["Servidor NTP secundario (Estrato 2)"] C --> D["Cliente NTP (Estrato 3)"] C --> E["Cliente NTP (Estrato 3)"] Cuando un cliente consulta varias fuentes a la vez, necesita decidir en cuáles confiar. NTP usa una variante del algoritmo de Marzullo para descartar servidores cuyo intervalo de error no se superpone con el de la mayoría, lo que se conoce como detectar un «falseticker». Por eso la documentación recomienda consultar al menos tres o cuatro fuentes: con una sola no hay nada contra qué comparar.
Ejemplos prácticos y cómo empezar
En Ubuntu y Debian, chrony es el cliente recomendado por encima de systemd-timesyncd cuando se necesita precisión real, porque ajusta el reloj con disciplina de frecuencia en vez de solo saltos ocasionales.
sudo apt update sudo apt install chrony sudo systemctl enable --now chrony Esto instala el paquete y arranca el servicio chrony (en RHEL y Fedora el servicio se llama chronyd). No hace falta reiniciar la máquina.
chronyc tracking La salida confirma si el reloj ya convergió y con qué estrato de referencia:
Reference ID : C0A80101 (2.debian.pool.ntp.org) Stratum : 2 Ref time (UTC) : Mon Nov 02 14:21:08 2026 System time : 0.000012391 seconds slow of NTP time Last offset : -0.000007823 seconds RMS offset : 0.000045112 seconds Frequency : 4.123 ppm slow Skew : 0.089 ppm Root delay : 0.023456789 seconds Root dispersion : 0.004321098 seconds Leap status : Normal chronyc sources -v lista cada servidor que chrony está evaluando, con su estrato y el símbolo que indica si lo está usando como referencia (*) o como respaldo (+):
MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 0.debian.pool.ntp.org 2 6 377 42 -74us[ -112us] +/- 23ms ^+ 1.debian.pool.ntp.org 2 6 377 45 +210us[ +198us] +/- 31ms ^- 2.debian.pool.ntp.org 3 6 377 40 -1.2ms[ -1.3ms] +/- 45ms Para agregar un pool propio, se edita /etc/chrony/chrony.conf y se agrega una línea como pool 2.debian.pool.ntp.org iburst, y después se reinicia el servicio con sudo systemctl restart chrony. Volver a correr chronyc sources -v debería mostrar el nuevo servidor en la lista en un par de minutos.
⚠️ Ojo: nunca dejes
chronyysystemd-timesyncdactivos al mismo tiempo: los dos intentan ajustar el mismo reloj del kernel y el resultado es una corrección inestable que oscila entre lo que cada uno cree correcto.
Si la red se cae, chrony no se queda ciego: guarda en su driftfile la última corrección de frecuencia conocida y la sigue aplicando (un modo llamado holdover) hasta que algún servidor vuelva a responder.
Casos de uso reales
En mercados financieros de alta frecuencia, los reguladores exigen sellos de tiempo con una divergencia de apenas microsegundos respecto al UTC, un nivel que NTP clásico no garantiza de forma consistente. Eso empuja a esas firmas hacia PTP (IEEE 1588), un protocolo hermano pensado para redes locales con hardware de timestamping dedicado.
En un centro de datos común, NTP (vía chrony) alcanza para que los logs de cientos de máquinas se puedan ordenar y correlacionar durante la investigación de un incidente: sin relojes alineados, reconstruir la secuencia exacta de eventos entre servidores distintos se vuelve prácticamente imposible.
Bases de datos distribuidas como Spanner, de Google, van un paso más allá: en vez de depender del NTP público, mantienen su propio servicio de tiempo respaldado por GPS y relojes atómicos para ofrecer garantías de consistencia que un cliente NTP convencional no podría sostener.
A escala pública, el NTP Pool Project reparte las consultas de millones de dispositivos entre servidores donados por voluntarios de todo el mundo, agrupados en subdominios regionales como 2.debian.pool.ntp.org.
chrony es el cliente NTP por defecto en Debian, Ubuntu, Fedora y RHEL desde hace varias versiones.
Errores comunes y buenas prácticas
- Un solo servidor NTP: sin al menos tres o cuatro fuentes, el cliente no puede descartar un servidor con hora incorrecta (un falseticker).- Puerto UDP 123 bloqueado: un firewall corporativo que lo cierra deja el reloj derivando sin ningún error visible hasta que algo con TLS o Kerberos falla.- Dos demonios de tiempo a la vez: tener chrony y systemd-timesyncd activos simultáneamente hace que compitan por ajustar el mismo reloj.- Confiar en el reloj de una VM sin NTP propio: una migración en vivo o una pausa del hipervisor puede saltar el reloj del huésped varios segundos de golpe.- Ignorar los segundos bisiestos: un salto de un segundo sin manejar puede romper software que asume que el tiempo nunca retrocede.
Comparativa: NTP frente a otras formas de sincronizar el reloj
Antes de elegir una herramienta conviene comparar qué tan preciso necesita ser el reloj. El protocolo NTP cubre la gran mayoría de los casos, pero no es la única opción.
OpciónPrecisión típicaCuándo usarlaLimitaciónNTP con chronyMilisegundos en internet, submilisegundo en LANServidores, laptops y contenedores sin requisitos extremosNo autentica el origen del tiempo salvo que se configure NTSsystemd-timesyncd (SNTP)Más baja, sin disciplina fina de frecuenciaEscritorios sin necesidad de precisiónNo puede actuar como servidor para otros clientesPTP (IEEE 1588)Microsegundos o mejorTrading de alta frecuencia, telecom, laboratoriosNecesita switches y tarjetas de red con soporte de hardwareGPS o reloj atómico (estrato 0)Referencia primariaAlimentar servidores de estrato 1 propiosCosto de antena, receptor y vista despejada al cielo
Profundizando: seguridad y precisión avanzada
La versión clásica de NTP no autentica sus respuestas: cualquiera que pueda interceptar el tráfico UDP puede falsificar la hora que recibe un cliente. RFC 8915 define NTS (Network Time Security), que usa TLS para negociar claves y después protege cada paquete de tiempo con un código de autenticación, sin cargar con el peso de cifrar cada mensaje completo.
💭 Clave: servicios públicos como Google Public NTP no aplican el segundo bisiesto de golpe: lo reparten (leap smear) en varias horas para que los clientes no vean el reloj retroceder de un salto.
Para elegir entre fuentes, chrony y ntpd combinan el algoritmo de intersección de Marzullo con un algoritmo de agrupamiento que pondera cada muestra por su dispersión acumulada, de modo que un servidor con poca latencia pero mala precisión histórica puede pesar menos que uno más lento pero estable.
📖 Resumen en Telegram: Ver resumen.
Tu próximo paso: corré chronyc tracking en tu propia máquina Linux y compará el campo Stratum con el de otro equipo de tu red para confirmar que ambos convergen a la misma jerarquía.
Preguntas frecuentes
¿Qué puerto de red usa NTP?
NTP intercambia sus mensajes por el puerto UDP 123, tanto para los clientes que piden la hora como para los servidores que la responden. Usa UDP porque prioriza la velocidad y la consistencia de la latencia sobre la garantía de entrega.
¿Qué diferencia hay entre un estrato 1 y un estrato 2?
Un servidor de estrato 1 está conectado directamente a un reloj de referencia como GPS o un reloj atómico, sin pasar por la red para obtener la hora. Un servidor de estrato 2 obtiene la hora de uno o varios servidores de estrato 1 a través de la red, así que acumula algo del retardo y el error de esa conexión.
¿chrony o systemd-timesyncd: cuál debería usar?
systemd-timesyncd alcanza para un escritorio que solo necesita una hora aproximada. chrony conviene en servidores, laptops que suspenden seguido y cualquier caso donde la precisión y la rapidez para volver a sincronizar después de un corte importen de verdad.
¿Es seguro el protocolo NTP?
Por defecto no: un atacante en la misma red puede falsificar las respuestas porque NTP clásico no autentica el origen de los paquetes. NTS, definido en RFC 8915, añade esa autenticación usando TLS para negociar las claves antes de empezar a sincronizar.
¿Puedo montar un servidor NTP sin conexión a internet?
Sí. Un receptor GPS conectado por USB o un reloj atómico de bajo costo puede actuar como estrato 0 local, y chrony lo expone como referencia para el resto de la red interna sin depender de ningún servidor externo.
¿Cómo sé si mi Linux está usando chrony o systemd-timesyncd?
systemctl status chrony y systemctl status systemd-timesyncd muestran cuál de los dos está activo. Solo uno debería estarlo: tenerlos corriendo juntos hace que compitan por ajustar el mismo reloj.
Referencias
- RFC 5905: especificación oficial de NTPv4, el protocolo descrito en este artículo.- RFC 8915: define NTS (Network Time Security), la extensión que autentica los mensajes de NTP.- chrony: sitio oficial del cliente y servidor NTP usado en los ejemplos de este artículo.- NTP Pool Project: red voluntaria de servidores NTP públicos como los del dominio pool.ntp.org.- Google Public NTP: documentación del servicio de tiempo público de Google y su manejo del segundo bisiesto.- Wikipedia: Network Time Protocol: resumen histórico y técnico del protocolo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
