La présente invention concerne le domaine des infrastructures de réseaux informatiques et plus précisément l'accès à des services distants via un navigateur web installé sur un poste client.

Etat de la technique

On connaît dans l'état de la technique des solutions mettant en œuvre un serveur intermédiaire de transcodage, par exemple le serveur web ou un serveur spécifique.

La demande de brevet américain US 20080313545 décrit un exemple connu de systèmes et des procédés ("outils") qui permettent à un utilisateur d'accéder à un bureau ou à une application à distance, et d' interagir avec ceux-ci, sans avoir besoin d'installer un module d'extension ou un logiciel en plus d'un navigateur Web. Selon certains modes de réalisation, les outils comprennent la double mise en mémoire tampon d'éléments graphiques qui affichent le bureau ou l'application à distance, et la mise en mémoire cache d'images qui sont répétées. Ces outils peuvent également comprendre l'identification de la partie du bureau ou de l'application qui a changé, et ensuite la transmission de la partie changée. On connaît aussi la demande de brevet US 20140372508 Al

(Native client tunnel service for client-serveur communication) .

Dans des modes de réalisation particuliers, un dispositif client compatible HTML charge un script HTML. Le dispositif client exécute le script HTML avec une spécification de Native Client. Le dispositif client reçoit des informations d'utilisateur spécifiant une connexion. Le dispositif client crée un port vers l'avant ou un dispositif de tunnel, et se connecte à un hôte cible par le port avant ou le dispositif de tunnel.

On connaît aussi dans l'état de la technique la demande de brevet chinois CN102833338 décrivant un procédé comprenant les étapes suivantes :

- un serveur de bureau distant envoie un paquet de données de protocole de bureau distant à un serveur Web ;

- Le serveur Web acquitte le paquet de données de protocole HTTP / HTTPS ;

- une unité de conversion de protocole côté client convertit le paquet de données de protocole HTTP / HTTPS en paquet de données de protocole de bureau à distance.

Un module d'analyse de protocole de bureau à distance restaure le paquet de données de protocole de bureau à distance dans une commande d'affichage spécifique, et la commande d'affichage est traitée à travers un module de protocole d'affichage de bureau à distance. Le résultat est envoyé à la page interactive du côté client et affiche des images d'un ordinateur de bureau distant vers un utilisateur. Inconvénients de l'art antérieur

Les solutions de l'art antérieur ne sont pas totalement satisfaisantes, car les performances sont limitées par les capacités de calcul, de tenue de charge et de la capacité mémoire des serveurs passerelles de transcodage.

Les serveurs passerelles de transcodage [gateway] de l'art antérieur doivent conserver un état mémoire correspondant à chaque connexion ouverte, en raison des protocoles connectés utilisés. Lorsque le nombre d'équipements clients est important, la capacité des serveurs passerelles de transcodage arrive à saturation et limite le nombre de connexions, sauf à augmenter le matériel.

Par ailleurs, lors d'évolutions du protocole, il est nécessaire de réécrire le code dans le langage du navigateur et de mettre à jour les navigateurs sur les postes clients à partir du serveur web.

D'autre part, dans les solutions de l'art antérieur, on met en œuvre deux protocoles :

un premier protocole initial entre le serveur terminal et le serveur intermédiaire (gateway), qui est un protocole complet

- un second protocole entre le poste client et le serveur intermédiaire (gateway), qui est un sous-ensemble ou un équivalent simplifié du protocole initial.

Dans les simplifications, les fonctions de négociation du protocole sont généralement supprimées. De ce fait ce protocole est moins souple et implique que tous les clients fonctionnent de la même façon, sans permettre la coexistence de clients de générations différentes sur une même infrastructure .

Le brevet chinois CN102833338 ne divulgue pas les caractéristiques de l'invention et notamment le fait que le code informatique dudit protocole standard est constitué par un composant JavaScript comportant trois couches :

une couche d ' interfaçage avec les périphériques d ' entrée-sortie

- une couche d'interface réseau assurant le pilotage du websocket

une couche protocolaire constituée par un code standard compilé en ASM.js ou Webassembly à partir d'un code source dans un langage haut niveau. Solution apportée par l'invention

