NTP — qu¹est-ce que c’est, protocole de temps et synchronisation dans les applications
NTP (Network Time Protocol) est un protocole réseau de synchronisation horaire qui offre une précision de l’ordre de la milliseconde sur les réseaux locaux et de la dizaine de millisecondes sur le réseau mondial. Développé par David Mills en 1985, le protocole est utilisé dans tous les systèmes d’exploitation modernes, les appareils mobiles et les équipements réseau pour synchroniser les horloges internes avec le temps de référence UTC. Selon le NTP Pool Project (2026), plus de 4 milliards d’appareils effectuent quotidiennement des requêtes NTP pour la synchronisation.
Points clés
- NTP — protocole de synchronisation horaire via le réseau, précision de 1 ms (LAN) à 50 ms (WAN)
- Hiérarchie des strates — un système de niveaux (stratum 0–16), où stratum 0 est l’horloge atomique de référence
- Correction de dérive — NTP ne se contente pas de régler l’heure, il ajuste la fréquence de l’horloge pour une précision continue
- SNTP — une version simplifiée de NTP pour les appareils à ressources limitées, utilisée dans l’IoT et Android
- Sécurité — NTPv4 prend en charge l’authentification par clés symétriques et NTS (Network Time Security)
Qu’est-ce que NTP ?
NTP (Network Time Protocol) est un protocole réseau conçu pour la synchronisation précise de l’horloge interne d’un ordinateur avec une source de temps de référence via un réseau à commutation de paquets. Décrit dans la RFC 5905 (NTPv4), le protocole utilise un système hiérarchique de serveurs, où chaque niveau est appelé strate. Un client NTP envoie des requêtes à un serveur, mesure le temps aller-retour du paquet (RTT) et calcule le décalage de sa propre horloge par rapport au temps de référence. L’algorithme de correction prend en compte non seulement un décalage unique, mais aussi la dérive du générateur d’horloge, ce qui permet de maintenir la précision pendant de longues périodes sans requêtes répétées.
Historique du développement de NTP
Le protocole a été développé par David Mills en 1985 pour le réseau ARPANET. La première spécification (RFC 958) décrivait un algorithme de synchronisation simple avec une précision allant jusqu’à 100 ms. NTPv3 (RFC 1305, 1992) a ajouté un algorithme de filtrage et un meilleur traitement des retards. NTPv4 (RFC 5905, 2010) — la version actuelle — inclut la prise en charge d’IPv6, la configuration automatique des serveurs et la protection contre les attaques via Network Time Security (NTS). En 40 ans, le protocole est passé d’un projet de recherche à un standard d’infrastructure sans lequel les transactions financières, les télécommunications et les réseaux mobiles seraient impossibles.
Comment fonctionne NTP
Le principe de fonctionnement de NTP repose sur la mesure du temps de parcours du paquet sur le réseau. Le client envoie une requête avec un horodatage T1 (heure locale d’envoi). Le serveur reçoit la requête au moment T2 (heure du serveur), génère une réponse avec l’horodatage T3 et l’envoie. Le client reçoit la réponse au moment T4. En utilisant les quatre horodatages, le client calcule le décalage = ((T2 - T1) + (T3 - T4)) / 2 et le retard = (T4 - T1) - (T3 - T2). Si le retard dépasse 1 seconde, le résultat est considéré comme non fiable — cela protège contre les canaux surchargés ou instables.
Correction de la dérive de l’horloge
Le simple réglage de l’heure exacte ne suffit pas — l’oscillateur à quartz d’un appareil dérive constamment (avance ou retarde) en raison de la température, du vieillissement et de la tension. NTP résout ce problème à l’aide de l’algorithme PLL (Phase-Locked Loop) : il ne règle pas l’heure de force, mais ajuste la vitesse de l’horloge. Si l’appareil avance de 0,1 seconde par heure, NTP ralentit l’horloge système jusqu’à ce que la dérive soit compensée. Cette approche permet une synchronisation toutes les quelques heures sur des réseaux stables, plutôt que toutes les 30 secondes.
cpp
// Simplified NTP algorithm schema
struct NTPPacket {
uint8_t flags; // LI, VN, Mode
uint8_t stratum; // server stratum level
uint32_t refTimestamp; // reference timestamp
uint32_t originTimestamp; // T1
uint32_t recvTimestamp; // T2
uint32_t xmitTimestamp; // T3
};
// Calculate offset and delay
double offset = ((t2 - t1) + (t3 - t4)) / 2.0;
double delay = (t4 - t1) - (t3 - t2);Strates — hiérarchie de NTP
L’ensemble du système NTP est organisé en une hiérarchie, où chaque niveau est appelé strate. La strate 0 est l’horloge de référence : horloges atomiques, récepteurs GPS ou signaux radio WWVB. Ces appareils ne sont pas directement connectés au réseau. La strate 1 sont les serveurs directement connectés aux horloges de référence. La strate 2 reçoit l’heure de la strate 1, la strate 3 de la strate 2, et ainsi de suite jusqu’à la strate 15. Plus le numéro de strate est élevé, plus la précision est potentiellement faible — chaque niveau ajoute un léger retard et une erreur. La strate 16 signifie que l’heure n’est pas disponible (non synchronisée).
| Strate | Description | Précision |
|---|---|---|
| Stratum 0 | Horloges atomiques, GPS, signaux radio | Nanosecondes |
| Stratum 1 | Serveurs connectés à la référence | Microsecondes |
| Stratum 2 | Serveurs NTP publics | 1–10 ms |
| Stratum 3 | Serveurs locaux des organisations | 10–50 ms |
| Stratum 4+ | Appareils clients | jusqu’à 100 ms |
Choix du serveur par strate
Pour les appareils mobiles, les serveurs de strate 2 sont optimaux — il y en a suffisamment et ils offrent un bon équilibre entre précision et disponibilité. Par exemple, pool.ntp.org est un pool de milliers de serveurs dans le monde entier qui répartit automatiquement la charge. Pour les applications Android, il n’est pas recommandé d’utiliser la strate 1 directement : premièrement, cela crée une charge excessive sur les serveurs primaires, et deuxièmement, un appareil mobile n’a besoin que d’une précision de 10–50 ms, que fournit la strate 2. Dans les réseaux d’entreprise, un serveur local de strate 3-4 est installé et se synchronise avec une strate 2 externe.
SNTP — version simplifiée de NTP
SNTP (Simple Network Time Protocol, RFC 4330) est une implémentation simplifiée de NTP pour les appareils à ressources limitées : microcontrôleurs, capteurs IoT et applications mobiles ne nécessitant pas une haute précision. Contrairement à NTP complet, SNTP n’effectue pas de filtrage de plusieurs serveurs, n’analyse pas la dérive de l’horloge et n’utilise pas d’algorithmes PLL complexes. Un client SNTP envoie une requête, reçoit une réponse et règle l’heure une seule fois. La précision de SNTP est de 10–100 ms selon le réseau — cela est suffisant pour la grande majorité des scénarios mobiles, à l’exception des transactions financières.
Quand utiliser SNTP au lieu de NTP
SNTP convient aux applications Android qui ont simplement besoin d’obtenir l’heure actuelle du serveur sans maintenir une synchronisation continue. Par exemple, une application affiche l’heure du serveur à la connexion ou se synchronise une fois par jour. NTP complet est nécessaire pour les systèmes serveurs, les équipements de télécommunications, les plateformes financières et les bases de données distribuées où la précision constante et la surveillance de la dérive sont critiques. Pour le développement mobile, SNTP est suffisant — le service d’heure intégré d’Android l’utilise pour la synchronisation périodique avec les serveurs Google.
Implémentation de NTP dans Android
Dans les applications Android, l’obtention de l’heure exacte via NTP est nécessaire lorsque l’heure système peut être modifiée par l’utilisateur ou diffère de l’heure réelle en raison d’un manque de réseau. Android ne dispose pas d’un client NTP public intégré — les développeurs utilisent la bibliothèque Apache Commons Net SntpClient ou des solutions tierces. En 2022, Google a ajouté une classe SntpClient interne à l’API Android (via Google Play Services), mais elle nécessite une configuration et n’est pas documentée pour un usage général. Une approche alternative consiste à demander l’heure via une API REST qui renvoie l’horodatage du serveur dans le corps de la réponse.
Exemple d’implémentation de client SNTP
Une implémentation de base de SNTP sur Android consiste à envoyer un paquet UDP à un serveur NTP (par exemple, pool.ntp.org), à analyser la réponse et à extraire l’horodatage de transmission (T3). Le code doit gérer les timeouts réseau et les erreurs d’analyse — dans une application réelle, cette opération est effectuée dans un thread d’arrière-plan et le résultat est mis en cache jusqu’à la prochaine synchronisation. La bibliothèque Apache Commons Net fournit une classe NTPUDPClient prête à l’emploi qui peut être utilisée dans Android avec des modifications minimales, en ajoutant la dépendance au build.gradle.
kotlin
// Get NTP time via Apache Commons Net
fun getNtpTime(server: String = "pool.ntp.org"): Date? {
return try {
val client = NTPUDPClient()
client.setDefaultTimeout(5000)
val info = client.getTime(InetAddress.getByName(server))
client.close()
Date(info.getMessage().getTransmitTimeStamp().getTime())
} catch (e: Exception) {
null
}
}Précision de NTP et facteurs d’influence
La précision de NTP dépend de plusieurs facteurs : le retard réseau (RTT), la stabilité du canal, la charge du serveur et la qualité du générateur d’horloge local. Sur un réseau local avec un retard inférieur à 1 ms, NTP atteint une précision de 0,1–1 ms. Via Internet avec un retard de 10–50 ms, la précision tombe à 10–50 ms. Plus importante que la précision ponctuelle est la stabilité : si le retard varie (gigue), NTP a besoin de plus de temps pour calculer un décalage fiable. Pour les appareils mobiles, le principal facteur d’instabilité est le basculement entre le Wi-Fi et les réseaux mobiles, où le retard peut changer d’un ordre de grandeur.
Recommandations pour le développement mobile
Pour les applications Android sensibles à l’heure exacte, il est recommandé : d’utiliser plusieurs serveurs NTP et de sélectionner celui avec le retard le plus faible ; d’éviter la synchronisation lors des changements de réseau ; de mettre en cache la dernière heure obtenue et de l’ajuster via System.currentTimeMillis. Pour les jeux et les applications en temps réel (NTP n’est pas adapté ici en raison de la latence réseau), utilisez l’heure du serveur transmise dans chaque requête. Dans les applications financières, vérifiez toujours l’écart avec le serveur — si la différence dépasse 5 secondes, bloquez l’opération comme potentiellement dangereuse.
Questions fréquentes
Qu’est-ce que NTP et à quoi sert-il ?
NTP (Network Time Protocol) est un protocole de synchronisation d’horloge via Internet. Il sert à aligner l’heure des appareils sur la référence UTC. Sans NTP, les horloges des ordinateurs dérivent de plusieurs secondes par jour en raison de la dérive de l’oscillateur à quartz, ce qui est critique pour les transactions financières, la journalisation et la sécurité.
Comment est structurée la hiérarchie NTP ?
Le système NTP utilise des niveaux — des strates : stratum 0 (horloges atomiques et GPS), stratum 1 (serveurs connectés à la référence), stratum 2 (serveurs NTP publics), stratum 3–4 (serveurs locaux), stratum 5–15 (clients). Plus la strate est élevée, plus l’erreur potentielle est grande. La strate 16 signifie que l’heure n’est pas synchronisée.
Quelle est la différence entre NTP et SNTP ?
SNTP est une version simplifiée de NTP pour les appareils à ressources limitées. Il ne filtre pas les serveurs, n’analyse pas la dérive de l’horloge et n’utilise pas PLL. SNTP convient aux applications mobiles où une précision de 10–100 ms est suffisante. NTP complet est nécessaire pour les serveurs, les équipements de télécommunications et les systèmes fintech.
Comment obtenir l’heure exacte via NTP dans Android ?
Utilisez la bibliothèque Apache Commons Net avec la classe NTPUDPClient. Envoyez une requête à pool.ntp.org, obtenez la réponse et extrayez l’horodatage de transmission. Alternativement, utilisez l’API REST de votre serveur, qui renvoie l’heure du serveur dans l’en-tête Date ou dans le corps de la réponse au format Unix Timestamp.
Pourquoi la synchronisation horaire est-elle importante sur les appareils mobiles ?
Sans synchronisation NTP, l’heure système sur un appareil peut différer de minutes ou d’heures. Cela perturbe les notifications push, la validation des certificats SSL, les journaux, les planificateurs de tâches et les protocoles cryptographiques. Dans les applications financières, un écart de plus de 5 secondes est considéré comme une menace de sécurité.
Résumé
- NTP — un protocole de synchronisation horaire réseau offrant une précision de 1 ms (LAN) à 50 ms (WAN) via une hiérarchie de strates 0–16
- Correction de dérive — NTP ne se contente pas de régler l’heure, il ajuste la fréquence de l’horloge via PLL, maintenant la précision pendant des heures entre les synchronisations
- Hiérarchie des strates — chaque niveau (strate) ajoute une erreur potentielle ; pour les appareils mobiles, les serveurs de strate 2 comme pool.ntp.org sont optimaux
- SNTP — une version simplifiée de NTP pour l’IoT et Android, sans filtrage ni PLL ; une précision de 10–100 ms suffit pour la plupart des scénarios
- Implémentation dans Android — via Apache Commons Net (NTPUDPClient) ou API REST avec horodatage du serveur ; il n’existe pas de client NTP public intégré sur la plateforme
- Sécurité — NTPv4 prend en charge Network Time Security (NTS) pour la protection contre l’usurpation de réponses ; critique pour les applications financières et d’entreprise
- Facteurs de précision — RTT, gigue, changement de réseau ; les applications mobiles ont besoin de 10–50 ms de précision, mais les opérations critiques nécessitent une vérification de l’écart avec le serveur
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi