Résumé

  • Un client SNTP ordinaire de la RFC 2030 consultait normalement un seul serveur. Les quatre horodatages d’un échange suffisaient à estimer délai et décalage, sans reproduire la sélection multi-source et l’exclusion des horloges fautives du NTP complet.
  • La RFC imposait en conséquence une limite topologique : client à la feuille, sans dépendants ; serveur seulement à la racine, directement alimenté par une référence fiable et utilisé avec prudence.
  • En mode anycast, le client retenait la première réponse puis poursuivait en unicast. Cette arrivée gagnante désignait un interlocuteur provisoire, pas le serveur le plus proche, le plus exact, le plus sûr ou durablement identique.

Avant de demander « quelle heure est-il ? », la RFC 2030 posait une question plus structurante : jusqu’où cette réponse aura-t-elle le droit de voyager ?

Publié en octobre 1996, le texte conservait le format de message NTP et simplifiait radicalement ce qui l’entourait. Le NTP complet maintenait des états, comparait plusieurs sources et cherchait à résister à celles qui devenaient fausses. SNTP visait les machines qui n’avaient pas besoin de cette performance. La simplification portait donc moins sur les octets que sur la responsabilité confiée au destinataire.

Une limite inscrite dans le réseau

La recommandation est explicite : SNTP ne devrait être employé qu’aux extrémités du sous-réseau de synchronisation. Le client occupe la feuille, au stratum le plus élevé, et aucun autre client NTP ou SNTP ne doit dépendre de lui. Une erreur reste alors terminale. Si cette même machine distribue l’heure, une opinion unique devient la chronologie commune de tous ses descendants.

À la racine, l’exception est tout aussi serrée. Un serveur SNTP de stratum 1 convient seulement lorsqu’il est directement relié à une source radio ou modem fiable et qu’aucune autre source n’est disponible. La RFC rappelle que la fiabilité d’un véritable serveur primaire vient normalement de références redondantes, de chemins réseau divers et d’algorithmes adaptés. La multiplicité des clients ne crée aucune diversité en amont.

Quatre moments, une seule rencontre

T1 marque l’émission par le client, T2 la réception par le serveur, T3 son envoi, T4 la réception finale. Le délai corrigé vaut d = (T4-T1) - (T3-T2) et le décalage t = ((T2-T1) + (T3-T4))/2. La Verified Errata 517 est essentielle : la RFC imprimée inversait les signes du second intervalle dans la formule du délai.

Ces valeurs décrivent une rencontre. Le champ originate de la réponse doit reprendre le transmit de la requête : voilà une liaison vérifiable entre les deux paquets. Mais rien n’y certifie la symétrie du trajet, la justesse de l’horloge de référence, l’identité administrative du répondant ou la stabilité du chemin suivant.

La même asymétrie vaut pour les contrôles de santé. LI=3 annonce une horloge non synchronisée et commande le rejet, quel que soit le reste. Un stratum aberrant, un transmit nul ou un originate incohérent justifient aussi la méfiance. L’absence de ces défauts n’est pourtant pas un certificat. Les champs de référence restent des déclarations du serveur.

Le service sans état déplace la mémoire

Une requête SNTP pouvait laisser presque tous ses champs à zéro. Le serveur répondait sans conserver d’état durable par client, d’où l’image d’un appel de procédure distant sans état. Ce minimalisme rend l’interopérabilité accessible, mais ne supprime pas la mémoire opérationnelle. Il faut toujours conserver le choix du serveur, sa provenance, la résolution d’adresse, le chemin, les changements de gagnant, les divergences et la décision de bascule.

Le principe de « spécification initiale minimale » de Lu Heng éclaire ce partage. Le format et les vérifications déterministes appartiennent au socle commun. La diversité des sources et la politique de défaillance restent des décisions locales. La primauté du code en fonctionnement interdit ensuite de confondre publication, implémentation, configuration et adoption observée.

Quand le premier paquet devient une relation

Dans le mode anycast décrit par la RFC 2030, le client interrogeait un groupe de diffusion ou multidiffusion. Plusieurs serveurs pouvaient répondre depuis leur adresse unicast ; le client se liait au premier arrivé et poursuivait avec lui.

Cette règle tranche vite, mais explique peu. Le gagnant peut devoir sa place au routage, à une file plus courte, à une perte concurrente, au périmètre multicast ou à un hasard de temporisation. « Premier ici, cette fois » ne signifie ni « géographiquement le plus proche », ni « toujours le plus rapide », ni « horloge la plus exacte ».

La RFC 1546 avait déjà séparé l’adresse de service du serveur concret. Ce récit général n’est pas répété ici. Le geste propre à la RFC 2030 est la conversion d’une course de réponses en attachement unicast. L’événement de sélection est visible ; la causalité qui l’a produit ne l’est presque pas.

Une extension d’authentification destinée au multicast et à l’anycast était évoquée, mais annoncée pour une publication ultérieure et qualifiée de provisoire. Elle ne peut donc servir de preuve rétroactive que l’identité du premier répondant était résolue en 1996.

La preuve doit s’arrêter où l’erreur s’arrête

Une couche de réalité peut réussir alors que la suivante échoue : paquet syntaxiquement valide, échange calculable, horloge correctement disciplinée, journal fiable, transaction bien ordonnée. Les confondre transforme un signal technique en certitude sociale.

La leçon historique de la RFC 2030 est ainsi topologique. Si une machine doit alimenter des dépendants, survivre à la faute d’une source ou établir une identité durable, elle ne peut être promue par simple renommage d’une feuille SNTP. Il faut ajouter ce que la simplification a retiré : références indépendantes, chemins divers, provenance, historique persistant et conduite testée en cas de désaccord.

SNTP rendait un échange lisible. La RFC n’a jamais prétendu qu’une réponse unique constituait un consensus.

Sources