Exposé non-formel et non-technique sur le NTP (Network Time Protocol).
Le NTP est un protocole permettant de synchroniser l’horloge d’un ordinateur avec celle d’un serveur de référence.
NTP est un protocole basé sur UDP/IP:123.
C’est donc un protocole internet basé sur l’adressage IP,
en mode non connecté avec User Datagram Protocol sur le port 123.
La synchronisation de l’heure est diffusée depuis des serveurs primaires dans une arborescence en réseau.
Plus de 1.8E5 clients et serveurs utilisent NTP sur internet.
NTP a été porté sur la plupart des plateformes dont Windows, Linux, Unix…
Le NTPv3 utilisé depuis 1992 permet une synchronisation de l’ordre de la milliseconde
ou mieux sur des réseaux locaux (LAN),
et avec des écarts inférieurs à 10 secondes sur des réseaux nationaux (WAN).
L’architecture de NTPv4 permet d’atteindre une précision 10 fois plus grande,
de l’ordre de la micro-seconde sur les réseaux rapides modernes.
Voir mon service d’heure en ligne.
Actuellement tout équipement informatique dispose d’une horloge matérielle ou logicielle à laquelle
il est fait référence pour horodater des fichiers, des transactions, des courriers électroniques, etc.
Cette horloge, bien que conçue autour d’un oscillateur à quartz, dérive comme toute montre ordinaire.
Ceci est d’autant plus gênant lorsque les machines sont en réseau et partagent des ressources communes comme des systèmes de fichiers.
Par exemple, certains outils de développement, comme la commande Unix make,
basent leur travail sur la comparaison des dates de modification de fichiers.
De même, la corrélation de messages de "logs" de plusieurs systèmes devient très difficile si elles ne sont pas à la même heure.
C’est encore plus ennuyeux lorsqu’il s’agit de serveurs visibles de tout l’Internet comme les relais de messagerie
qui oblitèrent les courriers qu’ils transmettent.
A titre d’exemple, début septembre 1995, près de 60% des relais de messagerie du domaine .fr avaient un décalage de plus de 1 minute
sur l’heure exacte et 27% de plus de 10mn. Ainsi il n’est pas rare de recevoir des courriers avant qu’ils ne soient émis…
Les serveurs DNS ne sont pas plus à l’heure…
Consulter cet autre article.
Elles sont toutes dérivées plus ou moins directement d’horloges atomiques.
On peut citer :
La mesure du temps ne suffit pas pour pouvoir utiliser le temps, car les oscillateurs choisis, naturels ou artificiels,
ne sont pas directement utilisables par le commun de mortels. C’est pourquoi on distingue les horloges primaires
et les horloges secondaires.
Les horloges primaires, naturelles ou artificielles, servent d’étalon sur lesquels on va se synchroniser.
Les horloges secondaires sont synchronisées sur les horloges primaires et servent à transporter le temps.
C’est le cas classique est très utilisé des montres et autres réveils.
Avec l’apparition des télécommunications il est maintenant possible de transporter le temps au moyen de signaux radios.
Et l’on sait synchroniser les différents étalons de fréquence entre eux sur la planète pour obtenir
un temps moyen coordonné appelé temps universel coordonné (TUC).
Naturellement ce temps est moins précis que celui des horloges atomiques puisqu’il faut tenir compte des délais de transmission
des signaux. Il y a à travers le monde plusieurs sites officiels de transmission du temps par des tops radio.
En France c’est l’émetteur de TDF qui est chargé de la transmission.
Les différents temps que l’on vient de mettre en évidence, temps solaire moyen, temps universel,
temps des éphémérides, temps atomique et temps universel coordonné, sont tous différents et ne sont pas utilisés de la même manière.
L’usage du temps qui nous intéresse ici est celui du service de l’heure pour la vie quotidienne,
c’est donc le temps universel (TU). Mais comme la seconde est définie à partir des étalons atomiques
il faut réajuster l’heure régulièrement afin que le soleil passe toujours au méridien de Greenwich à midi.
Ce réajustement a lieu si nécessaire fin juin ou fin décembre, et l’on ajoute ou enlève une seconde à la minute courante.
C’est ainsi que de temps en temps il y a des minutes qui font 61 secondes ou parfois 59 secondes.
TP fut le premier protocole permettant de synchroniser des machines. C’est le plus ancien (1983), il fait l’objet du RFC868. S’appuyant sur UDP ou TCP il se résume à l’envoi par les serveurs d’un paquet contenant le temps en secondes écoulé depuis le premier janvier 1900 à 00h00.
Il a été utilisé par le démon Unix timed mais sa faible résolution et l’absence de spécification de mécanismes de compensation de délais de transit ont conduit à l’étude d’un protocole plus sophistiqué.
Le NTP est né d’une initiative de D.L. Mills dans le RFC958 de Septembre 1985.
Cet exposé se basera sur le document RFC1305 de Mars 1992 (rendant obsolètes RFC1119, RFC1059, RFC958).
Les évolutions de NTP concernent surtout les algorithmes de mise à jour des horloges locales,
pour gagner en stabilité et précision, mais la compatibilité avec des versions plus anciennes est assurée.
NTPv3 a permis d’affiner les algorithmes et de supprimer les ambiguïtés des versions précédentes.
NTPv4 est compatible avec les versions précédentes ;
il permet d’accroître par 10 la précision et d’augmenter les délais entre les synchronisations sans trop de perte de précision.
Avec NTPv4 est aussi fourni un nouveau modèle de gestion amélioré de l’horloge locale.
L’implémentation a été simulée et testée sur différentes architectures machines.
Décrit dans le RFC 1361, c’est une version simplifiée de NTP, dépourvue des mécanismes de sélection,
destinée à des utilisations où une précision de l’ordre de la seconde est suffisante.
Un client SNTP peut aussi se synchroniser sur un serveur NTP.
Bien qu’ayant été conçu pour implémenter des clients simple,
SNTP permet aussi la mise en oeuvre de serveurs mais ceux-ci doivent alors être synchronisé directement par une référence temporelle (ex: radio).
Les clients SNTP doivent opérer dans une configuration où aucun client SNTP ne dépend d’un autre client SNTP.
La version 3 de SNTP, décrite dans la RFC 2030 supporte IPv6.
SNTP permet une synchronisation allant du dixième de seconde à la seconde, ce qui est suffisant la plupart du temps,
mais pas pour les applications temps réel…
NTP est basé sur un système de strates.
On peut avoir jusqu’à 15 couches, mais en général, on ne dépasse pas la 5ème.
Notons que les simples clients ne sont pas autorisés avant la strate 3.
Il y a plusieurs modes de communication :
NTP propose intègre système d’exploration du réseau pour découvrir automatiquement de nouveaux serveurs NTP, par différentes méthodes.
Des contrôles de time-out et de TTL garantissent le bon déroulement de la configuration.
La synchronisation de l’horloge locale ne se fait pas une seule fois, ni en une seule étape. En effet, une horloge locale dévie de manière assez aléatoire.
La base de synchronisation de temps décrite par les RFC 1305 est constituée par le format de message NTP (figure ci-dessous), constituée d’un nombre de bits et d’octets utilisés pour l’information de contrôle et de référence et d’une suite de zones d’horodatage pour les informations sur le temps. Chaque zone d’horodatage est constituée d’un nombre de 64 bits.
Les champs horaires sont codés en heure GMT (Greenwich Mean Time) sur 64 bits :
| Leap Indicator | prévient de la dérive en fin de journée (00:rien, 01:ajouter une seconde, 10:enlever une seconde, 11:horloge non synchronisée) |
| Version Number | numéro de version |
| Mode |
|
| Stratum | strate (1:serveur primaire(horloge radio, atomique, etc.)) |
| Poll | indique le nombre maximal de secondes qui peuvent s’écouler entre deux messages (exprimé en puissance de deux). Les deux parties doivent donc entretenir une communication dont la période de mise à jour doit être inférieure à Poll. |
| Precision | précision de l’horloge en secondes (exprimé en puissance de deux : -10 signifie 2-10, soit 1/1024=0.97ms) |
| Synchronizing Distance | temps d’aller-retour jusqu’au serveur primaire en secondes (les bits 15 et 16 représentent les fractions) |
| Synchronizing Dispersion | dispersion estimée jusqu’au serveur primaire (les bits 15 et 16 représentent les fractions) |
| Reference Clock Identifier | identifiant d’une horloge :
|
| Reference Timestamp | heure de la dernière mise à jour de l’horloge. |
| Originate Timestamp | heure de départ de la requête. |
| Receive Timestamp | heure d’arrivée de la requête. |
| Transmit Timestamp | heure de départ de la réponse à la requête. |
| Authenticator | comporte la signature DES de ce paquet émis. |
Pour utiliser le format de message NTP afin de synchroniser les horloges d’ordinateurs,
un programme client définit d’abord la zone Mode dans le format de message,
pour indiquer qu’une demande est effectuée (mode client).
Eventuellement, le client place l’heure courante de la machine cliente dans la zone d’horodatage.
La zone Transmit pourra servir, lors du retour du message depuis le serveur NTP,
à calculer le délai aller-retour de l’échange.
Après avoir défini ces zones, le client envoie le message au programme serveur NTP,
en utilisant l’interface sockets et le port réservé à l’utilisation NTP, port numéro 123.
Le programme serveur NTP reçoit le message sur le port 123 puis règle la zone d’horodatage Receive d’après
l’heure de réception de la requête.
Ensuite, la valeur d’horodatage Transmit envoyée par le client est copiée dans la zone d’horodatage Originate
d’où elle sera renvoyée au client et utilisée pour calculer le délai d’aller-retour.
Certaines zones de contrôle dans la première partie du message sont définies de manière à identifier
le mode de fonctionnement du serveur.
Enfin, le serveur place l’heure courante dans le tampon horodateur Transmit et renvoie le message au client.
Dès réception, le client vérifie la validité du message, calcule le délai d’aller-retour et la différence
entre les heures de l’horloge serveur et de l’horloge client (cette différence est appelée décalage d’horloge locale).
Le client applique alors sa politique de mise à l’heure.
Une fois connu le décalage entre l’heure locale et l’heure de référence, il faut mettre à jour l’heure locale. Changer l’heure système est un problème pour les services utilisant l’heure, comme les bases de données, ou simplement les comparaisons de fichiers grâce à la date. Aussi il existe deux méthodes de mise à l’heure.
Les seuils d’écart pour utiliser l’une ou l’autre des méthodes peuvent être configurés.
Au niveau de l’implémentation des algorithmes en machine, il est important de réduire les délais entre la couche physique réseau,
et le traitement des champs NTP.
NTP, et en particulier les nouvelles versions, est testé sur un réseau de test "DCnet Research Network".
Il évolue pour gagner en fiabilité, tenir compte des évolutions (IPv6) et des besoins futurs ;
par exemple pour fonctionner sur IPIN (InterPlanetary Internet).
NTP est reconnu pour être un protocole de synchronisation efficace,
en revanche la complexité des algorithmes mis en oeuvres limite son déploiement.
En effet, une grande précision horaire fait appel a des notions scientifiques spécifiques,
tant pour les mises à l’heure dues aux variations du mouvement terrestre,
que pour la résolution du problème du transfert de l’heure avec des délais variables.
Aussi, il est recommandé d’utiliser SNTP à l’extrémité des sous réseaux de synchronisation.