Afin de remédier à cet inconvénient, la présente invention concerne selon son acception la plus générale un procédé de connexion d'un équipement client local à une ressource informatique distante, par l'établissement d'une session informatique conforme à un protocole standard consistant à : - exécuter sur l'équipement client une application de navigation web

- ouvrir un premier tunnel [websocket] avec un serveur

GATEWAY

- ladite ouverture du premier tunnel entre l'équipement client et la GATEWAY commandant l'ouverture d'une connexion réseau avec ladite ressource distante.

Cette solution résout le problème du goulot d'étranglement sur le serveur passerelle de transcodage [gateway] résultant de l'utilisation partagée du code, car le traitement réalisé est minimal. La latence réseau dépend des caractéristiques du poste client, la latence additionnelle introduite par la GATEWAY est minimale. La charge du serveur nécessaire à un transcodage est déportée sur le client, ce qui implique que le serveur peut supporter plus de sessions simultanées pour une plus faible consommation électrique Enfin, le flux protocolaire utilise exclusivement des infrastructures réseau standard et il est sécurisé via la couche de sécurité HTTPS du navigateur Web.

Les solutions naturelles pour l'homme du métier consisteraient: - soit à diviser le client RDP en deux composants : un composant restreint embarqué dans le browser et un composant serveur autonome fonctionnant sur un serveur mandataire. Les deux composants communiquant entre eux via un protocole simplifié à travers un lien réseau rapide. Cette architecture est très commune. On la retrouve non seulement pour quelques clients RDP ou SSH embarqués dans un navigateur Web, mais aussi pour tous les clients webmail.

C'est la solution retenue par le brevet chinois

CN102833338. Contrairement à cette solution, l'invention prévoit de faire transiter les paquets RDP natifs jusqu'au navigateur à l'intérieur d'un tunnel Websocket.

- soit à se reposer sur une couche d'extension (plugin) spécifique au browser (Microsoft ActiveX, Google Native Client

NaCL) qui permet d'accéder à des ressources systèmes privilégiées et communiquant avec une application Web.

Il est connu que la technique de compilation de code C/C++ vers WebAssembly d'une application existante ne fonctionne pas lorsque le code source comporte des opérations bloquantes (voir la demande de brevet américaine US 20170139693 « Code exécution method and device) ». L'architecture objet de l'invention permet en particulier de lever cette contrainte dans le cadre de couches réseau protocolaires.

Selon l'invention, l'application Web est exécutée sur le client local calcule des paquets de données conformément à un protocole standard (RDP ou SSH par exemple) et commande la transmission desdits paquets de données à la ressource distante dans le format natif dudit protocole, sans transcodage ou transformation autre que les traitements standards des websocket, par l'intermédiaire du serveur gateway (Proxy websocket) assurant le transfert sans modification du paquet reçu de l'équipement client, au serveur distant et en ce que: - le code informatique dudit protocole standard est constitué par un composant JavaScript comportant trois couches une couche d ' interfaçage avec les périphériques d ' entrée-sortie

- une couche d'interface réseau assurant le pilotage du websocket

- un code protocolaire standard compilé en ASM.js ou Webassembly à partir d'un code source dans un langage haut niveau.

Le procédé selon l'invention présente les avantages suivants :

La mise à jour du code navigateur en fonction des évolutions du protocole est réalisée par une souche commune et une mise à jour du seul code client. On évite ainsi de procéder à la fois à la mise à jour du code exécuté par les serveurs passerelles de transcodage et aux mises à jour des applications embarquées par les navigateurs sur les postes clients.

Contrairement à l'art antérieur, dans le procédé décrit par l'invention il n'est pas nécessaire de mettre à jour le serveur de transcodage. - La solution selon l'invention permet par ailleurs une meilleure utilisation de la bande passante, car les étapes de transcodage additionnelles et l'utilisation d'un second protocole spécifique pour le transfert au client Web sont évitées. Un effet technique important concerne la réduction du problème du goulot d'étranglement sur le serveur passerelle de transcodage [gateway] résultant de l'utilisation partagée du code, car le traitement réalisé est minimal. La latence réseau dépend des caractéristiques du poste client, la latence additionnelle introduite par la GATEWAY est minimale.

