En 2005, des travaux ont commencé pour modifier la norme IEEE1588-2002 afin d'élargir les domaines possibles de son application (télécommunications, communications sans fil, etc.). Le résultat a été une nouvelle édition de la norme IEEE1588-2008, disponible depuis mars 2008 avec les nouvelles fonctionnalités suivantes :

• Algorithmes avancés pour garantir une précision à la nanoseconde.
• Performances de synchronisation de l'heure améliorées (une transmission plus fréquente des messages de synchronisation est possible).
• Prise en charge de nouveaux types de messages.
• Introduction d'un principe de fonctionnement monomode (pas besoin d'envoyer des messages FollowUp).
• Prise en charge de la soi-disant fonction horloges transparentes pour empêcher l'accumulation d'erreurs de mesure dans un schéma de connexion en cascade de commutateurs.
• Entrez des profils qui définissent les paramètres des nouvelles applications.
• Possibilité d'affectation à des mécanismes de transport tels que DeviceNet, PROFInet et IEEE802.3/Ethernet (affectation directe).
• Introduction d'une structure TLV (type, longueur, valeur) pour élargir la portée possible de la norme et répondre aux besoins futurs.
• Présentation d’extensions facultatives supplémentaires à la norme.

Le principe de fonctionnement des systèmes basés sur le protocole PTP

Dans les systèmes utilisant le protocole PTP, il existe deux types d'horloges : l'horloge maître et l'horloge esclave. L'horloge maître est idéalement contrôlée par une horloge radio ou un récepteur GPS et synchronise l'horloge esclave. L'horloge de l'appareil final, qu'il soit maître ou esclave, est considérée comme une horloge normale ; les horloges incluses dans les périphériques réseau qui remplissent la fonction de transmission et de routage des données (par exemple, dans les commutateurs Ethernet) sont considérées comme des horloges limites.

Riz. 1. Selon le protocole PTP, la synchronisation temporelle des appareils est effectuée sur la base du schéma « maître-esclave ».

La procédure de synchronisation selon le protocole PTP est divisée en deux étapes. Dans un premier temps, la différence de temps entre les horloges maître et esclave est corrigée, c'est-à-dire que la correction dite du décalage temporel est effectuée. Pour ce faire, l'appareil maître transmet un message dans le but de synchroniser l'heure de Sync à l'appareil esclave (type de message Sync). Le message contient l'heure actuelle de l'horloge mère et est transmis périodiquement à intervalles de temps fixes.

Cependant, comme la lecture de l'horloge mère, le traitement des données et leur transmission via le contrôleur Ethernet prennent un certain temps, les informations contenues dans le message transmis ne sont plus pertinentes au moment où elles sont reçues. Dans le même temps, l'instant auquel le message Sync quitte l'expéditeur, qui comprend l'horloge mère (TM1), est enregistré aussi précisément que possible. L'appareil maître transmet ensuite le timing enregistré du message Sync aux appareils esclaves (message de suivi). Ils mesurent également aussi précisément que possible le moment où le premier message a été reçu (TS1) et calculent la valeur par laquelle il est nécessaire de corriger la différence de temps entre eux et l'appareil maître, respectivement (O) (voir Fig. 1 et Fig.2). Ensuite, les lectures d'horloge dans les appareils esclaves sont directement corrigées par la valeur de décalage. S'il n'y avait aucun retard dans la transmission des messages sur le réseau, on peut alors dire que les appareils sont synchronisés dans le temps.

Riz. 3. Calcul du temps de retard des messages dans les commutateurs.

Le délai de transmission d'un message dans les deux sens sera identique si les appareils sont connectés les uns aux autres via une seule ligne de communication et rien de plus. S'il existe des commutateurs ou des routeurs dans le réseau entre les appareils, il n'y aura pas de retard symétrique dans la transmission des messages entre les appareils, car les commutateurs du réseau stockent les paquets de données qui les traversent et un certain ordre de leur transmission est mis en œuvre. Cette fonctionnalité peut, dans certains cas, affecter de manière significative le délai de transmission des messages (des différences significatives dans les délais de transmission des données sont possibles). Lorsque la charge d'informations sur le réseau est faible, cet effet a peu d'impact, mais lorsque la charge d'informations est élevée, cela peut affecter considérablement la précision de la synchronisation temporelle. Pour éliminer les erreurs importantes, une méthode spéciale a été proposée et le concept d'horloges limites a été introduit, qui sont implémentés dans le cadre des commutateurs réseau. Cette horloge limite est synchronisée dans le temps avec l'horloge maître. De plus, le commutateur sur chaque port est le périphérique maître pour tous les périphériques esclaves connectés à ses ports, dans lesquels la synchronisation d'horloge correspondante est effectuée. Ainsi, la synchronisation s'effectue toujours selon un schéma point à point et se caractérise par quasiment le même délai de transmission des messages dans le sens aller et retour, ainsi que la valeur pratiquement inchangée de ce délai d'une transmission de message à l'autre. .

Bien que le principe basé sur l'utilisation d'horloges limites ait montré son efficacité pratique, un autre mécanisme a été défini dans la deuxième version du protocole PTPv2 - le mécanisme d'utilisation de ce qu'on appelle. montre transparente. Ce mécanisme empêche l'accumulation d'erreurs causées par des changements dans l'ampleur des retards dans la transmission des messages de synchronisation par les commutateurs et empêche une diminution de la précision de synchronisation dans le cas d'un réseau avec un grand nombre de commutateurs en cascade. Lors de l'utilisation de ce mécanisme, la transmission des messages de synchronisation s'effectue du maître vers l'esclave, au même titre que la transmission de tout autre message sur le réseau. Cependant, lorsque le message de synchronisation transite par le commutateur, un retard dans sa transmission par le commutateur est enregistré. Le retard est enregistré dans un champ de correction spécial dans le cadre du premier message Sync ou dans le cadre du message FollowUp suivant (voir Fig. 2). Lors de la transmission des messages Delay Request et Delay Response, leur temps de retard dans le commutateur est également enregistré. Ainsi, la mise en œuvre du soutien à ce qu'on appelle. les horloges transparentes incluses dans les commutateurs permettent de compenser les retards qui se produisent directement dans ceux-ci.

Implémentation du protocole PTP

Si PTP est requis sur un système, une pile de protocoles PTP doit être implémentée. Cela peut être fait sous réserve d'exigences minimales en matière de performances des processeurs de l'appareil et de bande passante du réseau. Ceci est très important pour implémenter la pile de protocoles dans des appareils simples et bon marché. Le protocole PTP peut être facilement implémenté même dans des systèmes construits sur des contrôleurs bon marché (32 bits).
La seule condition à remplir pour garantir une précision de synchronisation élevée est que les appareils mesurent aussi précisément que possible le moment auquel le message est transmis et le moment où le message est reçu. La mesure doit être effectuée aussi près que possible du matériel (par exemple directement dans le pilote) et avec la plus grande précision possible. Dans les implémentations uniquement logicielles, l'architecture et les performances du système limitent directement la précision maximale autorisée.

En utilisant une prise en charge matérielle supplémentaire pour l'horodatage, la précision peut être considérablement améliorée et peut être rendue pratiquement indépendante du logiciel. Cela nécessite l'utilisation d'une logique supplémentaire, qui peut être implémentée dans un circuit intégré à logique programmable ou un circuit intégré spécialisé pour résoudre une tâche spécifique à l'entrée du réseau.

conclusions

Le protocole PTP a déjà prouvé son efficacité dans de nombreux domaines. Vous pouvez être sûr qu’elle se généralisera dans les années à venir et que de nombreuses solutions qui l’utilisent pourront être mises en œuvre plus simplement et plus efficacement qu’en utilisant d’autres technologies.

Équipement KYLAND prenant en charge IEEE 1588v2

Envoyer votre bon travail dans la base de connaissances est simple. Utilisez le formulaire ci-dessous

Les étudiants, étudiants diplômés, jeunes scientifiques qui utilisent la base de connaissances dans leurs études et leur travail vous seront très reconnaissants.

Publié sur http://www.allbest.ru/

Ministère de l'Éducation et des Sciences de la Fédération de Russie

Établissement d'enseignement autonome de l'État fédéral

Formation professionnelle supérieure

"Université Nationale de Recherche Nucléaire "MEPhI"

Institut technologique de Trekhgorny - branche de l'Université nationale de recherche nucléaire MEPhI

Département informatique

dans la discipline "Technologies Internet"

sur le thème : « Protocole RSYNC. Synchronisation de l'heure. Protocole NTP. Protocole SNTP"

Complété par : étudiant du groupe 5VT-58

Koltsov D.A.

Vérifié : Art. Tour. Dolgopolova M.O.

Trekhgorny 2012

PROTOCOLE RSYNC

SYNCHRONISATION DU TEMPS

PROTOCOLE NTP

PROTOCOLE SNTP

LISTE DES SOURCES INTERNET UTILISÉES

APPLICATIONS

PROTOCOLE RSYNC

