Scalabilité WebRTC : dimensionner l'infrastructure vidéo
Réponse courte
La scalabilité WebRTC repose sur l'architecture SFU (Selective Forwarding Unit) en cluster horizontal, le simulcast (plusieurs qualités par flux), le SVC (Scalable Video Coding) et un dimensionnement adapté des serveurs TURN. Contrairement au peer-to-peer pur, le SFU permet de monter en charge de dizaines à centaines de participants par session.
Pourquoi le P2P ne scale pas ?
En peer-to-peer, chaque participant envoie N-1 flux et reçoit N-1 flux :
| Participants | Flux par client | Charge |
|---|---|---|
| 2 | 1 | Faible |
| 5 | 4 | Modérée |
| 10 | 9 | Élevée |
| 20 | 19 | Insoutenable |
Le SFU résout ce problème : chaque client envoie 1 flux au serveur, qui redistribue sélectivement.
Stratégies de scalabilité SFU
1. Scaling horizontal
- Cluster de nœuds SFU ;
- Load balancer (round-robin, geo-routing) ;
- Session pinning (un SFU par session).
2. Simulcast
Le client encode 3 qualités (basse, moyenne, haute). Le SFU envoie la qualité adaptée à chaque récepteur selon sa bande passante.
3. SVC (Scalable Video Coding)
Couches vidéo dépendantes (VP9 SVC, AV1) : le SFU transmet les couches nécessaires sans retranscoder.
4. Sélective forwarding
Le SFU ne renvoie que les flux pertinents (speaker detection, layout dynamique) : réduit la charge client.
Dimensionnement : ordres de grandeur
| Session | SFU recommandé | Bande passante SFU |
|---|---|---|
| 1:1 | P2P ou SFU léger | ~2–6 Mbps |
| 10 participants | 1 nœud SFU | ~20–60 Mbps |
| 50 participants | 1–2 nœuds SFU | ~100–300 Mbps |
| 100+ | Cluster SFU | ~500 Mbps+ |
Les chiffres varient selon résolution, fps, partage d'écran. Demandez un benchmark documenté à l'éditeur.
Scalabilité TURN
Le TURN consomme de la bande passante quand tout passe en relais :
- Dimensionner TURN indépendamment du SFU ;
- Prévoir du TCP fallback (UDP bloqué) ;
- Redondance multi-zones.
Scalabilité et latence
La montée en charge ne doit pas dégrader la latence :
- SFU proche des participants (hébergement France) ;
- Pas de transcodage intermédiaire (forwarding pur) ;
- Monitoring packet loss et jitter.
Architecture hybride pour très grands publics
- WebRTC + SFU pour le plateau interactif (animateur, modérateurs, Q&R) ;
- HLS/DASH + CDN pour les spectateurs passifs (milliers+) ;
- Produit live : live.gniarkgniark.fr.
Comment Leagora dimensionne la scalabilité ?
Architecture SFU sur stack open source, cluster horizontal, simulcast, déploiement France ou on-premise. Contact pour un dimensionnement projet.
FAQ
Combien de participants par SFU ?
Variable (50–200+ selon hardware et config). Demandez un benchmark pour votre profil.
Le simulcast est-il obligatoire ?
Recommandé pour les sessions > 5 participants avec des réseaux hétérogènes.
Scalabilité verticale vs horizontale ?
Horizontale (cluster) est le standard : vertical (gros serveur) atteint un plafond rapidement.
Le SFU transcode-t-il les flux ?
Non (forwarding pur) : c'est ce qui préserve la latence faible et la scalabilité.
Leagora.io garantit-il un nombre de participants ?
Leagora.io documente l'architecture. Les garanties de capacité sont contractuelles.
À retenir
- Scalabilité WebRTC = SFU horizontal + simulcast + TURN dimensionné.
- P2P pur ne scale pas au-delà de 3–4 participants.
- Leagora.io = hub infrastructure ; dimensionnement via contact commercial.