Eine ausführliche Erklärung und Anwendung von STUN/TURN/TURNS/SFU in WebRTC

Was ist WebRTC?

WebRTC (Web Real-Time Communication) ist eine offene Technologie, die Echtzeit-Sprach-, Video- und Datenkommunikation zwischen Browsern ermöglicht. Sie wird von verschiedenen Unternehmen, darunter Google, als Mechanismus standardisiert, der P2P-Kommunikation ausschließlich über JavaScript-APIs ohne zusätzliche Plug-ins oder Software ermöglicht.

WebRTC besteht aus drei Hauptkomponenten:

• getUserMedia: Eine API zum Erfassen von Audio und Video von Geräten wie Kameras und Mikrofonen.
• RTCPeerConnection: Eine zentrale API zum Herstellen der Kommunikation zwischen Peers und zum Austausch von Medien und Daten.
• RTCDataChannel: Ein Datenkanal, der zum Senden von Dateien, Chatten usw. verwendet werden kann.

Diese APIs ermöglichen die Entwicklung zahlreicher Echtzeitanwendungen wie Videoanrufe, Audiokonferenzen, Dateifreigabe usw. Bei der tatsächlichen 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.

Unterschiede und Rollen von STUN, TURN und TURNS

Um eine stabile Peer-to-Peer-Verbindung mit WebRTC zu erreichen, ist ein NAT-Traversal-Mechanismus unerlässlich. Dieser Artikel erläutert detailliert die technischen Unterschiede, Anwendungsszenarien sowie Vor- und Nachteile der repräsentativen Technologien STUN, TURN und TURNS.

STUN dient in erster Linie dazu, die externe Adresse in einer NAT-Umgebung zu ermitteln, während TURN als Relay-Server fungiert, wenn keine direkte Verbindung möglich ist. TURNS hingegen verschlüsselt die TURN-Kommunikation mit TLS und verwendet dieselbe Portnummer 443 wie HTTPS. Dadurch ist die Kommunikation hinter strengen Firewalls, beispielsweise in Unternehmensnetzwerken, möglich.

Indem Sie die jeweiligen Eigenschaften verstehen und sie entsprechend nutzen, können Sie die Erfolgsquote und Qualität der WebRTC-Kommunikation steigern.

Rolle und Funktionen von STUN (UDP)

STUN (Session Traversal Utilities for NAT) ist ein Protokoll, das es Clients ermöglicht,Externe IP-Adresse und PortEs 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ßen ermitteln.

Der STUN-Server fungiert als Spiegel und gibt die Quellinformationen der empfangenen Anfrage unverändert zurück. Dadurch kann der Client seine eigene globale IP-Adresse und die vom NAT (Server Reflexive Candidate) zugewiesene Portnummer ermitteln.

Die STUN-Kommunikation erfolgt üblicherweise über UDP, der Standardport ist 3478 (UDP/3478). Da eine einfache, einmalige Kommunikation über UDP erforderlich ist, entsteht geringer Overhead, geringe Latenz und nahezu keine Serverlast. Daher wird in Umgebungen, in denen UDP-Kommunikation zulässig ist, zunächst eine NAT-Traversierung mit STUN versucht.

STUN-Nutzungsszenarien

Es eignet sich für 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ält, können diese direkt (Peer-to-Peer) kommunizieren. Durch den direkten Kommunikationspfad treten geringere Verzögerungen auf und die Qualität bleibt hoch. Da der Server lediglich den IP-Informationsaustausch übernimmt, bleiben die Kosten zudem sehr gering. Beispielsweise reicht STUN bei Online-Spielen oder Videoanrufen aus, um eine Peer-to-Peer-Verbindung zu ermöglichen, wenn sich beide Geräte in einem relativ offenen NAT befinden.

Einschränkungen und Nachteile von STUN

STUN dient lediglich dazu, die eigene externe Adresse zu ermitteln. Je nach NAT-Typ und Firewall-Einschränkungen ist eine Verbindung allein dadurch möglicherweise nicht möglich. Insbesondere in symmetrischen NAT- oder strengen Firewall-Umgebungen erreichen Pakete der Gegenstelle die durch STUN ermittelte Adresse möglicherweise nicht, was eine Kommunikation unmöglich macht.

