Brevet FR2961985A1 — publié le 20111230

DISPOSITIF DE COLLECTE DE DONNEES POUR LA SURVEILLANCE DE FLUX DANS UN RESEAU DE DONNEES [0001] La présente invention concerne les techniques de surveillance de flux de communication dans des réseaux de données. [0002] Dans le cadre de la surveillance de flux de données dans un réseau de données tel qu'Internet, les équipements sont confrontés à la multiplication des protocoles utilisés, à la masse des données transférées ainsi qu'à la multiplicité des émetteurs/récepteurs. [0003] II existe actuellement deux types de dispositifs pour la mise en oeuvre de telles surveillances de flux. Des dispositifs d'un premier type collectent pendant une durée déterminée un ensemble de paquets puis, dans une étape ultérieure, analysent et traitent les paquets collectés. Un exemple de ce type de dispositif repose sur le logiciel distribué sous la marque Wireshark, autrefois la marque Ethereal. [0004] Le second type de dispositif utilise des mécanismes matériels pour acquérir les données puis les transmettre à des dispositifs d'analyse. Très souvent la transmission d'information entre l'acquisition et les dispositifs d'analyse repose sur le protocole ipfix standardisé par l'IETF (Internet Engineering Task Force) sous la référence RFC 3917. [OOQ5] La demanderesse a développé des technologies de surveillance de réseaux de type Internet. Elle a en particulier déposé les demandes de brevet EP 1 722 509 Al et EP 1 722 508 Al décrivant des architectures multiniveaux permettant d'examiner en temps réel des empilements de protocoles complexes afin d'en extraire les flux, c'est-à-dire l'ensemble structuré de données transmis entre un émetteur et un récepteur. [00061 Au vu de la quantité d'informations à traiter au niveau des collecteurs de données, ceux-ci doivent se limiter à faire le traitement strictement indispensable pour transmettre l'information pertinente à un analyseur et seulement celle-ci. [0007] Certaines solutions chargent les collecteurs de données 2961985 -2- d'opérations de traitement permettant un transfert d'informations structurées et pertinentes. Toutefois, ces solutions obligent à développer des architectures matérielles très performantes compte tenu de la masse d'informations à examiner en temps réel par le collecteur de données. 5 [E008] D'autres types de solutions limitent les traitements effectués par les collecteurs de données, en leur faisant transférer des données non structurées, y compris des données redondantes et/ou inutiles, ce qui entraîne d'autres contraintes au niveau de l'analyseur et de son interface avec le collecteur. [0009] Une autre possibilité consiste à effectuer un traitement différé au 10 niveau de l'analyseur. II en résulte toutefois une moindre réactivité de l'application de surveillance de flux. [polo] II serait donc avantageux de proposer une technique de collecte de données qui permette de transférer à l'analyseur seulement des données structurées et pertinentes tout en limitant les ressources matérielles 15 nécessaires aux traitements d'acquisition et de mise en forme de ces données. [00lll Selon l'invention, il est proposé un dispositif de collecte de données pour la surveillance de flux dans un réseau de données utilisant un mode de transmission par paquets. Ce dispositif comprend: - un extracteur de données contenues dans des paquets appartenant à un 20 flux défini par un émetteur, un récepteur et un protocole; - un analyseur syntaxique agencé pour: - recevoir les données en temps réel de l'extracteur; - décomposer les données reçues en éléments en fonction de règles syntaxiques dudit protocole, les règles syntaxiques permettant de 25 représenter lesdits éléments suivant une structure en arbre; et - associer des indicateurs d'états arborescents respectifs à certains au moins desdits éléments, où l'indicateur d'état arborescent associé à un élément repère ledit élément dans la structure en arbre; et 2961985 -3- - une interface pour transmettre à un analyseur de flux les indicateurs d'états arborescents accompagnés des éléments auxquels ils ont été associés. [OO12] Dans un mode de réalisation du dispositif, l'indicateur d'état 5 arborescent associé à un élément comporte un identifiant d'un noeud père de la structure en arbre auquel se rattache un emplacement recevant ledit élément dans la représentation suivant la structure en arbre. L'analyseur syntaxique peut être agencé pour: - affecter un identifiant de noeud à un élément courant s'il est 10 déterminé selon les règles syntaxiques que l'élément courant est reçu, dans la représentation suivant la structure en arbre, à un emplacement situé à un noeud de la structure en arbre; et - inclure l'identifiant de noeud affecté à l'élément courant dans l'indicateur d'état arborescent associé audit élément courant. 15 [0013] Dans une réalisation avantageuse, l'analyseur syntaxique est agencé pour ne conserver en mémoire, pour un flux donné après transmission d'un élément et de son indicateur d'état arborescent associé, que chaque identifiant de noeud rencontré en remontant la structure en arbre à partir de l'emplacement recevant ledit élément dans la représentation suivant la 20 structure en arbre. [0014] Un autre aspect de l'invention se rapporte à un système de surveillance de flux dans un réseau de données utilisant un mode de transmission par paquets. Ce système comprend un dispositif de collecte de données tel que défini ci-dessus et un analyseur de flux recevant les éléments 25 transmis avec les indicateurs d'états arborescents associés. [0015] Un autre aspect encore de l'invention se rapporte à un procédé de surveillance de flux dans un réseau de données utilisant un mode de transmission par paquets. Le procédé comprend: - extraire des données contenues dans des paquets appartenant à un flux 30 défini par un émetteur, un récepteur et un protocole; 2961985 -4- - décomposer en éléments les données reçues en temps réel, en fonction de règles syntaxiques dudit protocole, les règles syntaxiques permettant de représenter lesdits éléments suivant une structure en arbre; - associer des indicateurs d'états arborescents respectifs à certains au 5 moins desdits éléments, où l'indicateur d'état arborescent associé à un élément repère ledit élément dans la structure en arbre; et - transmettre à un analyseur de flux les indicateurs d'états arborescents accompagnés des éléments auxquels ils ont été associés. [0016] Le procédé peut comprendre en outre la construction d'une partie au 10 moins de la structure en arbre au niveau de l'analyseur de flux à partir des éléments transmis avec les indicateurs d'états arborescents associés. [0017] D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'un exemple de réalisation non limitatif, en référence aux dessins annexés, dans lesquels : 15 - la figure 1 est une vue schématique d'un système de surveillance dans un réseau de données selon un mode de réalisation de l'invention; - la figure 2 est une vue schématique fonctionnelle d'un dispositif collecteur de données du système de surveillance de la figure 1; - la figure 3 est un organigramme de fonctionnement du dispositif 20 collecteur de la figure 2; - la figure 4 est un exemple illustratif de décomposition en arbre dynamique d'une requête HTTP selon un mode de réalisation de l'invention; et - la figure 5 montre un exemple de structure en arbre dans le cas d'un 25 protocole de messagerie électronique. [0018] En référence à la figure 1, un système de surveillance comporte un collecteur de données 1 branché directement sur un réseau de données 3, par exemple l'Internet, utilisant un protocole par paquets de type IP ("Internet Protocol") afin d'acquérir les paquets circulant sur ce réseau. Ce collecteur de 30 données 1 utilise par exemple l'architecture détaillée dans la demande de brevet EP 1 722 509 Al ou la demande de brevet EP 1 722 508 Al. Il transmet 2961985 -5- par une connexion de données 5 à un analyseur 7 des données structurées extraites des paquets circulant sur le réseau de données 3. [0019] Les transmissions sur le réseau de données 3 utilisent de façon classique un empilement de protocoles de transmission. Ainsi, par exemple, 5 dans le cadre de la consultation de sites web, un paquet IP contient une structure de données du protocole TCP ("Transmission Control Protocol") contenant elle-même une structure de données HTTP ("HyperText Transfer Protocol"). Dans le cadre de la messagerie électronique (e-mail), la structure de données TCP contient une structure de données SMTP ("Simple Mail 10 Transfer Protocol"), etc. En fonction du type de flux considéré, de nombreux autres protocoles de niveau applicatif ou transport sont employés, comme il est bien connu dans le domaine des communications sur réseau IP. [0020] Les informations circulant dans le cadre d'un flux donné sont rarement contenues dans un unique paquet IP. Ces informations sont au 15 contraire segmentées pour être transmises dans plusieurs paquets successifs. Ces paquets IP circulent sur le réseau, l'en-tête du paquet contenant des informations pour permettre son routage, notamment les adresses IP de la source et de la destination du paquet. Il peut s'intercaler entre eux d'autres paquets relevant d'autres flux. Les paquets peuvent suivre des routes 20 différentes au sein du réseau, et/ou être reçus d'un un ordre différent de celui dans lequel ils ont été émis. [0021] Pour surveiller un flux donné, il convient d'identifier les paquets relevant du flux en question, d'en extraire les informations pertinentes et de les analyser en fonction des besoins de l'application de surveillance considérée. 25 Dans l'architecture de la figure 1, l'identification et l'extraction incombent au collecteur de données 1 tandis que l'application de surveillance proprement dite est exécutée par l'analyseur 7. [0022] En référence à la figure 2, le collecteur de données 1 comporte un extracteur de données 11 connecté à un noeud ou un lien du réseau 3 afin 30 d'observer le trafic. L'extracteur de données 11 a une interface réseau adaptée aux couches protocolaires basses utilisées par le réseau 3 au niveau du noeud 2961985 -6- ou lien où l'extracteur est connecté. Il extrait les données contenues dans les paquets appartenant à un flux spécifié, le flux étant défini par un émetteur, un récepteur et un protocole (par exemple, SMTP pour du courrier électronique, HTTP pour de la navigation web, etc.). 5 [0023] Le collecteur de données 1 comporte en outre un analyseur syntaxique 13 qui reçoit en temps réel des données extraites par l'extracteur 11 pour un flux donné. L'analyseur syntaxique 13 dispose de ressources logiques incorporant des règles syntaxiques du protocole pertinent pour le flux considéré. Il décompose les données extraites du flux en éléments, encore 10 appelés événements, respectant la syntaxe du protocole du flux. Les éléments ainsi obtenus sont fournis à une interface 15 qui se charge de les transmettre à l'analyseur externe 7 avec des indicateurs d'états arborescents. [0024] La décomposition des données du flux en éléments est effectuée par l'analyseur syntaxique 13 en fonction des règles syntaxiques applicables 15 au protocole, qui permettent de représenter ces éléments suivant une structure en arbre. En pratique, la structure en arbre n'est pas mémorisée de manière complète au niveau du collecteur de données 1. Elle est reconstituée par l'analyseur de données structurées 7 si l'application le requiert. Le collecteur de données 1 se contente de mémoriser des états arborescents dont des 20 indicateurs sont respectivement associés aux éléments résultant de la décomposition opérée par l'analyseur syntaxique 13. [0025] L'indicateur d'état arborescent associé à un élément repère cet élément dans la structure en arbre pour que l'analyseur de données structurées 7 puisse le situer dans le flux surveillé. 25 [0026] Par arbre, il est entendu une structure de données au sens de la théorie des graphes comportant une donnée racine et des données filles de telle sorte qu'une donnée fille n'est reliée qu'à une seule donnée parente de niveau supérieur. Une donnée comportant des liens vers des données filles est appelée noeud de l'arbre et une donnée sans donnée fille est appelée feuille de 30 l'arbre. Un arbre est donc un graphe ne comportant pas de boucle. [0027] Le fonctionnement général du collecteur 1 est illustré par le 2961985 -7- diagramme de la figure 3. Dans une étape de configuration 21, les paramètres nécessaires à l'extracteur 11 lui sont fournis, en particulier: - l'émetteur, le récepteur et le protocole pertinents pour un flux surveillé; - une indication de types de données à extraire (toutes les données, 5 certains messages seulement, données respectant telle ou telle condition configurable, ...). Dans une configuration simple, toutes les données du flux sont extraites, les éventuels filtrages étant effectués au niveau de l'analyseur 7. Spécifier que certains types de données seulement sont à extraire permet, de manière facultative, de réduire la charge du collecteur 10 1 et la quantité d'information à faire transiter sur la connexion 5; - l'identification d'une instance de l'analyseur syntaxique 13 en charge du flux considéré puisqu'en pratique, l'extracteur 11 et l'analyseur 13 peuvent examiner plusieurs flux à la fois. [0028] À l'étape 23, l'extracteur 11 examine les paquets au fur et à mesure 15 de leurs transmissions sur le réseau 3. Pour ce faire, il utilise par exemple le procédé de reconnaissance et d'analyse de protocoles décrit dans la demande de brevet WO 2004/017595 A2. Il est ainsi capable d'extraire, à l'étape 25, les données appartenant au protocole spécifié lors de la configuration et circulant de l'émetteur spécifié vers le récepteur spécifié, et de transmettre ces données 20 en temps réel à l'analyseur syntaxique 13. [0029] Afin d'illustrer le fonctionnement de l'analyseur syntaxique 13 à l'étape de décomposition 27 indiquée sur la figure 3, on considère le cas particulier d'un flux obéissant au protocole HTTP entre un émetteur et un récepteur donnés. Dans cet exemple illustratif, l'extracteur 11 analyse les 25 paquets et extrait dans deux paquets successifs, après suppression des en-têtes, l'information indiquée au Tableau I. 2961985 -8 Numéro paquet Contenu HTTP du paquet P1 GET /search?hl=fr& P2 q=brevet HTTP/1.0\nHost: google.fr\n Tableau I [0030] Dans ce cas particulier, la requête HTTP complète: GET /search?hl=fr&q=brevet HTTP/1.0\nHost: google.fr\n a été segmentée en deux paquets pour qu'elle puisse être transportée tout en 5 respectant les limites imposées par les protocoles de niveau inférieur (TCP, IP, couches 1 et 2) en termes de taille de la charge utile. [0031] Sémantiquement, ce message HTTP se décompose en une commande de requête "GET" et un identifiant de ressource URI ("Uniform Resource Identifier"). L'URI se décompose lui-même en éléments ou 10 événements syntaxiquement pertinents. Ces éléments sont agencés dans les données placées dans les paquets conformément aux règles syntaxiques propres au protocole considéré (ici HTTP). [0032] Par exemple, les données du paquet P1 peuvent se décomposer comme l'indique le Tableau II, 2961985 -9 Numéro d'événement contenu 1.1 request 1.2 uri=/search?hl=fr& 1.3 uri_param 1.4 name = hl 1.5 value = fr Tableau II tandis que les données du paquet P2 peuvent se décomposer comme l'indique le Tableau III. Numéro d'événement contenu 2.1 uri = q=brevet 2.2 uri_param 2.3 name = q 2.4 value = brevet 2.5 server = google.fr Tableau III 5 [0033] L'événement 1.1 correspond à la détection de la commande "GET". Ensuite, l'analyseur syntaxique 13 détermine que le reste du paquet P1 fait partie de l'identifiant de ressource URI, ce qui constitue l'événement suivant 1.2. Cet événement "uri=/search?hl=fr&" doit lui-même être décomposé en événements car il fait apparaître une liste de paramètres qui peut être 10 incomplète. Cette nouvelle décomposition fait descendre d'un niveau dans la structure en arbre pour ajouter l'événement 1.3 qui annonce un paramètre d'URI. Ensuite, les événements 1.4 et 1.5 donnent les nom et valeur de ce 2961985 - 10- premier paramètre. À réception du paquet P2, il apparaît que l'URI se poursuit (événement 2.1) avec un autre paramètre (2.2) dont les nom et valeur sont donnés par les événements 2.3 et 2.4. Finalement, après le numéro de version du protocole HTTP, qui peut être ignoré dans cet exemple, le dernier 5 événement se rapporte au serveur interrogé, ici "google.fr". [0034] L'analyseur syntaxique 13 effectue une décomposition de ce type à l'étape 27 en fonction de la syntaxe du protocole analysé, pour convertir les données brutes fournies par l'extracteur 11 en événements. Chaque protocole applicatif (SMTP, SIP, RTP, etc.) utilise une syntaxe propre, généralement 10 différente de celle du protocole HTTP donné en exemple. L'analyseur syntaxique peut avoir une architecture modulaire lui permettant d'analyser des protocoles différents sur différents flux. Ainsi un nouveau protocole est analysable par l'analyseur syntaxique moyennant le développement d'un module spécifique à sa syntaxe. 15 [0035] On souhaite transmettre à l'analyseur externe 7 les données suffisantes pour lui permettre de reconstituer le flux, notamment suivant la structure en arbre, mais avec aussi peu d'information additionnelle que possible. Si le collecteur de données 1 ne transmet que les contenus d'événements indiqués dans les colonnes de droite des Tableaux II et III, il 20 demeure des ambiguïtés. Par exemple, l'analyseur 7 ne pourra pas savoir si l'événement 1.2, 2.1 ou 2.5 concerne la même requête que l'événement 1.1. Pour éviter ces ambiguïtés sans avoir à transmettre des informations relevant de couches protocolaires plus basses (comme par exemple des numéros de séquence de segments TCP), les contenus d'événement sont transmis par le 25 collecteur de données à l'étape 31 sous une forme structurée avec les indicateurs d'états arborescents associés par l'analyseur syntaxique 13 à l'étape 29. [0036] Les états arborescents peuvent être déterminés de la manière illustrée par la figure 4 dans l'exemple déjà discuté ci-dessus. Sur cette figure 30 4, la colonne de gauche montre la décomposition des paquets P1, P2 extraits du flux en éléments ou événements tels que rapportés aux Tableaux II et III. La colonne centrale de la figure 4 montre les événements tels que transmis par le collecteur de données 1 à l'analyseur externe 7 à l'étape 31, accompagnés de leurs indicateurs d'états arborescents respectifs, et la colonne de droite montre la manière dont l'analyseur 7 est capable de reconstituer l'arbre représentatif du flux surveillé. Dans cette partie droite, les caractères gras indiquent les éléments que l'analyseur 7 ajoute à l'arbre au fur et à mesure de leur réception depuis le collecteur 1. [0037] L'arbre peut être construit par l'analyseur 7 au fur et à mesure des événements reçus, en commençant par un noeud racine correspondant au flux analysé. Ce noeud racine est désigné par "http" sur la figure 4 et porte par exemple un identifiant de noeud (id) égal à 15C4. Dans cet exemple, l'arbre comporte déjà deux requêtes reçues avant celle portée par les paquets P1 et P2, désignées en partie supérieure de la colonne de droite par les deux noeuds "request" dont les ramifications de sont pas représentées pour éviter de surcharger le dessin. [0038] À réception de l'événement 1.1 indiquant une nouvelle requête pour le flux considéré, un nouveau noeud "request" est ajouté à l'arbre, ayant pour noeud père la racine "http". Comme il s'agit d'un événement dont l'analyseur syntaxique 13 sait, grâce aux règles du protocole HTTP, qu'il aura des données filles, il lui affecte un identifiant de noeud, dans cet exemple id = 38FA. L'indicateur d'état arborescent associé à l'événement 1.1 par l'analyseur syntaxique 13 à l'étape 29 comporte dans ce cas l'identifiant de noeud 38FA qu'il vient de lui affecter et l'identifiant (p) de son noeud père dans l'arbre, ici p = 15C4. [0039] À réception de l'événement 1.1 avec l'indicateur (id = 38FA / p = 15C4), l'analyseur 7 pourra rajouter le nouveau noeud à l'arbre, dont il garde en mémoire l'identifiant 38FA en rapport avec sa position (fils du noeud racine 15C4). [00401 L'événement suivant (2.2) résultant de l'étape de décomposition 27 se voit également affecter à l'étape 29 un indicateur d'état arborescent comportant l'identifiant de son noeud père dans l'arbre, en l'occurrence p = 38FA. Comme l'analyseur syntaxique 13 peut déterminer que cet 2961985 - 12 - événement correspond à une feuille de l'arbre, il n'a pas besoin de lui affecter un identifiant de noeud et son indicateur d'état arborescent peut donc se limiter à l'identifiant p = 38FA de son noeud père désignant la requête HTTP en cours. [0041] Le troisième événement 1.3 annonce que la suite contient des 5 paramètres de l'URI. Il peut donc être représenté comme un noeud fils du noeud "request" (38FA) qui aura des liens avec d'autres noeuds fils. En conséquence de quoi, l'analyseur syntaxique 13 lui affecte un identifiant unique, par exemple id = 8B53, de sorte que son indicateur d'état arborescent associé est (id = 8B53 / p = 38FA) . 10 [0042] Les événements suivants (1.4, 1.5) qui donnent les nom et valeur de paramètres de l'URI sont attachés sous forme de feuilles au noeud 8B53. Leurs indicateurs d'états arborescents sont simplement p = 8B53, sans spécifier de nouvel identifiant de noeud. [0043] Pour les événements 2.1-2.5 extraits du paquet P2, la logique de 15 construction de l'arbre par l'analyseur 7, représenté en partie basse de la figure 4, est semblable à celle qui vient d'être décrite. L'analyseur syntaxique 13 du collecteur 1 affecte donc à la volée des nouveaux identifiants aux noeuds qui apparaissent (sans avoir à le faire pour les feuilles de l'arbre), et il associe à chaque événement transmis un indicateur d'état arborescent comportant 20 l'identifiant unique de son noeud père et, s'il est lui-même représenté par un noeud ayant une descendance, l'identifiant nouvellement affecté à ce noeud. [0044] Il est à noter que l'URI, qui dans l'exemple a été tronqué dans le paquet P1 par suite de la segmentation des paquets, est complété après réception de l'événement 2.1 par l'analyseur 7. Celui-ci peut en effet constater 25 d'après la précédente feuille "uri=/search?hl=fr&" que l'URI est tronqué de sorte qu'à réception d'un nouvel événement de type URI (2.1), il procédera par concaténation sur la feuille correspondante plutôt que par création d'une nouvelle feuille. Ce traitement par l'analyseur 7 ne requiert pas de signalisation particulière de la part du collecteur 1. 30 [0045] L'ensemble du traitement de construction de l'arbre à l'aide des indicateurs d'états arborescents est visualisable sur la figure 4. La requête 2961985 -13- HTTP analysée est représentable sous forme d'un arbre tel que représenté en bas et à droite de la figure 4. [0046] Cette transmission permet avantageusement de ne transmettre que les informations nécessaires tout en préservant la structuration, ou le contexte, 5 des données transmises grâce aux identifiants de noeuds. Elle est effectuée au fur et à mesure de la réception des paquets par le collecteur 1 et elle permet à l'analyseur 7 de reconstituer les flux surveillés, immédiatement si nécessaire. [00471 Un autre avantage est que le collecteur de données 1, qui est soumis aux plus grandes contraintes de rapidité de traitement, n'a besoin de 10 conserver en mémoire que des informations dynamiques minimales, correspondant aux identifiants des noeuds qu'on rencontre dans l'arbre en remontant jusqu'à la racine à partir de l'événement courant. Les règles syntaxiques du protocole considéré permettent, en examinant la suite du flux, de se rattacher au noeud approprié. Les informations relatives aux noeuds 15 frères ou cousins de l'événement courant dans l'arbre n'ont pas besoin d'être conservées par le collecteur 1. [00481 Il faut noter que les procédés et dispositifs selon l'invention ne se limitent nullement au protocole HTTP qui n'a été mentionné que pour illustrer en termes concrets un exemple de réalisation. 20 [0049] Pour donner un autre exemple, on peut considérer un protocole applicatif de messagerie, tel SMTP. Un flux de ce protocole entre un émetteur et un récepteur donne lieu à des messages successifs (email dans la représentation en arbre de la figure 5) ayant chacun un objet (subject), un émetteur (sender) ayant une adresse de messagerie (sonder email) et un 25 pseudonyme éventuel (sonder alias), un ou plusieurs destinataires (receiver) ayant chacun une adresse de messagerie (receiver email) et un pseudonyme éventuel (receiver alias), un corps de message (message) et d'autres champs éventuels (indicateurs d'urgence, de confidentialité, pièce(s) jointe(s), etc.). Ces différents champs d'un message sont repérables par l'analyseur 30 syntaxique 13 si on lui fournit les règles syntaxiques appropriées du protocole employé. Ils sont souvent transmis dans des paquets IP différents en fonction - 14 - de la segmentation opérée au niveau de l'émetteur. [0050] La figure 5 détaille les ramifications dans l'arbre que peut construire l'analyseur de données structurées 7 pour représenter un exemple de message simple ayant deux destinataires. On suppose que les éléments placés dans le cadre en traits interrompus sont extraits d'un premier paquet P1' et que ceux placés dans le cadre en traits mixtes sont extraits d'un deuxième paquet P2' (qui peut être suivi d'un ou plusieurs autres paquets contenant une suite du corps du message, des pièces jointes, etc.). [0051] Dans cet exemple, l'étape de décomposition 27 donne lieu à sept événements 1.1-1.7 pour le premier paquet P1' et quatre événements 2.1-2.4 pour le deuxième paquet P2'. À l'étape 29, l'analyseur syntaxique 13 affecte des identifiants aux noeuds successivement détectés (représentés par des ellipses sur la figure 5) et rattache ces noeuds ainsi que les feuilles (représentées par des rectangles) à des noeuds pères respectifs. Ces identifiants et ces rattachements sont transmis en tant qu'indicateurs d'états arborescents à l'analyseur externe 7 qui reconstituera tout ou partie de l'arbre représenté sur la figure 5 si l'application le requiert. [0052] On observe qu'après avoir traité le premier paquet P1' qui se termine par l'adresse d'un destinataire (événement 1.7), l'analyseur syntaxique 13 du collecteur de données 1 n'a besoin de conserver en mémoire que l'identifiant du noeud père (1.6) de cet événement, pour le cas où un paquet ultérieur contiendrait un pseudonyme du destinataire en question, l'identifiant du noeud grand-père (1.1), pour le cas où le paquet suivant du flux commencerait par le corps du message, la date, une pièce jointe ou autre et l'identification du noeud racine pour le cas où un nouveau message apparaîtrait dans le flux. [0053] La méthode ci-dessus de représentation arborescente des données transmises dans un flux et de transmission d'une description structurelle minimale des éléments pouvant se placer dans l'arbre est applicable à tout type de protocole à partir d'une description des règles syntaxiques pertinente pour le protocole considéré. -15- [OO54] L'invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d'exemple et non comme limitant l'invention à cette seule description. De nombreuses variantes de réalisation sont possibles. REVENDICATIONS1. Dispositif de collecte de données pour la surveillance de flux dans un réseau de données (3) utilisant un mode de transmission par paquets, le dispositif comprenant: - un extracteur (11) de données contenues dans des paquets appartenant à un flux défini par un émetteur, un récepteur et un protocole; - un analyseur syntaxique (13) agencé pour: - recevoir les données en temps réel de l'extracteur; - décomposer les données reçues en éléments en fonction de règles syntaxiques dudit protocole, les règles syntaxiques permettant de représenter lesdits éléments suivant une structure en arbre; et - associer des indicateurs d'états arborescents respectifs à certains au moins desdits éléments, où l'indicateur d'état arborescent associé à un élément repère ledit élément dans la structure en arbre; et - une interface (15) pour transmettre à un analyseur de flux (7) les indicateurs d'états arborescents accompagnés des éléments auxquels ils ont été associés. 2. Dispositif selon la revendication 1, dans lequel l'indicateur d'état 20 arborescent associé à un élément comporte un identifiant d'un noeud père de la structure en arbre auquel se rattache un emplacement recevant ledit élément dans la représentation suivant la structure en arbre. 3. Dispositif selon la revendication 2, dans lequel l'analyseur syntaxique (13) est en outre agencé pour: 25 - affecter un identifiant de noeud à un élément courant s'il est déterminé selon les règles syntaxiques que l'élément courant est reçu, dans la représentation suivant la structure en arbre, à un emplacement situé à un noeud de la structure en arbre; et 15 2961985 -17- - inclure l'identifiant de noeud affecté à l'élément courant dans l'indicateur d'état arborescent associé audit élément courant. 4. Dispositif selon la revendication 3, dans lequel l'analyseur syntaxique (13) est agencé pour ne conserver en mémoire, pour un flux donné 5 après transmission d'un élément et de son indicateur d'état arborescent associé, que chaque identifiant de noeud rencontré en remontant la structure en arbre à partir de l'emplacement recevant ledit élément dans la représentation suivant la structure en arbre. 5. Système de surveillance de flux dans un réseau de données (3) 10 utilisant un mode de transmission par paquets, le système comprenant un dispositif de collecte de données (1) selon l'une quelconque des revendications précédentes et un analyseur de flux (7) recevant les éléments transmis avec les indicateurs d'états arborescents associés. 6. Procédé selon la revendication 5, dans lequel l'analyseur de flux (7) est agencé pour construire une partie au moins de la structure en arbre à partir des éléments transmis avec les indicateurs d'états arborescents associés. 7. Procédé de surveillance de flux dans un réseau de données (3) utilisant un mode de transmission par paquets, le procédé comprenant: - extraire (25) des données contenues dans des paquets appartenant à un flux défini par un émetteur, un récepteur et un protocole; - décomposer (27) en éléments les données reçues en temps réel, en fonction de règles syntaxiques dudit protocole, les règles syntaxiques permettant de représenter lesdits éléments suivant une structure en arbre; - associer (29) des indicateurs d'états arborescents respectifs à certains au moins desdits éléments, où l'indicateur d'état arborescent associé à un élément repère ledit élément dans la structure en arbre; et - transmettre (31) à un analyseur de flux (7) les indicateurs d'états arborescents accompagnés des éléments auxquels ils ont été associés. 2961985 -18- 8. Procédé selon la revendication 7, dans lequel l'indicateur d'état arborescent associé à un élément comporte un identifiant d'un noeud père de la structure en arbre auquel se rattache un emplacement recevant ledit élément dans la représentation suivant la structure en arbre. 5 9. Procédé selon la revendication 8, comprenant en outre: - affecter un identifiant de noeud à un élément courant s'il est déterminé selon les règles syntaxiques que l'élément courant est reçu, dans la représentation suivant la structure en arbre, à un emplacement situé à un noeud de la structure en arbre; et 10 - inclure l'identifiant de noeud affecté à l'élément courant dans l'indicateur d'état arborescent associé audit élément courant. 10. Procédé selon la revendication 9, dans lequel, pour un flux donné après transmission d'un élément et de son indicateur d'état arborescent associé, n'est conservé en mémoire que chaque identifiant de noeud rencontré 15 en remontant la structure en arbre à partir de l'emplacement recevant ledit élément dans la représentation suivant la structure en arbre. 11. Procédé selon l'une quelconque des revendications 7 à 10, comprenant en outre la construction d'une partie au moins de la structure en arbre au niveau de l'analyseur de flux (7) à partir des éléments transmis avec 20 les indicateurs d'états arborescents associés.