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 essais 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...
Pour mesurer le temps il faut disposer d'une échelle de temps, d'une origine sur cette échelle, et d'un intervalle de temps qui servira d'unité. Toute série d'événements reproductibles peut servir d'échelle de temps. L'astronomie nous en fournit plusieurs : rotation de la terre sur elle-même ou autour du soleil. Une fois définie une échelle de temps, on attend d'elle des propriétés permettant de faire des travaux scientifiques.
Si on prend comme oscillateur la rotation de la terre sur elle-même,
on s'aperçoit que cette rotation n'est pas uniforme sur quelques jours,
ce qui conduit à l'élaboration du temps solaire moyen basé sur un soleil moyen fictif dont les passages au méridien
sont séparés par des intervalles égaux subdivisés en périodes de 24 heures ou 86400 secondes.
Le temps solaire moyen du point de l'observatoire de Greenwich augmenté de 12 heures est appelé temps universel (TU).
Or ce temps universel n'est pas à son tour uniforme à cause de diverses irrégularités physiques dont le déplacement des pôles.
On aboutit à un temps universel corrigé nommé TU2.
Si on prend comme oscillateur la rotation de la terre autour du soleil, on définit un temps appelé temps des éphémérides (TE).
Ce temps est connu avec moins de précision que TU, mais à l'avantage d'être plus uniforme.
Ces temps obtenus sont différents; la seconde universelle n'est pas la même que la seconde des éphémérides.
Depuis 1955 avec l'apparition des horloges atomiques on s'est aperçu de la dérive des secondes définies au moyen des horloges naturelles.
On utilise maintenant des oscillateurs artificiels plus précis que sont les horloges à quartz, les horloges atomiques.
Celles-ci sont utilisées plus comme étalon de fréquences ou garde temps que comme mesure directe du temps.
Les horloges à quartz sont des oscillateurs mécaniques basés sur la vibration d'un cristal de quartz taillé suivant une certaine forme.
Deux cristaux de quartz ne sont jamais taillés de la même manière et ne sont donc pas exactement tous à la même fréquence.
Les horloges atomiques sont elles basées très schématiquement par la fréquence émise
lors du changement de transition d'un atome de gaz excité.
Il existe deux catégories d'horloges atomiques.
Les unes sont des garde temps beaucoup plus stable que les horloges à quartz ;
les autres constituent des étalons absolus de fréquences et sont à la base de la définition
moderne de la seconde, c'est ce qu'on appelle le temps atomique (TA).
Naturellement ce temps atomique va dépendre du type de gaz dont on va mesurer la fréquence de transition.
Le petit tableau ci-dessous donne les différentes précisions des temps définis ci-dessus.
| Temps | Précision | Uniformité |
| TU | 10-3 | 10-7 |
| TE | 10-1 | 10-9 |
| TA césium | 10-13 | 10-13 |
Le temps légal défini par la seconde légale a été basé :
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.