R.synchroniser(eng. Remote Synchronization) est un programme pour les systèmes de type UNIX qui synchronise les fichiers et les répertoires à deux endroits tout en minimisant le trafic, en utilisant le codage des données si nécessaire. Une différence importante entre rsync et de nombreux autres programmes/protocoles est que la mise en miroir est effectuée par un thread dans chaque direction (plutôt qu'un ou plusieurs threads par fichier). Rsync peut copier ou afficher le contenu d'un répertoire et copier des fichiers, éventuellement en utilisant la compression et la récursivité.

Développeur- Wayne Davison ;

salle d'opérationsystème- Logiciel multiplateforme.

Publié sous licence GNU GPL, rsync est un logiciel libre.

Multiplateforme(multiplateforme)logicielsécurité-- logiciel qui s'exécute sur plusieurs plates-formes matérielles et/ou systèmes d'exploitation. Un exemple typique est un logiciel conçu pour fonctionner simultanément sur les systèmes d’exploitation Linux et Windows.

Il existe une implémentation de rsync pour Winows, ou plutôt pas une implémentation directe, mais un assemblage de rsync et cygwin, appelé cwRsync.

Algorithme

Utilitaire rsync utilise un algorithme développé par le programmeur australien Andrew Tridgell (Annexe C) pour transférer efficacement des structures (telles que des fichiers) entre des connexions de communication lorsque l'ordinateur récepteur possède déjà une version différente de cette structure.

L'ordinateur récepteur divise sa copie du fichier en morceaux ne se chevauchant pas d'une taille fixe S et calcule une somme de contrôle pour chaque morceau : un hachage MD4 (Annexe A) et une somme de contrôle mobile plus faible (Annexe B), et les envoie à l'ordinateur destinataire. serveur avec lequel il est synchronisé.

Le serveur synchronisé calcule les sommes de contrôle pour chaque morceau de taille S dans sa version du fichier, y compris les morceaux qui se chevauchent. Cela peut être calculé efficacement grâce à la propriété spéciale de la somme de contrôle glissante : si la somme de contrôle glissante des octets n à n+S-1 est égale à R, alors la somme de contrôle glissante des octets n+1 à n+S peut être calculée à partir de R, l'octet n et l'octet n. +S sans avoir à prendre en compte les octets se trouvant à l'intérieur de cet intervalle. Ainsi, si la somme de contrôle glissante des octets 1 à 25 a déjà été calculée, alors la somme de contrôle précédente et les octets 1 et 26 sont utilisés pour calculer la somme de contrôle glissante des octets 2 à 26.

Basique avantages

Vitesse: Initialement, rsync réplique tout le contenu entre la source et la destination (récepteur). Ensuite, rsync transfère uniquement les blocs ou bits modifiés vers la destination, ce qui rend la synchronisation très rapide ;

Sécurité: rsync inclut le cryptage des données en transit à l'aide du protocole SSH ;

rsync compresse et décompresse les données bloc par bloc respectivement du côté envoi et réception. Ainsi, la bande passante utilisée par rsync est inférieure à celle des autres protocoles de transfert de fichiers.

Syntaxe

$ Destination source des options rsync, où la source et la destination peuvent être locales ou distantes. Lorsqu'il est utilisé avec des objets distants, spécifie la connexion, le nom du serveur et le chemin.

Quelques options importantes :

1) -un,--archive mode archives ;

2) -r,--récursif parcourir des répertoires (récursion);

3) -R,--relatif chemins relatifs ;

4) -H,--liens durs enregistrer les liens physiques ;

5) -S,--clairsemé gérer efficacement les fichiers clairsemés ;

6) -X,--un-système-de-fichiers ne franchissez pas les limites du système de fichiers ;

7) -exclure=MODÈLE exclure les fichiers d'un échantillon donné ;

8) -supprimer-pendant le récepteur est retiré LORS DE LA TRANSMISSION ;

9) -supprimer-après le récepteur est retiré APRÈS LA TRANSMISSION.

SYNCHRONISATION DU TEMPS

Le temps à l'ère des technologies de l'information a acquis une importance particulière pour l'homme moderne. Chacun de nous regarde sa montre au moins plusieurs fois par jour. De nombreuses personnes synchronisent régulièrement leurs appareils de reporting horaire via diverses sources, notamment Internet. L'heure précise joue parfois un rôle décisif dans des domaines où même les minutes ne sont pas importantes, mais les secondes. Par exemple, négocier en bourse peut entraîner la ruine d'un joueur dont la montre indique la mauvaise heure.

Technologie synchronisation temps

Tous le processus de synchronisation de l'heure est effectué via un protocole réseau spécial appelé NTP(RéseauTempsprotocole). Ce protocole est un ensemble de diverses règles et algorithmes mathématiques, grâce auxquels l'heure de votre ordinateur est ajustée avec précision avec un écart de quelques centièmes de seconde. Il existe également un protocole pour les systèmes qui ne nécessitent pas une synchronisation aussi précise, appelé SNTP. La différence entre la source et l'appareil récepteur peut aller jusqu'à 1 seconde.

La technologie permettant de transmettre des paramètres temporels précis est une structure multicouche, dans laquelle chaque couche sous-jacente de dispositifs électroniques est synchronisée avec la couche sous-jacente. Plus la couche technologique est basse, moins l’heure obtenue sera précise. Mais c'est en théorie, en pratique, tout dépend de nombreux paramètres impliqués dans le système de synchronisation et une heure plus précise peut être obtenue, par exemple, à partir de la quatrième couche d'appareils qu'à partir de la troisième.

Au niveau zéro de cette chaîne de transmission se trouvent toujours des appareils de mesure du temps, en gros des horloges. Ces horloges sont des dispositifs de chronométrage moléculaires, atomiques ou quantiques et sont appelées horloges de référence. De tels appareils ne transmettent pas les paramètres temporels directement à Internet ; ils sont généralement connectés à l'ordinateur principal via une interface haut débit avec des délais minimes. Ce sont ces ordinateurs qui constituent le premier maillon de la chaîne technologique. Sur la deuxième couche se trouveront des machines qui recevront l'heure des appareils de la première couche via une connexion réseau, le plus souvent via Internet. Toutes les couches suivantes recevront des informations sur l'heure exacte en utilisant les mêmes protocoles réseau des couches sus-jacentes.

Systèmes synchronisation temps

DANS conformément à la loi fédérale « sur les communications » n° 126 du 7 juillet 2003, article 49 - « Temps de comptabilisation et de déclaration dans le domaine des communications », dans les processus technologiques de transmission et de réception de messages de télécommunication et postaux, leur traitement dans sur le territoire de la Fédération de Russie, les opérateurs de télécommunications et les opérateurs postaux devraient utiliser un seul délai de comptabilité et de déclaration - Moscou." Pour ce faire, il est nécessaire d'organiser un système horaire précis sur le réseau numérique de l'opérateur de télécommunication.

Un système horaire précis est un ensemble de moyens techniques qui assurent la transmission périodique d'informations numériques sur la valeur de l'heure actuelle depuis une source de référence vers tous les éléments du réseau afin de synchroniser leurs horloges internes. Ceci s'applique aux équipements numériques des réseaux de télécommunication, dans lesquels diverses données sont traitées en temps réel et où l'exécution simultanée de certains processus technologiques internes doit être assurée.

La pertinence de résoudre le problème de l'organisation d'un système de synchronisation pour une heure précise unique, ou, en d'autres termes, d'organiser la synchronisation horaire, dans les réseaux de télécommunication est inextricablement liée au développement des systèmes de facturation, des systèmes de contrôle à des fins diverses, de la sécurité des réseaux, de l'informatique systèmes, ainsi que l'amélioration des méthodes d'exploitation des équipements de télécommunications numériques et du support métrologique .

Les consommateurs de signaux horaires précis et uniformes sont : les systèmes informatiques et les serveurs informatiques (systèmes de gestion et de surveillance des équipements de réseau), les équipements pour les réseaux de transport SDH, ATM, IP et les réseaux de commutation, les serveurs de facturation et de bases de données ; équipements de transmission de données et de commutation de paquets (routeurs, commutateurs), etc.

L'utilisation de la synchronisation temporelle vous permet de synchroniser les heures de début et de fin de tout processus dans le réseau d'un ou de différents opérateurs de télécommunications, par exemple lors de la localisation d'un accident à l'aide du diagnostic interne de l'équipement et de la création d'une entrée de journal sur l'événement survenu sur le serveur dans le système de contrôle, connectant les conversations des abonnés, tarification du trafic d'informations en fonction de l'heure de la journée et de la localisation de l'abonné dans la zone de service d'un réseau particulier, et enfin, exécution des procédures liées à la confirmation de la réception/ transfert d'une signature électronique, réalisation de transactions, etc.

Les travaux visant à créer un système horaire précis comprennent :

* sélection de la source de signal horaire exacte ;

* détermination de la méthode de transmission de signaux horaires précis sur un réseau de communication ;

* sélection de protocoles réseau et de signaux horaires précis ;

* identification des équipements nécessitant une synchronisation horaire ;

* sélection d'options de solutions pour fournir à différents types d'équipements des signaux horaires précis.

Parmi les moyens de transmission de signaux horaires de haute précision et les plus abordables qui ne nécessitent pas de location de lignes de communication existantes ou de construction de lignes de communication supplémentaires, on peut à juste titre inclure les systèmes mondiaux de navigation par satellite (GNSS) : russe GLONASS et américain GPS. La globalité des systèmes est assurée par le fonctionnement en orbite d'un ensemble de satellites visibles de n'importe où sur la Terre, transmettant en continu des signaux de haute précision pouvant être utilisés dans un système horaire précis.

Actuellement, par exemple, le système satellite GPS peut être utilisé pour synchroniser les équipements des réseaux de télécommunication des opérateurs de télécommunications russes uniquement en deuxième priorité, il est donc nécessaire d'utiliser un système satellite comme source principale de signaux horaires précis GLONASS.

Pour obtenir une échelle de temps des systèmes satellitaires, il est nécessaire d'utiliser un équipement spécial contenant des récepteurs de signaux GLONASS Et GPS. Cet équipement spécialisé est appelé serveur de temps ( TempsServeur). Lors de la transmission des signaux horaires du serveur aux clients du réseau distant, des protocoles Internet spéciaux sont utilisés NTP(RéseauTempsprotocole) Et PTP(PrécisionTempsProtocole- IEEE1588). Basé sur des protocoles réseau, il est conseillé de construire un système horaire précis selon le principe de hiérarchie.

PROTOCOLE NTP

Le protocole NTP (Network Time Protocol) est utilisé par les serveurs NTP pour diffuser des informations sur une heure de référence exacte entre les abonnés du réseau. Il est également utilisé par les outils Internet pour assurer la synchronisation des ordinateurs et des processus.

NTP est utilisé comme protocole Internet depuis plus de 25 ans. Ce protocole est le protocole Internet le plus utilisé. Il est né de la nécessité de synchroniser le temps et les processus sur Internet. Le protocole NTP a d'abord été utilisé sur les plates-formes LINUX et UNIX, notamment FreeBSD (une version non commerciale d'UNIX pour PC), mais a ensuite été utilisé sur le système d'exploitation Windows. Les systèmes NTP spéciaux utilisent principalement le système d'exploitation LINUX.

De plus, en plus du protocole NTP, il existe le SNTP (Simple Network Time Protocol). Au niveau des paquets, les deux protocoles sont entièrement compatibles. La principale différence entre eux est que SNTP ne dispose pas des systèmes de filtrage complexes ni de correction d'erreurs en plusieurs étapes que l'on trouve dans NTP. Ainsi, SNTP est une version simplifiée et plus facile à mettre en œuvre de NTP. Il est destiné à être utilisé dans des réseaux où une précision temporelle très élevée n'est pas requise, et dans la mise en œuvre de Microsoft, il fournit une précision dans les 20 secondes au sein d'une entreprise et pas plus de 2 secondes dans un seul site. Le protocole SNTP est normalisé sous les noms RFC 1769 (version 3) et RFC 2030 (version 4).

