Dans ce blog, nous continuerons notre exploration de WebRTC en nous concentrant sur les différentes architectures de connexions généralement utilisées. Celles-ci correspondent aux différentes manières dont les appareils sont connectés entre eux. Mais avant de plonger dans le sujet, nous avons besoin de revoir quelques notions sur cette technologie.
Quelques notions importantes
Le « Peer-to-peer » c'est quoi ?
Le « peer-to-peer » (pair-à-pair) ou « P2P » est une façon d'échanger des données où chaque entité est à la fois client et serveur. Les systèmes pair-à-pair peuvent être complètement décentralisés ou connectés à un serveur central qui s'occupe d'une partie de l'échange. Il assiste les connexions et aide au partage, même si l'information transite de poste en poste. Généralement, ce modèle est utilisé pour l'échange de fichiers, le calcul distribué ou la communication. En essence, cela permet aux informations de passer directement entre deux machines sans passer par un intermédiaire. Les différents appareils du réseau sont appelés des « nœuds ».¹
Les serveurs STUN and TURN
Commençons par les serveurs STUN (« Session Traversal Utilities for NAT »). Il s'agit d'un protocole qui est utile à d'autres, comme ICE, dont nous parlerons plus tard, pour mieux travailler avec le NAT. Bien qu'il soit mentionné qu'il s'agisse d'une série d'utilitaires, on parle plus souvent de serveurs STUN. Ceux-ci ont les utilitaires mentionnés et sont utilisés par des appareils pour leur permettre de découvrir leur adresse IP et leurs ports disponibles à l'extérieur d'un NAT.³ Il s'agit donc d'une méthode pour trouver les informations que WebRTC peut utiliser pour se connecter à des appareils au sein d'un réseau privé.
Même si l'utilisation d'un serveur STUN peut généralement être suffisante, certains réseaux sont plus stricts avec leurs pare-feu ou leur NAT, ce qui empêche de trouver des routes de connexion directes. Dans ces cas-là, il est plus difficile de trouver des informations utiles pour connecter directement deux appareils entre eux. C'est là qu'entrent en jeu les serveurs TURN (« Traversal Using Relays around NAT »). Ceux-ci agissent comme relais entre les hôtes pour le transfert de données. Ils sont généralement sur le réseau public et permettent de contourner les problèmes de réseaux restrictifs ou d'autres liés aux NAT.⁴
Généralement, il est facile de trouver des serveurs STUN gratuits, comme ceux de Google, mais pour ce qui est des serveurs TURN, étant donné les ressources nécessaires pour agir en tant que relais, surtout dans le contexte de WebRTC où des flux vidéo et audio sont transférés, ils sont payants ou ont des limitations quant à la quantité de données transférées.
Parlons « ICE Candidate »
Souvent, lorsqu'on commence à en apprendre un peu plus sur WebRTC, on retrouve fréquemment la mention d'« ICE candidate », que ce soit dans le nom des méthodes ou bien lors du débogage. On en vient donc naturellement à se demander ce que c'est.
Commençons donc par l'acronyme ICE, qui signifie « Interactive Connectivity Establishment ». Il s'agit d'une technique utilisée lorsqu'on traverse un NAT, lors de transferts de données généralement basés sur UDP, bien qu'elle prenne aussi en charge les connexions TCP. ICE échange une série d'adresses IP et de ports, qui sont découverts à l'aide de STUN ou TURN selon le réseau, pouvant servir à la connexion, et ces adresses sont testées à l'aide de STUN jusqu'à ce qu'une soit validée. C'est ici qu'entrent en jeu les « ICE candidates ». En effet, elles définissent des paquets contenant les adresses IP et ports qui peuvent possiblement mener à une connexion durable.²
Serveur de signals
Malgré le fait qu'une connexion WebRTC soit pair-à-pair, et donc ne dépende pas d'un serveur externe, il nous faut plusieurs informations avant même de créer le lien entre les deux machines, comme les « ICE candidates » que j'ai expliquées plus tôt, ou bien d'autres informations sur la connexion, comme les types de données qui seront transférées.
En raison de cela, il nous faut un moyen de communiquer ces informations. C'est là qu'entre en jeu un serveur de signalisation, généralement un serveur WebSocket, qui est utilisé pour transférer les informations, sous format JSON, afin d'établir le lien entre les machines.
Archtectures
Maintenant que nous avons une meilleure idée de certaines notions liées à WebRTC, nous pouvons plonger dans les différentes architectures utilisées.
« One-on-one »
Il s'agit là de l'architecture de connexion WebRTC la plus basique, celle dont nous avons parlé plus tôt : une connexion pair-à-pair qui utilise STUN ou TURN, les « ICE candidates », et un serveur de signalisation. Une fois la connexion établie grâce au serveur de signalisation, toutes les données sont partagées entre les deux machines. Celles-ci comprennent, entre autres, les flux de médias (audio et vidéo).
Cette façon de faire peut être assez avantageuse puisqu'elle est minimale, peu coûteuse (sauf s'il faut utiliser un serveur TURN), et assez facile à implémenter côté client, puisqu'il n'y a qu'une seule connexion à gérer, que l'on soit celui qui envoie l'offre de connexion ou celui qui répond à une offre. De plus, le backend est lui aussi plus léger, puisque tout ce qui est connexion est géré par les clients, sauf la partie signalisation.⁵
Malgré tout, cette architecture ne permet que des appels un à un, mais selon le système, cela peut être une bonne chose.
Participant A ---- Serveur de signalisation ---- Participant B
| |
| -------- Échange d'offres SDP --------------- |
| -------- Échange de candidats ICE ----------- |
| |
| ---- Requête STUN pour IP publique ---------- |
| |
| -------- Connexion P2P WebRTC --------------- |
Diagramme de l'architecture un-à-un
« Mesh »
Similaire à la précédente architecture, l'architecture en « mesh » est aussi simple, en principe. En effet, il s'agit de répéter les mêmes étapes que pour le un-à-un, mais avec plusieurs machines, et celles-ci font de même avec les autres.
Cela permet donc de faire des appels à plusieurs. Un autre avantage, c'est qu'étant donné que les connexions restent côté client, le backend n'est pas vraiment sollicité, sauf pour la partie signalisation.⁵
Par contre, cette architecture présente des problèmes dus au fait que chaque client doit maintenir une connexion WebRTC avec chaque autre client, mais aussi encoder, décoder et traiter tout ce qui est flux de médias. Ceci impacte considérablement la quantité de ressources que les utilisateurs ont besoin, et plus le nombre de participants augmente, plus la quantité de puissance nécessaire augmente. Donc, il ne s'agit pas vraiment d'une solution très évolutive.⁵
Serveur de signalisation
/ | \
/ | \
/ | \
Participant A ------- Participant B \
\ / | \ \
\ / | \ \
\ / | \ \
\ / | \ \
Participant C ---|----------------
| | |
| | |
| Requête STUN pour IP publique
| | |
Connexion P2P WebRTC établie entre tous les pairs
Diagramme de l'architecture plusieurs-à-plusieurs
Serveur de média
Comme nous l'avons vu, la solution en « mesh » n'est pas très évolutive, et donc nous sommes restreints à un nombre limité de participants. Alors, que pouvons-nous faire ? C'est là qu'entre en jeu un serveur de média. Il en existe deux principaux types, et leur but est de réduire la puissance nécessaire sur le client pour la gestion des médias. Ceux-ci sont : les « Selective Forwarding Units » (SFU) et les « Multipoint Conferencing Units » (MCU).
Dans une architecture utilisant un SFU, chaque participant envoie son flux de média à un serveur central, et celui-ci se charge de lui envoyer les flux des autres participants. Donc, au lieu d'encoder le même flux vidéo et de le renvoyer plusieurs fois à chaque client, il suffit de faire appel au SFU. De plus, le SFU ne va pas décoder et réencoder, mais va simplement transférer le flux aux autres.⁵
Un gros avantage qui découle de cela vient du fait que chaque participant n'a pas à dédoubler le travail d'encodage et d'envoi selon le nombre de machines connectées.⁵
┌─ Participant A ─┐ ┌──────── SFU ────────┐
│ WebRTC │ ─ Flux média A ─> │ │
└─────────────────┘ │ Redistribution │ ─ Flux A + B ─> Participant C
┌─ Participant B ─┐ │ sélective │ ─ Flux A + C ─> Participant B
│ WebRTC │ ─ Flux média B ─> │ des flux │ ─ Flux B + C ─> Participant A
└─────────────────┘ | |
┌─ Participant C ─┐ | |
│ WebRTC │ ─ Flux média C ─> | |
└─────────────────┘ | |
└─────────────────────┘
Diagramme de l'architecture avec un serveur de média SFU
Un MCU ressemble un peu au SFU, mais la différence réside dans la façon dont les flux de médias sont traités lorsqu'ils sont reçus. En effet, un MCU décode chaque flux reçu, les mélange dans un seul et même flux, puis les réencode et les envoie à tous les participants.⁵
En faisant cela de cette manière, il est vrai que plus de performances sont économisées du côté des clients, puisqu'il n'y a qu'un seul flux à décoder à la réception.⁵
Cependant, cela demande beaucoup plus de ressources au niveau du serveur de média, puisqu'il doit encoder et décoder plusieurs flux. De plus, on perd certains avantages, comme celui de pouvoir manipuler individuellement les flux, puisqu'ils sont tous fusionnés.⁵
┌─ Participant A ─┐ ┌──────── MCU ────────┐
│ WebRTC │ ─ Flux média A ─> │ Décodage │
└─────────────────┘ │ Mixage │ ── Flux mixé ──> Tous
┌─ Participant B ─┐ │ Encodage │
│ WebRTC │ ─ Flux média B ─> │ │
└─────────────────┘ | |
┌─ Participant C ─┐ | |
│ WebRTC │ ─ Flux média C ─> | |
└─────────────────┘ | |
└─────────────────────┘
Diagramme de l'architecture avec un serveur de média MCU
Conclusion
Maintenant que nous en savons un peu plus sur les connexions pair-à-pair, les serveurs STUN / TURN, les « ICE candidates », les serveurs de signalisation et les différentes architectures pour les connexions WebRTC, comme un-à-un, « mesh », ou encore l'utilisation d'un serveur de médias SFU ou MCU, on peut enfin commencer à créer des applications de vidéoconférence dans les prochains blogs, n'est-ce pas ?
Eh bien non, car même si j'ai envie de plonger dans le code, j'aimerais vous éviter les nuits blanches que j'ai eues lorsque j'ai travaillé avec WebRTC. Pour ce faire, la semaine prochaine, nous allons explorer comment déboguer un projet WebRTC, une chose que j'aurais dû faire lorsque j'en apprenais davantage sur le sujet.
Sources
-
« Pair-à-pair », dans Wikipédia, 7 Février 2025, https://fr.wikipedia.org/wiki/Pair-%C3%A0-pair
-
A. KERANEN, et al, « RFC 8445: Interactive Connectivity Establishment (ICE) : A Protocol for Network Address Translator (NAT Traversal ) », dans rfc-editor, Juillet 2018, ISSN: 2070-1721, https://www.rfc-editor.org/rfc/rfc8445#section-1
-
J. ROSENBERG, et al, « RFC 5389: Session Traversal Utilities for NAT (STUN) », dans rfc-editor, Octobre 2008, https://www.rfc-editor.org/rfc/rfc5389
-
R. MAHY, et al, « RFC 5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) », dans rfc-editor, Avril 2010, ISSN: 2070-1721, https://www.rfc-editor.org/rfc/rfc5766
-
Maulik SHAH, « WebRTC Architecture – A Layman’s Guide », dans tragofone, 29 Septembre 2022, https://tragofone.com/webrtc-architecture-types-guide/
les diagrammes en ascii ont été généré par IA et grandement modifié par moi
Commentaires