Qu'est-ce qu'une vérification de dérive NTP
Une vérification de dérive NTP mesure la différence entre l'horloge de ton ordinateur, celle de notre serveur et quatre serveurs NTP publics. Notre serveur envoie un petit paquet UDP sur le port 123 à chacun, lit les horodatages renvoyés et calcule l'offset (de combien de millisecondes ton horloge est décalée) et le délai aller-retour.
Tu obtiens une vue unique avec l'heure de ta machine, l'heure de notre serveur, l'heure de référence NTP et un graphique en barres de la dérive par serveur. Rien à installer, pas de droits admin, juste rafraîchir la page.
Comment l'utiliser
- Ouvre l'outil. En quelques secondes, tu vois trois grands chiffres : l'heure de ton ordinateur, l'heure de notre serveur et l'heure de référence NTP (médiane sur les quatre serveurs).
- En dessous, deux lectures : ton ordinateur vs NTP et notre serveur vs NTP. Une valeur positive signifie que ton horloge est plus lente que NTP. Négative = plus rapide.
- À droite, un graphique en barres de la dérive par serveur (pool.ntp.org, time.cloudflare.com, time.google.com, time.windows.com). Utile pour confirmer que les serveurs sont d'accord entre eux.
- Active le rafraîchissement automatique toutes les 10 secondes avec l'interrupteur en haut. Désactivé = mesure unique, comme cliquer sur "Rafraîchir".
- Si un serveur signale erreur : timeout, il n'a pas répondu en 3 secondes. Souvent un filtre UDP sur le chemin. Les trois autres serveurs donnent quand même une image utile.
- La colonne "strate" montre à quel point ce serveur est proche de la source. 1 = horloge atomique ou GPS, 2 = un serveur qui interroge un strate 1, et ainsi de suite. Les nombres plus bas ont plus d'autorité.
Quand c'est utile
Six situations où la dérive d'horloge fait vraiment mal :
- TOTP / 2FA échoue ("code invalide" même avec le bon secret) parce que l'horloge d'un téléphone ou serveur a dérivé de 30+ secondes. Tu peux voir immédiatement si le problème vient de chez toi.
- Certificats TLS marqués invalides ou "pas encore valides" parce que l'horloge serveur est décalée de plusieurs minutes dans un sens ou l'autre et tout casse.
- Corrélation de logs entre microservices : si chaque nœud a une dérive différente, les événements dans Grafana et Loki s'alignent dans le mauvais ordre et le debug devient de la devinette.
- Kerberos / Active Directory rejette les tickets quand l'écart entre client et contrôleur de domaine dépasse 5 minutes (la tolérance d'asymétrie d'horloge par défaut).
- Bases de données multi-master (Cassandra, ScyllaDB, CockroachDB) utilisent les timestamps pour résoudre les conflits d'écriture, une mauvaise horloge signifie que c'est le dernier-écrivant-gagne sur la mauvaise écriture.
- Smart contracts et RPCs blockchain valident souvent que block.timestamp est raisonnable versus now. Une mauvaise horloge sur ton nœud = transactions rejetées.
Liens utiles : horloge mondiale, convertisseur de fuseaux horaires, Unix timestamp, recherche DNS.
Questions et réponses
Network Time Protocol est un protocole de 1985 (RFC 5905) qui permet aux ordinateurs de synchroniser leurs horloges sur le réseau avec une précision en milliseconde sur un LAN et quelques dizaines de ms sur internet. Le client envoie un petit paquet UDP à un serveur NTP, le serveur répond avec des timestamps, le client calcule offset et délai. Tout ton système d'exploitation fait tourner un client NTP en arrière-plan : sur Windows c'est W32Time, sur Linux en général chrony ou systemd-timesyncd, sur macOS timed.