WebRTC

Wenn du Skype oder Zoom im Browser nutzt, ist das WebRTC. Normalerweise redet der Browser immer mit einem Server. Bei einem Videocall wäre das zu langsam (Latenz). A -> Server -> B. WebRTC erlaubt Browser-zu-Browser (Peer-to-Peer). A -> B. Direkte Verbindung. Ohne Umweg. Video, Audio und Daten fließen in Echtzeit.

Merksatz: Ein Open-Source-Projekt, das Browsern und mobilen Anwendungen Echtzeit-Kommunikation (Video, Audio, P2P-Datentransfer) über einfache APIs ermöglicht.

Funktioniert in 3 Schritten:

Signaling: A und B treffen sich kurz auf einem Server ("Hallo, ich bin IP 1.2.3.4").
Verbindung: A und B bauen einen Tunnel auf (über UDP).
Streaming: Video läuft direkt durch den Tunnel. Der Server ist raus.

1. STUN & TURN

Das Problem: Firewalls und NAT. Dein Router verbirgt deine IP.

STUN-Server: Sagt dir deine öffentliche IP ("Spiegel"). Reicht meistens.
TURN-Server (Relay): Wenn die Firmen-Firewall alles blockt ("Symmetric NAT"), muss der Traffic doch über einen Server (TURN) gehen. Das kostet Geld und Bandbreite.

2. Data Channels

Man kann nicht nur Video senden, sondern beliebige Daten. BitTorrent im Browser (WebTorrent)? Ja. Multiplayer-Gaming mit Null Latenz? Ja.

1. ICE, STUN und TURN (Der Verbindungstanz)

WebRTC nutzt das ICE-Protokoll (Interactive Connectivity Establishment). Beide Browser sammeln alle Wege, über die sie erreichbar sein könnten: lokale IP, öffentliche IP (via STUN) und Relay-IP (via TURN). Diese "Candidates" werden via Signaling ausgetauscht. Technischer Kniff: Die Browser probieren alle Wege gleichzeitig aus und wählen den schnellsten, der funktioniert. Ein "Symmetric NAT" in Firmennetzwerken verhindert oft P2P, weshalb ohne einen global verteilten TURN-Cluster (z.B. CoTURN) ca. 15-20% aller WebRTC-Calls scheitern würden.

2. Der Security-Stack: DTLS & SRTP

WebRTC ist sicher per Spezifikation – es gibt kein unverschlüsseltes WebRTC. Es nutzt DTLS (Datagram TLS), um Schlüssel auszutauschen, und danach SRTP (Secure Real-time Transport Protocol), um die Video/Audio-Bits zu verschlüsseln. In der Produktion ist das ein CPU-Faktor. Wenn ein Server tausende WebRTC-Streams gleichzeitig verarbeiten muss (z.B. als Recording-Server), verbringt er 30-50% seiner CPU-Zeit nur mit Verschlüsselung und Paket-Validierung.

3. SFU vs. MCU (Scaling)

Für Gruppen-Calls (10 Personen) skaliert P2P nicht (dein Browser müsste 9-mal Video hochladen -> Bandbreiten-Tod). Man nutzt einen Server in der Mitte:

MCU (Multipoint Control Unit): Der Server mischt alle 9 Videos zu einem einzigen Bild zusammen. Gut für alte Geräte, aber teuer für den Server.
SFU (Selective Forwarding Unit): Der heutige Standard. Der Server empfängt den Stream und leitet ihn einfach 9-mal weiter, ohne ihn zu verarbeiten. Er kann sogar entscheiden: "Dem User mit dem schlechten Internet schicke ich nur die niedrige Auflösung" (Simulcast).