Darüber hinaus kann die UDP-Kommunikation selbst in Unternehmensnetzwerken blockiert sein, sodass STUN-Anfragen das Gerät nicht erreichen. Kurz gesagt: STUN ist ein Mechanismus, um festzustellen, ob direkte Kommunikation möglich ist, und funktioniert nicht in Umgebungen, in denen direkte Kommunikation physisch unmöglich ist. Aus diesem Grund wird STUN in ICE (siehe unten) verwendet, um Kandidaten für die erste Stufe zu ermitteln. Sollte STUN nicht ausreichen, wird auf TURN (siehe unten) zurückgegriffen.

Rolle und Funktionen von TURN (UDP)

TURN (Traversal Using Relays around NAT) ist ein Protokoll, das als Relay fungiert, wenn eine direkte Kommunikation mit STUN nicht möglich 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ält eine Relay-IP-Adresse und einen Port, den sogenannten Relay-Kandidaten. Anschließend erfolgt der Medien- und Datenaustausch mit der Gegenstelle über diesen TURN-Server.

TURN kommuniziert normalerweise ebenfalls über UDP. Solange UDP verwendet wird, kann es Medienpakete ähnlich wie bei direkter Kommunikation weiterleiten. Standardmäßig wird das TURN-Protokoll auf Port 3478 (UDP) akzeptiert, genau wie STUN. Selbst wenn die UDP-Portnummer durch die Firewall-Richtlinie eingeschränkt ist, kann TURN auch auf einem zulässigen Port wie UDP/443 ausgeführt werden. Solange UDP verwendet wird, ist Weiterleiten mit höherer Echtzeitleistung als TCP möglich.

TURN-Nutzungsszenarien

TURN ist unerlässlich, 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 über symmetrische NATs verfügen und das UDP-Hole-Punching fehlschlägt.In einer solchen Umgebung ist die Kommunikation ohne Weiterleitung über einen TURN-Server nicht möglich, sodass TURN als eine Art letzter Ausweg fungiert.

WebRTC zielt darauf ab, dass alle Teilnehmer direkt kommunizieren können. Selbst wenn dies nicht möglich ist, kann die Kommunikation durch einen Rückgriff auf TURN fortgesetzt werden. Im praktischen Einsatz besteht die allgemeine Strategie darin, zunächst eine direkte Verbindung per STUN herzustellen und erst dann auf TURN-Relay umzuschalten, wenn dies fehlschlägt. Wenn beispielsweise bei einer Videokonferenz über ein internes Netzwerk die beiden Teilnehmer nicht direkt miteinander kommunizieren können, wird automatisch auf den TURN-Server umgeschaltet, sodass der Benutzer das Gespräch unmerklich fortsetzen kann.

Vorteile von TURN

Der größte Vorteil ist die Zuverlässigkeit. Unabhängig von Ihrer NAT- oder Firewall-Umgebung ist Peer-to-Peer-Kommunikation möglich, 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ögerungen nahtlos verläuft.

Nachteile von TURN

Die größten Nachteile sind Ressourcenverbrauch und Latenz. Bei TURN müssen alle Audio- und Videodaten über 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ührt zu hohen Betriebskosten eines TURN-Servers, und für umfangreiche Dienste müssen mehrere TURN-Relay-Server vorbereitet und skaliert werden.

Darüber hinaus ist die Verzögerung umso größer, je länger der Kommunikationspfad ist, was zu einer Zeitverzögerung und einer verringerten Video- und Audioqualität führt. Darüber hinaus ist die Kommunikation über 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üsselte RTP/Datagramme weiterleiten und die Inhalte nicht interpretieren).

TURN sollte grundsätzlich nur bei Bedarf eingesetzt werden. Tatsächlich können die meisten WebRTC-Kommunikationen direkt über 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ötigen TURN, für diese ist jedoch eine TURN-Infrastruktur unerlässlich.

Rolle und Funktionen von TURNS (TLS über TCP/443)

TURNS ist eine Abkürzung für „TURN over TLS“ und ein Protokoll, das Relay-Kommunikation mithilfe des TURN-Protokolls mit TLS (Transport Layer Security) verschlüsselt.TURN-Kommunikation durch TLS (HTTPS) gesichertund wird häufig auf TCP-Port 443 bedient.Port 443 ist dieselbe Portnummer wie HTTPS, sodass er problemlos Unternehmensfirewalls passieren und Proxys und Zensur leicht umgehen kann..

