P2P, SFU, MCU: WebRTC-Architekturen verstehen

Dieser Artikel zeigt dir, wie WebRTC-Architekturen wirklich funktionieren. Verständlich, auch ohne tiefen Tech-Background.

WebRTC ist ein Open-Source-Projekt, das Geräte über Peer-to-Peer-fähige Web-Apps verbindet. Wenn du schon mal einen Video-Call im Browser geführt oder ein Echtzeit-Spiel über den Browser gespielt hast, lief im Hintergrund mit hoher Wahrscheinlichkeit WebRTC.

Inhaltsverzeichnis

1. Architektur-Optionen
2. P2P (Peer-to-Peer / Mesh)
3. SFU (Selective Forwarding Unit)
4. MCU (Multipoint Control Unit)
5. Hybride Architekturen
6. 2026-Update: Wo Media over QUIC ins Bild kommt

Architektur-Optionen

Im Kern jeder Videokonferenz-Lösung steht die Architektur, mit der Video- und Audio-Streams zwischen den Teilnehmern verschickt und empfangen werden. Wenn N Teilnehmer in einer Konferenz sind, muss jeder Einzelne das Video und Audio der anderen N−1 Personen sehen und hören.

Das lässt sich auf verschiedene Weise umsetzen. In der Praxis gibt es drei Haupt-Architekturen:

• P2P (Peer-to-Peer / Mesh)
• SFU (Selective Forwarding Unit)
• MCU (Multipoint Control Unit)

Möglich ist auch ein hybrider Ansatz, der je nach Teilnehmerzahl unterschiedliche Architekturen kombiniert. Das ist eher eine Optimierung und wird am Ende des Artikels behandelt.

P2P (Peer-to-Peer)

Peer-to-Peer (P2P) ist eine Anwendungs-Architektur, gelegentlich auch Mesh-Architektur genannt. Sie ist die fundamentalste Form des Netzwerk-Designs und einfach zu verstehen. In einer Konferenz ist jede Person ein Peer, der sein Video und Audio per direkter Peer-Verbindung an jeden anderen Peer sendet.

Das Diagramm unten zeigt eine P2P-Architektur mit vier Teilnehmern:

Weil keine zwischengeschalteten Medienserver beteiligt sind, ist Privatsphäre per Ende-zu-Ende-Verschlüsselung von Haus aus gegeben. Das klingt erst mal nach einem klaren Vorteil. P2P hat aber eine deutliche Schwäche: Es verwendet die Upload-Bandbreite nicht effizient.

Bei N Teilnehmern im Call muss jeder Teilnehmer N−1 Peer-Verbindungen aufbauen und sein Video bzw. Audio N−1 Mal senden. Insgesamt entstehen N×(N−1) Peer-Verbindungen.

Viele Privathaushalte haben außerdem asymmetrische Internet-Anschlüsse, etwa klassisches ADSL (Asymmetric Digital Subscriber Line), bei dem der Upload deutlich langsamer ist als der Download. Auch ein schneller Upload hilft im Büro nur begrenzt, wenn sich viele Mitarbeiter dieselbe Leitung teilen.

In der Praxis ergibt P2P vor allem für 1-zu-1-Calls Sinn. In diesem Szenario ist P2P sogar optimal, weil jede der beiden Personen ihr Audio/Video nur einmal sendet.

Vorteile:

• Privatsphäre ist mühelos gegeben. Alle Video- und Audio-Streams sind per Default E2E-verschlüsselt, weil keine zwischengeschaltete Infrastruktur mithören kann.
• Aufwand und Hosting-Kosten sind niedrig, weil keine Medienserver betrieben und gewartet werden müssen.

Nachteile:

• Upload-Bandbreite wird ineffizient verbraten und ist selbst bei wenigen Teilnehmern schnell ausgereizt.
• CPU-Last ist clientseitig deutlich höher, weil der Browser das Video N−1 Mal kodieren muss, um es an alle anderen zu schicken. Ohne starke Maschine fällt die Performance schnell ab.

Diese Nachteile machen P2P vor allem für 1-zu-1-Calls verlässlich, aber nicht skalierbar. Sobald mehr Teilnehmer beteiligt sind, wird in der Praxis eine SFU bevorzugt — mit zentraler Verwaltung der Streams.

SFU (Selective Forwarding Unit)

