Brevet FR2849559A1 — publié le 20040702

2002-0147 Domaine technique La présente invention concerne les réseaux de transmission de données dans lesquels il est nécessaire d'effectuer l'analyse du réseau entre un premier dispositif de traitement de données tel qu'un ordinateur hôte et un second dispositif de traitement de données tel qu'un serveur, et 5 concerne en particulier un outil et une méthode d'analyse de chemin dans un réseau de transmission de données comprenant plusieurs systèmes autonomes Internet. Etat de la technique Aujourd'hui, il y a un besoin pour les utilisateurs et fournisseurs de services du réseau 10 Internet de comprendre le comportement du réseau qui peut être lent et congestionné et dans lequel l'accès au serveur pour traiter une requête d'un utilisateur prend beaucoup de temps parce que le serveur est très chargé. Il est difficile de diagnostiquer à distance un problème du serveur, mais quelques outils de base peuvent aider à vérifier le réseau. Les deux fonctions standard utilisées le plus souvent pour 15 déboguer les réseaux sont appelées "Ping" et "Traceroute". Les deux outils sont sous UNIX (marque de la société UNIX), mais ont généré des programmes sous DOS et Windows (marque de la société Windows Corp.) qui se comportent de la même façon (notamment Ping et Tracert qui sont disponibles en utilisant l'environnement DOS). La fonction ping est basée sur un paquet spécifique du protocole Internet (IP) appelé 20 paquet de requête d'écho du protocole de message de contrôle Internet (ICMP) utilisé pour envoyer des informations de réseau entre deux ordinateurs hôtes. Lorsque l'hôte destinataire reçoit le paquet de requête d'écho d'origine, il répond par un message de réponse d'écho en plaçant le paquet de requête d'écho d'origine dans le champ de données du message de réponse d'écho. Ping est un outil utile pour tester la connectivité du réseau et mesurer si les paquets de 25 données vont bien d'un hôte source à un hôte destinataire et donner des détails sur le chemin. En outre, le ping permet de mesurer combien de temps met un paquet de données d'un hôte à un autre hôte. La fonction Traceroute est un outil plus sophistiqué définissant le chemin de routeurs que prend un paquet. En fait, traceroute est une particularité des messages ICMP. Un de ces messages 30 est envoyé à l'hôte source lorsque le champ "Temps à vivre" (TTL) qui est décrémenté d'un chaque fois que le message traverse un routeur atteint zéro. Ceci signifie que l'hôte destinataire ne 2 2002-0147 peut pas être atteint et, dans ce cas, il est nécessaire pour l'hôte source de mettre en oeuvre une requête inverse de service de nom de domaine (DNS). Comme la fonction ping, la fonction traceroute fournit un temps de réponse routeur à routeur permettant de déterminer un point de blocage dans le réseau entre deux routeurs. Un goulot d'étranglement peut être d à l'unité de transmission maximum par paquets (MTU) qui limite la longueur d'un message qui peut être mis dans une trame physique. IP requiert que chaque liaison ait un MTU d'au moins 68 bytes. Si un réseau fournit une valeur inférieure, la fragmentation et le ré-assemblage doivent être mis en oeuvre dans la couche d'interface réseau d'une manière transparente à IP. Les implémentation IP ne sont pas exigées 10 pour traiter des messages non fragmentés supérieurs à 576 bytes, mais la plupart des implémentations traitent des valeurs plus élevées, de façon typique un peu supérieures à 8192 bytes ou plus, et rarement moins que 1500. Les nouvelles technologies avec l'emploi de tunnels augmentent la taille des paquets entrants et par conséquent, la taille des paquets est plus importante que celle attendue. Ceci conduit à des problèmes MTU qui nécessitent d'être 15 identifiés. Ces problèmes peuvent impacter les temps d'accès mais également l'acheminement des paquets. D'autres outils Internet sont très utiles pour résoudre un problème de réseau. Ils incluent la fonction Whois qui peut déterminer quelle compagnie (ou entité légale) est responsable pour une adresse IP et peut alors grouper plusieurs adresses IP dans un groupe de Système Autonomes 20 (AS). Ils incluent également la fonction DNS qui permet de faire le lien entre l'adresse IP et le nom de l'hôte. DNS aussi bien que Whois sont des fonctions capables de déterminer qui est la personne responsable pour une adresse IP. Mais, aujourd'hui, aucun des outils existants qui inclut les fonctions cidessus les réunit d'une manière efficace permettant de résoudre les problèmes soulevés dans le chemin de données 25 à travers un réseau. Exposé de l'invention En conséquence le principal but de l'invention est de construire un outil et de réaliser une méthode utilisant des procédures de requêtes d'information telles que "ping" ou "traceroute" pour 30 analyser le comportement d'un réseau entre un dispositif de traitement de données source tel qu'un ordinateur hôte et un dispositif de traitement de données destinataire tel qu'un serveur. 3 2002-0147 L'objet de l'invention est donc une méthode pour effectuer l'analyse des caractéristiques d'un chemin de données entre un premier dispositif de traitement de données et un second dispositif de traitement de données à travers un réseau comprenant au moins un système autonome, consistant à définir le scénario à utiliser dans un fichier scénario, le scénario comprenant les actions à mettre 5 en oeuvre, construire un fichier de paramètres définissant les paramètres à utiliser dans les actions, exécuter au moins un module programme d'analyse basé sur les actions du fichier scénario et sur les paramètres du fichier de paramètres, le module appelant au moins une procédure de demande d'informations prédéfinie, et mémoriser dans au moins un fichier de sortie les données résultant de l'exécution du module programme d'analyse 10 Description brève des dessins Les buts, objets et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description qui suit faite en référence aux dessins dans lesquels: * la figure 1 est une représentation schématique d'un premier réseau avec plusieurs 1 5 systèmes autonomes Intemet dans lequel l'invention peut être mise en oeuvre, * la figure 2 est une représentation schématique d'un second réseau dans lequel l'invention comportant un dispositif de filtrage entre deux systèmes autonomes Internet peut être mise en oeuvre, la figure 3 est une représentation schématique d'un troisième réseau dans lequel 20 l'invention peut être mise en oeuvre comprenant un serveur adapté pour réunir les résultats d'analyse, la figure 4 est un bloc-diagramme de l'outil d'analyse de chemin selon l'invention, * la figure 5 est un organigramme représentant la méthode selon l'invention appliquée à l'analyse de zone, * la figure 6 est un organigramme représentant la méthode selon l'invention appliquée à l'analyse du délai, * la figure 7 est un organigramme représentant la méthode selon l'invention appliquée à l'analyse de la jigue, * la figure 8 est un organigramme représentant la méthode selon l'invention appliquée à 30 l'analyse MTU, et 4 2002-0147 la figure 9 est un organigramme représentant la méthode selon l'invention appliquée à l'analyse du débit. Description détaillée de l'invention La figure 1 montre un exemple de réseau de transmission de données dans lequel l'invention est mise en oeuvre entre un premier dispositif de traitement de données qui est un ordinateur hôte 10 et un second dispositif de traitement de données qui est un serveur 12. Plusieurs réseaux ou sous-réseaux peuvent être interconnectés entre les dispositifs 10 et 12 tels que les systèmes autonomes Internet ASI 15, AS2 16, et AS3 17. On supposera que dans l'hôte, 10 le logiciel client est basé sur une application propriétaire qui effectue le traitement et un navigateur web standard qui permet à l'hôte 10 de visualiser ses résultats de mesure d'une manière formatée. Dans le serveur 12, plusieurs applications de base sont groupées pour fournir l'outil d'analyse de chemin. Plusieurs protocoles standards et serveurs associés peuvent être utilisés pour construire 15 l'outil d'analyse de chemin comprenant un serveur Whois 13 et un serveur DNS 14 qui sont connectés à AS1 15. Une autorité de certification CA 18 connectée à AS2 16 peut aussi être utilisée pour obtenir les caractéristiques des dispositifs de traitement de données. CA permet de fournir des informations sres dans la mesure o ces informations sont signées par des organisations ou des compagnies. A noter que les serveurs DNS sont moins srs puisqu'ils 20 peuvent être usurpés et ne contiennent pas toute l'information nécessaire. Un cas non couvert par les outils d'analyse des réseaux existants d'aujourd'hui est illustré sur la figure 2. Un pare-feu 19 (ou un dispositif de filtrage) est présent dans le chemin entre l'hôte 10 et le serveur 12. Ce cas existe lorsque l'un des deux dispositifs 10 est connecté à un système autonome tel que AS3 17 et l'autre dispositif 12 est connecté à un autre système autonome tel que 25 AS2 16. Le mode serveur client permet d'effectuer simultanément une demi-analyse à partir d'une extrémité (interne) vers le pare-feu et un autre demi-analyse à partir de la deuxième extrémité verts le pare-feu (externe). Les résultats structurés peuvent alors facilement reconstruire l'analyse d'une extrémité à l'autre et fournir des résultats et des statistiques. La méthode peut être utilisée pour tous les types de tests tels que analyse de zone, analyse du délai, analyse de la jigue, analyse 30 MTU et analyse du débit. A noter que, de façon générale, le logiciel nécessaire pour implémenter 2002-0147 la méthode selon l'invention pourrait être partagé entre les dispositifs source et destinataire dans d'autres cas que le cas illustré avec le pare-feu. Un autre cas illustré sur la figure 3 est la consolidation des résultats d'analyse pour plusieurs hôtes tels que les hôtes 31, 32 connectés au système autonome 16 et les hôtes 33, 34 5 connectés au système autonome 17 effectuant le même type de tests avec le même serveur 12 connecté au même système autonome ou à un autre système autonome tel que AS1 15. Les résultats d'analyse peuvent être facilement consolidés grâce à une structure commune pour la génération du test et les résultats de test et une corrélation de serveur basée sur un estampillage temporel du côté serveur. Des statistiques en temps réel peuvent être fournies aux deux 10 dispositifs et aux administrateurs de réseaux par un échange dynamique des fichiers de sortie dans lesquels les résultats sont mémorisés. L'outil d'analyse de chemin selon l'invention est illustré sur la figure 4. Les entrées pour l'outil sont des fichiers qui peuvent être situés localement dans la base de données locale DB 44 ou à distance dans une base de données similaire mais située dans un autre serveur de test telle 15 que DB 43. Les deux principaux fichiers nécessaires, le fichier de paramètres 41 et le fichier scénario 42, peuvent être emmagasinés dans ces bases de données ou peuvent être des fichiers emmagasinés comme fichiers réguliers dans le système d'exploitation de l'hôte utilisateur. Des fichiers tels que les fichiers de sortie emmagasinés dans DB 43 et 44 peuvent aussi être utilisés comme entrées pour des tests comme décrit ci-dessous. Une dernière entrée peut être 20 une référence temps 40 utilisée pour fournir un estampillage temporel pour les commandes comprenant les mesures de retards dans un sens. Pour fonctionner, la fonction nécessite d'être disponible dans l'hôte et dans le serveur. Plusieurs types d'analyses peuvent être effectués. Le fichier scénario identifie quels modules seront utilisés dans les blocs d'analyse. Le fichier scénario peut utiliser un ou plusieurs 25 blocs d'analyse, chacun définissant une procédure d'analyse. Les blocs d'analyse définis couramment incluent un bloc d'analyse de zone 45, un bloc d'analyse du délai 46, un bloc d'analyse de la jigue 47, un bloc d'analyse du débit 48 et un bloc d'analyse MTU 49. D'autres blocs peuvent être ajoutés sans changements majeurs au système qui est modulaire. Par exemple, un bloc d'analyse de sécurité peut être ajouté. Ce bloc peut utiliser des fonctions existantes telles 30 que la fonction de récupération de certificat CA 54 ou ajouter de nouvelles fonctions telles que 6 2002-0147 l'authentification à un serveur. Le mode de réalisation proposé effectue seulement le test de performance mais la structure est ouverte à tout test de réseau. Un bloc d'analyse peut contenir plusieurs modules. Par exemple, le bloc d'analyse de zone comprend un module "SortZone" utilisé pour grouper des dispositifs appartenant au même réseau 5 ou système autonome. Un autre module est le calculateur "Temps à vivre" (TTL). Ce module utilise le champ TTL des paquets IP qui est établi à une valeur relativement élevée. Au fur et à mesure que le paquet circule dans le réseau, le champ TTL est décrémenté de un à chaque routeur. Lorsque le TTL tombe à 0, le paquet est rejeté par le routeur. Ainsi, le TTL peut être utilisé pour déterminer approximativement combien de routeurs ont été traversés par le paquet. Un autre module est le module "Get" qui est un module d'analyse croisée pour fournir une analyse avec des données extérieures telles que des fichiers de sortie. Ce module n'est pas représenté sur la figure mais seulement par la flèche venant du bloc 44 aux blocs d'analyse. De façon similaire, le module "Put" permet de mémoriser les informations dans un fichier tel que le fichier de sortie ou un fichier intermédiaire. Un autre module commun est le module "Temps 1 5 écoulé" qui empêche un test de durer au delà d'un certain temps. Des fonctions externes peuvent être appelées par un bloc d'analyse. Ces fonctions sont relatives aux protocoles de réseau et l'appel d'une fonction génère des paquets sur l'interface réseau. Une fonction qui est souvent utilisée est la fonction ping 50. La fonction ping fournit une mesure du délai aller-retour d'un paquet transmis et dépend principalement de la taille du paquet 20 et de la classe de service du paquet. Lorsqu'un ping est envoyé vers un dispositif destinataire, la fonction envoie un paquet de requête d'écho toutes les secondes par exemple, à l'adresse IP du dispositif. Lorsque le programme ping reçoit en retour une réponse provenant du dispositif éloigné, il imprime la réponse, fournissant plusieurs informations intéressantes. La première est l'adresse IP du lieu d'o elle provient (normalement, l'adresse du dispositif destinataire). La 25 seconde est le numéro de séquence qui indique quel est le paquet ping qui a permis d'obtenir une réponse (un numéro de séquence sauté indique un paquet annulé). La troisième est le champ "Temps à vivre" comme mentionné ci-dessus et la quatrième est le temps (en millisecondes) qu'il a fallu pour obtenir une réponse. Une autre fonction souvent utilisée est la fonction "traceroute" 51. Traceroute est une 30 fonction qui fournit l'identification de l'adresse IP des noeuds du réseau dans le chemin pour atteindre le dispositif destinataire. Plusieurs paquets ayant des valeurs TTL allant de 1 à N (N est 7 2002-0147 le nombre de routeurs entre les dispositifs source et destinataire) sont successivement envoyés à chaque routeur entre les dispositifs source et de destination. Lorsque l'adresse IP de réponse est la même que l'adresse du dispositif destinataire, ceci signifie que le dispositif destinataire a été atteint. A noter que l'adresse IP du dispositif destinataire peut être déterminée en effectuant une requête de service de nom de domaine (DNS) pour trouver l'adresse IP à partir du nom de l'hôte. D'autres fonctions sont représentées sur la figure 4: Whois qui détermine quel compagnie ou légale entité est responsable pour une adresse IP et qui peut regrouper plusieurs adresses IP, DNS qui permet de trouver le lien entre une adresse IP et le nom de l'hôte, et la fonction CA (autorité de certification) qui permet de fournir l'authentification des informations contenues dans 10 un certificat pour des organisations ou compagnies autorisées. Mais la liste n'est pas limitée à ces protocoles. Lorsque nécessaire, d'autres fonctions peuvent être appelées telles que Telnet, FTP, Finger. Quelques unes d'entre elles nécessitent d'avoir la liste des dispositifs à joindre de façon à obtenir l'information qui peut être emmagasinée dans un fichier (par ex: Whois, DNS, CA). Finalement, les résultats de chaque analyse sont utilisés pour créer ou modifier au moins 15 un fichier de sortie 55 qui est défini dans le fichier scénario 42. Les détails d'un tel fichier de sortie sont décrits ci-dessous. La grammaire qui suit en langage XML du fichier scénario explique la structure de chaque champ et de chaque commande interne. A noter que XML n'est pas obligatoire, mais l'utilisation de fichier structurés pour les fichiers d'entrée et de sorite simplifie et améliore l'outil 20 pour être facilement interfacé avec d'autres logiciels. input::= [ action]* action::= attributes::= [ name Il doIt Il serverDest Il tracerouteFileName Il hosts I timeOut Il whoisFileName il SortZonesFileName]* name:= String doIt::= Bool serverDest::= String /I peering point to test tester. fileName: := String /1 OUTPUT FILE name. 8 2002-0147 hosts:= String [] Il "whois" server list timeOut:= int Ainsi, l'exemple suivant est une analyse de zone pour un dispositif suivie par une analyse 5 du retard basée sur une séquence définie de pings pour tous les noeuds du chemin vers le dispositif destinataire qui est un serveur web. 15 Dans l'exemple ci-dessus, l'analyse est faite grâce aux fonctions traceroute et Whois et le module SortZone en tant que première étape et ensuite ping comme deuxième étape lorsque le 20 scénario est impliqué. Mais un mécanisme plus complexe peut être ajouté si nécessaire tel que le module traceroute avancé. Deux fichiers de sortie pour écrire des résultats de test sont crées dans cet exemple: un fichier Whois qui contient les détails pour chaque noeud pour lequel les actions Whois ont été effectuées et un fichier SortZone qui contient les résultats de la consolidation par fournisseur. L'autre fichier d'entrée, le fichier de paramètres, procure la flexibilité en fournissant un accès aisé aux paramètres et le séquencement des fonctions à l'utilisateur. Des fichiers de paramètres peuvent être utilisés ou modifiés pour des besoins spécifiques. Ce fichier définit quels types de paquets doivent être transmis, de quelle taille est chaque paquet et de quelle durée. Ainsi, la commande ping peut être utilisée en mode par blocs séquentiels, et un module "Burst" 30 est alors utilisé pour définir les paramètres à appliquer à la fonction ping. "Burst" est un module qui peut être invoqué dans l'analyse du délai, dans l'analyse de la jigue ou dans l'analyse du débit. 9 2002-0147 Les caractéristiques d'un bloc dans la fonction ping définies dans la grammaire qui suit comprend l'espace entre blocs appelé "période" et l'espace entre pings dans un bloc appelé "espace bloc". test::= [ parameter]+ parameter::= [ burst]* burst: index:: int exec nb::= int nextindex:= int 15 size::= int burstsspace::= [ Day & Hour & Minute & Second & MilliSecond] Day::= [1..31] Hour::= [0..23] Minute::= [0..59] 20 Second::= [0..59] MilliSecond::= [0..99] period::= int Le fichier de paramètres qui suit montre un exemple de plusieurs blocs séquentiels 25 configurés avec des durées différentes et des tailles de paquet différentes. 2002-0147 Le fichier de sortie contient les résultats de l'analyse qui sont structurés d'une manière prédéfinie de façon à être présentés facilement à l'utilisateur grâce à un navigateur web. Une grammaire de fichier de sortie est définie pour chaque type de test. Ainsi, la grammaire qui suit est donnée pour la mesure du retard structuré par zones. stats:= [ action]+ action: [ result]+ il [ group]+ 20 result: group: [ result]+ attributes::= [ index Il host Il value J[ timeout Il name IJ domain I nbHosts Il packetSize IJ timeStamp I1 period I1 pingIn Il pingOut IJ crossTime Il ttl 11 * name::= String j 'unresolved' value::= String Il 'unresolved' 30 index::= Int host::= String ! i2002-0147 timeOut:= Int domain::= String Il 'unresolved' nbHosts::= Int packetSize::= Int timeStamp::= [ Day & Hour & Minute & Second & MilliSecond] Day::= [1..31] Hour::= [0..23] Minute::= [0..59] Second::= [0..59] MilliSecond::= [0..99] period::= int pingIn::= int Il 'unresolved' pingOut::= int 11 'unresolved' crossTime::= int Il 'unresolved' 15 ttl::= int Pour chaque test, les résultats détaillés peuvent être emmagasinés ou seulement les résultats consolidés ou les deux. Aussi, chaque action correspondant à un appel d'une fonction externe ou d'une fonction interne d'un module d'un bloc d'analyse peut être définie comme une 20 fonction ayant des sorties. L'information de sortie de chaque action comme résultat standard ou résultat avancé peut avoir plusieurs champs d'attributs définis dans la grammaire de sortie. Pour exemple, le fichier de sortie qui suit montre une première action traceroute fournissant juste une liste d'adresses IP correspondant aux noeuds du chemin. Puis, l'action Whois fournit le réseau auquel appartient chaque adresse IP ou nom d'hôte. Une troisième action 25 SortZone définit quels sont les premier et dernier noeuds du chemin dans les réseaux correspondants comprenant le nombre de routeurs de chaque réseau. Une dernière action est l'action ping (en mode par blocs séquentiels) fournissant des statistiques par zone. 12 2002-0147 10 15 20 25 30 13 2002-0147 Maintenant, des exemples des procédures d'analyse montrées sur la figure 4 sont illustrés par les organigrammes des figures 5 à 9. En référence à la figure 5, l'analyse de zone fournit 10 l'identification détaillée des dispositifs du chemin et peut grouper des dispositifs selon leur adresse IP, leur appartenance à un système autonome ou d'autres paramètres identiques pour ces dispositifs de façon à simplifier la topologie montrée à l'utilisateur et fournir des mesures associées à chaque groupe ainsi défini. L'analyse initialisée à l'étape 81, débute par une action traceroute à l'étape 82 qui fournit en retour à l'étape 83, les adresses de noeuds dans le chemin qui 15 sont identifiés un à un. Les noeuds non découverts parce que masqués et ne répondant pas peuvent être identifiés en utilisant la fonction traceroute avancée qui emploie d'autres moyens. Ceci correspond à la réponse non à l'étape 84 suivie par un ping (TTL) 85 qui établit le TTL dans la commande ping au numéro de routeur correspondant au dispositif n'ayant pas répondu. Généralement, les dispositifs doivent répondre aux paquets lorsque le TTL est atteint, ce qui est 20 le cas même s'ils refusent de répondre aux messages ICMP (ping). Si l'adresse IP est trouvée de cette façon ou au moyen de la première traceroute, le procédé continue à l'étape 87 o plus de détails sont demandés grâce à une requête utilisant Whois, une requête DNS ou CA ou plusieurs de ces fonctions. Si l'adresse IP n'est pas reconnue à l'étape 86, le noeud est identifié comme étant inconnu à l'étape 80. Après identification, les adresses IP sont triées par réseau ou zone à l'étape 25 88. Les informations sur les dispositifs identifiés et non identifiés sont emmagasinées dans un fichier de sortie à l'étape 90 et le procédé continue ou non avec le noeud suivant si le noeud traité n'est pas le dernier noeud de la liste d'adresses de noeuds grâce au rebouclage à l'étape 89 vers l'étape 84. En référence à la figure 6, l'analyse du délai fournit la mesure du délai aller retour ou dans 30 un seul sens à l'aide de paquets définis ou prédéfinis par l'utilisateur dont les paramètres sélectionnés incluent la longueur du paquet, la classe de service, le protocole et le séquencement 14 2002-0147 des paquets. L'analyse initialisée à l'étape 79, a trois modes de tests principaux sélectionnés à l'étape 92. Soit un simple test spécifique de noeud peut être effectué et ensuite, en utilisant le fichier de paramètres, un ping ou une séquence de pings est généré à l'étape 91. Les réponses aux pings sont utilisées pour faire les mesures et calculer les statistiques requises à l'étape 98. Puis, en 5 utilisant le fichier scénario, les résultats sont emmagasinés dans un fichier de sortie défini à l'étape 99. Une analyse de retard du lien principal ou une analyse de retard de zone peut être réalisée pour laquelle les résultats obtenus par une analyse de zone doivent être récupérés (étape 93) à partir de fichiers appropriés. L'analyse du délai continue alors à l'étape 94 o tous les noeuds de la frontière du réseau 10 ou du sous-réseau sont soumis à des pings avec des paramètres définis par le fichier de paramètres. La réception des paquets ping fournit des informations qui peuvent être utilisées pour calculer l'information requise sur le retard à l'étape 96 qui est alors mémoriséedans un fichier de sortie à l'étape 99. La différence principale pour le calcul du délai de lien principal est que un ping (ou une 15 séquence de pings) est envoyé à tous les noeuds du chemin à l'étape 95 et ensuite, la mesure du délai est effectuée à l'étape 97 par le calcul de la différence de délai de transmission aller retour pour deux noeuds consécutifs. La classification des noeuds peut aussi être réalisée à cette étape selon la requête qui a été définie dans le fichier scénario. La dernière étape 99 est de mémoriser les résultats dans un fichier de sortie comme pour l'autre analyse. En référence à la figure 7, l'analyse de la jigue fournit la mesure de la jigue aller retour ou dans un seul sens à l'aide de paquets définis ou prédéfinis par l'utilisateur dont les paramètres sélectionnés incluent la longueur du paquet, la classe de service, le protocole et le séquencement des paquets. L'analyse initialisée à l'étape 101, comporte deux modes sélectionnés à l'étape 102 dépendant du fait que le test est effectué avec le serveur comme destinataire ou avec un dispositif 25 normal. Sans le serveur, une séquence de pings, généralement une suite de blocs, est générée à l'étape 107 pour identifier la variation de délai qui fournira le délai global par calculs des deltas à l'étape 108. Les résultats des pings ou le délai de transmission aller retour sont mémorisés dans un fichier de sortie à l'étape 109. Avec un serveur, la même séquence de pings peut être transmise à l'étape 103 mais 30 comme le serveur est un serveur propriétaire, d'autres protocoles que ICMP peuvent être utilisés, par exemple le test peut être effectué avec TCP ou UDP dans l'environnement IP. Le serveur 2002-0147 intercepte ces paquets et reconstruit une séquence similaire en utilisant le même fichier de paramètres. Soit le scénario est prédéfini, soit la station débutant le test envoie son scénario au serveur avant le test. Aussi le serveur renvoie la même séquence à la station, séquence qui est reçue à l'étape 104. Les étapes dans le serveur ne sont pas montrées comme étant similaires aux 5 étapes dans la station. Le serveur peut effectuer le test en parallèle de son côté. La station demande ensuite les résultats de la première séquence au serveur et obtient les résultats concernés à l'étape 105. Les résultats fournissent la jigue pour le chemin de la station au serveur alors que la séquence reçue fournit la jigue pour le chemin du serveur à la station après calcul à l'étape 106. La dernière étape 100 est de mémoriser les résultats dans un fichier de sortie. En référence à la figure 8, l'analyse MTU fournit la valeur MTU d'une extrémité à l'autre du chemin avec la possibilité d'identifier le dispositif qui limite le MTU. L'analyse initialisée à l'étape 1 1 0, débute avec une étape de prise en compte des résultats à l'étape 11 1 obtenus par une analyse de chemin précédente. Ceci est nécessaire lorsque l'identification d'un goulot d'étranglement est aussi défini dans le fichier scénario contenant la requête. Autrement, l'étape 15 1 1 1 peut être shuntée. L'étape suivante 112 est le ping du dispositif destinataire avec la valeur attendue du MTU max aussi définie dans le fichier de paramètres. Si une réponse est reçue, alors l'étape 113 passe à l'étape 114 et le MTU est trouvé et mémorisé dans un fichier de sortie. Si aucune réponse n'est reçue, un dépassement de temps à l'étape 113 provoque le branchement à l'étape 115 o le MTU est réduit à une valeur définie dans le fichier de 20 paramètres. La méthode peut être, soit un test dichotomique, soit une diminution de la valeur du MTU correspondant à une diminution de la longueur du paquet ping. Puis, l'étape 115 repasse à l'étape 113 et attend une réponse. Si une identification de goulot d'étranglement se produit à l'étape 116, ce qui peut être le cas pour tout MTU qui n'est pas le MTU max ou pour un MTU de valeur définie, un ping est 25 envoyé à chaque noeud du chemin avec une valeur juste au dessus du MTU trouvé à l'étape 117. Le premier noeud qui ne répond pas (ou le dernier qui répond à partir de la source) identifie le noeud o il y a goulot d'étranglement à l'étape 118. Les informations sont mémorisées dans un fichier de sortie de manière à servir à améliorer le comportement du réseau lors d'une prochaine investigation. En référence à la figure 9, l'analyse du débit fournit la mesure du débit aller retour ou dans un seul sens à l'aide de paquets définis ou prédéfinis par l'utilisateur dont les paramètres 16 2002-0147 sélectionnés incluent la longueur du paquet, la classe de service, le protocole et le séquencement des paquets. L'analyse est initialisée à l'étape 120, permet de mesurer le comportement du réseau dépendant de la taille des paquets et du nombre de paquets transmis. Le procédé décrit est valable pour tout dispositif alors qu'un mécanisme amélioré peut être utilisé avec le serveur puisqu'un autre protocole que ping peut être employé pour le test tel que UDP/IP, TCP/IP, FTP, HTTP... L'analyse du débit est plus efficace si la transmission débute avec des paquets de taille maximale de sorte que le calcul du MTU aide à définir cette valeur qui peut être une entrée pour l'analyse. Dans ce cas, la taille maximale du paquet est établie à cette valeur MTU à l'étape 121 et 10 ensuite une séquence de paquets (généralement des pings) définie dans le fichier de paramètres est transmise à la destination à l'étape 122. Si seulement des grands paquets sont transmis, ceci fournit le débit maximal, mais ne fournit pas toutes les caractéristiques du réseau de sorte que le test préféré est de continuer après la première séquence de paquets à transmettre des plus petits paquets en diminuant la taille. Ceci est une option du fichier scénario. Dans un tel cas, le premier 15 accès à l'étape 123 verra que la limite basse de la taille de paquet n'est pas atteinte et alors, à l'étape 124, la taille du paquet est diminuée avant de renvoyer une séquence entière de test. Lorsque la limite inférieure est atteinte, l'étape 123 passe directement à l'étape 125 o les résultats sont mémorisés dans un fichier de sortie. 17 2002-0147 REVENDICATIONS 1. Méthode pour effectuer l'analyse des caractéristiques d'un chemin de données entre un 5 premier dispositif de traitement de données (10) et un second dispositif de traitement de données (12) à travers un réseau comprenant au moins un système autonome (15, 16, 17), consistant à: * définir le scénario à utiliser dans un fichier scénario (42), ledit scénario comprenant les actions à mettre en òuvre, * construire un fichier de paramètres (41) définissant les paramètres à utiliser dans lesdites actions, * exécuter au moins un module programme d'analyse basé sur les actions dudit fichier scénario et sur les paramètres dudit fichier de paramètres, ledit module appelant au moins une procédure de demande d'informations prédéfinie, et * mémoriser dans au moins un fichier de sortie (55) les données résultant de l'exécution dudit module. 2. Méthode selon la revendication 1, dans laquelle ledit module de programme d'analyse est inclus dans une procédure d'analyse identifiée par ledit fichier scénario (42). 20 3. Méthode selon la revendication 2, dans laquelle ladite procédure d'analyse est une analyse de zone (45) fournissant l'identification détaillée des dispositifs et pouvant regrouper les dispositifs selon leur adresses IP ou leur appartenance à un système autonome de façon à simplifier la topologie et fournir des mesures supplémentaires associées à chaque groupe 25 de dispositifs. 4. Méthode selon la revendication 2, dans laquelle ladite procédure d'analyse est une analyse du délai (46) fournissant la mesure du délai aller-retour ou dans un seul sens avec des paquets dont les paramètres comprennent la longueur du paquet, la classe de service, le 30 protocole et le séquencement des paquets. 5. Méthode selon la revendication 2, dans laquelle ladite procédure d'analyse est une analyse de la jigue (47) fournissant la mesure du délai aller-retour ou dans un seul sens avec des 18 2002-0147 paquets dont les paramètres comprennent la longueur du paquet, la classe de service, le protocole et le séquencement des paquets. 6. Méthode selon la revendication 2, dans laquelle ladite procédure d'analyse est une analyse 5 du débit (49) fournissant la mesure du délai aller-retour ou dans un seul sens avec des paquets dont les paramètres comprennent la longueur du paquet, la classe de service, le protocole et le séquencement des paquets. 7. Méthode selon la revendication 2, dans laquelle ladite procédure d'analyse est une analyse 10 MTU fournissant la mesure du MTU d'une extrémité à l'autre du chemin avec la possibilité d'identifier le dispositif qui limite le MTU. 8. Méthode selon l'une des revendications 1 à 7, dans laquelle ladite procédure de demande d'informations est la fonction ping (50) fournissant la mesure du délai aller-retour d'un 15 paquet. 9. Méthode selon l'une des revendications 1 à 7, dans laquelle ladite procédure de demande d'informations est la fonction traceroute (51) fournissant l'identification de l'adresse IP des noeuds du chemin jusqu'audit second dispositif de traitement de données (12). 20 10. Méthode selon l'une des revendications 1 à 7, dans laquelle ladite procédure de demande d'informations est la fonction Whois (52) déterminant quelle compagnie ou entité légale est responsable pour une adresse IP. 11. Méthode selon l'une des revendications 1 à 7, dans laquelle ladite procédure de demande d'informations est la fonction DNS (53) qui permet de faire le lien entre l'adresse IP et le nom de l'hôte. 12. Méthode selon l'une des revendications 1 à 7, dans laquelle ladite procédure de demande 30 d'informations est la fonction d'autorité de certification (54) fournissant l'authentification des informations contenues dans un certificat numérique. 19 2002-0147 13. Méthode selon l'une des revendications 1 à 12, dans laquelle les données résultant de l'exécution d'un module de programme d'analyse antérieur qui ont été mémorisées dans ledit fichier de sortie (55) sont utilisées par un autre module de programme d'analyse. 14. Méthode selon la revendication 13, dans laquelle le réseau comprend deux systèmes autonomes (16 et 17) interconnectés par un dispositif pare-feu, une première demi-analyse étant effectuée par ledit premier dispositif de traitement de données (10) pour le chemin entre ledit premier dispositif de traitement de données et ledit dispositif pare-feu et une deuxième demi-analyse étant effectuée par ledit second dispositif de traitement de 10 données et ledit dispositif pare-feu. 15. Méthode selon la revendication 13, dans laquelle plusieurs analyses sont effectuées pour les chemins entre plusieurs hôtes (31, 32, 33, 34) qui sont connectés à un ou plusieurs systèmes autonomes (15, 16, 17) et un serveur (12), les résultats de toutes les analyses 15 étant ensuite consolidés par ledit serveur. 16. Outil d'analyse de chemin de données comprenant des moyens adaptés pour mettre en oeuvre les étapes de la méthode selon l'une des revendications 1 à 15.