Beispielsweise lässt ein internes Firmennetzwerk möglicherweise nur externe Kommunikation über 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 über Port 443 verwendet. Da die Kommunikation zudem mit TLS verschlüsselt ist, ist sie sicher und für Dritte nur schwer abzufangen.

In WebRTC sind die Einstellungen"URLs": "Turns:Turnsserver:443"Im URI-Schema:dreht sich:Sie können diesen TLS-verschlüsselten TURN-Server verwenden, indem Sie

Szenen, in denen TURNS verwendet wird

TURNS eignet sich für die WebRTC-Kommunikation in stark eingeschränkten 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.

Es wird auch in Situationen verwendet, in denen bestimmte Ports in öffentlichen WLANs geschlossen sind oder wenn auf der Clientseite nur TLS-Kommunikation möglich ist.Zuerst UDP, wenn das nicht funktioniert, dann TCP, wenn das nicht funktioniert, dann TLS bis 443„Es handelt sich um die letzte Phase eines schrittweisen Rückzugs.“

Vorteile von TURNS

Sein größter Vorteil ist die hohe Firewall-Resistenz. TLS-verschlüsselte Kommunikation ist schwer von allgemeinem HTTPS zu unterscheiden und passiert daher eher strenge Filter. Insbesondere bei der Einführung eines Webkonferenzsystems in einem Unternehmen müssen externe Verbindungen aus dem internen Netzwerk zugelassen werden. TLS-Kommunikation über TCP/443 wird jedoch von Sicherheitsrichtlinien eher akzeptiert. Da sie zudem verschlüsselt ist, ist die Vertraulichkeit der Kommunikation mit dem Relay-Server selbst gewährleistet (*Inhalte selbst, wie z. B. Videos, werden jedoch häufig bereits auf der WebRTC-Ebene verschlüsselt).

Nachteile von TURNS

Der größte Nachteil ist die Leistungseinbuße. Neben der Verzögerung und Belastung von TURN selbst kommt noch der Overhead von TLS und TCP hinzu. TCP ist ein zuverlässiges Transportmittel und verfügt über einen Mechanismus zur erneuten Übertragung bei Paketverlust, ist jedoch nicht für Echtzeitmedien geeignet. Bei Verlusten können Video und Audio möglicherweise nicht reibungslos wiedergegeben werden.

Darüber hinaus ist TCP aufgrund der Paketreihenfolge anfällig für Head-of-Line-Blockierungen.Auch der Jitter (die Schwankung) nimmt im Vergleich zu UDP zu.Darüber hinaus belastet die TLS-Ver- und -Entschlüsselung die CPU zusätzlich. Es wurde berichtet, dass dadurch eine zusätzliche Verzögerung von 50 ms oder mehr auftritt, die für die Benutzer spürbar ist. Insbesondere bei Videokonferenzen kann diese erhöhte Verzögerung das Gesprächstempo verlangsamen und zu spürbaren Zeitabweichungen führen.

Auf diese Weise kann TURNS qualitativ als Methode der „letzten Instanz“ betrachtet werden, es ist jedoch auch eine zuverlässige Rettungsleine in Situationen, in denen es keine andere Möglichkeit gibt, als eine Kommunikation herzustellen.

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.

Kommunikationsfluss, wenn UDP STUN nicht verfügbar ist

Wir erklären Schritt für Schritt, wie die WebRTC ICE-Verarbeitung abläuft, wenn STUN über UDP nicht verfügbar ist. Nehmen wir eine Situation an, in der UDP vollständig blockiert ist, beispielsweise in einem Unternehmensnetzwerk, und verfolgen, wie die ICE-Verhandlung zurückfällt.

1. Der Client sendet eine externe IP-Anfrage (UDP/3478) an den STUN-Server:
   WebRTC-Client (Browser)iceServersEine Bindungsanforderung (Anforderung zur Überprüfung der externen Adresse) wird über 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ück und wird der Kandidatenliste als Server Reflexive Candidate (srflx-Kandidat) hinzugefügt.