La charge du serveur nécessaire à un transcodage est déportée sur le client, ce qui implique que le serveur peut supporter plus de sessions simultanées pour une plus faible consommation électrique.

Enfin, le flux protocolaire utilise exclusivement des infrastructures réseau standard et il est sécurisé via la couche de sécurité HTTPS du navigateur Web.

Description détaillée d'un exemple non limitatif de 1 ' invention La présente invention sera mieux comprise à la lecture de la description détaillée d'un exemple non limitatif de l'invention qui suit, se référant aux dessins annexés où :

la figure 1 représente une vue schématique de l'architecture fonctionnelle d'une infrastructure selon l'invention

la figure 2 représente une vue schématique de l'architecture du poste client.

Description de l'architecture fonctionnelle un serveur d'application terminal (1) un ou plusieurs serveur informatique passerelle websocket/TCP socket (2) une pluralité de postes clients exécutant notamment une application de type navigateur web (3). Le serveur d'application terminal (1) communique avec l'environnement extérieur avec un protocole standard, par exemple RDP ou SSH. La solution selon l'invention n'implique aucune intervention ni modification du serveur d'application terminal (1), ni de ses interfaces de communication.

L'essentiel de l'invention se traduit par les modifications intervenant au niveau de l'application embarquée dans le navigateur (4), telle que détaillée par la Figure 2 et exécutée par le poste client (3).

Cette application embarquée est constituée de plusieurs couches :

- une couche d'affichage (7) exécutant les ordres d'affichage provenant du protocole, par exemple bitmap, tracé de caractères, de texte, d'images,..., en fonction du protocole RDP ou SSH. Cette couche réalise aussi les fonctions d'interaction avec le clavier, souris et plus généralement les périphériques d'entrée.

Cette couche est constituée par un programme JavaScript écrite spécifiquement pour le protocole, par exemple dans un langage de type HTML5. Cette couche est disponible pour une pluralité d'équipements, tels que des ordinateurs, des téléphones cellulaires, des tablettes à écran tactile, etc.

Une couche protocolaire (6) compilée vers asm.js ou Webassembly, à l'aide par exemple de la chaîne de compilation Emscripten, assemblée à partir d'une souche de code écrite dans un langage haut niveau, typiquement en C ou C++. Cette couche implémente le décodage et l'encodage du protocole réseau, à partir de librairies connues et disponibles sous forme de code source, par exemple le code ReDemPtion (nom commercial de la société WALLIX, disponible sous licence libre, qui constitue une implémentation libre du protocole RDP de la société MICROSOFT) .

Cette couche protocolaire pilote de préférence les fonctions de préchargement des données protocolaires de la couche d'entrée/sortie (5).

Une couche d'entrée/sortie (5) basée sur le protocole HTML5 Websocket. Cette couche d'entrée/sortie (5) précharge les paquets protocolaires dans la mémoire vive du poste client, de façon à permettre un fonctionnement asynchrone, et d'adapter la solution selon l'invention à un protocole essentiellement synchrone .

Lors de l'initiation d'une connexion, trois solutions sont prévues :

La première solution prévoit que le serveur passerelle (2) impose la cible (terminal d'application prédéfinie (1), et non modifiable par le client (3)).

La seconde solution prévoit une négociation préalable pour la configuration de la cible (1), par mécanisme lié au serveur passerelle (2)

La troisième solution prévoit l'installation d'une extension de protocole spécifique, commandant l'ouverture de la session, préalable au démarrage du protocole principal.

La passerelle (2) assure une fonction de simple relai du protocole sous-jacent, entre la couche de transport WEBSOCKET (5) et la couche de transport entre la passerelle (2) et le serveur d'application terminal (1)· Contrairement aux solutions de l'art antérieur, la passerelle (2) n'assure aucune fonction intelligente telle que le décodage du protocole, la mise en cache de bitmap, etc., fonctions qui, selon l'invention, sont réalisées par l'application embarquée dans le navigateur du poste client.

La passerelle (2) peut exécuter un code standard de type module APACHE assurant le relai WEBSOCKET vers le serveur d'application terminal (1)