La présente invention concerne le traitement de données dans des réseaux de télécommunications, et notamment l'analyse de flux transitant vers/depuis un client.

Elle concerne plus précisément des applications de surveillance et de filtrage de flux de données, par exemple des flux internet.

Dans la suite, on entend par flux de données tout ensemble de données échangées entre un client et une entité, c'est-à-dire entre un client et un serveur, ou entre deux clients (flux dits pair à pair, ou P2P), par exemple sur un réseau de type Internet.

Il est connu d'appliquer différentes méthodes de classification de flux de données afin de détecter un format de données, ou un protocole employé pour leur transport, en vue de filtrer les flux de données, de catégoriser un flux afin de permettre la mise en place d'une qualité de service QoS dans le réseau, ou plus généralement de traiter un flux de données.

A cet effet, des analyseurs de flux peuvent être disposés en interception dans des points d'accès réseau, tels que des bornes Wi-fi par exemple, situés dans des lieux publics tels qu'un hôpital ou un campus universitaire par exemple. En effet, dans un hôpital ou dans un campus universitaire, il peut être souhaitable d'empêcher les flux de données P2P, et il est ainsi nécessaire de détecter de tels flux de données.

De tels analyseurs de flux de données interceptent des paquets du flux de données et les paquets sont traités pour procéder à la classification du flux.

Des algorithmes statistiques et des algorithmes déterministes (aussi appelés DPI, pour « Deep Packet Inspection » en anglais) sont bien connus et permettent, à partir des paquets de données interceptés, de déterminer le format des données échangés ou le protocole utilisé pour leur transport, ou plus généralement de ranger le flux de données dans une catégorie, afin de déduire si le flux de données est un flux autorisé ou non en fonction de la catégorie qui lui est attribuée ou si une QoS spécifique doit être appliquée pour ce flux. Toutefois, l'analyse des paquets d'un flux de données introduit un délai lorsque l'analyseur de flux est en interception dans le réseau de télécommunications : chaque paquet reçu par l'analyseur est traité et retenu pendant le traitement appliqué par l'analyseur.

L'analyse d'un paquet peut permettre de catégoriser le flux correspondant au paquet traité. Dans ce cas, le paquet est retenu si le flux est interdit, est transféré si le flux est autorisé, ou une politique de QoS est appliquée au flux correspondant au paquet. Dans le cas où l'analyse du paquet n'est pas suffisante pour catégoriser le flux, le paquet est transféré à l'issue de l'analyse.

Ainsi, chaque paquet de données est retenu durant son analyse ce qui introduit de la latence dans le réseau. De plus, les durées d'analyse étant variables (de quelques millisecondes à quelques dixièmes de seconde), la latence n'est aucunement garantie pour le client, ce qui n'est pas satisfaisant.

Ainsi, il existe un besoin d'analyser les flux de données d'un client efficacement tout en garantissant une latence minimale au client.

La présente invention vient améliorer la situation.

Elle propose à cet effet un procédé de traitement d'un flux de données échangé entre un client et une entité via un réseau de télécommunications, le flux de données comprenant un ensemble de paquets de données, le procédé de traitement comprenant les étapes suivantes :

- sur interception d'un paquet de données appartenant à un flux de données, le flux de données comprenant une source et un destinataire, le client étant la source ou le destinataire du flux de données, copier le paquet de données ou générer une référence au paquet de données, et transférer le paquet de données au destinataire;

- transmettre ladite copie ou référence à un analyseur de flux apte à analyser le flux de données;

- recevoir un résultat d'analyse du flux de données depuis l'analyseur de flux ;

- traiter le flux de données sur la base du résultat d'analyse reçu. On entend par entité toute entité apte à échanger des flux de données avec le client : il peut par exemple s'agir d'un autre client ou d'un serveur.