Basique des principes protocole NTP

Protocole NTP a été créé pour fournir aux utilisateurs du réseau trois paramètres :

1) définition d'un échec standard de temps ;

2) réglage d'un cycle complet de temporisation ;

3) régler la répartition des paramètres par rapport à des horloges de référence spécialisées.

L'échec de la référence temporelle est la différence de temps entre l'horloge locale et l'horloge de référence. Un cycle complet de latence correspond au temps nécessaire au protocole pour recevoir une réponse du serveur. L'étalement des paramètres est l'erreur maximale de l'horloge locale par rapport à l'étalon.

messages protocole NTP

Protocole NTP utilise UDP (User Datagram Protocol) Un message NTP se compose de plusieurs champs :

1) Indicateur de saut ;

2) Numéro de version ;

6) Précision ;

7) Défaut dans le système racinaire ;

8) Variation des paramètres ;

9) Identifiant standard ;

10) Date de création ;

11) Horodatage de réception ;

12) Horodatage du transfert ;

13) Reconnaissance des codes ;

14) Résumé du message.

L'indicateur de saut avertit d'un pic de sommation ou de suppression imminent.

Le numéro de version affiche le numéro de version NTP utilisé.

Mode permet de définir le mode du message NTP actuel.

Decomposer est un système 8 bits qui identifie le niveau hiérarchique de l'horloge de référence.

Poll définit l'intervalle maximum entre les messages.

La précision établit la fidélité de l'horloge locale.

L'erreur racine indique l'erreur de référence temporelle nominale.

L'identifiant du standard est un code ASCII à 4 caractères qui identifie la source du standard, par exemple : GPS, DCF, MSF. Le champ Code Identifiant est utilisé lorsqu'il est nécessaire d'établir la validité du code.

La date de création du modèle définit l'heure à laquelle la requête NTP de l'utilisateur a été envoyée au serveur NTP.

L'horodatage reçu indique l'heure à laquelle la demande a été reçue par le serveur NTP.

L'horodatage de transmission indique l'heure à laquelle le message de réponse du serveur NTP a été transmis à l'utilisateur.

Le champ digest stocke le code d'authentification du message MAC (Message Authentication Code).

Modes travail NTP les serveurs

NTP le serveur peut fonctionner selon trois modes :

Dans les deux premiers modes, l'utilisateur envoie une requête NTP au serveur. Le serveur répond avec un message que l'utilisateur utilise pour synchroniser l'heure NTP. En mode multidiffusion, les messages NTP sont envoyés périodiquement à des intervalles de temps spécifiés.

Horloge de référence

Pour synchroniser l'heure des serveurs NTP, diverses sources externes d'heure précise peuvent être utilisées. Le GPS est très souvent utilisé pour garantir la précision du temps. Il existe également diverses sources gouvernementales de temps de référence, telles que les émissions de radio. De nombreuses stations de radio diffusent non seulement sur le territoire de leurs États, mais également à l'étranger, vous pouvez donc facilement régler l'heure en les utilisant.

PROTOCOLE SNTP

fichier de synchronisation du programme de protocole

SNTP(Anglais : Simple Network Time Protocol) - protocole de synchronisation de l'heure sur un réseau informatique. Il s'agit d'une implémentation simplifiée du protocole NTP. Utilisé dans les systèmes et appareils embarqués qui ne nécessitent pas une haute précision, ainsi que dans les programmes horaires personnalisés. Le protocole SNTP utilise le même format d'heure que le protocole NTP : un nombre de 64 bits composé d'un compteur de secondes de 32 bits et d'un compteur de fractions de secondes de 32 bits. Une valeur nulle du compteur horaire correspond à zéro heure le 1er janvier 1900, 6 heures 28 minutes 16 du 7 février 2036, etc. Pour le bon fonctionnement du protocole, il est nécessaire que le client connaisse son heure à ±34 près. années par rapport au temps du serveur.

Format messages

Figure 1 - Format des messages

Description des champs du format de message SNTP présenté dans la figure 1 :

L'indicateur de correction (IC) affiche un avertissement concernant une future insertion ou suppression d'une seconde dans la dernière minute de la journée ;

Numéro de version (NV) – la valeur actuelle est 4 ;

Polling Interval est un entier non signé dont l'exposant binaire représente l'intervalle maximum entre des messages consécutifs en secondes. Défini uniquement pour les messages du serveur, valeurs valides de 4 (16 s) à 17 (environ 36 h) ;

La précision est un entier signé dont l'exposant binaire représente la précision de l'horloge système. Définies uniquement pour les messages du serveur, les valeurs typiques vont de ?6 à ?20 ;

La latence est un nombre signé avec un point fixe, situé entre 15 et 16 chiffres, indiquant le temps total nécessaire au signal pour se propager vers la source de synchronisation du serveur de temps. Défini uniquement pour les messages du serveur ;

La variance est un nombre à virgule fixe non signé compris entre 15 et 16 chiffres indiquant l'erreur maximale due à l'instabilité de l'horloge. Défini uniquement pour les messages du serveur ;

ID source : source de synchronisation du serveur, chaîne pour les strates 0 et 1, adresse IP pour les serveurs secondaires. Défini uniquement pour les messages du serveur ;

Heure de mise à jour : heure à laquelle l'horloge du système a été réglée ou ajustée pour la dernière fois ;

Clé d'identification, résumé du message - champs facultatifs utilisés pour l'authentification.

Opérations les serveurs SNTP

Serveur SNTP peut fonctionner en modes monodiffusion, monodiffusion ou multidiffusion, et peut également implémenter n'importe quelle combinaison de ces modes. En modes unicast et anycast, le serveur reçoit des requêtes (mode 3), modifie certains champs de l'en-tête NTP et envoie une réponse (mode 4), en utilisant éventuellement le même tampon de message que la requête. En mode monodiffusion, le serveur écoute une adresse de diffusion ou de multidiffusion spécifique définie par l'IANA, mais utilise sa propre adresse de monodiffusion dans le champ d'adresse source de la réponse. A l'exception du choix de l'adresse dans la réponse, le fonctionnement du serveur en modes unicast et unicast est identique. Les messages multicast sont généralement envoyés à des intervalles de 64 à 1 024 secondes, en fonction de la stabilité de l'horloge du client et de la précision requise.

En modes anycast et unicast, les champs VN et d'enregistrement (Poll) de la demande sont copiés sans modification de la réponse. Si le champ mode de requête contient le code 3 (client), il est mis à 4 (serveur) dans la réponse ; sinon, ce champ est écrit à 2 (passif symétrique) pour garantir la conformité à la spécification NTP. Cela permet aux clients configurés pour le mode actif symétrique (mode 1) de fonctionner correctement même si la configuration n'est pas optimale. En mode multicast sur le terrain VN on saisit le code 4, dans le champ mode code 5 (diffusion) et dans le champ d'enregistrement la partie entière est la valeur du logarithme base 2 de la durée de la période d'envoi de la requête.

En modes unicast et anycast, le serveur peut répondre ou ignorer les demandes, mais le comportement préféré est d'envoyer une réponse dans tous les cas, car cela permet de vérifier que le serveur est joignable.

L'indicateur le plus important de panne de serveur est le champ LI, où un code de 3 indique un manque de synchronisation. Lorsque cette valeur particulière est reçue, le client DOIT ignorer le message du serveur, quel que soit le contenu des autres champs.

Configuration Et contrôle

Original Les serveurs et clients SNTP peuvent être configurés à partir d'un fichier de configuration, si un tel fichier existe, ou via le port série. On suppose que les serveurs et clients SNTP nécessitent peu ou pas de configuration spécifique à l'hôte (au-delà d'une adresse IP, d'un masque de sous-réseau ou d'une adresse OSI NSAP).

Les clients uniques doivent recevoir le nom ou l'adresse du serveur. Si un nom de serveur est utilisé, une ou plusieurs adresses des serveurs DNS les plus proches sont requises.

Les serveurs de multidiffusion et les clients anycast doivent recevoir une valeur TTL, ainsi qu'une adresse de diffusion locale ou de multidiffusion multidiffusion. Les serveurs Anycast et les clients multicast peuvent être configurés à l'aide de listes de paires adresse-masque. Cela fournit un contrôle d'accès afin que les transactions n'aient lieu qu'avec des clients ou des serveurs connus. Ces serveurs et clients doivent prendre en charge le protocole IGMP et connaître également l'adresse de diffusion ou de multidiffusion locale.

LISTE DES SOURCES INTERNET UTILISÉES

1) https://ru.wikipedia.org/wiki/Rsync ;

2) http://greendail.ru/node/487 ;

3) http://inetedu.ru/articles/19-services/70-synchronization-time.html ;

4) http://www.ptime.ru/exec_time.htm ;

5) http://www.tenderlib.ru/articles/56 ;

6) http://docstore.mik.ua/manuals/ru/inet_book/4/44/sntp4416.html ;

7) http://www.ixbt.com/mobile/review/billing.shtml.

APPLICATIONS

Annexe A

MD4(Message Digest 4) est une fonction de hachage développée par le professeur Ronald Rivest de l'Université du Massachusetts en 1990 et décrite pour la première fois dans la RFC 1186. Étant donné un message d'entrée arbitraire, la fonction génère une valeur de hachage de 128 bits appelée résumé de message. Cet algorithme est utilisé dans le protocole d'authentification MS-CHAP, développé par Microsoft pour effectuer des procédures d'authentification sur les postes de travail Windows distants. C'est le prédécesseur du MD5.

Figure A – Fonctionnement du MD4

Une opération MD4 (Figure A). Le hachage MD4 comprend 48 opérations de ce type, regroupées en 3 séries de 16 opérations. F -- fonction non linéaire ; à chaque tour, la fonction change. M i désigne le bloc de message d'entrée de 32 bits, et K i est une constante de 32 bits, différente pour chaque opération.

Appendice B

Somme de contrôle glissante

Annulairehacher hachage roulant - une fonction de hachage qui traite les entrées dans une certaine fenêtre. Obtenir la valeur de hachage pour la fenêtre décalée dans de telles fonctions est une opération peu coûteuse. Pour recalculer la valeur, il vous suffit de connaître la valeur de hachage précédente ; la valeur des données d'entrée restées en dehors de la fenêtre ; et la signification des données qui sont entrées dans la fenêtre. Le processus est similaire au calcul de la moyenne mobile.