Diese Architektur hat sich zur Standard-Wahl in modernen Videokonferenz-Lösungen entwickelt. Eine zentrale SFU (Selective Forwarding Unit) fungiert als Medienserver: Sie empfängt die eingehenden Streams und leitet sie unverändert an die anderen Teilnehmer weiter.

Dieser Ansatz bringt zwar zusätzlichen Aufwand auf der Serverseite, ist aber ein klarer Fortschritt gegenüber P2P. Er löst das Problem der begrenzten Upload-Bandbreite und verbessert die Skalierbarkeit deutlich.

Häufig kommt in der SFU-Videokonferenz die Simulcast-Technik zum Einsatz. Jeder Teilnehmer sendet mehrere Streams in unterschiedlichen Qualitäten an die SFU. Die SFU wählt dann die passende Qualität pro Empfänger aus. Eine schwächere Verbindung bekommt einen niedriger aufgelösten Stream. Wer einen Stream im Vollbild anzeigt, bekommt die hochaufgelöste Variante.

Dadurch lässt sich viel Download-Bandbreite einsparen, und auch bei durchschnittlicher Internetverbindung lassen sich viele Teilnehmer gleichzeitig im Grid anzeigen. Der SFU-Server entlastet zusätzlich, weil er Streams nur weiterleitet, ohne sie zu dekodieren.

In einer SFU-Videokonferenz, wie im Diagramm oben gezeigt, sendet jeder Teilnehmer seinen Stream einmal an die SFU und empfängt im Gegenzug die Streams aller anderen.

Vorteile:

• Teilnehmer publizieren genau einmal an die SFU. Das macht SFU upload-bandbreitenschonend, anders als P2P/Mesh.
• Deutlich besser skalierbar als P2P. Simulcast spielt die jeweils passende Stream-Variante an Bandbreite und CPU des Empfängers aus.
• Flexibles Layout. Teilnehmer entscheiden selbst, welche Streams sie sehen, wo sie sie anzeigen und in welcher Qualität.

Nachteile:

• Zwischengeschaltete Medienserver erhöhen Kosten und Aufwand auf der Serverseite.
• Volle E2E-Verschlüsselung ist nicht out-of-the-box gegeben, weil die SFU beim Weiterleiten Zugriff auf die rohen Stream-Bytes hat. Das ist ein Nachteil gegenüber P2P, lässt sich aber abmildern: indem die Streams mit einem eigenen Schlüssel verschlüsselt werden, bevor sie zur SFU gehen. Auf Empfängerseite ist dann eine entsprechende Entschlüsselung nötig.

SFU (Selective Forwarding Unit) ist heute die populärste Architektur in Videokonferenzen.

SFU ist beim Upload deutlich effizienter und besser skalierbar als P2P.

Auch wenn jeder Empfänger die Streams der anderen weiterhin selbst herunterladen und dekodieren muss, lassen sich dank Simulcast bei durchschnittlicher Verbindung und Hardware bis zu rund 50 Teilnehmer parallel im Grid darstellen.

MCU (Multipoint Control Unit)

In der MCU (Multipoint Control Unit)-Architektur sendet jeder Teilnehmer seinen Stream nur einmal an einen zentralen Server. Anders als bei der SFU spielt der MCU-Server aber die Rolle eines Mixers: Er fasst alle eingehenden Streams zu einem einzigen Stream zusammen.

Alle Teilnehmer empfangen dann diesen einen gemischten Stream, statt sich einzeln auf die Streams der anderen zu abonnieren.

Vorteile:

• Jeder Teilnehmer abonniert nur einen Stream, das fertige Layout aller anderen. Das ist clientseitig sehr CPU- und bandbreitenschonend, sogar effizienter als SFU, weil der Browser nur einen einzigen Stream dekodiert.
• Da clientseitig nur ein Stream ankommt, ist die Architektur einfach zu durchdringen und im Frontend einfach zu integrieren und zu debuggen. Der Aufwand verlagert sich dafür ins Backend.

Nachteile:

