Résumé

  • NTP tire de quatre horodatages une estimation du décalage et du délai aller-retour, puis filtre une suite d’échantillons avant de régler l’horloge locale.
  • La sélection peut écarter des « falsetickers » lorsque les intervalles d’incertitude concordent suffisamment. Elle peut aussi échouer : plusieurs sources partageant la même panne ne constituent pas une diversité réelle.
  • Le stratum mesure une distance de synchronisation et prévient les boucles ; il ne certifie ni la précision ni l’autorité. NTS authentifie un échange client-serveur, pas la vérité de l’amont.

La ponctualité n’est pas un effet de la connectivité

En 1989, une enquête relatée dans le RFC 1129 interrogea 94 260 hôtes et passerelles avec trois protocoles horaires. Sur 20 758 répondants, environ la moitié s’écartaient de plus de deux minutes de la référence de l’expérience. Un dixième dépassait quatre heures ; quelques horloges avaient plus de deux semaines d’erreur.

L’échantillon ne représentait pas chaque machine d’Internet. Il décrivait les systèmes qui avaient répondu à cette méthode. La leçon demeure nette : une réponse réseau n’est pas une attestation. Un oscillateur dérive, un fuseau peut être mal appliqué, une source amont peut tomber en panne, et une erreur stable garde l’apparence rassurante de la régularité.

Le génie institutionnel de NTP fut donc de ne pas confondre disponibilité et crédibilité. Le protocole rendit les affirmations horaires comparables et donna au client le droit de ne pas en suivre une.

Mesurer le voyage en même temps que l’heure

Le service d’horloge DCNET de 1981 annonçait déjà la méthode. Le RFC 778 mettait en présence une horloge radio WWV à COMSAT et des horloges liées au réseau électrique, sujettes au décalage et à la dérive. L’échange d’horodatages ICMP encadrait le trajet d’une requête et de sa réponse.

Dans la notation NTP moderne, le client émet à t1, le serveur reçoit à t2, répond à t3, puis le client reçoit à t4. Le décalage estimé est [(t2 - t1) + (t3 - t4)] / 2; le délai aller-retour est (t4 - t1) - (t3 - t2).

Ces calculs ne séparent pas les deux délais unidirectionnels. Lorsque l’aller et le retour ne sont pas symétriques, une part de cette différence devient une erreur d’horloge. Les nombreux chiffres d’un horodatage ne suppriment donc pas l’incertitude du chemin.

Une mesure perdue n’interrompt pas le temps

Le RFC 958 spécifia NTP en septembre 1985. En 1988, le RFC 1059 décrivit la version 1 après environ deux ans d’exploitation de prototypes. Plusieurs sources primaires alimentaient un sous-réseau hiérarchique et auto-organisé de serveurs secondaires. Aucun scrutin mondial ne devait élire une horloge maîtresse unique.

Un datagramme perdu n’avait pas non plus à être rejoué comme une transaction indispensable. La mesure suivante pouvait le remplacer. Ce choix convenait à un Internet à multiples passerelles, où les paquets prenaient du retard, changeaient de route ou disparaissaient.

La première version filtrait déjà les échantillons, compensait la dérive de l’oscillateur, amortissait les anomalies et corrigeait progressivement l’horloge. Les dizaines de millisecondes rapportées dans le RFC 1059 appartiennent au prototype et à son environnement ; elles ne sont pas une garantie universelle rétroactive.

Écarter un témoin sans inventer un oracle

Une association NTP accumule des estimations de décalage, de délai et d’incertitude. Le filtre privilégie notamment les observations à faible délai apparent : la mise en file d’attente peut rallonger un trajet, mais elle ne révèle pas un chemin physiquement plus court que le meilleur cas observé. Un pic isolé peut ainsi être traité comme du bruit.

Quand les sources s’opposent, l’algorithme les représente par des intervalles de correction possibles. Il cherche une intersection défendable et rejette comme falsetickers les candidats incompatibles. Le RFC 1305 affina ces bornes et cette sélection pour NTPv3 ; le RFC 5905 expose ensuite sélection, regroupement des survivants et combinaison de leurs estimations dans NTPv4.

