Arrière-plan de l'invention

La présente invention se rapporte au domaine général des serveurs proxy (en anglais « proxy server »), de tels serveurs faisant fonction d'intermédiaire entre les ordinateurs d'un réseau local et le réseau Internet.

La présente invention s'intéresse plus précisément, dans une architecture de type client/serveur, à la mesure de l'usage, par un dispositif client donné, d'une application accessible auprès d'un serveur d'application.

La figure 1 représente de façon schématique une utilisation connue d'un relais inverse 20 (en anglais « reverse proxy ») pour mesurer l'usage, par un dispositif client C d'un site Web hébergé par un dispositif serveur S, ces deux équipements étant connectés au réseau Internet.

Dans l'architecture conventionnelle représentée ici, la référence 10 représente un portail d'accès à plusieurs applications, pouvant être sélectionnées par le dispositif client C.

On supposera que ce portail 10 est hébergé par un fournisseur d'accès auquel le dispositif client C doit se connecter pour accéder au réseau Internet, et qu'il remplit la fonction de serveur de contrôle d'accès

Ainsi, et de façon connue, le dispositif client C émet, pour se connecter au réseau Internet, une réponse HTTP 1 à une requête d'authentification initiée par le portail 10, cette réponse comportant par exemple un identificateur (login) et un mot de passe.

On supposera également, qu'après cette phase d'authentification, le client C envoie au dispositif de contrôle d'accès une requête HTTP 2 pour sélectionner l'application désirée parmi celles offertes par le portail 10. En réponse à cette requête HTTP de sélection 2, le portail 10 envoie une réponse HTTP 4 au dispositif client. De façon connue, si le dispositif client C dispose des habilitations nécessaires, cette réponse HTTP 4 comporte l'adresse IP (Internet Protocol) et un numéro de port TCP 30 (Transmission Control Protocol) pour accéder au serveur applicatif S hébergeant le site Web désiré.

En pratique cette adresse IP et ce numéro de port TCP 30 sont ceux d'un relais inverse 20 installé en coupure de flux entre le dispositif client C et le serveur d'application S pour mesurer l'usage de l'application précitée par le dispositif client C. On supposera dans cet exemple que l'accès à ce site Web requiert une authentification préalable auprès du serveur applicatif S.

De façon connue, le relais inverse 20 se comporte comme un serveur proxy en ce qu'il répond ainsi aux requêtes du client C et effectue les requêtes vers le serveur d'application S. Il se comporte comme un serveur HTTP vis-à-vis du dispositif client C et comme un client HTTP vis- à-vis du serveur S.

Ainsi, toute requête HTTP, envoyée par le dispositif client C à destination du serveur S est interceptée par le relais inverse 20 et relayée au serveur applicatif 20 sous la forme d'une autre requête HTTP. En particulier, le relais inverse 20 intercepte la requête HTTP d'authentification 5 envoyée par le dispositif client C au dispositif serveur S pour accéder au site Web, et relaye cette requête 5 vers le dispositif serveur S sous la forme d'une requête HTTP 6.

Après avoir validé cette authentification, le relais inverse 20 intercepte toutes les requêtes HTTP d'usage 7 envoyées par le dispositif client C à destination du serveur d'application S, et les réponses HTTP à ces requêtes d'usage 7 et en déduit au moins une mesure de l'usage de l'application précitée par le client C. Cette mesure peut notamment être constituée par - une mesure de volume, obtenue en comptabilisant le volume d'octets que représentent ces requêtes et réponses ; et/ou par :

- une mesure de durée, obtenue à partir des dates d'interception des requêtes d'usage 7 et de leurs réponses.

Bien entendu, le relais inverse 20 relaye les requêtes HTTP d'usage 7 vers le serveur d'application S sous la forme de requêtes HTTP 8.

Comme expliqué ci-dessus, la mesure de l'usage de l'application du serveur S par le dispositif client C, repose sur l'analyse des requêtes et des réponses HTTP échangées entre le client C et le serveur applicatif S. Une telle technique nécessite donc une interprétation du protocole applicatif par le relais 20, par exemple du protocole HTTP

lorsque l'application concerne l'accès à un site Web hébergé par Ie serveur S, ou du protocole P0P3 lorsque le serveur S est un serveur de courrier électronique.

En conséquence, le relais 20 décrit ci-dessus, placé en coupure de flux entre le client C et le serveur d'application S, ne peut pas mesurer l'usage d'une application s'il n'est pas en mesure d'interpréter le protocole applicatif utilisé entre ce client C et ce serveur S.