On entend par résultat d'analyse toute classification du flux de données dans une catégorie donnée, ou toute déduction d'une caractéristique du flux de données. Ce résultat peut être obtenu par l'analyse d'un seul paquet du flux, ou peut alternativement requérir l'analyse de plusieurs paquets du flux. Le traitement du flux peut être basé sur un ensemble de règles prenant en entrée un résultat d'analyse et indiquant le traitement associé à ce résultat d'analyse.

Dans le cas où l'analyseur de flux et l'entité mettant en œuvre le procédé selon l'invention partagent le même espace mémoire, une référence au paquet de données (telle qu'une adresse de stockage du paquet en mémoire) suffit à l'analyseur de flux pour analyser le paquet. Dans ce cas, le paquet est d'une part transféré au destinataire et d'autre part conservé en mémoire jursqu'à ce que l'analyseur de flux, et l'entité mettant en œuvre le procédé, aient fini leurs traitements respectifs du paquet, peu importe l'ordre d'achèvement de ces traitements. Ainsi, il est possible que le paquet ait déjà été transmis au destinataire mais est néanmoins conservé en mémoire car son traitement par l'analyseur de flux n'ait pas achevé. La génération d'une référence permet ainsi, dans le cas où l'analyseur de flux et l'entité mettant en œuvre le procédé selon l'invention partagent le même espace mémoire, d'éviter de copier le paquet de données inutilement. On évite ainsi la consommation inutile de ressources logicielles requises pour la copie d'un paquet de données.

En outre, baser l'analyse du flux sur des copies de paquets de données, ou sur des références à des paquets de données, permet avantageusement de réduire la latence associée à l'analyse du flux puisque les paquets de données n'ont pas à être retenus pendant que chaque paquet est analysé. La contrepartie, dans le cas où le traitement consiste à autoriser ou interdire un flux, est que des paquets de données appartenant potentiellement à un flux interdit sont transmis au destinataire, mais, en pratique, laisser passer quelques paquets de données d'un flux interdit n'est pas dommageable, notamment dans le contexte où l'on cherche à interdire certains types de flux (tels que les flux P2P par exemple). Dans le cas où le traitement consiste à appliquer une politique de qualité de service dépendant du résultat d'analyse, la contrepartie est que la politique de qualité de service n'est mise en œuvre qu'une fois le résultat d'analyse reçu. Toutefois, cela empêche uniquement - dans le scénario le plus pessimiste - d'appliquer la qualité de service sur les premiers paquets correspondant à une vidéo conférence par exemple, ce qui n'est pas dommageable pour l'utilisateur.

Le procédé peut comprendre en outre une étape de temporisation d'une durée D prédéterminée suite à la copie du paquet de données ou à la génération de la référence, et le paquet de données peut être transféré au destinataire à l'expiration de la temporisation, uniquement :

- si le résultat d'analyse de flux a été reçu de l'analyseur de flux et le flux de données est autorisé ; ou

- si le résultat d'analyse de flux n'a pas encore été reçu de l'analyseur de flux.

Ainsi, il est permis de limiter le risque de transférer un paquet de données d'un flux interdit ou d'éviter de transférer un paquet auquel une politique de qualité de service données devrait être appliquée, tout en assurant une latence maximum garantie, ce qui est avantageux dans le contexte de flux de données tels que des flux internet.

En variante, après avoir été copié ou après avoir généré une référence, le paquet de données peut être transféré instantanément au destinataire.

Lorsqu'une référence est transférée à l'analyseur de flux, et que le paquet de données est transféré au destinataire, le paquet de données est en outre conservé dans une mémoire de l'entité mettant en œuvre le procédé. Cette mémoire est mise à disposition de l'analyseur de flux qui accède au paquet au moyen de la référence reçue.

Le procédé de filtrage est ainsi transparent en termes de latence selon ce mode de réalisation.

Dans un mode de réalisation, traiter le flux de données peut comprendre : - appliquer une politique de qualité de service dépendant du résultat d'analyse reçu ; ou

- autoriser ou interdire le flux de données sur la base du résultat d'analyse reçu.

D'autres traitements peuvent bien entendu être envisagés, l'application d'une politique de qualité de service et le filtrage (autorisation ou interdiction) d'un flux n'étant donnés qu'à titre illustratif.