Le vote n’est pas infaillible. La description de l’Université du Delaware prévoit le cas où aucune intersection suffisante n’existe : la sélection échoue. Et plusieurs noms peuvent cacher le même récepteur GPS, le même hyperviseur, le même exploitant ou la même politique de leap smear. Une majorité corrélée peut se tromper ensemble.

Le stratum n’est pas une noblesse

Dans NTPv4, le stratum 1 est directement associé à une horloge de référence primaire. Les strata 2 à 15 indiquent les étapes suivantes de la chaîne ; le stratum 16 signifie non synchronisé. Cette distance évite qu’un serveur prenne l’heure chez son descendant et fasse circuler indéfiniment la même erreur.

Elle ne mesure pas la qualité d’une organisation. Un serveur stratum 1 congestionné ou mal surveillé peut être moins utile qu’un stratum 2 stable. Le champ n’accorde aucun titre de propriété et aucun mandat public. NTP conserve bien une distribution hiérarchique, mais aussi des modes client-serveur, diffusion et pair symétrique. Il n’est ni un arbre à souverain unique, ni un réseau sans confiance.

La distinction est décisive : une distance technique aide à contrôler une boucle ; elle ne doit pas être blanchie en rang politique.

Les obligations que le protocole ne peut exécuter

Le RFC 8633 recommande plusieurs sources réellement diverses et une surveillance continue. Quatre sources ou davantage améliorent la tolérance seulement si leurs pannes sont suffisamment indépendantes. Des adresses situées dans des réseaux différents peuvent encore partager une seule référence. Mélanger une heure lissée autour d’une seconde intercalaire avec une UTC non lissée peut faire paraître fautives des sources saines.

L’autorisation compte aussi. Un serveur public n’est pas une ressource sans propriétaire. Un fabricant qui inscrit son adresse dans des millions d’appareils peut lui imposer du trafic bien après la fin du produit. Les exploitants doivent en outre limiter l’exposition et le débit d’un service UDP qui a servi à des attaques par amplification.

Ces choix forment la partie sociale de la précision : sélectionner les amonts, connaître leurs dépendances, obtenir leur accord et regarder ce qu’ils deviennent.

Sécuriser la provenance, pas décréter la vérité

Le RFC 8915 a standardisé en 2020 Network Time Security pour le mode client-serveur. Un échange NTS-KE fondé sur TLS fournit des clés et des cookies protégés ; les paquets NTP ultérieurs portent des champs authentifiés. Le serveur peut rester sans état après l’établissement, le client lui rapportant les cookies.

NTS prouve mieux l’identité du répondant et l’intégrité du paquet. Il ne prouve pas que sa référence amont est juste, indépendante ou conforme à la politique temporelle du client. Une erreur authentifiée reste une erreur. Le texte ne couvre pas davantage les modes symétriques ou de contrôle.

Une heure commune qui demeure contestable

Les journaux, certificats, bases de données et systèmes industriels ont besoin d’un ordre temporel. Cette dépendance pousse à déléguer la certitude à une marque connue. NTP propose une discipline plus exigeante : mesurer plusieurs témoignages, tenir compte du trajet, refuser les incompatibles, combiner les survivants et corriger l’oscillateur local sans prétendre posséder le temps.

La confiance ne disparaît pas ; elle devient plurielle, observable et révocable. L’exploitant de la référence maintient son lien au temps civil. Le serveur gère ses amonts et son accès. Le réseau façonne le délai. Le client choisit les sources et décide comment son horloge bougera.

Quand les preuves ne se recoupent plus, déclarer « non synchronisé » est une fonction, non un échec moral. C’est ainsi qu’une heure d’Internet a pu émerger du désaccord sans transformer un serveur en souverain permanent.

Sources et limites de preuve

Le mécanisme antérieur à NTP vient du RFC 778. La première spécification est le RFC 958, l’architecture de la version 1 le RFC 1059, et l’enquête de 1989 le RFC 1129. Le filtrage et la sélection de NTPv3 sont dans le RFC 1305. Le modèle à quatre horodatages, les strata et la chaîne de sélection mature sont dans le RFC 5905 et le Clock Select Algorithm. Les devoirs opérationnels viennent du RFC 8633, et la portée de NTS du RFC 8915.

Les résultats du RFC 1129 concernent les répondants de l’enquête. Les versions du protocole diffèrent ; les fonctions tardives ne sont pas attribuées à l’implémentation de 1985.