• Das Layout ist meist nicht flexibel. Der zentrale Server bestimmt ein festes Layout, das alle Teilnehmer sehen. Eine Person kann die Streams nicht selbst umsortieren oder einen bestimmten in Hochauflösung in den Vordergrund holen.
• CPU-Last und Aufwand serverseitig sind deutlich höher als bei SFU, weil alle Streams zusammengemischt werden müssen. Räume lassen sich vor allem vertikal skalieren, also über stärkere CPUs. Vertikales Skalieren hat seine bekannten Grenzen: immer leistungsfähigere und gleichzeitig stabile Maschinen sind schwer und teuer zu bekommen.
• Das Mixen aller Streams zu einem Ergebnis-Stream bringt eine etwas größere Verzögerung als SFU, das Streams nur weiterleitet. Und falls im MCU-Layout ein Fehler steckt, betrifft er alle Teilnehmer gleichzeitig.

MCU ist die beste Wahl, wenn clientseitiger Ressourcenverbrauch das einzige Kriterium ist. In der Praxis verliert MCU aber gegen SFU, weil der Betrieb serverseitig mindestens zehnmal teurer ist.

Encoding, Decoding und Mixing belasten den Server ungleich stärker als reines Weiterleiten wie bei der SFU. Da Unternehmen den zehnfachen Server-Aufwand selten tragen können, gewinnt in den meisten Fällen die SFU als pragmatischer Kompromiss.

Hybride Architekturen

Beim hybriden Ansatz werden je nach Teilnehmerzahl unterschiedliche Architekturen verwendet. Bei 1-zu-1-Calls läuft die Verbindung über P2P, bei mehr Teilnehmern wechselt das System auf SFU.

Das spart Server-Ressourcen, vor allem bei kleinen Calls, weil bei P2P kein zwischengeschalteter Medienserver nötig ist. Sobald eine dritte Person dazukommt, übernimmt die SFU.

Visualisieren lässt sich das gut in einem Architektur-Diagramm, das den Übergang von P2P zu SFU mit wachsender Teilnehmerzahl zeigt: aus direkten Peer-Verbindungen werden Streams, die durch eine SFU an die anderen weitergeleitet werden.

Vorteile:

• Effiziente Server-Ressourcen: P2P bei 1-zu-1-Calls spart Server-Bandbreite.
• Skaliert mit der Teilnehmerzahl: Bei mehr Teilnehmern wechselt das System automatisch auf SFU.
• Kosteneffizient: Die hybride Architektur kombiniert die günstige P2P-Variante für kleine Calls mit der skalierbaren SFU für größere Runden.

Nachteile:

• Mehr Aufwand: Eine hybride Architektur verlangt, mehrere Systeme zu betreiben und reibungslos zwischen ihnen umzuschalten. Das macht das Backend aufwendiger.
• Wartung: Eine hybride Architektur erhöht den Code- und Wartungsaufwand, vor allem weil die Übergänge zwischen P2P und SFU (und ggf. MCU) im laufenden Call sauber funktionieren müssen.

2026-Update: Wo Media over QUIC ins Bild kommt

Wer 2026 über WebRTC-Architekturen liest, sollte ein neues Protokoll auf dem Schirm haben: Media over QUIC (MoQ). MoQ ist ein Pub/Sub-Transportprotokoll der IETF, das Sub-Sekunden-Latenz bei CDN-Skalierung liefern soll. Es ersetzt WebRTC nicht, beide Protokolle lösen unterschiedliche Probleme.

Für die meisten Plattformen läuft es 2026 auf einen hybriden Stack hinaus: WebRTC für die interaktive Schicht (Konferenz, gegenseitige Kommunikation zwischen Sprechenden und Moderatoren), MoQ für die Distributions-Schicht (Publikum, das nur zuschaut). Ein SFU-Setup kann einen Composite-Stream in ein MoQ-Relay-Netzwerk publizieren, das ihn dann an beliebig viele Zuschauer ausspielt, ohne dass die SFU Per-Viewer-Verbindungen verwalten muss.

Heißt: SFU bleibt das Herzstück der Konferenz. MoQ kommt obendrauf, wenn aus der Konferenz ein Broadcast wird.

Eine moderne WebRTC-Anwendung in Aktion

In diesem Artikel hast du die verschiedenen Architektur-Optionen kennengelernt, die WebRTC-Technologie antreiben und Videokonferenzen erst möglich machen. Wie setzt Digital Samba WebRTC im Backend um, damit Live-Videokonferenzen modern und verlässlich funktionieren?

Digital Samba ist ein Anbieter für DSGVO-konforme Videokonferenz-API und -SDK und liefert eine Plattform, mit der sich Videokonferenz-Funktionen in eigene Produkte oder Websites einbetten lassen. Unsere Lösung baut auf WebRTC auf, dem Open-Source-Projekt für Peer-to-Peer-Web-Anwendungen in Echtzeit.

