Resumen

  • Cuatro marcas permiten estimar desfase y demora de ida y vuelta, no conocer por separado ambos trayectos. NTP filtra muchas mediciones antes de disciplinar el reloj local.
  • La selección aparta fuentes incompatibles cuando existe intersección suficiente, pero no vence fallos correlacionados. El stratum evita bucles y expresa distancia a una referencia; no garantiza precisión ni autoridad.
  • NTS protege la identidad e integridad de un intercambio cliente-servidor. Elegir fuentes diversas, tener permiso, vigilar dependencias y decidir cómo mover el reloj sigue siendo tarea del operador.

Miles de respuestas y ninguna garantía

El RFC 1129 documentó en 1989 una encuesta dirigida a 94.260 hosts y gateways. Respondieron 20.758 mediante tres protocolos horarios. Cerca de la mitad se desviaba más de dos minutos de la referencia usada; alrededor del diez por ciento, más de cuatro horas; algunos relojes erraban por más de dos semanas.

No fue un censo completo, sino una medición de quienes contestaron. Precisamente por eso resulta útil: una máquina accesible y locuaz puede estar profundamente equivocada. La conectividad no certifica el oscilador, la fuente aguas arriba ni la atención de quien opera el servicio.

NTP convirtió esa desconfianza en procedimiento. En vez de coronar al servidor que respondiera primero, permitió que cada cliente acumulara pruebas, comparara incertidumbres y conservara el control de su propio reloj.

Encerrar el tránsito entre cuatro instantes

El servicio DCNET de 1981 ya enfrentaba relojes desiguales. El RFC 778 describía una referencia de radio WWV en COMSAT y relojes de red eléctrica con deriva y desfase. Los mensajes ICMP de timestamp registraban una solicitud y su devolución.

La forma madura usa t1 cuando el cliente envía, t2 cuando el servidor recibe, t3 cuando responde y t4 cuando el cliente recibe. El desfase se estima como [(t2 - t1) + (t3 - t4)] / 2; la demora de ida y vuelta como (t4 - t1) - (t3 - t2).

La simetría es una aproximación, no un hecho observado. Si la ruta de salida tarda más que la de regreso, parte de esa diferencia se confunde con error de reloj. NTP obtiene una estimación operativa, no una visión independiente de cada demora unidireccional.

Una red que no debía entregar cada paquete

El RFC 958 publicó NTP en septiembre de 1985. Tres años después, el RFC 1059 describió la versión 1: varias fuentes primarias, servidores secundarios ordenados en una subred jerárquica y autoorganizada, y ningún requisito de elegir un único maestro mundial.

El protocolo podía perder un datagrama y continuar. La siguiente observación reemplazaba a la ausente. Era una propiedad importante en un Internet de múltiples gateways, colas cambiantes y rutas inestables. El estado útil nacía de la serie, no de una transacción sagrada.

La versión temprana ya filtraba muestras, amortiguaba saltos, corregía deriva y ajustaba el reloj gradualmente. Sus resultados de decenas de milisegundos, atribuidos por el RFC 1059 al prototipo probado durante unos dos años, no deben convertirse en promesa para cualquier época o red.

Seleccionar no es adivinar

Cada asociación produce desfases, demoras y límites de error. El filtro favorece observaciones de menor demora aparente y evita que una cola pasajera gobierne el sistema. Luego llega la comparación entre fuentes.

NTP representa sus posibles correcciones como intervalos. Cuando existe una intersección defendible, las fuentes incompatibles pueden ser marcadas como falsetickers. El RFC 1305 perfeccionó filtros y selección en NTPv3; el RFC 5905 describe en NTPv4 la selección, el agrupamiento de supervivientes y la combinación final.

El algoritmo de la Universidad de Delaware conserva una salida honesta: si no hay suficiente intersección, no selecciona. Tampoco puede revelar todas las dependencias ocultas. Diez direcciones pueden depender de un mismo receptor, operador o política de leap smear. Una mayoría correlacionada sigue siendo una sola clase de fallo.

Una escalera técnica, no una jerarquía política

Un servidor stratum 1 está asociado directamente con un reloj primario. Los strata 2 a 15 se alejan por la cadena de sincronización; 16 indica que no hay sincronía. La distancia ayuda a impedir que un servidor tome la hora de su propio descendiente y cree un bucle.

No concede rango institucional. Un stratum 1 mal operado puede rendir peor que un stratum 3 estable. El número no demuestra quién posee el equipo, qué organización tiene mandato ni quién debería obedecer. NTP sí tiene distribución jerárquica y fuentes primarias, pero también modos cliente-servidor, broadcast y peer simétrico. Describirlo como red sin jerarquías sería tan falso como imaginar una sola pirámide mundial.

Diversidad, permiso y vigilancia

El RFC 8633 recomienda varias fuentes de fallos independientes y control continuo. Cuatro o más ayudan cuando son realmente diversas. La dirección o el ASN no bastan: servicios distintos pueden compartir reloj de referencia, plataforma o administración. Durante un segundo intercalar, mezclar fuentes con leap smear y UTC sin smear puede generar desacuerdo deliberado entre relojes sanos.

También hay que pedir permiso. Un fabricante que fija un servidor público ajeno en millones de dispositivos puede transferirle costos y abuso durante años. Que un puerto responda no constituye un contrato. El uso de UDP y el historial de amplificación obligan además a decidir exposición, límites y monitorización.

La exactitud tiene así una economía: alguien mantiene la referencia, paga el tráfico, responde a incidentes y revisa la cadena. El cálculo no sustituye esas obligaciones.

Seguridad para el intercambio, no para toda la cronología

El RFC 8915 definió NTS en 2020 para el modo cliente-servidor. NTS-KE usa TLS para establecer material criptográfico y cookies; después, extensiones autenticadas protegen los paquetes NTP y permiten al servidor mantener poco estado.

Eso dificulta la suplantación y la alteración en tránsito. No certifica que el servidor reciba tiempo correcto ni que sus fuentes sean independientes. Un valor equivocado puede llegar perfectamente autenticado. La especificación tampoco cubre los modos simétricos o de control.

El derecho de un reloj a no estar de acuerdo

Los relojes ordenan logs, vencimientos de certificados, escrituras y acciones físicas. Cuanto mayor es esa dependencia, más seductora resulta una marca que prometa certeza. NTP ofrece algo más robusto: una práctica para comparar testimonios falibles y decir “no sincronizado” cuando no existe acuerdo suficiente.

La referencia primaria mantiene su vínculo con el tiempo civil. El servidor elige upstreams y acceso. La red altera la demora. El cliente decide fuentes y política de ajuste. Ninguna capa recibe automáticamente los derechos de las demás.

NTP no eliminó la confianza. La volvió plural, medida y revocable. De ese desacuerdo disciplinado nació una hora común sin que todos los sistemas entregaran para siempre su reloj a un mismo servidor.

Fuentes y límites de la evidencia

El antecedente de timestamps está en RFC 778; la primera especificación, en RFC 958; la arquitectura de versión 1, en RFC 1059; y la encuesta, en RFC 1129. NTPv3 se documenta en RFC 1305. El modelo de cuatro timestamps, los strata y la selección madura están en RFC 5905 y Clock Select Algorithm. Las prácticas operativas provienen de RFC 8633 y el alcance de NTS de RFC 8915.

Las cifras de 1989 describen a los sistemas que respondieron. Las funciones de versiones posteriores explican el mecanismo maduro; no se atribuyen retroactivamente a 1985.