En complément, la durée D prédéterminée peut être déterminée de manière statistique de manière à ce que, pour un ensemble N de flux de données, au moins une fraction k prédéterminée des N flux de données est analysable par l'analyseur de flux en une durée d'analyse inférieure à D.

La durée D est ainsi optimisée pour assurer un compromis entre une latence faible et un risque faible de transférer des paquets de données de flux interdits ou de transférer des paquets de données auxquels une politique de qualité de service aurait dû être appliquée.

Selon un mode de réalisation de l'invention, l'étape de traitement du flux de données sur la base de l'analyse reçue peut comprendre les étapes suivantes :

- stocker dans une base de données un marquage du flux de données, le marquage indiquant si le flux est autorisé ou interdit.

Le procédé peut comprendre en outre, sur chaque interception d'un paquet de données :

- identifier le flux de données correspondant au paquet reçu ;

- si le paquet de données correspond à un flux autorisé, transférer le paquet de données au destinataire ;

- si le paquet de données correspond à un flux interdit, bloquer le paquet de données.

Un deuxième aspect de l'invention concerne un produit programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l'invention, lorsque ce programme est exécuté par un processeur. Un troisième aspect de l'invention concerne un dispositif de traitement d'un flux de données échangé entre un client et une entité via un réseau de télécommunications, le flux de données comprenant un ensemble de paquets de données, le dispositif de traitement comprenant :

- une interface d'entrée pour intercepter un paquet de données appartenant à un flux de données ;

- une interface de sortie ;

- un processeur configuré pour, sur interception un paquet de données appartenant à un flux de données, le flux de données comprenant une source et un destinataire, le client étant la source ou le destinataire du flux de données, copier le paquet de données ou générer une référence au paquet de données, et pour transférer le paquet de données au destinataire via l'interface de sortie.

L'interface de sortie peut en outre être agencée pour transmettre la copie à un analyseur de flux apte à analyser le flux de données, l'interface d'entrée peut en outre être agencée pour recevoir un résultat d'analyse du flux de données depuis l'analyseur de flux et le processeur peut en outre être agencé pour traiter le flux de données sur la base du résultat d'analyse reçu.

Le processeur peut en outre être apte à temporiser d'une durée D prédéterminée suite à la copie du paquet de données ou à la génération de la référence, et à transférer le paquet de données au destinataire à l'expiration de la temporisation, uniquement :

- si le résultat d'analyse de flux a été reçu de l'analyseur de flux et le flux de données est autorisé ; ou

- si le résultat d'analyse de flux n'a pas encore été reçu de l'analyseur de flux

Un quatrième aspect de l'invention concerne un système de traitement de flux de données comprenant un dispositif de traitement selon le troisième aspect de l'invention et un analyseur de flux apte à, à partir d'un ou plusieurs paquets de données d'un flux de données, obtenir un résultat d'analyse du flux de données.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels:

- la figure 1 illustre une architecture générale d'un système selon un mode de réalisation de l'invention;

- la figure 2 est un diagramme présentant les étapes d'un procédé de traitement selon un mode de réalisation de l'invention ;

- la figure 3 est une courbe illustrant les durées d'analyse de différents flux de données ;

- la figure 4 illustre la structure d'un dispositif de traitement de données selon un mode de réalisation de l'invention.

La figure 1 illustre un système selon un mode de réalisation de l'invention.

Le système comprend un terminal utilisateur 10, appelé « client » par la suite, tel qu'un ordinateur portable ou de bureau, une tablette tactile, un Smartphone ou encore tout dispositif électronique comprenant une interface permettant de communiquer avec un point d'accès 1 1 à un réseau de télécommunications 14, tel que le réseau Internet par exemple.

Aucune restriction n'est attachée au point d'accès 1 1 qui peut être un point d'accès sans fil, de type Wi-fi par exemple, ou une liaison filaire (ADSL ou fibre par exemple).