Mit Digital Samba Embedded bringst du diese Kraft in deine Plattform und gibst deinen Nutzern hochwertige Echtzeit-Kommunikation. Die Lösung ist DSGVO-konform aufgebaut, Audio- und Videodaten bleiben in der EU. Über unsere EU-Infrastruktur und Ende-zu-Ende-Verschlüsselung sind sensible Inhalte aus Videokonferenzen geschützt.

Ob du ein Remote-Collaboration-Tool baust, eine Online-Tutoring-Plattform oder ein virtuelles Klassenzimmer: Mit Digital Samba arbeiten Teilnehmer reibungslos zusammen. Die WebRTC-Architektur erlaubt direkte Verbindungen mit geringer Latenz und einer stabilen Video-Erfahrung.

Bei Digital Samba läuft Videokonferenz vollständig über eine SFU-Architektur, ausgelegt auf Skalierung, Stabilität und Bandbreiten-Effizienz. Anders als P2P- oder MCU-basierte Systeme liefert unser SFU-Ansatz konsistente Performance über alle Call-Größen hinweg, vom 1-zu-1-Meeting bis zur großen Gruppensession. Das senkt Latenz, schont Bandbreite und bildet die verlässliche Basis dafür, Video in beliebige Anwendungen einzubetten.

Die WebRTC-gestützte Live-Videokonferenz von Digital Samba unterstützt auch weiterführende Features wie Bildschirmfreigabe, File Sharing und interaktives Whiteboarding. Diese Features machen Zusammenarbeit produktiver und ermöglichen interaktive Lern-Erlebnisse für virtuelle Klassenzimmer, Remote-Trainings und Online-Meetings.

Möchtest du Digital Sambas WebRTC-gestützte Live-Videokonferenz selbst ausprobieren? Sprich mit unserem Team und finde heraus, wie du deine Videokonferenz-Plattform damit aufwertest.

Häufige Fragen zu WebRTC-Architekturen

1. Was ist der Unterschied zwischen P2P und SFU in WebRTC?

P2P (Peer-to-Peer) verbindet Teilnehmer direkt, ohne zentralen Server. Das ist für kleine Calls praktisch, belastet aber Bandbreite und CPU stark, sobald mehr Personen dazukommen. SFU (Selective Forwarding Unit) leitet die Medien-Streams über einen Server, optimiert dadurch Bandbreite und Skalierung und ist deshalb die richtige Wahl für größere Calls.

2. Wie verbessert SFU die Skalierung von Videokonferenzen?

Die SFU senkt die Datenmenge, die jeder Teilnehmer hochladen muss. Statt N−1 Streams sendet jeder Teilnehmer seinen Medien-Stream nur einmal an den SFU-Server. Der Server verteilt den Stream dann an alle anderen. Das reduziert Upload-Bandbreite und clientseitige CPU-Last deutlich.

3. Wann macht MCU in WebRTC Sinn?

MCU (Multipoint Control Unit) lohnt sich, wenn alle Teilnehmer-Streams zu einem einzigen Stream pro Empfänger gemischt werden sollen. Das ist sinnvoll, wenn du ein konsistentes Layout brauchst und clientseitig möglichst wenig Last erzeugen willst. MCU skaliert aber schlechter und ist serverseitig deutlich teurer als SFU.

4. Was sind die wichtigsten Vorteile von WebRTC für Videokonferenzen?

WebRTC erlaubt Echtzeit-Kommunikation direkt zwischen Browsern, ohne Plugins. Es ist kostengünstig, liefert hohe Video- und Audio-Qualität und ist mit Ende-zu-Ende-Verschlüsselung sicher. Außerdem wird WebRTC von allen großen Browsern und Plattformen unterstützt.

5. Kann WebRTC große Videokonferenzen abdecken?

WebRTC kann große Konferenzen handhaben, wird mit steigender Teilnehmerzahl aber weniger effizient, weil Netzwerk- und CPU-Last stark anziehen. SFU- und MCU-Architekturen machen große Calls handhabbarer; die Skalierungsgrenze hängt am Ende von der gewählten Infrastruktur ab. Für reine Broadcast-Szenarien mit hunderttausenden Zuschauern kommt zusätzlich Media over QUIC ins Spiel, das WebRTC ergänzt.