WebRCT P2P vs SFU vs CPU

WebRTC : les approches P2P, SFU et MCU pour bien communiquer

Aujourd'hui, les applications faisant appel à la technologie WebRTC pour faire transiter des flux audio/vidéo sont de plus en plus nombreuses. Nextcloud Talk bien entendu, mais également Jitsi, BigBlueButton et bien d'autres. Néanmoins, il y a essentiellement 3 approches pour faire transiter les flux et permettre une scalabilité qui va de quelques utilisateurs à plusieurs milliers simultanément.

WebRTC est essentiellement une technologie peer-to-peer, et il est nécessaire de configurer un serveur central séparé (ou plusieurs, avec un, ou plusieurs, répartiteurs de charge - Load Balancer - en amont) en fonction de l'objectif du service, comme lors de la construction d'un service de diffusion multimédia à grande échelle ou lorsqu'un traitement de contenu est requis. Selon le cas d'utilisation, l'architecture peut être considérée comme suit.

P2P (Peer to Peer) ou Mesh

C'est le mode adopté par Nextcloud Talk dans sa version livrée avec Nextcloud (et Cloudeezy) par défaut. La connexion directe de bout en bout sans serveur(s) central est avantageuse en termes de coût, mais à mesure que le nombre de pairs augmente (structure maillée), le système et le réseau nécessitent une capacité élevée. Pour comprendre grossièrement, une connexion ADSL (A = Asymétrique) convient pour jusqu'à 4 utilisateurs simultanés car elle est limitée en Uplink (débit montant). C'est pourquoi, dans ce mode de connexion, un utilisateur avec une bonne machine (CPU + liaison internet fibrée symétrique par exemple) rencontrera peu de problèmes alors qu'un utilisateur en ADSL va vite rencontrer des problèmes dès lors que les participants se joignent à la conférence.

Peut-être que dans quelques années il sera possible de se passer des autres modes (CPUs de plus en plus puissants, connections fibres ou 5G très puissantes et répandues globalement) mais pour l'instant, nous nécessitons la mise en place de centralisations (en datacenter ou "on-premises" si la liaison - symétrique - est idéale) pour palier à ce problème et faire transiter la charge des clients vers les serveurs, beaucoup plus puissants.

SFU (Unité d'expédition sélective)

Il s'agit d'un (ou plusieurs) serveur central qui relaie le trafic multimédia, et chaque homologue s'y connecte pour le traitement de décryptage / cryptage. Il convient à une structure de service de streaming telle que la diffusion vidéo. Ce mode est utilisé, entre autres, par Jitsi.

MCU (Unité de contrôle multipoint)

En tant que méthode de serveur central dans laquelle une pluralité de supports de transmission sont mélangés ou transcodés par un serveur central et livrés à un côté récepteur, la charge du client et du réseau est considérablement réduite, tandis qu'une puissance de calcul élevée du serveur central est requise. C'est le mode adopté par Nextcloud Talk dans sa version HPB (en option sur nos offres d'hébergement Nextcloud).

Tableau de comparaison des besoins pour chaque approche

  P2P SFU MCU
Débit (en upload) Élevé Faible Faible
Débit (en download) Élevé Faible Élevé
Utilisation du CPU client Élevé Faible Moyen
Utilisation du CPU serveur - Élevé Faible
Latence possible Dépend de la bande passante réseau Dépend de la puissance du processeur Dépend de la bande passante réseau
Capacité de transcodage - Oui Non
Capacité de diffusion simultanée / SVC - - Oui

Conclusion

Une conception adaptée aux cas d'utilisation tels que les objectifs de service et les coûts est requise. En règle générale :

  • les appels voix / vidéo à petite échelle (1:1) sont des services de P2P, de diffusion unidirectionnelle de niveau moyen ou supérieur (par exemple, e-Learning, Broadcasting, etc. )
  • des services à des fins telles que la vidéoconférence sont SFU, conversation vocale à grande échelle (par exemple, mixage vocal)
  • les système de contrôle en temps réel (par exemple, le transcodage vidéo en grille) sont conçus en premier lieu avec MCU.

L'option de maillage complet (P2P) est réalisable tant que le nombre de participants est petit. Comme mentionné dans l'article, le problème principal est la bande passante. Le MCU ressemble à une solution facile mais il a des problèmes d'échelle et de coût.

Des "solutions" existent pour limiter les problèmes, par exemple des faible résolutions pour chaque participant (vidéo de moindre qualité = besoin en CPU pour le décoder et en bande passante pour l'envoyer/recevoir plus faibles) mais aujourd'hui personne ne souhaite faite une conférence "pixélisée" avec nos écrans à haute résolution.

Une architecture de service de visioconférence peut comprendre une combinaison des 3 options ou une partie d'entre elles et l'utilisation de chacune en fonction de la logique du service et du type / nombre de participants, par exemple, une combinaison de maillage complet (P2P) et de SFU.

D'autres articles similaires