Utilisé dans l'algorithme de recherche de sous-chaînes Rabin-Karp, ainsi que dans le programme rsync pour comparer les fichiers binaires (la version en anneau d'adler-32 est utilisée).

Annexe C

Andrew Tridgell

André"Tridge"Tridgell(28 février 1967) -- Programmeur australien, connu comme auteur et contributeur du projet Samba et co-créateur de l'algorithme rsync. Il est également connu pour son travail d'analyse de protocoles et d'algorithmes propriétaires complexes, conduisant à la création d'implémentations libres interopérables. Gagnant du Free Software Award 2005.

GratuitLogicielPrix-- Prix annuel de la FSF pour les contributions au logiciel libre, créé en 1998.

Figure C – Andrew Tridgell

Publié sur Allbest.ru

Documents similaires

Analyse des principales attaques sur le protocole TLS et identification des méthodes pour contrer ces attaques. Développement d'une méthode d'interception et de décryptage du trafic transmis via le protocole HTTPS. Décryptage des données transmises en temps quasi réel.

article, ajouté le 21/09/2017


Création du système d'exploitation UNIX. Historique de la création et du développement des protocoles TCP/IP. Protocole de transport. Un canal de communication logique entre l'appareil et la sortie des données sans établir de connexion. Protocole d'interaction avec un serveur de noms de domaine.

test, ajouté le 18/05/2009


Types de cas d'unités système. Topologies de réseau de base : bus, anneau, étoile, arbre. FTP est un protocole conçu pour transférer des fichiers sur des réseaux informatiques. Classement des logiciels. Systèmes de recherche d'informations et leur classification.

test, ajouté le 24/12/2010


Définition d'un protocole IP qui transfère des paquets entre réseaux sans établir de connexions. Structure d'en-tête de paquet IP. Initialisation d'une connexion TCP, ses étapes. Implémentation de l'IP sur le routeur. Protocole pour la livraison fiable des messages TCP, ses segments.

test, ajouté le 09/11/2014


Le concept du protocole Secure Sockets Layer. "Canal sécurisé", propriétés de base. Utilisation du protocole, ses inconvénients. Interface du programme EtherSnoop. Phases du protocole de dialogue. Clés publiques, fonctionnalités de distribution. Échange de données sur Internet.

résumé, ajouté le 31/10/2013


Informations générales sur le protocole de transfert de données FTP. Processus techniques pour établir une connexion via le protocole FTP. Logiciel permettant d'établir des connexions via le protocole FTP. Quelques problèmes avec les serveurs FTP. Commandes du protocole FTP.

résumé, ajouté le 11/07/2008


Description et objectif du protocole DNS. Utilisation du fichier hôte Caractéristiques et description des méthodes d'attaques sur DNS : faux serveur DNS, simple inondation DNS, phishing, attaque via requêtes DNS réfléchies. Protection et lutte contre les attaques sur le protocole DNS.

résumé, ajouté le 15/12/2014


Développement d'un programme serveur permettant de surveiller à distance un ordinateur sous Linux. Conditions nécessaires pour résoudre ce problème : protocoles de transfert de données utilisés, logiciels, bibliothèques dynamiques.

travail de cours, ajouté le 18/06/2009


Description des principaux types de stations du protocole HDLC. Modes de fonctionnement normal, asynchrone et équilibré de la station en état de transmission d'informations. Méthodes de contrôle des flux de données. Format et contenu des champs d'information et de contrôle du protocole HDLC.

travaux de laboratoire, ajouté le 10/02/2013


La fonction du protocole et la structure du package du protocole en cours de développement. Longueur des champs d'en-tête. Calcul de la longueur du tampon de réception en fonction de la longueur du paquet et du délai acceptable. Algorithmes de traitement des données en réception et en transmission. Implémentation logicielle du protocole.

les technologies

S.Telegin

Protocole PTP pour la synchronisation des réseaux NGN

problèmes d'application

DANS L'article aborde le problème de la synchronisation des réseaux de données de nouvelle génération (NGN). DANS

Comme méthode alternative de transfert de synchronisation, l'auteur suggère d'utiliser le protocole PTP. Les caractéristiques des systèmes de synchronisation basés sur le protocole PTP (IEEE 1588) sont présentées en comparaison avec les systèmes utilisant le bus PXI, ainsi qu'avec le protocole NTP.

Problème de synchronisation dans les réseaux NGN

Le développement des technologies de télécommunications et des réseaux de données conduit progressivement à la construction par les opérateurs télécoms de réseaux convergés de nouvelle génération (NGN – Next Generation Networks). La principale différence entre ces réseaux et les réseaux traditionnels dotés d'une hiérarchie numérique synchrone (SDH) est que pour la transmission de données de base, ainsi que les canaux synchrones conventionnels, ils utilisent des technologies asynchrones telles qu'Ethernet (Gigabit Ethernet, 10Gigabit Ethernet). La principale exigence des opérateurs de télécommunications pour les réseaux de nouvelle génération est la transmission simultanée de la voix, de la vidéo et des données sur un seul réseau.

Lors du passage des réseaux de données traditionnels basés sur le multiplexage temporel aux réseaux NGN, une attention particulière est accordée à la transmission des signaux de synchronisation. La synchronisation des équipements est nécessaire avant tout pour une transmission sans erreur des données en temps réel – images vocales et vidéo. Étant donné que les réseaux Ethernet utilisent la commutation de paquets qui, en raison des propriétés statistiques de propagation des paquets de données sur des canaux de transmission asynchrones, détruit le flux de données initialement synchronisé, la transmission synchronisée dans les réseaux NGN est une tâche distincte. Pour transmettre des données synchrones sur des réseaux à commutation de paquets, on utilise généralement une émulation de canal avec multiplexage temporel, qui consiste à encapsuler les données synchrones dans des datagrammes UDP et à leur restauration ultérieure au nœud de destination.

	PREMIER mile 5-6/2009

Pour une récupération sans erreur des données transmises à la jonction des canaux asynchrones et synchrones, l'équipement doit également recevoir un signal d'horloge. Les exigences en matière de stabilité du signal d'horloge varient en fonction de l'objectif spécifique du réseau de données. Ainsi, dans les réseaux des opérateurs pour la fourniture de services de téléphonie et d'accès à Internet, les exigences de synchronisation sont assez douces - 50 ppm (unités par million), et dans les réseaux cellulaires, pour une transition transparente des abonnés mobiles d'une station de base à une autre, une stabilité de 50 ppb (unités par million) est requis. milliards).

Méthodes de synchronisation des réseaux NGN

La Recommandation UIT-T G.8261 traite de trois méthodes principales permettant de restaurer la synchronisation aux limites d'un environnement de transport à commutation de paquets lors de la transmission d'un signal en bande de base multiplexé dans le temps sous la forme d'un service d'émulation de canal. Pour y parvenir, l’équipement de la station terminale doit disposer de capacités de mise en réseau. Tous les abonnés de l'environnement de transport à commutation de paquets peuvent recevoir la fréquence d'horloge du réseau de synchronisation via la distribution centralisée habituelle (Fig. 1). Si l'équipement de l'abonné fonctionne à sa propre fréquence d'horloge (Fig. 2), alors à la périphérie du réseau de commutation de paquets, il est restauré de diverses manières relatives, par exemple en utilisant l'algorithme d'adaptation de débit SRTS. Dans les deux cas, le nœud passerelle doit avoir accès à l'interface avec le générateur de synchronisation principal.

les technologies

(RPC). Pour ce faire, l'opérateur du réseau NGN doit soit construire un réseau de synchronisation distinct, soit le louer auprès des opérateurs de réseau de transport SDH existants.