Par exemple, dans ce qui suit, le point d'accès 1 1 est considéré comme étant une borne Wi-fi d'un campus universitaire. Comme discuté en introduction, il peut être souhaité l'interdiction de flux de données P2P pour les utilisateurs accédant à un réseau internet via un point d'accès d'un campus universitaire.

Via le réseau de télécommunications 14, le client 10 peut communiquer avec un serveur distant 15 afin de requérir des contenus multimédias, par exemple, ou plus simplement de requérir le chargement d'une page Internet, ou encore d'échanger des fichiers (en voie montante et/ou en voie descendante) avec un autre client 16 via un protocole de communication pair à pair. L'invention prévoit également que le client 10 puisse procéder au téléversement (« upload » en anglais) d'un contenu multimédia sur le serveur 15. La manière dont la communication est établie, les requêtes et réponses sont routées, est bien connue en soi et n'est pas présentée plus en détails dans ce qui suit.

Lorsque la communication est établie entre le client 10 et le serveur 15 ou le client 16, un flux de données est échangé via le réseau de télécommunications 14. Ce flux de données peut mettre en œuvre un échange de paquets de données, tels que des paquets TCP (pour « Transport Control Protocol » en anglais) par exemple, lorsque ce protocole de transport est employé. Aucune restriction n'est cependant attachée à la couche de protocoles employée pour la communication du flux de données.

Un tel flux de données peut être observé et intercepté par un dispositif de traitement 12 selon un mode de réalisation de l'invention, pouvant être situé en amont ou en aval du point d'accès 1 1 , ou pouvant être intégré dans le point d'accès 1 1 . Par exemple, le campus universitaire de l'exemple considéré ci-dessus peut être équipé d'un unique dispositif de traitement 12.

Le dispositif de traitement 12 peut être relié à un analyseur de flux 13 en charge d'analyser les paquets d'un flux de données en vue de catégoriser ce flux de données. En variante, l'analyseur de flux 13 peut être intégré dans le dispositif de traitement 12. L'analyseur de flux 13 et le dispositif de traitement 12 peuvent, selon certains modes de réalisation, partager une même mémoire.

Un tel analyseur de flux 13 est bien connu en soi et sort du cadre de l'invention. On pourra par exemple se référer au système d'analyse de trafic de la demande de brevet publiée sous le numéro EP1722509.

En tout état de cause, l'analyseur de flux 12 est apte à renvoyer au dispositif de traitement 12 un résultat d'analyse exploitable pour traiter le flux de données. Par exemple, le résultat d'analyse peut permettre une catégorisation du flux de données, par exemple, entre un groupe de flux de données P2P, et un groupe de flux de données non P2P. Ainsi, dans le cas où le dispositif de traitement 12 est dédié au filtrage, il peut interdire les flux catégorisés comme étant P2P et autoriser les flux catégorisés comme étant non P2P. En variante, la catégorisation des flux peut être utilisée par l'unité de traitement 12 pour appliquer des politiques de QoS différenciées. La figure 2 est un diagramme illustrant les étapes d'un procédé de traitement d'un flux de données selon un mode de réalisation de l'invention. Le procédé de traitement de flux peut être mis en œuvre par le dispositif de traitement 12 représenté sur la figure 1 .

Dans ce qui suit, l'exemple du filtrage de flux de données est considéré, de manière illustrative. Les flux de données peuvent alors être autorisés ou interdits par le dispositif de traitement 12. Toutefois, comme détaillé ci-dessus, l'invention s'applique également à l'application de politiques de QoS à des flux de données, et plus généralement à tout traitement de flux de données.

A une étape 201 , un paquet de données est intercepté par le dispositif d'analyse 12. Comme précédemment expliqué, le paquet de données peut être émis depuis le client 10 ou peut être destiné au client 10.

A une étape 202, un flux de données auquel correspond le paquet de données est identifié. Aucune restriction n'est attachée à la manière d'identifier un flux. Un identifiant de flux peut par exemple comprendre un identifiant de la source et un identifiant du destinataire. Le client 10 est soit la source soit le destinataire du flux identifié.

