WebRTC (Web Real-Time Communication) ist eine offene Technologie, die Echtzeit-Sprach-, Video- und Datenkommunikation zwischen Browsern erm\u00f6glicht. Sie wird von verschiedenen Unternehmen, darunter Google, als Mechanismus standardisiert, der P2P-Kommunikation ausschlie\u00dflich \u00fcber JavaScript-APIs ohne zus\u00e4tzliche Plug-ins oder Software erm\u00f6glicht.<\/p>\n\n\n\n
WebRTC besteht aus drei Hauptkomponenten:<\/p>\n\n\n\n
Diese APIs erm\u00f6glichen die Entwicklung zahlreicher Echtzeitanwendungen wie Videoanrufe, Audiokonferenzen, Dateifreigabe usw. Bei der tats\u00e4chlichen Kommunikation gibt es jedoch Probleme mit NAT-Traversal und Firewalls. Daher ist es wichtig, NAT-Traversal-Technologien wie STUN\/TURN\/TURNS zu verstehen und zu implementieren.<\/p>\n\n\n\n
Um eine stabile Peer-to-Peer-Verbindung mit WebRTC zu erreichen, ist ein NAT-Traversal-Mechanismus unerl\u00e4sslich. Dieser Artikel erl\u00e4utert detailliert die technischen Unterschiede, Anwendungsszenarien sowie Vor- und Nachteile der repr\u00e4sentativen Technologien STUN, TURN und TURNS.<\/p>\n\n\n\n
STUN dient in erster Linie dazu, die externe Adresse in einer NAT-Umgebung zu ermitteln, w\u00e4hrend TURN als Relay-Server fungiert, wenn keine direkte Verbindung m\u00f6glich ist. TURNS hingegen verschl\u00fcsselt die TURN-Kommunikation mit TLS und verwendet dieselbe Portnummer 443 wie HTTPS. Dadurch ist die Kommunikation hinter strengen Firewalls, beispielsweise in Unternehmensnetzwerken, m\u00f6glich.<\/p>\n\n\n\n
Indem Sie die jeweiligen Eigenschaften verstehen und sie entsprechend nutzen, k\u00f6nnen Sie die Erfolgsquote und Qualit\u00e4t der WebRTC-Kommunikation steigern.<\/p>\n\n\n\n
STUN (Session Traversal Utilities for NAT) ist ein Protokoll, das es Clients erm\u00f6glicht,Externe IP-Adresse und Port<\/strong>Es handelt sich um ein einfaches Protokoll, um die IP-Adresse eines PCs zu ermitteln. Befindet sich ein PC beispielsweise hinter einem NAT, kennt er seine eigene globale IP-Adresse nicht, kann aber durch eine Abfrage des STUN-Servers seine eigene IP-Adresse:Port von au\u00dfen ermitteln.<\/p>\n\n\n\n Der STUN-Server fungiert als Spiegel und gibt die Quellinformationen der empfangenen Anfrage unver\u00e4ndert zur\u00fcck. Dadurch kann der Client seine eigene globale IP-Adresse und die vom NAT (Server Reflexive Candidate) zugewiesene Portnummer ermitteln.<\/p>\n\n\n\n Die STUN-Kommunikation erfolgt \u00fcblicherweise \u00fcber UDP, der Standardport ist 3478 (UDP\/3478). Da eine einfache, einmalige Kommunikation \u00fcber UDP erforderlich ist, entsteht geringer Overhead, geringe Latenz und nahezu keine Serverlast. Daher wird in Umgebungen, in denen UDP-Kommunikation zul\u00e4ssig ist, zun\u00e4chst eine NAT-Traversierung mit STUN versucht.<\/p>\n\n\n\n Es eignet sich f\u00fcr Umgebungen, in denen NAT-Traversal erforderlich ist, die UDP-Kommunikation selbst jedoch nicht blockiert ist, wie z. B. in Heimnetzwerken und Mobilfunkleitungen. Wenn STUN die externe IP-Adresse des jeweils anderen Clients erh\u00e4lt, k\u00f6nnen diese direkt (Peer-to-Peer) kommunizieren. Durch den direkten Kommunikationspfad treten geringere Verz\u00f6gerungen auf und die Qualit\u00e4t bleibt hoch. Da der Server lediglich den IP-Informationsaustausch \u00fcbernimmt, bleiben die Kosten zudem sehr gering. Beispielsweise reicht STUN bei Online-Spielen oder Videoanrufen aus, um eine Peer-to-Peer-Verbindung zu erm\u00f6glichen, wenn sich beide Ger\u00e4te in einem relativ offenen NAT befinden.<\/p>\n\n\n\n STUN dient lediglich dazu, die eigene externe Adresse zu ermitteln. Je nach NAT-Typ und Firewall-Einschr\u00e4nkungen ist eine Verbindung allein dadurch m\u00f6glicherweise nicht m\u00f6glich. Insbesondere in symmetrischen NAT- oder strengen Firewall-Umgebungen erreichen Pakete der Gegenstelle die durch STUN ermittelte Adresse m\u00f6glicherweise nicht, was eine Kommunikation unm\u00f6glich macht.<\/p>\n\n\n\n Dar\u00fcber hinaus kann die UDP-Kommunikation selbst in Unternehmensnetzwerken blockiert sein, sodass STUN-Anfragen das Ger\u00e4t nicht erreichen. Kurz gesagt: STUN ist ein Mechanismus, um festzustellen, ob direkte Kommunikation m\u00f6glich ist, und funktioniert nicht in Umgebungen, in denen direkte Kommunikation physisch unm\u00f6glich ist. Aus diesem Grund wird STUN in ICE (siehe unten) verwendet, um Kandidaten f\u00fcr die erste Stufe zu ermitteln. Sollte STUN nicht ausreichen, wird auf TURN (siehe unten) zur\u00fcckgegriffen.<\/p>\n\n\n\n TURN (Traversal Using Relays around NAT) ist ein Protokoll, das als Relay fungiert, wenn eine direkte Kommunikation mit STUN nicht m\u00f6glich ist. Der TURN-Server fungiert als global erreichbarer Relay-Punkt zwischen Kommunikationspartner und Gegenstelle und leitet Pakete weiter. Der Client verbindet sich mit dem TURN-Server und erh\u00e4lt eine Relay-IP-Adresse und einen Port, den sogenannten Relay-Kandidaten. Anschlie\u00dfend erfolgt der Medien- und Datenaustausch mit der Gegenstelle \u00fcber diesen TURN-Server.<\/p>\n\n\n\n TURN kommuniziert normalerweise ebenfalls \u00fcber UDP. Solange UDP verwendet wird, kann es Medienpakete \u00e4hnlich wie bei direkter Kommunikation weiterleiten. Standardm\u00e4\u00dfig wird das TURN-Protokoll auf Port 3478 (UDP) akzeptiert, genau wie STUN. Selbst wenn die UDP-Portnummer durch die Firewall-Richtlinie eingeschr\u00e4nkt ist, kann TURN auch auf einem zul\u00e4ssigen Port wie UDP\/443 ausgef\u00fchrt werden. Solange UDP verwendet wird, ist Weiterleiten mit h\u00f6herer Echtzeitleistung als TCP m\u00f6glich.<\/p>\n\n\n\n TURN ist unerl\u00e4sslich, wenn keine direkte Verbindung hergestellt werden kann. BeispielsweiseDies ist der Fall, wenn sich eine oder beide Parteien hinter einer strengen Unternehmensfirewall befinden oder wenn beide Parteien \u00fcber symmetrische NATs verf\u00fcgen und das UDP-Hole-Punching fehlschl\u00e4gt.<\/span>In einer solchen Umgebung ist die Kommunikation ohne Weiterleitung \u00fcber einen TURN-Server nicht m\u00f6glich, sodass TURN als eine Art letzter Ausweg fungiert.<\/p>\n\n\n\n WebRTC zielt darauf ab, dass alle Teilnehmer direkt kommunizieren k\u00f6nnen. Selbst wenn dies nicht m\u00f6glich ist, kann die Kommunikation durch einen R\u00fcckgriff auf TURN fortgesetzt werden. Im praktischen Einsatz besteht die allgemeine Strategie darin, zun\u00e4chst eine direkte Verbindung per STUN herzustellen und erst dann auf TURN-Relay umzuschalten, wenn dies fehlschl\u00e4gt. Wenn beispielsweise bei einer Videokonferenz \u00fcber ein internes Netzwerk die beiden Teilnehmer nicht direkt miteinander kommunizieren k\u00f6nnen, wird automatisch auf den TURN-Server umgeschaltet, sodass der Benutzer das Gespr\u00e4ch unmerklich fortsetzen kann.<\/p>\n\n\n\n Der gr\u00f6\u00dfte Vorteil ist die Zuverl\u00e4ssigkeit. Unabh\u00e4ngig von Ihrer NAT- oder Firewall-Umgebung ist Peer-to-Peer-Kommunikation m\u00f6glich, solange die Kommunikation vom Client zum TURN-Server funktioniert. Da TURN zudem eine protokolltechnische Erweiterung von STUN darstellt, kann eine einzelne Serverimplementierung (wie z. B. coturn, siehe unten) sowohl STUN- als auch TURN-Anfragen verarbeiten. Sobald eine Verbindung hergestellt ist, werden nachfolgende Medien als Stream weitergeleitet, sodass die Kommunikation aus Benutzersicht bis auf einige Verz\u00f6gerungen nahtlos verl\u00e4uft.<\/p>\n\n\n\n Die gr\u00f6\u00dften Nachteile sind Ressourcenverbrauch und Latenz. Bei TURN m\u00fcssen alle Audio- und Videodaten \u00fcber den Server laufen, was serverseitig enorme Bandbreite und Rechenleistung erfordert. Geht man beispielsweise davon aus, dass ein Einzelvideoanruf eine Bandbreite von 1 Mbit\/s in eine Richtung verbraucht, so ist nach einfachen Berechnungen bei 1.000 gleichzeitigen Nutzern eine Relay-Bandbreite von 1 Gbit\/s erforderlich. Dies f\u00fchrt zu hohen Betriebskosten eines TURN-Servers, und f\u00fcr umfangreiche Dienste m\u00fcssen mehrere TURN-Relay-Server vorbereitet und skaliert werden.<\/p>\n\n\n\n Dar\u00fcber hinaus ist die Verz\u00f6gerung umso gr\u00f6\u00dfer, je l\u00e4nger der Kommunikationspfad ist, was zu einer Zeitverz\u00f6gerung und einer verringerten Video- und Audioqualit\u00e4t f\u00fchrt. Dar\u00fcber hinaus ist die Kommunikation \u00fcber TURN im Vergleich zur Peer-to-Peer-Kommunikation mit STUN nicht streng Peer-to-Peer und daher in Bezug auf die Vertraulichkeit etwas schlechter (obwohl TURN-Server normalerweise nur unverschl\u00fcsselte RTP\/Datagramme weiterleiten und die Inhalte nicht interpretieren).<\/p>\n\n\n\n TURN sollte grunds\u00e4tzlich nur bei Bedarf eingesetzt werden. Tats\u00e4chlich k\u00f6nnen die meisten WebRTC-Kommunikationen direkt \u00fcber STUN abgewickelt werden. Google-Statistiken zeigen, dass insgesamt etwa 861 TP3T-Anrufe ohne Relays (Peer-to-Peer) aufgebaut werden. Nur die verbleibenden 141 TP3T-Anrufe ben\u00f6tigen TURN, f\u00fcr diese ist jedoch eine TURN-Infrastruktur unerl\u00e4sslich.<\/p>\n\n\n\n TURNS ist eine Abk\u00fcrzung f\u00fcr \u201eTURN over TLS\u201c und ein Protokoll, das Relay-Kommunikation mithilfe des TURN-Protokolls mit TLS (Transport Layer Security) verschl\u00fcsselt.TURN-Kommunikation durch TLS (HTTPS) gesichert<\/span>und wird h\u00e4ufig auf TCP-Port 443 bedient.Port 443 ist dieselbe Portnummer wie HTTPS, sodass er problemlos Unternehmensfirewalls passieren und Proxys und Zensur leicht umgehen kann.<\/span>.<\/p>\n\n\n\n Beispielsweise l\u00e4sst ein internes Firmennetzwerk m\u00f6glicherweise nur externe Kommunikation \u00fcber die Ports 80 und 443 zu. Aber selbst in diesem Fall besteht eine hohe Wahrscheinlichkeit, dass die Kommunikation durchkommt, wenn der TURN-Server TLS-Kommunikation \u00fcber Port 443 verwendet. Da die Kommunikation zudem mit TLS verschl\u00fcsselt ist, ist sie sicher und f\u00fcr Dritte nur schwer abzufangen.<\/p>\n\n\n\n In WebRTC sind die Einstellungen TURNS eignet sich f\u00fcr die WebRTC-Kommunikation in stark eingeschr\u00e4nkten Umgebungen wie Unternehmensnetzwerken, in denen alle anderen Kommunikationswege blockiert sind. Selbst in Umgebungen, in denen alle UDP- und allgemeinen TCP-Ports blockiert sind, gibt es viele Richtlinien, die die Kommunikation auf die gleiche Weise wie HTTPS zulassen. Daher ist TURN auf TLS-Port 443 praktisch nur ein letzter Ausweg.<\/p>\n\n\n\n Es wird auch in Situationen verwendet, in denen bestimmte Ports in \u00f6ffentlichen WLANs geschlossen sind oder wenn auf der Clientseite nur TLS-Kommunikation m\u00f6glich ist.Zuerst UDP, wenn das nicht funktioniert, dann TCP, wenn das nicht funktioniert, dann TLS bis 443<\/span>\u201eEs handelt sich um die letzte Phase eines schrittweisen R\u00fcckzugs.\u201c<\/p>\n\n\n\n Sein gr\u00f6\u00dfter Vorteil ist die hohe Firewall-Resistenz. TLS-verschl\u00fcsselte Kommunikation ist schwer von allgemeinem HTTPS zu unterscheiden und passiert daher eher strenge Filter. Insbesondere bei der Einf\u00fchrung eines Webkonferenzsystems in einem Unternehmen m\u00fcssen externe Verbindungen aus dem internen Netzwerk zugelassen werden. TLS-Kommunikation \u00fcber TCP\/443 wird jedoch von Sicherheitsrichtlinien eher akzeptiert. Da sie zudem verschl\u00fcsselt ist, ist die Vertraulichkeit der Kommunikation mit dem Relay-Server selbst gew\u00e4hrleistet (*Inhalte selbst, wie z. B. Videos, werden jedoch h\u00e4ufig bereits auf der WebRTC-Ebene verschl\u00fcsselt).<\/p>\n\n\n\n Der gr\u00f6\u00dfte Nachteil ist die Leistungseinbu\u00dfe. Neben der Verz\u00f6gerung und Belastung von TURN selbst kommt noch der Overhead von TLS und TCP hinzu. TCP ist ein zuverl\u00e4ssiges Transportmittel und verf\u00fcgt \u00fcber einen Mechanismus zur erneuten \u00dcbertragung bei Paketverlust, ist jedoch nicht f\u00fcr Echtzeitmedien geeignet. Bei Verlusten k\u00f6nnen Video und Audio m\u00f6glicherweise nicht reibungslos wiedergegeben werden.<\/p>\n\n\n\n Dar\u00fcber hinaus ist TCP aufgrund der Paketreihenfolge anf\u00e4llig f\u00fcr Head-of-Line-Blockierungen.Auch der Jitter (die Schwankung) nimmt im Vergleich zu UDP zu.<\/span>Dar\u00fcber hinaus belastet die TLS-Ver- und -Entschl\u00fcsselung die CPU zus\u00e4tzlich. Es wurde berichtet, dass dadurch eine zus\u00e4tzliche Verz\u00f6gerung von 50 ms oder mehr auftritt, die f\u00fcr die Benutzer sp\u00fcrbar ist. Insbesondere bei Videokonferenzen kann diese erh\u00f6hte Verz\u00f6gerung das Gespr\u00e4chstempo verlangsamen und zu sp\u00fcrbaren Zeitabweichungen f\u00fchren.<\/p>\n\n\n\n Auf diese Weise kann TURNS qualitativ als Methode der \u201eletzten Instanz\u201c betrachtet werden, es ist jedoch auch eine zuverl\u00e4ssige Rettungsleine in Situationen, in denen es keine andere M\u00f6glichkeit gibt, als eine Kommunikation herzustellen.<\/p>\n\n\n\n In den letzten Jahren wurde ein neuer Ansatz (TURN over QUIC) in Betracht gezogen, der auf UDP-Port 443 operiert und DTLS\/QUIC anstelle von TLS verwendet. Dieser befindet sich jedoch noch im Standardisierungsprozess und wird nicht allgemein verwendet.<\/p>\n\n\n\n Wir erkl\u00e4ren Schritt f\u00fcr Schritt, wie die WebRTC ICE-Verarbeitung abl\u00e4uft, wenn STUN \u00fcber UDP nicht verf\u00fcgbar ist. Nehmen wir eine Situation an, in der UDP vollst\u00e4ndig blockiert ist, beispielsweise in einem Unternehmensnetzwerk, und verfolgen, wie die ICE-Verhandlung zur\u00fcckf\u00e4llt.<\/p>\n\n\n\n Dies ist der Ablauf der ICE-Verhandlung in anspruchsvollen Umgebungen, in denen UDP nicht verwendet werden kann. Kurz gesagt: Kandidaten werden in der Reihenfolge \u201eHost \u2192 STUN \u2192 TURN\u201c ausprobiert. Wenn dies nicht funktioniert, schl\u00e4gt die Verbindung fehl. Entwickler sollten dieses Verhalten verstehen und zumindest einen TURN\/TURNS-Server in die ICE-Serverliste aufnehmen, damit auch im schlimmsten Fall eine Kommunikation m\u00f6glich ist. Bei Benutzeranfragen ist au\u00dferdem eine Fehlersuche erforderlich, z. B. das Ableiten eines Problems in der Netzwerkumgebung (z. B. UDP-Blockierung) aus Informationen wie \u201eICE fehlgeschlagen\u201c und die \u00dcberpr\u00fcfung fehlender TURN-Servereinstellungen.<\/p>\n\n\n\nSTUN-Nutzungsszenarien<\/strong><\/h4>\n\n\n\n
Einschr\u00e4nkungen und Nachteile von STUN<\/h4>\n\n\n\n
Rolle und Funktionen von TURN (UDP)<\/h3>\n\n\n\n
TURN-Nutzungsszenarien<\/h4>\n\n\n\n
Vorteile von TURN<\/strong><\/h4>\n\n\n\n
Nachteile von TURN<\/strong><\/h4>\n\n\n\n
Rolle und Funktionen von TURNS (TLS \u00fcber TCP\/443)<\/h3>\n\n\n\n
"URLs": "Turns:Turnsserver:443"<\/code>Im URI-Schema:dreht sich:<\/code>Sie k\u00f6nnen diesen TLS-verschl\u00fcsselten TURN-Server verwenden, indem Sie<\/p>\n\n\n\nSzenen, in denen TURNS verwendet wird<\/h4>\n\n\n\n
Vorteile von TURNS<\/h4>\n\n\n\n
Nachteile von TURNS<\/h4>\n\n\n\n
Kommunikationsfluss, wenn UDP STUN nicht verf\u00fcgbar ist<\/h2>\n\n\n\n
WebRTC-Client (Browser)iceServers<\/code>Eine Bindungsanforderung (Anforderung zur \u00dcberpr\u00fcfung der externen Adresse) wird \u00fcber UDP-Port 3478 an den angegebenen STUN-Server gesendet. Dies ist der erste Schritt beim Sammeln von ICE-Kandidaten. Bei Erfolg gibt der Server seine eigene globale IP-Adresse und Portnummer zur\u00fcck und wird der Kandidatenliste als Server Reflexive Candidate (srflx-Kandidat) hinzugef\u00fcgt.<\/li>
In diesem Fall verhindern die Firewall-Einstellungen des Netzwerks, dass UDP-Kommunikation nach au\u00dfen gelangt. Daher erreichen Anfragen an den STUN-Server diesen nicht oder die Antwort den Client nicht. Der ClientSTUN-Antwort nicht empfangen<\/strong>Die externe IP-Adresse ist nicht bekannt. Der ICE-Agent wartet eine gewisse Zeit auf eine Antwort, tritt dann aber ein Timeout ein. Aus Benutzersicht wird die Verbindung noch verarbeitet, und es wird keine Fehlermeldung angezeigt. In WirklichkeitKandidaten konnten nicht gesammelt werden<\/strong>Dies geschieht derzeit.<\/li>
Normalerweise verf\u00fcgt der Client bei erfolgreichem STUN zus\u00e4tzlich zum Host-Kandidaten (Ihrer lokalen IP) \u00fcber einen Server-Reflexive-Kandidaten (Ihre globale IP) und pr\u00fcft die Verbindung, indem er diesen mit dem \u00e4hnlichen Kandidaten des Gegenparts kombiniert. Wenn jedoch aufgrund eines STUN-Fehlers kein globaler IP-Kandidat vorhanden ist,Kandidaten f\u00fcr direkte Peer-Verbindungen sind \u00e4u\u00dferst begrenzt<\/strong>Wenn beispielsweise beide Parteien nur \u00fcber private IP-Adressen verf\u00fcgen, k\u00f6nnen sie sich selbst bei Verbindungsversuchen nicht erreichen. ICE stellt daraufhin fest, dass eine direkte Kommunikation nicht m\u00f6glich ist. Ist der ICE-Server (TURN) nicht konfiguriert, wird das gesamte ICE zu diesem Zeitpunkt als Fehler behandelt und die WebRTC-Verbindung wird nicht hergestellt (die Entwicklerkonsole zeigt an:ICE ist ausgefallen<\/code>und ... undICE-Verbindungsstatus: fehlgeschlagen<\/code>usw. werden angezeigt).<\/li>
Selbst wenn die direkte Kandidatenakquise durch STUN scheitert,iceServers<\/code>Wenn ein TURN-Server angegeben ist inN\u00e4chste Schritte<\/strong>Da UDP in diesem Beispiel nicht verf\u00fcgbar ist, versucht der Client, \u00fcber TCP oder TLS eine Verbindung zum TURN-Server herzustellen (z. B.Kurven:turn.example.com:443<\/code>(Falls konfiguriert, startet der TLS-Handshake.) Gl\u00fccklicherweise erlaubt die Firewall HTTPS-Kommunikation \u00fcber TCP 443, sodass die TURN-Verbindung \u00fcber TLS erfolgreich ist. Der Client sichert sich eine Relay-Adresse auf dem TURN-Server.Staffelkandidat<\/strong>Die Gegenseite erh\u00e4lt Relay-Kandidaten, virtuelle Kandidaten f\u00fcr die Kommunikation \u00fcber den TURN-Server. Gleichzeitig erh\u00e4lt die Gegenseite (die Remote-Seite) ebenfalls Relay-Kandidaten oder, sofern das Netzwerk einwandfrei funktioniert, direkte Kandidaten oder STUN-Kandidaten. Sobald mindestens eine Seite Relay-Kandidaten hat, kann die Gegenseite versuchen, eine Verbindung zu diesem TURN-Server herzustellen.<\/li>
Sobald beide Peers \u00fcber verf\u00fcgbare Kandidaten verf\u00fcgen (in diesem Beispiel einen oder beide Relay-Kandidaten), nutzt ICE diese zur Verbindungspr\u00fcfung. Sobald die Kommunikation \u00fcber den TURN-Server mit dem Server hergestellt ist, kann sie weitergeleitet werden. Der Medienkanal wird somit ge\u00f6ffnet, auch wenn UDP nicht direkt zwischen den Peers \u00fcbertragen wird. Dies erm\u00f6glicht die Video- und Audiokommunikation zwischen den Benutzern. Nach dem Verbindungsaufbau entsteht zwar ein gewisser Overhead in Form von TCP \u00fcber TLS, die Kommunikation selbst ist jedoch m\u00f6glich. Tritt jedoch auch hier ein Fehler auf (z. B. wenn ein Unternehmensproxy Nicht-HTTP-TLS-Kommunikation erkennt und blockiert oder die Authentifizierung des TURN-Servers fehlschl\u00e4gt), schl\u00e4gt ICE leider fehl und die Verbindung wird abgebrochen. Die Anwendung muss diese Situation erkennen und den Benutzer benachrichtigen, dass die Verbindung nicht m\u00f6glich war usw.<\/li><\/ol>\n\n\n\nErstellen und Konfigurieren eines STUN\/TURN\/TURNS-Servers mit Coturn<\/h2>\n\n\n\n