Le 30 août 2026, Jeff Geerling branche de vieux Mac à un service réseau tellement simple qu'il tient presque dans une phrase : ouvrir le port 37, recevoir quatre octets, fermer.1
Les quatre octets représentent un entier non signé de 32 bits, le nombre de secondes écoulées depuis le 1er janvier 1900 à minuit,3 sans JSON, fuseau, identifiant de serveur, mesure de latence ni même fraction de seconde.
En 1983, le protocole RFC 868 appelle cela simplement Time.3
Sa petitesse est séduisante aujourd'hui, au point de donner l'impression d'une époque où les protocoles savaient encore se tenir. Mais la raison est plus prosaïque : ces quatre octets restent minuscules parce que le protocole ne résout qu'une partie très étroite du problème.
NTP apparaîtra deux ans plus tard pour récupérer tout ce que ces quatre octets ne peuvent pas dire.4
Deux services
RFC 867 et RFC 868 sont publiées toutes les deux en mai 1983, avec deux réponses très différentes au même besoin. Daytime, RFC 867, écoute sur le port 13. Le serveur renvoie une ligne de texte avec la date et l'heure, puis ferme la connexion en TCP ; en UDP, un datagramme reçu déclenche un datagramme de réponse.2
Le document ferait probablement frémir un auteur d'API moderne : il n'impose aucune syntaxe précise.2
Il recommande une seule ligne ASCII et donne deux formats populaires, mais un client ne peut pas supposer qu'un serveur suivra l'un ou l'autre. Daytime est surtout un outil humain de diagnostic et de mesure.2
RFC 867 le dit elle-même : pour une heure utile à une machine, utilisez RFC 868.2
Time abandonne cette lisibilité au profit d'une réponse déterministe : sur TCP, le client se connecte au port 37, reçoit un entier de 32 bits puis voit le serveur fermer ; sur UDP, un datagramme vide suffit à provoquer le retour des quatre octets.3
Quatre octets
RFC 868 choisit une époque qui survivra ensuite dans NTP : 00:00:00 le 1er janvier 1900.3
Le 1er janvier 1970 vaut ainsi 2 208 988 800 dans cette représentation.3 Pour convertir une valeur Time vers l'époque Unix, on peut donc retrancher 2 208 988 800 secondes, exactement ce que Geerling fait dans sa démonstration 2026.1
Le protocole a une résolution d'une seconde, conséquence directe de son compteur entier,3 un choix cohérent avec la motivation donnée dans la RFC : certains systèmes n'ont pas d'horloge date/heure, et ceux qui en ont restent sujets aux erreurs humaines ou matérielles. Un bref sondage de plusieurs serveurs indépendants permet au moins de confirmer ou corriger l'idée locale de l'heure.3
Quatre octets suffisent parfaitement à cette tâche si l'on accepte trois hypothèses : la seconde suffit comme granularité, le trajet réseau est négligeable pour l'usage visé, et le client sait déjà comment interpréter l'époque 1900.
Le protocole paraît rudimentaire seulement si on lui demande davantage que ce qu'il promet ; son contrat est surtout étroit.
Le trajet manque
Imaginons que le serveur estampille sa réponse à 12:00:00 et que celle-ci arrive 400 ms plus tard.
RFC 868 donne au client « 12:00:00 », sans lui permettre de savoir si le paquet a mis 2 ms, 40 ms ou 400 ms à arriver, puisqu'il ne possède ni timestamp de départ de la requête, ni timestamp de réception côté serveur, ni information sur le délai de retour.
Même une valeur encodée à la microseconde ne suffirait pas à connaître l'heure locale exacte au moment de la réception, puisque la précision du nombre ne mesure pas le temps passé sur le réseau.
C'est la distinction essentielle entre résolution et synchronisation.
Geerling la retrouve naturellement en rejouant le protocole sur un réseau contemporain : Time est excellent pour montrer l'heure sur un ancien ordinateur, mais il n'a aucun mécanisme pour compenser les délais variables d'un Internet à plusieurs sauts.1
La simplicité du paquet ne supprime donc pas le problème, elle le repousse vers le client et vers les hypothèses qu'il accepte.
Quatre timestamps
Le premier RFC intitulé Network Time Protocol est RFC 958, publié en septembre 1985, et non 1988 ;4 RFC 1059 de juillet 1988 est la spécification NTP version 1 qui le remplace.5 La distinction est petite historiquement, mais utile lorsque l'on raconte précisément comment Time devient NTP.
RFC 958 dit explicitement que NTP évolue du Time Protocol et du message ICMP Timestamp.4
Le saut conceptuel apparaît dans quatre instants :
- t1 : la requête quitte le client ;
- t2 : elle arrive au serveur ;
- t3 : la réponse quitte le serveur ;
- t4 : elle arrive au client.4
Avec ces quatre nombres, le client peut estimer le délai aller-retour et son décalage d'horloge par rapport au serveur. RFC 958 donne déjà les formules qui restent reconnaissables dans NTP moderne.4
Le calcul garde évidemment une hypothèse : les délais aller et retour doivent être suffisamment symétriques pour que l'estimation reste utile, et une forte asymétrie peut encore la biaiser.4
Mais le protocole possède désormais les données nécessaires pour parler du réseau au lieu de faire comme s'il n'existait pas.
Trente-deux plus trente-deux
NTP 1985 utilise déjà des timestamps sur 64 bits :4 la moitié haute contient les secondes, toujours comptées depuis 1900, tandis que la moitié basse ajoute une fraction de seconde sur 32 bits. Le bit de fraction le plus faible représente environ 0,23 nanoseconde de résolution numérique.4
Cette finesse du format ne signifie pas qu'un ordinateur de 1985 synchronise réellement son horloge à 0,23 ns ; la résolution du timestamp et l'exactitude du système appartiennent à deux niveaux différents.
NTP ajoute en plus des informations sur la précision de l'horloge locale, son erreur estimée, sa dérive et sa source de référence.4 Les versions suivantes développeront les algorithmes de sélection, filtrage et discipline d'horloge ; NTPv4 formalise notamment offset, délai, dispersion et jitter.6
Ce que RFC 868 obtenait en retirant presque tout, NTP l'obtient en transportant assez de contexte pour décider à quel point croire l'heure reçue.
Le 7 février
Le compteur de secondes 32 bits de RFC 868 possède une échéance mathématique : après 4 294 967 295 secondes, il n'existe plus de valeur supérieure dans le champ. La seconde suivante correspond à 06:28:16 UTC le 7 février 2036.7
RFC 868 prévenait déjà en 1983 que son époque « servira jusqu'en 2036 ».3
NTP hérite du même champ secondes sur 32 bits dans son timestamp 64 bits. La moitié fractionnaire augmente la résolution ; elle n'allonge pas la plage du compteur de secondes.
Les spécifications modernes utilisent donc des ères NTP. RFC 4330 explique qu'un timestamp après le rollover peut être interprété relativement à une nouvelle base commençant précisément à 06:28:16 UTC le 7 février 2036.7 RFC 5905 formalise l'ère 0 puis l'ère 1 autour de ce wrap.6
À partir de là, le contexte devient indispensable puisqu'une valeur de secondes isolée ne suffit plus à distinguer 1900 de 2036.
C'est un joli retournement : le protocole qui gagnait en élégance grâce à un entier autonome finit par avoir besoin d'une information extérieure pour rester non ambigu au-delà de sa première fenêtre de 136 ans.
Plusieurs horloges
RFC 868 contient pourtant une idée plus sophistiquée que son paquet : elle conseille un bref sondage de plusieurs sites indépendants afin de confirmer ou corriger l'heure locale.3
Le paquet ne contient aucun mécanisme de consensus et laisse la stratégie au client ; NTP transformera progressivement cette intuition en système distribué. Dès RFC 958, des pairs peuvent publier la nature de leur horloge, sa précision, son erreur estimée et sa dérive, puis sélectionner de meilleures références et prévoir des sources de secours.4
NTPv4 va beaucoup plus loin avec une hiérarchie de strates, des filtres, une discipline d'horloge et des procédures pour écarter des mesures incohérentes.6
Le prix du protocole augmente parce que la question a changé : RFC 868 répond quelle heure ce serveur dit-il qu'il est ?, tandis que NTP essaie de répondre quelle estimation de l'heure pouvons-nous défendre après avoir tenu compte des horloges, du réseau et de leur incertitude ?
Garder les quatre octets
Cela ne rend pas RFC 868 ridicule en 2026.
La démonstration de Geerling montre exactement pourquoi les vieux protocoles restent agréables à manipuler : un service xinetd, un port, quatre octets visibles dans xxd, et un ancien ordinateur peut obtenir une heure réseau sans embarquer un client NTP contemporain.1
Dans un laboratoire fermé, un test, un appareil très limité ou une démonstration pédagogique, un protocole étroit peut être la bonne abstraction.
Son intérêt reste intact à condition de nommer précisément ce qu'il laisse volontairement de côté.
La leçon de RFC 868 n'est pas que nous aurions dû garder les réseaux simples. C'est que la taille d'un protocole correspond souvent à la quantité d'incertitude qu'il accepte de laisser ailleurs.
Quatre octets suffisent pour transporter un compteur de secondes ; dès qu'on veut savoir combien de temps le compteur a mis à arriver, si le serveur dérive, si une autre horloge le contredit, quelle erreur est plausible et de quel côté de février 2036 se trouve la valeur, les quatre octets cessent d'être l'heure complète.
Ils redeviennent ce qu'ils ont toujours été : une mesure, accompagnée d'hypothèses que le réseau moderne a fini par apprendre à écrire explicitement.