Objet et résumé de l'invention La présente invention a donc pour but principal de pallier cet inconvénient en proposant un procédé de mesure de l'usage d'une application accédée par un dispositif client auprès d'un serveur de cette application sur un réseau de communication en mode connecté, notamment sur tout réseau acceptant le protocole IP (Internet Protocole). Ce procédé comporte :

- une étape d'établissement d'un canal de communication entre le dispositif client et un relais inverse en coupure de flux entre le dispositif client et le serveur, ce canal étant établi sur un port de communication du relais inverse, ce port de communication étant alloué dynamiquement en vue d'une connexion avec le dispositif client et ouvert pour une seule connexion ; et

- une étape de mesure, par le relais inverse, de l'usage de ce canal de communication.

Ainsi, le procédé de mesure selon l'invention peut être utilisé pour mesurer l'usage par le dispositif client de l'application précitée, en observant le flux échangé sur le port de communication alloué dynamiquement et réservé à cette seule connexion, même si les données circulant dans le canal de communication sont inintelligibles pour le relais inverse. L'homme du métier comprendra qu'il s'agit là d'une utilisation privilégiée de l'invention, mais qu'elle s'applique aussi dans le cas où le protocole applicatif entre le dispositif client et le serveur d'application peut être interprété par le relais inverse.

Le procédé selon l'invention peut comporter une étape préalable d'authentification du dispositif client.

Dans un premier mode de réalisation, cette étape préalable d'authentification du dispositif client est effectuée par un portail, l'étape d'ouverture du port de communication étant commandée par ce portail. Ainsi, le canal de communication est associé par le portail à un dispositif client dûment authentifié, et l'usage applicatif de ce canal de communication peut être attribué à un identificateur de ce client.

Dans une variante préférée de réalisation, le choix du port de communication à attribuer à un dispositif client est à la charge du portail.

En alternative, le portail n'intervient pas dans le choix du port de communication à attribuer à un dispositif client, ce choix étant à la charge du relais inverse.

Cette variante autorise ainsi le pilotage du relais inverse par plusieurs portails. Elle est notamment appropriée dans une architecture redondante dans laquelle un portail de secours visant à pallier les défaillances du premier portail, utilise la même gestion centralisée d'attribution du canal de communication par le relais inverse.

Dans un mode préféré de réalisation, le port de communication alloué dynamiquement est fermé après une durée prédéterminée, empêchant ainsi toute nouvelle tentative de connexion sur ce port par un client non autorisé qui essaierait de se connecter à ce port par essai aléatoire ou systématique de ports de communication disponibles (technique du « port scanning »).

Corrélativement, l'invention vise un relais inverse susceptible d'être positionné en coupure de flux entre un dispositif client et un serveur sur un réseau de communication en mode connecté, ce relais inverse comportant :

- des moyens d'établissement d'un canal de communication entre le dispositif client et un port de communication de ce relais inverse, ce port de communication étant alloué dynamiquement en vue d'une connexion avec le dispositif client et ouvert pour une seule connexion ;

- des moyens de mesure de l'usage du canal de communication précité pour le transport des données échangées entre le dispositif client et le serveur d'application pour lors de l'accès à une application déterminée. Selon une implémentation préférée, le procédé de mesure selon l'invention peut être mis en œuvre par un programme d'ordinateur.

En conséquence, l'invention vise également un programme d'ordinateur stocké sur un support d'informations, ce programme étant susceptible d'être mis en œuvre par un relais inverse en coupure de flux entre un dispositif client et un serveur sur un réseau de communication en mode connecté, ce programme comportant :

- des instructions adaptées à ouvrir un port de communication du relais inverse, ce port de communication étant alloué dynamiquement en vue d'une connexion avec le dispositif client et ouvert pour une seule connexion ; et - des instructions adaptées à mesurer l'usage d'un canal de communication établi entre le dispositif client et ce port de communication pour le transport de données échangées entre le dispositif client et le serveur d'application lors de l'accès à une application déterminée.

L'invention concerne également un support d'informations lisible par un relais inverse, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, et comportant des instructions d'un programme d'ordinateur tel que mentionné brièvement ci-dessus. L'invention vise aussi un système de mesure de l'usage d'une application accédée par un dispositif client auprès d'un serveur de cette application sur un réseau de communication en mode connecté, ce système comportant :