2. UDP-Pakete werden von der Firewall blockiert und es wird keine Antwort empfangen:
   In diesem Fall verhindern die Firewall-Einstellungen des Netzwerks, dass UDP-Kommunikation nach außen gelangt. Daher erreichen Anfragen an den STUN-Server diesen nicht oder die Antwort den Client nicht. Der ClientSTUN-Antwort nicht empfangenDie 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 werdenDies geschieht derzeit.
3. Die Prüfung der direkten ICE-Verbindung schlägt fehl, da keine Server Reflexive-Kandidaten verfügbar sind:
   Normalerweise verfügt der Client bei erfolgreichem STUN zusätzlich zum Host-Kandidaten (Ihrer lokalen IP) über einen Server-Reflexive-Kandidaten (Ihre globale IP) und prüft die Verbindung, indem er diesen mit dem ähnlichen Kandidaten des Gegenparts kombiniert. Wenn jedoch aufgrund eines STUN-Fehlers kein globaler IP-Kandidat vorhanden ist,Kandidaten für direkte Peer-Verbindungen sind äußerst begrenztWenn beispielsweise beide Parteien nur über private IP-Adressen verfügen, können sie sich selbst bei Verbindungsversuchen nicht erreichen. ICE stellt daraufhin fest, dass eine direkte Kommunikation nicht möglich 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 ausgefallenund ... undICE-Verbindungsstatus: fehlgeschlagenusw. werden angezeigt).
4. Versuch, TURN-Relay-Kandidaten zu erhalten (über TCP/TLS/443):
   Selbst wenn die direkte Kandidatenakquise durch STUN scheitert,iceServersWenn ein TURN-Server angegeben ist inNächste SchritteDa UDP in diesem Beispiel nicht verfügbar ist, versucht der Client, über TCP oder TLS eine Verbindung zum TURN-Server herzustellen (z. B.Kurven:turn.example.com:443(Falls konfiguriert, startet der TLS-Handshake.) Glücklicherweise erlaubt die Firewall HTTPS-Kommunikation über TCP 443, sodass die TURN-Verbindung über TLS erfolgreich ist. Der Client sichert sich eine Relay-Adresse auf dem TURN-Server.StaffelkandidatDie Gegenseite erhält Relay-Kandidaten, virtuelle Kandidaten für die Kommunikation über den TURN-Server. Gleichzeitig erhält 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.
5. ICE-Verbindungsaufbau (bzw. ggf. Abbruch) über Relay:
   Sobald beide Peers über verfügbare Kandidaten verfügen (in diesem Beispiel einen oder beide Relay-Kandidaten), nutzt ICE diese zur Verbindungsprüfung. Sobald die Kommunikation über den TURN-Server mit dem Server hergestellt ist, kann sie weitergeleitet werden. Der Medienkanal wird somit geöffnet, auch wenn UDP nicht direkt zwischen den Peers übertragen wird. Dies ermöglicht die Video- und Audiokommunikation zwischen den Benutzern. Nach dem Verbindungsaufbau entsteht zwar ein gewisser Overhead in Form von TCP über TLS, die Kommunikation selbst ist jedoch möglich. 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ägt), schlägt ICE leider fehl und die Verbindung wird abgebrochen. Die Anwendung muss diese Situation erkennen und den Benutzer benachrichtigen, dass die Verbindung nicht möglich war usw.

Dies ist der Ablauf der ICE-Verhandlung in anspruchsvollen Umgebungen, in denen UDP nicht verwendet werden kann. Kurz gesagt: Kandidaten werden in der Reihenfolge „Host → STUN → TURN“ ausprobiert. Wenn dies nicht funktioniert, schlägt 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öglich ist. Bei Benutzeranfragen ist außerdem eine Fehlersuche erforderlich, z. B. das Ableiten eines Problems in der Netzwerkumgebung (z. B. UDP-Blockierung) aus Informationen wie „ICE fehlgeschlagen“ und die Überprüfung fehlender TURN-Servereinstellungen.

Erstellen und Konfigurieren eines STUN/TURN/TURNS-Servers mit Coturn

Wenn Sie Ihren eigenen STUN/TURN-Server einrichten möchten, verwenden Sie die Open-Source-Implementierung. CoturnEs ist üblich, coturn zu verwenden. coturn ist eine Serverimplementierung, die sowohl STUN als auch TURN unterstützt und je nach Einstellungen auch TURNS (TLS) unterstützen kann. Dieser Artikel erklärt die Installation von coturn auf einem Linux-Server und den Aufbau eines Servers, der STUN/TURN/TURNS unterstützt, sowie die Konfigurationspunkte. Außerdem wird die typische Konfigurationsdatei (turnserver.conf) wird ebenfalls angezeigt.