Il existe de nombreux exemples de synchronisation matérielle locale. Par exemple, une source de synchronisation primaire (PRS) basée sur GPS peu coûteuse est placée dans la salle de la station et la fréquence d'horloge est distribuée à partir de celle-ci à l'aide de technologies sans fil ou via des câbles dédiés conventionnels, dans l'environnement physique Ethernet, ainsi qu'en utilisant d'autres circuits originaux. . Si la construction d'un réseau de synchronisation (ou l'utilisation de joints de synchronisation) est impossible ou indésirable, alors la méthode adaptative la plus simple, mais problématique pour des raisons de stabilité, pour faire correspondre les vitesses de réception et de transmission est utilisée (Fig. 3).

Les résultats de la recherche montrent que la méthode adaptative peut être utilisée si l'abonné n'a pas d'exigences strictes en matière de stabilité de sa fréquence d'horloge, sinon un lissage matériel supplémentaire du signal d'horloge récupéré est nécessaire. Une alternative à la méthode adaptative est l'utilisation du protocole RTP lors de l'encapsulation de données avec multiplexage temporel dans des paquets de données asynchrones (Fig. 4). Comme l'expérience l'a montré, dans ce cas, avec une grande stabilité du signal d'horloge restitué, l'équipement s'avère faiblement sensible aux changements de fréquence au niveau de la source de synchronisation, ce qui est nécessaire, par exemple, dans les réseaux cellulaires lors du passage à un signal d'horloge de secours.

protocole PTP

Apparemment, la prochaine étape de développement sera une transmission séparée de signaux de synchronisation de réseau avec commutation de paquets.

en utilisant des protocoles spécialement développés (Fig. 5). Pour le moment, il s'agit des protocoles NTP et PTP. Ces protocoles ont été créés à l'origine pour synchroniser l'heure sur différents appareils d'un réseau, mais si la synchronisation de l'horloge réussit, il est également possible de mettre en œuvre des algorithmes de synchronisation d'horloge pour récupérer des données en temps réel. NTP (Network Time Protocol) est largement utilisé pour synchroniser l'heure actuelle au niveau de l'application. En revanche, le Precision Time Protocol (PTP) fonctionne au niveau de la deuxième couche du modèle Open Systems Interconnection (OSI). Le protocole RTP est décrit dans la norme IEEE 1588. Il est prévu qu'à l'avenir, RTP puisse être utilisé à la fois pour une synchronisation de haute précision de l'heure actuelle et pour la synchronisation d'horloge des équipements. Examinons ce protocole plus en détail.

La norme IEEE 1588 suppose que le protocole PTP fournit une méthode standard pour synchroniser les appareils sur un réseau avec une précision meilleure que 1 µs (jusqu'à 10 ns). Ce protocole garantit que les appareils esclaves sont synchronisés à partir du maître en garantissant que les événements et les horodatages sur tous les appareils utilisent la même base de temps. Le protocole prévoit deux étapes pour synchroniser les appareils : déterminer

Riz. 3 Synchronisation adaptative

Figure 4	Transfert de synchronisation à l'aide de RTP
Figure 5	Transfert de synchronisation à l'aide de PTP

PREMIER mile 5-6/2009

Riz. 6 Algorithme de fonctionnement PTP

contrôle du dispositif maître (1) et correction du décalage horaire provoqué par le décalage d'horloge dans chaque dispositif et les retards dans la transmission des données sur le réseau (2). Lors de l'initialisation du système, PTP utilise un algorithme de « meilleure horloge maître » pour déterminer la source d'horloge la plus précise sur le réseau. Un tel appareil devient le maître et tous les autres appareils du réseau deviennent des esclaves et ajustent leurs horloges sur l'appareil maître.

La différence de temps entre les appareils maître et esclave est une combinaison du décalage d'horloge et du délai de transmission du message de synchronisation. Par conséquent, la correction du décalage temporel doit être effectuée en deux étapes : calculer les délais de transmission et de décalage, puis les corriger. Considérons la séquence de synchronisation des horloges de deux appareils (Fig. 6).

Le maître commence à corriger le décalage d'horloge à l'aide des messages de synchronisation et de suivi. Le message de suivi spécifie l'heure à laquelle le message de synchronisation (TM1) a été envoyé, mesurée la plus proche du support de transmission pour minimiser l'erreur de synchronisation de la source de référence. Une fois que l'appareil esclave a reçu les premiers messages de synchronisation et de suivi, il utilise son horloge pour marquer l'heure d'arrivée du message de synchronisation (TS1) et compare cet horodatage avec celui reçu du périphérique maître dans le message de suivi. La différence entre ces deux marques reflète le décalage d'horloge T0 plus le délai de transmission du message du maître vers l'esclave ∆TMS : TS1 – TM1 = T0 + ∆TMS.

Pour calculer le temps de retard du message et le décalage d'horloge, le périphérique esclave envoie un message Delay_request avec son heure TS2. Le maître note l'arrivée de ce message et répond par un message Delay_response avec une balise TM2. La différence entre les deux marques est le délai de transmission de l'esclave au maître ∆TSM moins le décalage dans l'échantillon esclave : TM2  – TS2  = ∆TSM  – T0 .

Lors du calcul du délai de transmission des messages, on suppose que le délai moyen de transmission des données dans le canal est

sur la moyenne arithmétique des délais de propagation dans différentes directions du canal :

		TMS + TSM

Connaissant les instants TS1, TM1, TM2 et TS2, l'équipement esclave calcule le délai de propagation moyen dans le canal de données :

T = (TS1 - TM1) + (TM2 - TS2). 2

La synchronisation finale de l'horloge se produit après que le maître envoie le deuxième ensemble de messages Sync (TS3) et Follow-up (TM3). L'appareil esclave calcule son décalage d'horloge à l'aide de la formule T0 = TS3 – TM3 – ∆T.

L'esclave ajuste alors son horloge en fonction des valeurs calculées. Étant donné que les références d'horloge de chaque périphérique sont instables et que les retards des canaux peuvent varier dans le temps, il est nécessaire d'ajuster périodiquement l'horloge du périphérique esclave.

Caractéristiques de la mise en œuvre du protocole PTP

La plupart des implémentations PTP ont un écart inférieur à 1 µs, mais les performances réelles varient en fonction de l'application. Le protocole PTP dans les appareils est implémenté de trois manières : logiciel, micrologiciel et matériel. Les implémentations logicielles RTP permettent de transmettre des signaux de synchronisation avec une précision d'environ 100 μs. Pour obtenir une plus grande précision, du matériel doit être utilisé. Chaque composant qui traite un paquet PTP après sa réception du support physique augmente l'erreur de synchronisation. Le côté logiciel introduit le plus d'erreurs car la charge du processeur et la latence du traitement des interruptions affectent la vitesse à laquelle la demande de synchronisation est traitée.

Lorsqu'elles sont implémentées dans le matériel et le logiciel, les fonctions les plus sensibles du protocole, telles que l'enregistrement de l'horodatage d'un paquet PTP, sont implémentées au niveau de la couche physique Ethernet, par exemple dans une puce logique programmable distincte. De telles méthodes sont aujourd'hui les plus optimales, car elles ne nécessitent pas trop de ressources et de temps pour développer le dispositif, permettant d'atteindre une précision d'environ 20 ns. Dans le cas d'une implémentation matérielle complète du protocole PTP, une précision d'environ 10 ns est réalisable.

Outre la méthode de mise en œuvre, un certain nombre d'autres facteurs influencent la précision du protocole RTP. Par exemple, la norme IEEE 1588 ne précise pas la fréquence d'horloge entre les appareils maître et esclave. En conséquence, les horloges à basse fréquence auront une résolution temporelle moins précise, ce qui entraînera des horodatages moins précis dans les messages d'horloge. La stabilité de la fréquence de l'oscillateur de référence affecte également la qualité de la mise en œuvre du protocole. Les signaux de synchronisation obtenus à l'aide d'oscillateurs à quartz thermostatés et compensés en température seront plus stables (de

	PREMIER mile 5-6/2009

						les technologies
	écart en parties par milliard) que les oscillateurs à cristal					la meilleure alternative pour synchroniser les systèmes distribués
	sans stabilisation thermique (écart en parties par million).					ceux avec une précision inférieure à la microseconde.
	La qualité de la synchronisation des appareils est également affectée par la topologie					Ainsi, PTP est une alternative
logique du réseau et uniformité du trafic. Dans un réseau avec un grand nombre						méthode de synchronisation du réseau, qui peut être dis-
appareils cassés et charge élevée sur les canaux de transmission de données						distribution dans les réseaux NGN. Par rapport à ceux utilisés dans
la précision de la diffusion de synchronisation sera pire. Donc pour						actuellement moyen de synchronisation, cette méthode
la transmission de signaux de synchronisation est utilisée de préférence						présente de nombreux avantages :
créer un réseau de données séparé.						L'équipement ne nécessite pas d'accès direct à l'interface de synchronisation
						Mise en œuvre du PRC, qui permettra aux opérateurs d'optimiser
Caractéristiques comparatives						dépenses pour construire un réseau. Dans ce cas, le protocole RTP peut fournir
systèmes de synchronisation						transfert de synchronisation d'impression avec une précision inférieure à la microseconde
Considérons les caractéristiques des systèmes de synchronisation utilisant						tew, ce qui signifie qu'une stabilité meilleure que 1 ppm est réalisable ;
utilisant le protocole PTP, en comparaison avec les systèmes avec synchronisation						Contrairement à la méthode adaptative, pour restaurer la synchronisation
via bus PXI (ligne de synchronisation physique) et via protocole						La ronisation nécessite un oscillateur de référence très stable
lu NTP (voir tableau). Contrairement aux systèmes avec une ligne physique						uniquement dans l'appareil maître ;
synchronisation, où l'exactitude des événements est déterminée par l'exactitude						Pour les tâches de synchronisation, vous pouvez utiliser des tâches asynchrones
signal d'horloge, dans le protocole PTP, le facteur déterminant est						canal avec une capacité de débit relativement faible
il y a une gigue de phase (gigue) associée à des changements aléatoires						ité, ce qui réduit considérablement le coût de mise en œuvre.
réduction des intervalles inter-paquets. La plupart des implémentations du prototype						Il est préférable que cette chaîne soit dédiée.
Cola PTP offre une précision inférieure à 1 µs.						Compte tenu de la facilité de déploiement du réseau
	Une autre valeur importante qui distingue les différentes méthodes					Ethernet, précision et performances inférieures à la microseconde
synchronisation, est le temps d'attente pour l'événement de synchronisation						avec des coûts minimes pour le traitement des messages, des protocoles
Tia. Il s'agit du temps écoulé entre l'envoi d'un événement au périphérique maître.						Le nombre de PTP est de plus en plus utilisé dans de nombreuses industries, notamment
le vôtre et le faire suivre. Depuis PTP et						en automatisation industrielle, métrologie, etc. En attendant-
NTP pour la transmission des messages de synchronisation utilise						Xia qu'à l'avenir, les capacités du protocole PTP l'étendront
il y a des paquets de données, l'attente d'un événement est déterminée par le temps						application en télécommunications pour la synchronisation d'appareils
attente du paquet plus temps de transmission et de traitement de l'en-tête						essaims sur les réseaux à commutation de paquets.
paquet et dure généralement quelques millisecondes. DANS
la différence avec eux réside dans les systèmes avec une ligne de synchronisation physique						Littérature
attendre un événement de synchronisation pendant plusieurs						1. Stein Y., Schwartz E. Extension de circuit sur IP : le
nanosecondes Temps d'attente pour synchroniser l'opération d'événement						Approche évolutive du transport de la voix et de l'héritage
définit une telle caractéristique comme le maximum possible						Données sur réseaux IP. – Communications de données RAD, 2002.
réglage de la fréquence du signal d'horloge.						2. Synchronisation et synchronisation ITU-T G.8261/Y.1361
	Systèmes de synchronisation avec un seul bus de synchronisation,					aspects dans les réseaux de paquets. – ITU_T, avril 2008.
tels que le PXI sont idéaux pour les applications de haute précision et à grande vitesse						3. Rodrigues S. Options technologiques pour la livraison synchronisée dans
restauration de synchronisation complète et peut être étendue						Réseaux de nouvelle génération. – 3ème International Télécom
renes sur des distances allant jusqu'à des centaines de mètres à l'aide de
modules de synchronisation placés dans des cassettes. Standard-						4. Télégin S.A. Application du multiplexage TDMoIP
synchronisation via le réseau Ethernet via NTP						rirovaniya pour la transmission de données dans les réseaux de transport
définit la synchronisation en millisecondes adaptée à						GSM. – Monde non linéaire, 2007, vol. 5, n° 5, p. 270-271.
applications à faible vitesse qui ne sont pas très critiques en termes de qualité						5. Norme IEEE. 1588–2008 Norme IEEE pour une précision
synchronisation Le protocole PTP est un bon						Protocole de synchronisation d'horloge pour les réseaux
	Caractéristiques comparatives des systèmes de synchronisation					Systèmes de mesure et de contrôle. – IEEE, juillet 2008.
						6. Protocole de temps réseau IETF RFC1305 (version 3).
			Synchronisation	Protocole	Protocole
						Spécification, mise en œuvre et analyse. – IETF,
			modules sur bus PXI
	Temporaire
					<1·107	7. Tan E. Heure du protocole de temps de précision IEEE 1588
	autorisation
	événements, ns					Performances de synchronisation. Note d'application 1728.–
						National Semiconductor, octobre 2007.
	attentes
						8. Hamdi M. Neagoe T. Un matériel IEEE-1588
						Implémentation avec contrôle de fréquence du processeur. –
	ajustements					Arrow Electronics, août 2006.

PREMIER mile 5-6/2009

Pourquoi avez-vous besoin d’une heure exacte ?

De toute façon, qui a besoin de cette heure exacte ? Bien sûr, nous, les utilisateurs, en avons besoin pour être moins en retard. Imaginons un aéroport moderne : pour son fonctionnement, des centaines de pilotes et de régulateurs doivent utiliser une horloge fonctionnant sans erreur. Le système d'enregistrement des marchandises dans les entrepôts, les hôpitaux, les guichets ferroviaires et de nombreuses autres institutions nécessite que l'heure soit la même dans tous les objets du système à un degré ou à un autre. Surtout les ordinateurs. Ils gèrent de nombreux services et programmes dont le fonctionnement normal nécessite un temps précis et, en règle générale, un temps plus précis que celui dont nous, les humains, avons habituellement besoin. Les services système, les composants du système de sécurité et simplement les programmes d'application peuvent être très critiques pour la précision de l'horloge. L’exemple le plus frappant de ces services est le protocole d’authentification Kerberos. Ainsi, pour que cela fonctionne, il faut que sur les ordinateurs accessibles via ce protocole, l'heure du système ne diffère pas de plus de 5 minutes. De plus, l'heure précise sur tous les ordinateurs facilite grandement l'analyse des journaux de sécurité lors des enquêtes sur des incidents sur un réseau local.

protocole NTP

NTP (Network Time Protocol) est un protocole conçu pour synchroniser l'heure sur un réseau. Il s'agit d'un ensemble d'algorithmes assez complexes conçus pour garantir une grande précision (jusqu'à plusieurs microsecondes) et une tolérance aux pannes du système de synchronisation temporelle. Ainsi, le protocole implique une synchronisation simultanée avec plusieurs serveurs.

Il existe plusieurs versions de ce protocole, avec quelques différences. La troisième version de ce protocole a été normalisée sous le nom de RFC 1305 en 1992. La quatrième version (actuellement la plus récente) apporte quelques améliorations (configuration et authentification automatiques, algorithmes de synchronisation améliorés) par rapport à la troisième, mais elle n'est pas encore normalisée dans la RFC.

De plus, en plus du protocole NTP, il existe le SNTP (Simple Network Time Protocol). Au niveau des paquets, les deux protocoles sont entièrement compatibles. La principale différence entre eux est que SNTP ne dispose pas des systèmes de filtrage complexes ni de correction d'erreurs en plusieurs étapes que l'on trouve dans NTP. Ainsi, SNTP est une version simplifiée et plus facile à mettre en œuvre de NTP. Il est destiné à être utilisé dans des réseaux où une précision temporelle très élevée n'est pas requise, et dans la mise en œuvre de Microsoft, il fournit une précision dans les 20 secondes au sein d'une entreprise et pas plus de 2 secondes dans un seul site. Le protocole SNTP est normalisé sous les noms RFC 1769 (version 3) et RFC 2030 (version 4).

Le modèle de synchronisation NTP suppose une structure hiérarchique. Au premier niveau de la hiérarchie se trouvent les serveurs de temps dits « primaires » (Première strate). Ils sont situés à différents endroits du monde et ont l’heure la plus précise. Il existe relativement peu de serveurs de ce type, car l'heure exacte y est maintenue à l'aide d'équipements spécialisés coûteux (canal radio, canal satellite). Les serveurs de deuxième niveau (Deuxième strate) sont synchronisés avec les serveurs de premier niveau à l'aide du protocole NTP. Ils sont déjà beaucoup plus nombreux, mais ils sont déjà quelque peu désynchronisés (de 1 à 20 millisecondes) par rapport aux serveurs « primaires ». Viennent ensuite les serveurs des troisième, quatrième et suivants niveaux :

Avec le passage à chaque niveau, l'erreur par rapport au serveur principal augmente légèrement, mais le nombre total de serveurs augmente et, par conséquent, leur charge diminue. Par conséquent, en tant que source externe de synchronisation, au lieu d'utiliser les serveurs principaux qui ont l'heure la plus précise, il est recommandé d'utiliser des serveurs secondaires car ils sont moins chargés.

Pour synchroniser l'heure sous Windows 2000/XP/2003, le protocole SNTP est utilisé. La prise en charge de ce protocole est implémentée sous la forme du service système Windows Time, qui fait partie du système d'exploitation MS Windows 2000/XP/2003. Une particularité de cette implémentation est que le service Windows Time prend en charge l'authentification de domaine lors de l'accès au serveur de temps de référence, ce qui est important du point de vue de la sécurité.

Il existe plusieurs options pour faire fonctionner le service SNTP inclus dans Windows :

• Hiérarchique (NT5DS). Utilisé par défaut pour tous les ordinateurs joints à un domaine. La synchronisation de l'heure sur les postes de travail et les serveurs de domaine s'effectue de manière hiérarchique. Ainsi, les postes de travail et les serveurs membres sont synchronisés avec le contrôleur de domaine qui a authentifié la connexion, les contrôleurs de domaine sont synchronisés avec le maître de l'opération « émulateur PDC », qui à son tour est synchronisé avec le contrôleur de domaine situé à un niveau supérieur de la hiérarchie. Il convient de noter que cet ordre de synchronisation est utilisé « par défaut » et peut être remplacé manuellement ou à l'aide de stratégies de groupe. Comment procéder sera discuté ci-dessous.
• Forcer la synchronisation avec le serveur NTP sélectionné (NTP). Dans ce cas, la source de temps de référence pour le service de temps Windows est définie manuellement ou à l'aide de stratégies de groupe.
• Désactivez la synchronisation (NoSync). Ce mode est requis pour un schéma de gestion du temps mixte, dans lequel un produit tiers est utilisé pour la synchronisation avec une source externe et l'heure Windows est utilisée pour maintenir l'heure au sein du domaine.

Ainsi, dans le cas d'un groupe de travail, la synchronisation horaire devra toujours être configurée manuellement. Par exemple, l'un des ordinateurs peut être configuré pour se synchroniser avec un serveur externe à l'aide du protocole SNTP, et les autres peuvent être configurés pour se synchroniser avec celui-ci. Les étapes requises pour cela seront décrites ci-dessous.

Pour un domaine, il est recommandé d'utiliser la synchronisation hiérarchique utilisant le protocole SNTP. Dans la plupart des cas, il fournit une précision temporelle système acceptable au sein de la forêt du domaine. De plus, il assure automatiquement la sécurité des mises à jour temporelles en prenant en charge l'authentification Active Directory. Pour maintenir l'heure « correcte » dans le domaine, il est nécessaire de synchroniser le contrôleur de domaine de premier niveau, qui possède le rôle « émulateur PDC », avec un serveur NTP externe. Dans notre exemple, le rôle d'un tel serveur sera une machine Linux avec le démon ntpd en cours d'exécution.

Configuration de SNTP sous Windows

Pour configurer le service Windows Time, deux utilitaires sont utilisés :

• Temps net
• W32tm

Net Time est principalement utilisé pour configurer le service de temps, et w32tm est utilisé pour surveiller et diagnostiquer le fonctionnement. Cependant, sous Windows XP/2003, l'utilitaire w32tm a subi des modifications significatives et peut être utilisé pour configurer le service de temps. La configuration NTP sera ensuite effectuée en utilisant Windows XP/2003 comme exemple.

Ainsi, afin de spécifier « manuellement » la source de synchronisation en utilisant net time, il suffit d'écrire sur la ligne de commande :

et heure /setsntp:list_of_time_servers_separated by_space

Pour obtenir des informations sur le serveur de temps actuel :

heure nette /querysntp

Vous pouvez connaître l'heure sur un contrôleur de domaine comme ceci :

heure nette /domaine : nom_domaine

Et synchronisez l'heure avec un contrôleur de domaine comme ceci :

Heure nette /domaine : nom_domaine /set

L'utilitaire système w32tm peut faire tout de même et même plus :

• w32tm /resync - À l'aide de cette commande, vous pouvez forcer un ordinateur local ou distant à synchroniser son horloge système avec le serveur de temps qu'il utilise.
• w32tm /config – Cette commande est utilisée pour configurer le service de temps Windows. Avec son aide, vous pouvez préciser la liste des serveurs de temps utilisés et le type de synchronisation (hiérarchique ou sélectionnée par serveurs).

Par exemple, pour remplacer les valeurs par défaut et configurer la synchronisation de l'heure avec une source externe, vous pouvez utiliser la commande :

w32tm /config /syncfromflags:manuel /manualpeerlist:PeerList

Et pour que Windows Time applique les nouveaux paramètres, au lieu de redémarrer le service, vous pouvez utiliser la commande :

w32tm /config /mise à jour

De plus, w32tm propose les options suivantes liées à la surveillance du temps sur les ordinateurs :

• w32tm /monitor – en utilisant cette option, vous pouvez découvrir en quoi l'heure système de cet ordinateur diffère de l'heure du contrôleur de domaine ou d'autres ordinateurs.
• w32tm /stripchart – affiche graphiquement la différence de temps entre l'ordinateur actuel et l'ordinateur distant.
• w32tm /register – Enregistre le service Windows Time en tant que service sur cet ordinateur. Cette option peut être utile sur les ordinateurs qui ne font pas partie d'un domaine, puisque par défaut le service de temps y est arrêté.

Des informations plus détaillées sur les paramètres des utilitaires net time et w32tm peuvent être obtenues à l'aide de la touche /?. ou en ouvrant la section appropriée du système d'aide du Centre d'aide et de support MS Windows XP/2003.

Il n'est pas difficile de deviner que les paramètres du service de temps Windows sont stockés dans le registre Windows dans la section HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\.

A la racine de la section, les paramètres de fonctionnement du service lui-même sont définis, dans la sous-clé Config – paramètres liés au fonctionnement du protocole SNTP lui-même, le mode de synchronisation est défini dans la sous-clé Paramètres. Les paramètres du client et du serveur SNTP se trouvent respectivement dans les connexions TimeProviders\NtpClient et TimeProviders\NtpServer. Examinons les principales valeurs qui déterminent les paramètres du client et du serveur NTP :

• Type – détermine le mode de fonctionnement du client NTP (NTDS5 – hiérarchique, NTP – « manuel », NoSync – ne pas synchroniser, AllSync – tous les types de synchronisation sont disponibles) ;
• Activé – détermine si ce composant (client ou serveur) est activé ;
• CrossSiteSyncFlags – détermine s'il est possible de synchroniser l'heure avec une source située en dehors du domaine si la synchronisation hiérarchique est utilisée (0 – impossible, 1 – uniquement avec l'émulateur PDC, 2 – avec tous) ;
• EventLogFlags – détermine si les messages de Windows Time seront enregistrés ou non (une fonctionnalité très utile lors du débogage).

Une autre option pour configurer le service de temps Windows consiste à utiliser des stratégies de groupe. Les paramètres sont définis dans l'objet de stratégie de groupe à l'adresse suivante : « Configuration ordinateur –> Modèles d'administration –> Système –> Service de temps Windows ».

Si Windows 2000 Server est installé et que vous n'avez pas trouvé un tel paramètre, ne désespérez pas, il vous suffit de mettre à jour les « Modèles d'administration ». Pour ce faire, copiez tous les fichiers .adm du dossier système system32\GroupPolicy\Adm de n'importe quel ordinateur sur lequel Windows XP est installé sur le serveur qui est un contrôleur de domaine. Ensuite, tout en définissant le GPO, faites un clic droit sur « Modèles d'administration » et sélectionnez « Ajouter/Supprimer des modèles... » Supprimez les modèles qui y sont répertoriés et ajoutez ceux copiés. Après avoir cliqué sur le bouton « OK », les modèles seront mis à jour et vous pourrez configurer le service de temps à l'aide des politiques de groupe :

Il est facile de voir que cela répertorie principalement tous les paramètres pouvant être modifiés dans le registre. Il n’y a rien d’étonnant à cela, car c’est exactement ainsi que fonctionnent la plupart des polices de groupe.

Sous Windows XP, une autre façon de paramétrer un serveur de temps est apparue, qui peut être très pratique pour mettre en place la synchronisation sur un ordinateur personnel ou un ordinateur faisant partie d'un groupe de travail :

Serveur NTP pour Linux - synchronisation externe pour domaine Windows

Comme mentionné ci-dessus, le protocole NTP est plus résistant aux erreurs, il est donc préférable d'utiliser un serveur NTP comme source d'heure de référence pour la synchronisation externe. De plus, le contrôleur de domaine de premier niveau n'a pas toujours accès à Internet via le port UDP 123, qui est utilisé pour le fonctionnement NTP. L'accès peut très bien être refusé pour des raisons de sécurité, ce qui est une pratique courante dans les grandes organisations. Dans de tels cas, pour résoudre ce problème, vous pouvez installer votre propre serveur de temps dans la DMZ, configuré pour se synchroniser avec une source externe, et l'utiliser comme source de temps de référence pour synchroniser le contrôleur de domaine de niveau supérieur. Tout ordinateur, pas nécessairement moderne, avec un système d'exploitation de type * nix, par exemple Linux, installé dans une configuration minimale, sans serveur X et autres éléments potentiellement vulnérables, convient tout à fait comme tel ordinateur.

Il existe de nombreux programmes de synchronisation de l'heure pour le système d'exploitation Linux. Les plus connus sont Xntpd (NTP version 3), ntpd (NTP version 4), Crony et ClockSpeed. Dans notre exemple, nous utiliserons le serveur ntpd ntp inclus dans Redhat 9, fourni dans le package ntp-4.1.2-0.rc1.2.i386.rpm.

Le package comprend plusieurs programmes conçus pour fonctionner avec NTP.

Voici les principaux :

• Ntpd – démon ntp qui maintient une heure précise en arrière-plan ;
• Ntpq est un utilitaire conçu pour interroger les serveurs NTP prenant en charge le protocole d'interrogation standard NTP mode 6. Avec son aide, vous pouvez connaître et modifier l'état actuel du serveur, si ses paramètres le permettent ;
• Ntptdc – un utilitaire avec lequel vous pouvez interroger le démon ntpd et obtenir des statistiques sur son fonctionnement ;
• Ntpdate est un programme permettant de définir l'heure actuelle du système à l'aide du protocole NTP.

Une fonctionnalité standard du protocole NTP est la possibilité d'effectuer une authentification. Dans ce cas, on peut utiliser aussi bien des algorithmes symétriques (DES), apparus dans la deuxième version du protocole, que des algorithmes asymétriques à clé publique, qui constituent une innovation dans la quatrième version.

Dans le cas de l'utilisation d'un schéma d'authentification symétrique, le client et le serveur sélectionnent un identifiant arbitraire et l'une des 65534 clés définies par la norme. Lors de l'utilisation d'algorithmes asymétriques, on utilise le schéma dit Autokey, dont la particularité est qu'il n'est pas nécessaire de pré-distribuer les clés publiques des serveurs.

Pour configurer l'authentification dans ntpd, il existe des utilitaires ntp-genkeys, ntpq et ntpdc.

Toutes les fonctionnalités NTP liées à la prise en charge d'une heure précise sont implémentées dans le démon ntpd. Il est configuré de la manière UNIX habituelle - en éditant le fichier de configuration ntp.conf situé dans le dossier /etc.

Définissons les options suivantes pour le serveur NTP.

Tout d'abord, indiquons les serveurs avec lesquels la synchronisation horaire sera effectuée :

serveur ntp.nasa.gov # Un serveur de strate 1 sur nasa.org
serveur ntp1.demos.net # Un serveur stratum 2 sur demos.net

restreindre le masque ntp.research.gov 255.255.255.255 nomodify notrap noquery

Ici, le masque 255.255.255.255 est utilisé pour restreindre l'accès à notre serveur depuis le serveur ntp.nasa.gov. Définissons maintenant une liste d'hôtes sur notre réseau local auxquels nous souhaitons autoriser l'accès à notre serveur NTP pour obtenir l'heure :

restreindre 192.168.1.0 masque 255.255.255.0 notrust nomodify notrap

Nous exigeons également que la machine Linux ait un accès complet aux ressources de son serveur :

restreindre 127.0.0.1

Et maintenant, la chose la plus importante : nous devons nous assurer que le refus par défaut, qui a une priorité plus élevée, est commenté :

#restrict ignorer par défaut

Après avoir enregistré le fichier ntp.conf, la configuration peut être considérée comme terminée, mais il peut arriver qu'après le démarrage du démon, l'heure ne soit toujours pas synchronisée. Le fait est que le protocole NTP a été développé à l'origine comme un protocole permettant de maintenir l'heure et non de la définir. Par conséquent, si la différence entre les lectures de l'horloge est suffisamment grande (plus de quelques minutes), la synchronisation ne se produira pas. Dans ce cas, il est judicieux de régler initialement l’heure manuellement à l’aide de la commande ntpdate (vous pouvez également ajouter la commande ntpdate aux scripts de démarrage de la machine) :

# ntpdate clock.vsu.ru
17 février 23:44:54 ntpdate : serveur de temps pas à pas 198.123.30.132 offset 25.307598 sec

17 février 23:45:05 ntpdate : ajuster le serveur de temps 198.123.30.132 offset 0,002181 sec
# ntpdate clock.vsu.ru

Le démon ntp est lancé via des scripts d'initialisation. Si le programme a été installé à partir d'un package RPM, tous les problèmes liés à son lancement automatique ont probablement déjà été résolus. Pour vérifier cela, vous pouvez utiliser la commande :

# chkconfig -list ntpd
ntpd 0: activé 1: désactivé 2: désactivé 3: activé 4: désactivé 5: activé 6: désactivé

Si vous ne voyez pas cette ligne, cela signifie que ntpd n'est pas configuré pour démarrer automatiquement. Pour résoudre ce problème, tapez :

# chkconfig –niveau 035 ntpd activé

Pour gérer NTP (démarrage, lancement, redémarrage, statut), un script d'initialisation standard est utilisé :

# /etc/init.d/ntpd début

Pour afficher les statistiques de synchronisation du serveur, vous pouvez utiliser la commande suivante :

#ntpq -p
refid à distance st t lorsque l'interrogation atteint le délai de décalage de la gigue
==============================================================================
*tick.usnogps.na .USNO. 1 u 38 64 377 220,00 0,149 7,08
-navobs1.wustl.e.PSC. 1 u 55 64 377 193,47 6,857 4,81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254,88 7,471 9,58
-ntp0.NL.net.GPS. 1 u 144 512 377 122,54 12,515 13,75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133,94 14,594 41,99
+timekeeper.isi. .GPS. 1 u 13 64 377 245,30 3,454 15,08
+news-zero.demos ntp0.usno.navy. 2 u 16 64 377 37,51 -3,239 11,14
LOCAL(0) LOCAL(0) 10 l - 64 377 0,00 0,000 10,01

Modes de fonctionnement du serveur/client NTP

Serveur client

Ce mode est de loin le plus utilisé sur Internet. Le plan de travail est classique. Le client envoie une requête à laquelle le serveur envoie une réponse dans un délai déterminé. Le client est configuré à l'aide de la directive serveur dans le fichier de configuration, où le nom DNS du serveur de temps est spécifié.

Mode symétrique actif/passif

Ce mode est utilisé si la synchronisation de l'heure est effectuée entre un grand nombre de machines homologues. En plus du fait que chaque machine se synchronise avec une source externe, elle se synchronise également avec ses voisins (pairs), agissant pour eux comme client et serveur de temps. Ainsi, même si une machine « perd » une source externe, elle pourra toujours obtenir l’heure précise de ses voisins. Les voisins peuvent travailler selon deux modes : actif et passif. Travaillant en mode actif, la machine transmet elle-même son heure à toutes les machines voisines répertoriées dans la section peers du fichier de configuration ntp.conf. Si les voisins ne sont pas indiqués dans cette section, alors la machine est considérée comme fonctionnant en mode passif. Pour empêcher un attaquant de compromettre d'autres machines en se faisant passer pour une source active, l'authentification doit être utilisée.

Mode diffusion

Ce mode est recommandé dans les cas où un petit nombre de serveurs dessert un grand nombre de clients. Lorsqu'il fonctionne dans ce mode, le serveur envoie périodiquement des paquets en utilisant l'adresse de diffusion du sous-réseau. Un client configuré pour se synchroniser de cette manière reçoit le paquet de diffusion du serveur et se synchronise avec le serveur. Une caractéristique de ce mode est que l'heure est transmise au sein d'un seul sous-réseau (limitation des paquets de diffusion). De plus, l’authentification doit être utilisée pour se protéger contre les attaquants.

Mode multidiffusion

Ce mode est à bien des égards similaire à la diffusion. La différence est que les adresses de multidiffusion des réseaux de classe D de l'espace d'adressage IP sont utilisées pour transmettre les paquets. Pour les clients et les serveurs, l'adresse du groupe de multidiffusion est spécifiée, qu'ils utilisent pour la synchronisation de l'heure. Cela permet de synchroniser des groupes de machines situées sur différents sous-réseaux, à condition que les routeurs qui les connectent prennent en charge le protocole IGMP et soient configurés pour transmettre du trafic multicast.

Mode multidiffusion

Ce mode est une innovation dans la quatrième version du protocole NTP. Cela implique que le client recherche des serveurs manycast parmi ses voisins du réseau, reçoit des échantillons de temps de chacun d'eux (en utilisant la cryptographie) et, sur la base de ces données, sélectionne les trois « meilleurs » serveurs manycast avec lesquels le client se synchronisera. Si l'un des serveurs tombe en panne, le client met automatiquement à jour sa liste.

Pour transmettre des échantillons de temps, les clients et les serveurs fonctionnant en mode multicast utilisent des adresses de groupe multicast (réseaux de classe D). Les clients et serveurs utilisant la même adresse forment la même association. Le nombre d'associations est déterminé par le nombre d'adresses multicast utilisées.

Questions fréquemment posées

Pourquoi l'heure n'est-elle pas synchronisée après la commande net time /setsntp:server ?

Assurez-vous que le type de démarrage du service w32time est défini sur Automatique.
Assurez-vous que le port UDP 123 du serveur NTP que vous utilisez est disponible.
Assurez-vous que le temps entre le client et le serveur ne varie pas trop.

Un client SNTP peut-il se synchroniser avec un serveur NTP ?

Oui, c’est possible, puisque le protocole SNTP est un sous-ensemble de NTP et est entièrement compatible avec celui-ci.

Puis-je utiliser un serveur NTP tiers sous Windows 2000/XP/2003 ?

Oui, vous pouvez utiliser n’importe quel serveur, payant ou gratuit. Vous devez d'abord désactiver les composants appropriés (client ou serveur) des services de temps Windows.

Pourquoi le client NTP ne fonctionne-t-il pas sur un ordinateur sur lequel MS SQL Server est installé ?

Le problème est très probablement que SQL Server occupe d'une manière ou d'une autre le port UDP 123. Une solution pourrait consister à exécuter le client NTP avant MS SQL Server.

Le démon ntpd, après son démarrage, fonctionne pendant 10 à 20 minutes, après quoi il s'arrête. Quel pourrait être le problème?

Assurez-vous que les horaires du client et du serveur ne diffèrent pas trop (pas plus de 5 minutes). Sinon, forcez la synchronisation à l'aide de ntpdate.

Est-il possible de synchroniser l'heure sous les systèmes d'exploitation Windows NT4, 95, 98, Me ?

Cela est possible en utilisant des programmes tiers, par exemple NetTime, Automacahron, World Time5, le port ntpd Windows NT.

Lorsque vous essayez de vous connecter à un domaine Windows, un message apparaît indiquant que le temps entre le contrôleur de domaine et le poste de travail diffère trop, malgré le fait que la synchronisation soit configurée avec précision.

Le problème est très probablement que l'heure s'est très mal passée (réinitialisation CMOS, sabotage pirate) et que le service n'est pas en mesure de s'authentifier à l'aide du protocole Kerberos. Pour résoudre ce problème, vous devez soit régler l'heure manuellement, soit ne pas utiliser ce type d'authentification lors de la mise à jour de l'heure.

09/07/2012, lundi, 10h07, heure de Moscou

Le principal problème des réseaux de transport de nouvelle génération est que la technologie Ethernet a été conçue à l'origine pour les réseaux locaux et n'a jamais été prévue pour transporter des signaux de synchronisation. Au cours des dernières décennies, les réseaux à commutation de circuits ont été dominés par la technologie de hiérarchie numérique synchrone (SDH) comme support de transport, basé sur la transmission de signaux d'horloge. Mais même cette technologie fiable et éprouvée ne répond pas aux exigences des applications modernes.

pages : précédent | | 2

Utilisation de la norme Sync Ethernet

La technologie Ethernet a été initialement développée exclusivement pour être utilisée dans les réseaux locaux. Les méthodes de codage linéaire des informations au niveau physique ont été choisies en fonction de tâches n'impliquant pas la transmission d'un signal d'horloge. Les réseaux SDH utilisaient initialement des codes de ligne NRZ, adaptés pour transmettre la synchronisation au niveau de la couche physique du canal de communication. Lors de la création de la technologie Sync Ethernet, la couche physique et les méthodes de codage ont été empruntées à la technologie SDH, et la deuxième couche (canal) n'a pratiquement pas été affectée. La structure de la trame reste inchangée, à l'exception de l'octet d'état de synchronisation SSM. Ses significations ont également été empruntées à la technologie SDH.

Le principe de la transmission de synchronisation via le protocole Sync Ethernet

Les avantages de la technologie Sync Ethernet incluent l'utilisation de la structure de couche physique SDH et, parallèlement, une expérience vaste et inestimable dans la conception et la construction de réseaux de synchronisation de réseaux d'horloge. L'identité des méthodes a permis de conserver la pertinence des anciennes recommandations G.803, G.804, G.811, G.812 et G.813 dans la nouvelle technologie. Des appareils coûteux - oscillateurs de référence primaires (PEG), oscillateurs maîtres secondaires (MSO) - peuvent également être utilisés dans le nouveau réseau de transport construit sur la norme Sync Ethernet.

Schéma de synchronisation typique utilisant la technologie Sync Ethernet

Les inconvénients incluent le fait que dans l'ensemble du réseau de transmission, chaque appareil doit prendre en charge la nouvelle norme, et s'il y a un appareil sur la ligne qui ne prend pas en charge Sync Ethernet, alors tous les appareils derrière ce nœud ne peuvent pas fonctionner en mode synchrone. Par conséquent, des coûts matériels importants sont nécessaires pour moderniser l’ensemble du réseau. Un autre inconvénient est que cette méthode ne prend en charge que la transmission de la synchronisation de fréquence.

Utilisation de PTP (IEEE1588v2)

Et la dernière méthode de transfert de synchronisation, qui est récemment devenue de plus en plus populaire, est le Precise Time Protocol (PTP). Il est décrit dans la recommandation IEEE 1588. En 2008, une deuxième version de ce document a été publiée, qui décrit l'utilisation du protocole dans les réseaux de télécommunications. Precise Time Protocol est assez jeune, mais la technologie de transfert de temps elle-même a été empruntée au protocole Network Time Portocol (NTP). Le protocole NTP dans sa dernière version n'offre pas la précision requise pour les applications modernes et reste donc un bon outil de synchronisation temporelle, largement utilisé dans la synchronisation de serveurs, de bases de données distribuées, etc. Mais lors de la construction d'un réseau de synchronisation d'horloge, une suite logique du protocole NTP convient - c'est le protocole PTP. Les éléments du réseau qui participent à l'interaction via le protocole PTP sont les appareils suivants : PTP Grand Master et PTP Slave. Généralement, le Grand Maître prend le timing du récepteur GNSS et, en utilisant ces informations, échange des paquets avec l'appareil Esclave et corrige constamment les écarts de temps entre les appareils Grand Maître et Esclave. Plus cet échange est actif, plus la précision de l’ajustement sera élevée. L'inconvénient d'un tel échange actif est l'augmentation de la bande passante allouée au protocole PTP. Le problème le plus important dans le calcul de l'écart dans les intervalles de temps est qu'il peut y avoir des routeurs de couche 3 « classiques » entre les appareils Grand Maître et Esclave. Le terme « classique » dans ce cas est utilisé pour souligner que ces appareils ne comprennent rien au protocole PTP couche 5.

Les retards dans les tampons de ces routeurs sont assez difficiles à gérer et ils sont de nature aléatoire. Afin de contrôler ces erreurs aléatoires, et également de rendre plus précis le calcul de l'écart temporel entre le Grand Maître et l'Esclave, un paramètre spécial a été introduit dans le protocole PTP - le Time Stamp. Cette étiquette indique le temps nécessaire à un paquet pour passer par le routeur. Si tout au long du chemin allant du Grand Maître aux routeurs Esclaves disposent de la fonctionnalité PTP et définissent un horodatage, alors l'erreur aléatoire associée au passage des paquets PTP via le réseau IP peut être minimisée.

Un exemple de construction d'un réseau de synchronisation utilisant le protocole PTP

Comparaison des méthodes de transfert de synchronisation dans les réseaux paquets de nouvelle génération

La fonctionnalité PTP sur les routeurs n'est pas requise, mais est fortement recommandée lors de l'utilisation du protocole PTP. Il convient de noter que la plupart des fabricants de routeurs incluent cette fonctionnalité dans leurs appareils. Un exemple de construction d'un schéma de synchronisation pour un opérateur mobile est présenté dans la figure ci-dessous. L'avantage de PTP est que le protocole est conçu pour transmettre les trois types de synchronisation : fréquence, phase et temps. Le principal inconvénient du protocole est sa dépendance à la charge. Lorsqu'il existe des congestions sur un réseau IP difficiles à gérer, il est très difficile d'assurer le strict respect des règles de transmission de la synchronisation sur le réseau.

Technologie	Avantages	Défauts
GNSS	Assurer la synchronisation de fréquence, de phase et de temps. Ne dépend pas de la charge du réseau.	Installation d'antenne obligatoire. Impossibilité d'utilisation dans des espaces clos. Interférences possibles provenant d'autres appareils radio. La redondance n'est assurée qu'en installant un deuxième récepteur GNSS
Synchroniser Ethernet	Ne dépend pas de la charge du réseau. Similaire au réseau SDH	Fournit uniquement la synchronisation de fréquence. La prise en charge de la synchronisation Ethernet est requise pour tous les éléments du réseau
PTP	Assurer la synchronisation de fréquence, de phase et de temps.	Cela dépend de la charge du réseau.

Chaque méthode a ses propres avantages et inconvénients, présentés dans le tableau. Pour déterminer la bonne approche, il est recommandé de considérer de nombreux critères spécifiques aux différents réseaux.

Mikhaïl Vekselman

pages : précédent | | 2