- un relais inverse en coupure de flux entre le dispositif client et le serveur ;

- des moyens d'ouverture d'un port de communication du relais inverse, ce port de communication étant alloué dynamiquement en vue d'une connexion avec le dispositif client et ouvert pour une seule connexion ; - des moyens d'établissement d'un canal de communication entre le dispositif client et ce port de communication pour le transport des données échangées entre le dispositif client et le serveur d'application lors de l'accès à l'application précitée ; et

- des moyens de mesure de l'usage du canal de communication. Dans un mode particulier de réalisation, ce système de mesure comprend des moyens d'authentification du dispositif client, le port de

communication étant ouvert uniquement avec ledit dispositif client authentifié.

Les avantages particuliers du relais inverse, du programme d'ordinateur, du support d'informations et du système de mesure étant identiques à ceux du procédé de mesure mentionné précédemment, ils ne seront pas rappelés ici.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

- la figure 1, déjà décrite, est un schéma illustrant le principe d'un procédé conventionnel de mesure de l'usage d'une application; et - la figure 2 est un schéma illustrant le principe d'un procédé de mesure de mesure de l'usage d'une application conforme à l'invention dans un mode préféré de réalisation.

Description détaillée d'un mode de réalisation La figure 2 illustre, dans le contexte du réseau Internet, le principe d'un procédé de mesure de mesure de l'usage d'une application conforme à l'invention dans un mode préféré de réalisation.

Dans le mode de réalisation décrit ici, on supposera que le dispositif client C émet, pour se connecter au portail 10, une réponse 1 à une requête d'authentification initiée par le portail 10, cette réponse 1 étant suivie, par une requête d'usage 2 pour choisir l'application désirée. Comme dans le cas de l'architecture conventionnelle décrite en référence à la figure 1, le procédé de mesure selon l'invention utilise un relais inverse 20 en coupure de flux entre le dispositif client C et le serveur d'application S.

Conformément à l'invention, le portail 10 établit un canal de communication, pour une seule connexion, entre le dispositif client C et un port de communication 40 du relais inverse 20, ce port de communication

40 étant alloué dynamiquement.

Dans le mode préféré de réalisation décrit ici, ce port de communication 40 est constitué par un couple formé par une adresse IP et un port TCP.

Dans le mode préféré de réalisation décrit ici, le relais inverse 20 attribue ce port dynamique 40 et communique les caractéristiques de ce port de communication 40 au portail 10.

Dans une variante de réalisation, le portail 10 attribue ce port dynamique 40 et communique les caractéristiques du port de communication 40 au relais inverse 20. Quoiqu'il en soit, Ie portail 10 envoie au dispositif client C, sous la forme d'une réponse 4 à la requête d'usage 2, l'adresse IP et le numéro de port de communication TCP 40 du relais inverse 20.

Comme mentionné précédemment, l'invention trouve une application privilégiée lorsque le relais inverse 20 ne comporte pas de moyens d'interprétation du protocole applicatif entre le client C et le serveur application S.

En effet, il suffit au relais inverse 20 de surveiller le port de communication TCP 40 pour mesurer l'intégralité du trafic établi entre le client C et le serveur applicatif S, même si les paquets TCP échangés entre ces deux entités sont inintelligibles pour le relais inverse 20.

Cette mesure peut notamment être constituée par :

- une mesure de volume, obtenue en comptabilisant le volume d'octets que représentent ces paquets TCP ; et/ou par :

- une mesure de durée, obtenue à partir des dates d'établissement et de rupture des flux TCP.

Bien entendu, et comme dans le cas de l'architecture conventionnelle de la figure 1, le relais inverse 20 se comporte comme un serveur proxy :

- en ce qu'il relaye, à destination du serveur d'application S, sous la forme de paquets TCP p', les paquets TCP p reçus du dispositif client C ; et

- en ce qu'il relaye, à destination du dispositif client C , sous la forme de paquets TCP q', les paquets TCP q reçus du serveur d'application S.

Dans le mode préféré de réalisation décrit ici, le port TCP dynamique 40 est fermé, après une durée prédéterminée, à toute tentative de nouvelle connexion.

Bien entendu, l'homme du métier comprendra que cette durée prédéterminée doit être suffisante pour permettre l'envoi, par le portail 10, de la réponse 4 au dispositif client C, et l'envoi du premier paquet TCP p par le dispositif client C dans le canal de communication.

Cette durée prédéterminée peut par exemple être choisie égale à dix secondes.