Architecture et flux de données

Drovio repose sur WebRTC pour offrir une expérience rapide et à faible latence, avec les meilleurs encodages audio et vidéo du moment, AV1, VP9 et VP8, tout en conservant une architecture pair à pair hautement sécurisée et soucieuse de la confidentialité.

Vue d'ensemble

Drovio se compose d'un logiciel serveur, Drovio Server, disponible en édition Entreprise uniquement, et d'un logiciel client, l'application Drovio. La solution fournit également un client web, qui permet de rejoindre n'importe quelle session de partage d'écran ou n'importe quel appel sans rien télécharger, installer ni souscrire.

Le parcours interactif ci-dessous suit une session de l'authentification jusqu'aux flux, et indique les protocoles et les ports mis en jeu à chaque étape.

Flux de connexion

1 · Authentification2 · Signalisation3 · STUN4 · Flux pair à pair5 · Repli TURN

HTTPS · TLS 1.2 / 1.3 · 443

L'authentification sur Drovio se fait en HTTPS, TLS 1.2 ou 1.3. Des connexions WebSocket sont ensuite ouvertes entre Drovio Server et les clients pour porter l'ensemble de la signalisation.

En édition Entreprise, les protocoles et les suites de chiffrement activés se règlent avec http.tls_protocols et http.tls_cipher_suites.

WebSocket (WSS) · 443

La signalisation, au sens de WebRTC, désigne l'échange des capacités de diffusion, les codecs audio et vidéo, et des capacités réseau entre les extrémités, c'est-à-dire les clients. Les SDP et les candidats ICE circulent entre l'hôte et l'invité par l'intermédiaire de Drovio Server, sur WebSocket.

Le SDP, Session Description Protocol, sert à énumérer les flux pris en charge. En parallèle, les candidats ICE disponibles sont collectés sur chaque extrémité, chacun désignant une adresse IP, un port et une couche de transport possibles. Ils sont échangés et forment des paires de candidats. Plusieurs paires sont retenues mais une seule est sélectionnée pour porter la communication pair à pair, sauf en cas de réinitialisation ICE, qui impose de renégocier la connexion et d'en sélectionner une autre. Drovio s'en charge de façon transparente.

STUN · UDP 443

Pendant la signalisation, les clients peuvent s'appuyer sur un serveur STUN, Session Traversal Utilities for NAT, pour traverser un NAT. Leur seule raison d'être est de répondre à la question « quelle est mon adresse IP publique ? ».

DTLS-SRTP / SCTP · UDP 1024-65535

Les connexions pair à pair s'établissent ensuite directement entre les clients. Un flux vidéo en direct de l'écran ou de l'application de l'hôte est envoyé aux invités, accompagné le cas échéant d'un flux audio, microphone ou son du système. Les invités peuvent eux aussi partager leur microphone et envoyer des actions de souris et de clavier, que l'hôte peut retirer à tout moment, voir Accès et contrôle des sessions. Drovio Server n'intervient pas pendant la session de partage d'écran, sinon pour collecter quelques statistiques destinées à améliorer l'expérience, voir Statistiques.

TURN · UDP/TCP 443 · UDP 49152-65535

Lorsque les pare-feux ou les règles de NAT sont trop restrictifs, les connexions directes ne peuvent pas s'établir entre les clients. Des serveurs relais, TURN pour Traversal Using Relays around NAT, servent alors à transmettre les paquets d'un client à l'autre. La communication reste chiffrée de bout en bout : un relais transmet des paquets qu'il ne peut pas déchiffrer, les clés étant négociées entre les seules extrémités.

En édition Cloud, les serveurs STUN et TURN sont hébergés sur AWS et déployés dans le monde entier. Ils portent environ 15 % des sessions de partage d'écran, et c'est le serveur géographiquement le plus proche de l'utilisateur qui est employé le cas échéant. En édition Entreprise, ces serveurs sont facultatifs : nous pouvons vous aider à déployer les vôtres lorsque le partage d'écran doit passer par Internet, voir Serveur relais (TURN).

Un relais n'est pas un proxy ouvert. Obtenir une allocation exige des identifiants à durée limitée dérivés d'un secret partagé, les allocations expirent au bout de quelques minutes, et le relais refuse les destinations de bouclage et de multicast, si bien qu'il ne peut pas être retourné contre des réseaux internes. TLS 1.0 et 1.1 y sont désactivés, sa liste de suites de chiffrement est restreinte aux suites ECDHE modernes, et il n'annonce pas sa version logicielle.

Récapitulatif des protocoles et des ports

Étape	Protocole(s)	Port(s)
Authentification	HTTPS (TLS 1.2 / 1.3)	TCP 443
Signalisation	HTTPS et WebSocket (WSS)	TCP 443
STUN	UDP	443
Partage d'écran (pair à pair)	DTLS-SRTP, DTLS-SCTP	UDP 1024-65535, en sortie et en retour
TURN (relais)	UDP / TCP pour joindre le relais, puis UDP pour les flux relayés	443, puis 49152-65535

À propos de la plage pair à pair. 1024-65535 n'est pas une liste de ports à ouvrir sur un serveur. Ce sont les ports média de WebRTC : à chaque session, chaque extrémité choisit un port éphémère qui lui est propre et l'annonce comme candidat ICE. Ce qu'un pare-feu doit autoriser, c'est l'UDP sortant et son trafic retour, pas un port fixe. Là où ce n'est pas possible, la session bascule sur TURN et tout passe par le port 443.

À propos des ports du relais. 49152-65535 est la plage d'allocation du serveur relais lui-même, pas celle des clients. En édition Cloud, nos relais n'écoutent que sur le 443, en UDP comme en TCP, ce qui franchit la plupart des pare-feux d'entreprise. En édition Entreprise, vous choisissez les ports : le guide Serveur relais (TURN) suggère le 80 et le 443 pour la même raison.