Installation und Grundkonfiguration

Installieren

Für Ubuntu und Debian,geeignetSie können das Coturn-Paket von installieren. Verwenden Sie beispielsweise den folgenden Befehl, um es zu installieren und den automatischen Start einzurichten.

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

Dadurch wird der Coturn-Server als Daemon gestartet. Standardmäßig wird die Konfigurationsdatei ausgeführt /etc/turnserver.conf Dadurch wird die Datei geladen und Sie können sie bearbeiten (erstellen Sie vor der Bearbeitung sicherheitshalber eine Sicherungskopie).

Grundeinstellungen

turnserver.confStellen Sie nun die folgenden Elemente ein:

• Realm und Servername: Dies ist der Domänenname oder Identifikationsname des TURN-Servers. Er kann bei der Authentifizierung eines WebRTC-Clients verwendet werden, kann aber grundsätzlich eine beliebige Zeichenfolge sein. Beispiel: realm=example.com,Servername=example.com.
• Abhörport: Die UDP-Portnummer, auf der TURN und STUN überwacht werden. Der Standardwert ist 3478.Abhören-IPSie können auch eine Bindung an eine bestimmte Netzwerkkarte herstellen mit0.0.0.0Wir akzeptieren alle.
• TLS-Abhörport: Dies ist die TCP-Portnummer, auf der TLS (TURNS) überwacht wird. In der Regel wird 443 oder 5349 angegeben. Beispiel: tls-listening-port=443.
• externe IP: Befindet sich der Server selbst hinter einem NAT, geben Sie seine eigene globale IP an (so erkennt der Server die Zuordnung zwischen interner und externer IP). Dies ist nicht erforderlich, wenn der Server eine direkte globale IP hat.
• Authentifizierungsmethode: WebRTC verwendet langfristige Anmeldeinformationen für TURN, alsolt-cred-mech(Long Term Credential Mechanism) ist aktiviert.Benutzer=Benutzername:Passwortoder legen Sie den Benutzernamen und das Passwort im Formatuse-auth-secret(Letzteres ist eine tokenbasierte Authentifizierung, die die Sicherheit wirksam verbessert, hier zeigen wir jedoch als Beispiel eine einfache statische Benutzerauthentifizierung.)
• Protokolleinstellungen: Zur FehlerbehebungProtokolldateiGeben Sie den Pfad der Protokolldatei inausführlichMöglicherweise möchten Sie die detaillierte Protokollierung aktivieren.

Firewall-Einstellungen