A une étape 203, il est vérifié si le flux identifié a été préalablement catégorisé dans le dispositif de traitement 12 en tant que flux autorisé ou flux interdit.

Si aucune catégorisation du flux n'a été préalablement effectuée, le paquet de données est copié à une étape 204. Une copie du paquet de données est ainsi obtenue et est transmise à l'analyseur de flux 13. En variante, dans le cas où l'analyseur de flux 13 et le dispositif de traitement 12 partagent une mémoire commune, l'étape 204 consiste à générer une référence au paquet de données.

Le paquet de données est ensuite transmis à une étape 205 au destinataire du flux (le client 10 lorsqu'il est destinataire, le serveur 15 ou le client 16 lorsque le client 10 est la source). Dans le cas où une référence est générée en lieu et place d'une copie du paquet de données, le paquet de données est en outre conservé en mémoire jusqu'à l'achèvement de l'étape 206 détaillée ci-après. Aucune restriction n'est attachée à l'ordre dans lequel le paquet de données et sa copie (ou sa référence) sont transférés, et l'agencement des étapes de la figure 2 est donné à titre illustratif.

Le fait de baser l'analyse du flux sur des copies de paquets de données ou sur des références permet de réduire la latence associée à l'analyse du flux puisque les paquets de données n'ont pas à être retenus dans l'unité de traitement 12 jusqu'à ce que le paquet soit analysé. La contrepartie est que des paquets de données appartenant potentiellement à un flux interdit sont transmis au destinataire. Toutefois, en pratique, laisser passer quelques paquets de données d'un flux interdit n'est pas dommageable, notamment dans le contexte où l'on cherche à interdire certains types de flux (tels que les flux P2P par exemple).

A une étape 206, lorsqu'une ou plusieurs copies ou références de paquets de données correspondant à un flux de données ont été transférées à l'analyseur de flux 13, un résultat de l'analyse est reçu de l'analyseur de flux 13 à une étape 206. La durée requise pour l'obtention d'un tel résultat ne peut être connue à l'avance et varie selon le flux de données à analyser. On peut représenter, comme sur la figure 3, la durée d'analyse d'un flux de données par la courbe 301 .

En abscisse est représenté un indice d'un flux de données et en ordonnée est représentée la durée d'analyse de ce flux de données. La courbe 301 est obtenue après analyse d'un nombre N de flux de données, N étant de l'ordre de grandeur de plusieurs centaines ou plusieurs milliers. Les indices des flux de données sont classés de manière à ce que les durées d'analyse soient décroissantes. En pratique, la courbe 301 obtenue est de forme hyperbolique, c'est-à-dire que seul un nombre relativement faible de flux de données requièrent une analyse longue.

A une étape 207, sur réception d'un résultat d'analyse de l'analyseur de flux 13, l'unité de traitement 12 peut catégoriser le flux de données en vue d'autoriser ou d'interdire le flux de données. Le résultat de cette catégorisation peut être exploité à l'étape 203 sur réception d'un nouveau paquet de données correspondant au même flux de données.

L'unité de traitement 12 peut stocker un ensemble de règles prenant en entrée le résultat d'analyse et retournant une catégorisation du flux parmi un flux autorisé et un flux interdit. Dans l'exemple particulier décrit ci-avant, le résultat d'analyse peut indiquer si le flux de données est un flux P2P, et seuls les flux P2P sont catégorisés en tant que flux interdits par l'unité de traitement 12. La catégorisation du flux de données (ou marquage du flux de données) peut être stockée en association avec un identifiant du flux de données dans une base de données de l'unité de traitement 12. Comme précédemment expliqué, l'identifiant du flux de données peut comprendre un identifiant du destinataire (adresse IP, ou couple numéro de port/adresse IP par exemple) et un identifiant de la source.

Ainsi, lorsqu'il est déterminé à l'étape 203 que le flux de données correspondant au paquet de données reçu a été catégorisé, le procédé comprend le filtrage à une étape 208 du paquet de données sur la base de la catégorie attribuée au flux de données qui lui correspond :

- si le flux de données est autorisé, par exemple si le flux de données est établi entre le client 10 du campus universitaire et le serveur 15 (flux non-P2P), le paquet de données est directement transféré au destinataire ;

- si le flux de données est interdit, par exemple si le flux de données est établi entre le client 10 du campus universitaire et l'autre client 16 (flux

P2P), le paquet de données est bloqué.

