Protocole et modes de connexion

Reemo établit une session temps réel entre un client (client web ou Reemo Thin Client) et une ressource cible (agent Reemo Desktop, conteneur ou machine virtuelle). Cette session transporte l’affichage distant, l’audio et les événements de contrôle (clavier, souris, périphériques) dans les deux sens.

Pour acheminer ce flux, Reemo s’appuie sur deux familles de transport : WebRTC, en liaison directe ou relayée, et WebSocket. Le mode retenu dépend de la topologie réseau et du choix d’infrastructure.

Les trois modes de connexion

Un client et le Reemo Agent se connectent selon trois modes : WebRTC direct en UDP pair à pair, WebRTC relayé où le client et l’agent contactent tous deux un serveur TURN, et WebSocket où ils contactent tous deux un relais RELAYWS.

Les trois modes de connexion entre le client et le Reemo Agent.

WebRTC direct

Le client et la ressource communiquent en pair à pair, sans intermédiaire sur le chemin média. WebRTC utilise le protocole ICE pour découvrir le chemin le plus direct, aidé par STUN pour franchir un NAT simple.

C’est le mode le plus performant : latence minimale et aucune bande passante consommée sur un relais. Il suppose qu’un chemin direct peut s’établir entre les deux pairs.

WebRTC relayé (TURN)

Quand aucune liaison directe n’est possible — NAT symétrique, pare-feu d’entreprise, réseau n’autorisant que le trafic sortant vers le port 443 — WebRTC bascule sur un serveur TURN, qui relaie l’intégralité du flux.

Ce repli est négocié par ICE au sein de la même connexion WebRTC : le client n’a rien à configurer. La session est garantie au prix d’une consommation de bande passante sur le relais.

WebSocket (RELAYWS)

Le mode WebSocket est une alternative à WebRTC, choisie au niveau de l’infrastructure via l’environnement RELAYWS. À chaque connexion, un conteneur de relais dédié est déployé à la volée : le client et la ressource s’y connectent, et le conteneur transfère les paquets dans les deux sens.

Ce mode isole chaque connexion dans son propre conteneur et n’exige que des flux WebSocket sur HTTPS, ce qui convient aux réseaux très contraints où WebRTC n’est pas utilisable.

Comment Reemo choisit le mode

  • Le choix WebRTC ou WebSocket se fait au niveau de l’infrastructure : une instance qui déploie RELAYWS achemine les sessions en WebSocket, sinon elles passent par WebRTC.

  • En WebRTC, le choix direct ou relayé est automatique et négocié connexion par connexion par ICE : le direct est tenté en premier, le relais TURN sert de repli.

Le résultat est transparent pour l’utilisateur : la session s’établit avec le meilleur transport disponible selon le réseau et la configuration de l’instance. Voir Flux réseau & ports pour les ports et les flux mis en jeu.