Auf der Serverseite für STUN/TURNUDP-Port 3478und für TURN/TLSTCP-Port 443(oder 5349) muss geöffnet sein. Darüber hinaus verwendet das TURN-Relay standardmäßig den UDP-Portbereich 10000-20000. Öffnen Sie diesen Portbereich daher auch auf dem Server (falls erforderlich).Min-PortundMax-Port(Der Bereich kann geändert werden mit

Nachfolgend sehen Sie ein Beispiel, das die oben aufgeführten Grundeinstellungen widerspiegelt./etc/turnserver.confHier ist ein Beispiel:

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

Im obigen Beispiel ist die Domäneexample.comWir erhalten ein Let’s Encrypt-Zertifikat und verwenden es für TLS-Einstellungen.lt-cred-mechAktivieren Sie die Langzeitauthentifizierung mitBenutzerDadurch wird eine einfache Benutzername/Passwort-Authentifizierung eingerichtet.use-auth-secretundstatisches AuthentifizierungsgeheimnisDie empfohlene Methode besteht darin, eine tokenbasierte Methode zum Ausstellen temporärer Anmeldeinformationen zu verwenden, aber darauf werden wir hier nicht näher eingehen.

Vorsichtsmaßnahmen bei der Verwendung von TLS

Wenn Sie coturn auf Port 443 ausführen, müssen Sie in einer Linux-Umgebung auf die Portberechtigungen achten. Ports unter 1024 werden als privilegierte Ports bezeichnet und können normalerweise nicht ohne Root-Rechte geöffnet werden. Das Ubuntu-Paket coturn verwendet standardmäßigTurnserverDa es von einem Benutzer ausgeführt wird, kann es nicht so wie es ist an Port 443 gebunden werden./etc/default/coturnÄndern Sie den laufenden Benutzer in root, odersetcapMit dem BefehlTurnserverzur ausführbaren Dateicap_net_bind_serviceEs gibt eine Möglichkeit, Berechtigungen zu erteilen. Im letzteren Fall beispielsweisesudo setcap cap_net_bind_service=+ep /usr/bin/turnserverMit diesem Befehl können auch Nicht-Root-Benutzer Ports mit niedriger Nummer binden. Geben Sie außerdem den korrekten Pfad zur Zertifikatsdatei (cert/pkey) an und legen Sie die Dateiberechtigungen so fest, dass der Coturn-Benutzer sie lesen kann. Nach der Änderung der Einstellungensudo systemctl restart coturnStarten Sie den Dienst neu und überprüfen Sie die Protokolle auf Fehler.

Funktionsprüfung

Nachdem wir den Coturn-Server gestartet haben, testen wir ihn mit einem STUN-Client, um seine Funktion zu überprüfen, und versuchen auch, von der WebRTC-App im Browser aus eine Verbindung zu ICE herzustellen.StunclientBefehl(apt-get installiere Stun-Client(Verfügbar für die Installation unterstunclient <Server-IP> 3478Sie können versuchen, Ihre externe IP-Adresse zu erhalten, indem Sie Folgendes ausführen. Außerdem werden in Ihrem Browser die ICE-Kandidaten im Protokoll der Entwicklertools aufgelistet, sodasssrflx(Server Reflexive) Kandidaten undRelaisPrüfen Sie, ob Sie einen Kandidaten finden. Falls nicht, versuchen Sie die folgenden Punkte zur Fehlerbehebung:

• Sind die erforderlichen Ports in den Firewall-Einstellungen des Servers geöffnet (iptables oder Cloud-Sicherheitsgruppen)?
• Sind in den clientseitigen ICE-Servereinstellungen (siehe unten) die richtigen URI-, Port- und Authentifizierungsinformationen festgelegt?
• turnserver.confvonReichStellen Sie sicher, dass die Einstellungen mit der Client-Authentifizierung übereinstimmen. (Dies ist in der Browserversion von WebRTC normalerweise kein Problem, da der Realm automatisch zugewiesen wird. Seien Sie jedoch vorsichtig, wenn Sie eine benutzerdefinierte Implementierung haben.)
• Coturn-Protokoll (/var/log/turnserver.log) und prüfen Sie, ob ein Authentifizierungsfehler vorliegt (FALSCHE BENUTZERWenn ein Fehler wie der oben genannte auftritt, stimmen Benutzername und Passwort nicht überein.

Mit den oben genannten Einstellungen verfügen Sie über einen eigenen STUN/TURN/TURNS-Server, der läuft und WebRTC-Verbindungen in einer Vielzahl von Netzwerkumgebungen unterstützen kann.

Beispiel für ICE-Servereinstellungen für WebRTC-Client (JavaScript)

Um den STUN/TURN-Server, den wir gerade auf der WebRTC-Anwendung (Browser) erstellt haben, tatsächlich zu verwenden,ICE-ServereinstellungenIn der WebRTC-API von JavaScriptRTCPeerConnectionSie können beim Generieren einer eine Liste von STUN/TURN-Servern angeben. Im Folgenden zeigen wir ein konkretes Codebeispiel, das alle STUN/TURN/TURNS-Server angibt und deren Bedeutung erklärt.

Erstellen Sie zunächst ein Konfigurationsobjekt für den ICE-Server. Geben Sie den Domänennamen Ihres Servers ein.turn.example.com(Zutreffendes ersetzen). STUN erfordert keine Authentifizierung, daher wird nur die URI angegeben. TURN/TURNS erfordert eine Authentifizierung, daher werden auch Benutzername und Passwort angegeben.

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

ObenstehendesiceServersDas Array hat drei Einträge.

1. BETÄUBEN: stun:turn.example.com:3478
   Gibt die Adresse Ihres eigenen STUN-Servers an (wenn der Port weggelassen wird, wird 3478 verwendet). STUN wird verwendet, um NAT-Traversal zu bestimmen und Kandidaten zu erhalten. Der Browser fragt diesen Server zunächst per UDP ab, um serverreflexive Kandidaten zu erhalten.
2. DREHEN (UDP): drehen:turn.example.com:443?transport=udp
   Erstellen Sie Ihren eigenen TURN-ServerUDP-Port 443Dies ist die zu verwendende Einstellung. Der Benutzername, der zuvor in coturn als Authentifizierungsinformation festgelegt wurdewebrtcuserund Passwortsecretpass123Der Abfrageparameter ist angegeben.?transport=udp(Wenn nichts anderes angegeben ist, versucht der Browser zuerst UDP und, wenn dies fehlschlägt, auch TCP.) Mit dieser Einstellung können Sie einen Kandidaten für das TURN-Relay auf UDP-Port 443 erhalten, selbst wenn eine direkte Verbindung mit normalem STUN fehlschlägt.
3. TURN (TLS/TCP): Kurven:turn.example.com:443
   TURN mit TLSDies ist die Einstellung für den TURNS-Server. Benutzername und Passwort werden hier ebenfalls angegeben. Der Browser stellt eine TLS-Verbindung zu diesem Eintrag über TCP-Port 443 her, um einen TURN-Relay-Kandidaten zu erhalten. Dies ist der Relay-Kandidat der letzten Instanz, und es besteht die Möglichkeit, eine Kommunikation aufzubauen, selbst wenn eine Kommunikation über UDP überhaupt nicht möglich ist.

RTCPeerConnectionWenn der ICE-Agent den ICE-Server generiert, versucht er, der Reihe nach eine Verbindung zu den angegebenen ICE-Servern herzustellen und Kandidaten zu sammeln. Der ICE-Agent ermittelt zunächst STUN-Kandidaten (srflx) und anschließend parallel dazu TURN-Kandidaten (Relay). Der ICE-Algorithmus kombiniert diese Kandidaten, führt eine Verbindungsprüfung durch und wählt die optimale Route. Entwickler müssen sich nicht um weitere Verfahren kümmern.

Punkt: Wie oben erwähntBereiten Sie mehrere Kandidaten vorist wichtig. Zum Beispielbetäuben:Wenn Sie nur TURN (UDP) angeben, werden in einer Umgebung, in der UDP blockiert ist, keine Kandidaten gefunden, und die Verbindung schlägt fehl. Wenn Sie nur TURN (UDP) angeben, schlägt die Verbindung in einer Umgebung fehl, in der nur TCP zulässig ist. Daher, wenn möglich,drehen:unddreht sich:Durch die Einbindung beider in den ICE-Server wird Redundanz erreicht, sodass in jeder Umgebung mindestens ein gültiger Kandidat gefunden werden kann (der TURN-Server muss natürlich sowohl UDP als auch TCP/TLS unterstützen). Der Client (Browser) wählt automatisch einen verfügbaren Pfad aus, sodass die Reihenfolge der Liste kein großes Problem darstellt. Wenn ich sagen müsste:EistransportpolitikvonRelaisSofern Sie dies nicht angeben, priorisiert der Browser direkte Verbindungen. Durch die Eingabe eines STUN-Eintrags können Sie die unnötige Nutzung des TURN-Servers vermeiden. Auch wenn irrelevante Server (nicht vorhandene Adressen usw.) in der ICE-Serverliste eingetragen sind, kann es aufgrund von Wartezeiten zu Verzögerungen kommen. Tragen Sie daher am besten nur Server ein, die definitiv verfügbar sind.

Lassen Sie uns abschließend die WebRTC-Anwendung mit dieser Einstellung ausführen und den Verbindungsstatus überprüfen.peerConnection.getStats()oderchrome://webrtc-internalsSie können den ICE-Kandidaten und den Verbindungsstatus mit (Chrome) überprüfen. Wenn alles wie erwartet funktioniert, sollte in einer Umgebung mit verfügbarem UDP automatisch auf eine direkte (P2P-)Verbindung zurückgegriffen werden, und in einer Umgebung, in der dies schwierig ist, auf eine Verbindung über TURN/TLS.

Unterschied zwischen SFU und TURN

WebRTC-Relays lassen sich grob in „TURN“ und „SFU“ unterteilen. Ihre Rollen, Konfigurationen und Anwendungen unterscheiden sich jedoch erheblich. Hier fassen wir die technischen Unterschiede zusammen.

TURN: Relay als Alternative zu Peer-to-Peer

TURN (Traversal Using Relays around NAT) ist ein zusätzlicher Relay-Server, der in Umgebungen eingesetzt wird, in denen WebRTC-P2P-Kommunikation nicht möglich ist. Der TURN-Server fungiert zwischen Peers und leitet Pakete weiter, wenn STUN aufgrund von NAT oder Firewalls nicht funktioniert. Da jeder Peer einen Stream an jeden Kommunikationspartner einzeln sendet, ist die Konfiguration netzartig, und TURN fungiert als „Pinch Hitter“.

• Zusammensetzung: Jeder Benutzer überträgt an jeden anderen Benutzer über ein Relais (effektiv ein Mesh)
• Skalierbarkeit: Niedrig (je mehr Personen, desto höher die Belastung)
• Sendeinhalte: Nur einfache Paketübertragung, keine Medienanalyse oder -optimierung

SFU: Effizientes Relay für Mehrparteiengespräche

SFU (Selective Forwarding Unit) ist ein intelligenter Relay-Server, der in Webkonferenzen mit mehreren Teilnehmern verwendet wird.Jeder Client sendet einen Stream an die SFU, die ihn selektiv an andere Teilnehmer weiterleitet.Darüber hinaus führt es Prozesse wie Sprechererkennung, Bildqualitätsanpassung und Latenzoptimierung durch und ermöglicht so skalierbares, leistungsstarkes Broadcasting.

• Zusammensetzung: Sterntyp, bei dem jeder Client mit einer SFU verbunden ist
• Skalierbarkeit: Teuer (nur eine Übertragung, auch wenn die Personenzahl steigt)
• Sendeinhalte: Steuerung des Übertragungsziels und Medienoptimierung sind möglich

Vergleichstabelle zwischen TURN und SFU

TURN ist lediglich ein letzter Ausweg, wenn keine P2P-Kommunikation möglich ist, und ist ein Relay, das das P2P-Netz ergänzt.SFU ist eine Relay-Architektur, die von Anfang an auf Effizienz bei Mehrparteiengesprächen ausgelegt ist.Da die beiden grundsätzlich unterschiedliche Rollen haben, ist es wichtig, sie beim Entwurf nicht zu verwechseln.

Zusammenfassung

Dieser Artikel bietet WebRTC-Benutzern mit mittleren bis fortgeschrittenen Kenntnissen eine detaillierte Erklärung der technischen Unterschiede zwischen STUN, TURN und TURNS sowie wann sie verwendet werden, wie man mit Coturn und einigen Codebeispielen einen Server erstellt und wie sich ICE in rauen Netzwerkumgebungen verhält.

BETÄUBENEs ist leichtgewichtig und ermöglicht die direkte Kommunikation in NAT-Umgebungen.DREHENbietet eine Rettungsleine für die Kommunikation in schwierigen Situationen; undKurvenDurch die Kombination dieser wird es möglich, WebRTC auch in speziellen Umgebungen wie beispielsweise innerhalb eines Unternehmens einzusetzen.

Jede dieser Optionen hat ihre Vor- und Nachteile. Idealerweise sollten Sie daher, wann immer möglich, eine direkte Verbindung mit STUN herstellen und TURN-Relay nur verwenden, wenn es unbedingt nötig ist. Bei der Entwicklung von WebRTC-Anwendungen können Sie durch die hier vorgestellte Vorbereitung mehrerer Routen in den ICE-Servereinstellungen und die ordnungsgemäße Konfiguration und Ausführung von Coturn auf der Serverseite stabile Echtzeitkommunikation in verschiedenen Netzwerkumgebungen gewährleisten.

WebRTC ist ein komplexes Feld, das Browser-APIs und Netzwerktechnologien kombiniert. Um jedoch zuverlässige Anwendungen zu erstellen, ist es wichtig zu verstehen, wie STUN/TURN und ICE funktionieren.

Wir hoffen, dass Sie die Informationen in diesem Artikel nutzen, um die NAT-Traversal-Herausforderung in Ihren eigenen Produkten zu meistern. So können Ihre Benutzer dank der intelligenten Verbindungsverarbeitung im Hintergrund nahtlos kommunizieren, ohne es zu merken.