Comme précédemment expliqué, le paquet de données est transféré à une étape 205 au destinataire après avoir été copié à l'étape 204 (ou après avoir généré une référence). Selon un premier mode de réalisation, le paquet de données est immédiatement transféré à l'étape 205 après avoir été copié ou après avoir généré une référence (branche de gauche en sortie du bloc 204).

Selon un deuxième mode de réalisation, il peut être temporisé à une étape 209 durant une durée D prédéterminée après avoir copié le paquet de données, ou après avoir généré une référence, à l'étape 204 (branche de droite en sortie du bloc 204). A l'issue de la durée D, il est déterminé si un résultat d'analyse a été reçu, à une étape 210. Si tel n'est pas le cas, le paquet de données est transféré à l'étape 205 vers le destinataire du flux de données.

S'il est déterminé que le résultat d'analyse a été reçu à l'étape 210, il est vérifié à une étape 21 1 si le flux de données est catégorisé comme un flux autorisé. Si c'est le cas, le paquet de données est transféré à l'étape 205. Au contraire, si le flux de données est interdit, le paquet de données est bloqué à une étape 212.

Ainsi, selon le deuxième mode de réalisation, tous les paquets de données sont retardés d'une durée D tant qu'un résultat d'analyse n'a pas été reçu.

La durée D peut être avantageusement choisie à partir de la courbe 301 présentée sur la figure 3. Par exemple, D peut être la durée pour laquelle un résultat d'analyse peut être obtenu pour au moins k% des flux de données, par exemple 90%. D est ainsi calculé de manière à ce que le nombre Ni illustré sur la figure 3 représente un dixième du nombre N totale de flux de données considérés.

Ceci permet d'assurer une latence fixe, de valeur relativement faible, tout en réduisant le risque de transférer un paquet de données appartenant à un flux interdit (puisque le résultat d'analyse aura été obtenu à l'issue de la durée D dans 90% des cas).

La figure 3 représente un dispositif de traitement 12 selon un mode de réalisation de l'invention.

Le dispositif de traitement 12 comprend une mémoire vive 404 et un processeur 403 pour stocker des instructions permettant la mise en œuvre des étapes du procédé décrit ci-avant en référence à la figure 2. Le dispositif de filtrage 12 comporte aussi une base de données 405 pour le stockage de données destinées à être conservées après l'application du procédé, notamment des données de marquage de flux de données, en flux de données autorisés ou flux de données interdits ou en flux de données différenciés par politiques de QoS à appliquer, mais également des règles permettant de déduire une catégorisation de flux à partir d'un résultat d'analyse. Le dispositif de traitement 12 comporte en outre une interface d'entrée 401 destinée à recevoir les paquets de données de flux de données échangés via le point d'accès 1 1 , et à recevoir les résultats d'analyse de l'analyseur de flux 13. En variante, des interfaces d'entrées distinctes peuvent être prévues, l'une étant dédiées à l'interception des paquets de données échangés via le point d'accès, et l'autre étant dédiée à la réception des résultats d'analyse de l'analyseur de flux 13.

Le dispositif de traitement 12 comprend une interface de sortie 406 apte à transmettre d'une part des copies de paquets de données (ou des références aux paquets de données) à l'analyseur de flux 13 et d'autre part à transférer les paquets de données vers le client 10 ou vers le réseau 14. Tout comme pour l'interface d'entrée 401 , des interfaces de sortie distinctes peuvent être prévues.

Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple ; elle s'étend à d'autres variantes.