TURN-Server: Was es ist, wie es funktioniert und wo es eingesetzt wird

Was ist ein TURN-Server

TURN-Server (Traversal Using Relays around NAT) ist ein in RFC 5766 definierter und in RFC 8656 aktualisierter Netzwerkdienst, der UDP- und TCP-Verkehr zwischen zwei Clients weiterleitet, wenn eine direkte P2P-Verbindung aufgrund von NAT- oder Firewall-Einschränkungen nicht möglich ist. In der WebRTC-Architektur fungiert der TURN-Server als letzter Fallback-Mechanismus, der die Konnektivität unter allen Netzwerkbedingungen garantiert.

Im Gegensatz zu STUN, das einem Client lediglich seine externe Adresse mitteilt, beteiligt sich der TURN-Server aktiv an der Datenübertragung. Jeder Peer stellt eine Verbindung zum TURN-Server her und sendet seine Mediendaten an ihn. Der TURN-Server leitet diese Daten dann an den anderen Peer weiter. Dadurch besteht keine direkte Verbindung zwischen den Peers – der gesamte Verkehr läuft über den Relay-Server, was die Zustellung selbst unter den strengsten NAT-Einschränkungen garantiert.

TURN-Protokoll

TURN ist eine Erweiterung des STUN-Protokolls. TURN-Nachrichten verwenden denselben 20-Byte-Header und denselben Attributmechanismus. Der Hauptunterschied besteht darin, dass TURN neue Nachrichtentypen (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) und Attribute definiert, die für die Verwaltung von Relay-Allokationen erforderlich sind. Der Client erstellt eine Allokation auf dem TURN-Server über eine Allocate-Nachricht, erhält eine weitergeleitete Transportadresse (relayed transport address) und verwendet sie zum Senden und Empfangen von Daten über den Server.

Wie ein TURN-Server funktioniert

Der TURN-Server arbeitet nach der folgenden Schrittfolge. Der Client sendet eine Allocate-Anfrage mit Authentifizierung (username, credential). Der Server überprüft die Anmeldeinformationen und erstellt eine Allokation – eine temporäre Bindung einer weitergeleiteten Adresse (IP:Port auf dem TURN-Server) an den Client. Der Server sendet eine Allocate-Antwort mit einer weitergeleiteten Transportadresse zurück – der Adresse, die andere Peers verwenden, um Daten an diesen Client über den TURN-Server zu senden.

Nach der Erstellung der Allokation kann der Client Daten über den TURN-Server mithilfe von Send Indication-Nachrichten oder über Kanäle (ChannelBind) senden. Beim Empfang von Daten vom Client überprüft der TURN-Server die Berechtigungen (Autorisierung zum Senden von Daten an bestimmte Peers) und leitet die Daten an den Ziel-Peer weiter. Zum Empfangen eingehender Daten muss der Client zunächst eine Berechtigung für den Peer erstellen, von dem er Daten erwartet; andernfalls verwirft der TURN-Server das eingehende Paket. Eine Berechtigung wird über eine CreatePermission-Nachricht unter Angabe der IP-Adresse des Peers erstellt.

Allokation und Lebensdauer

Eine Allokation auf dem TURN-Server hat eine begrenzte Lebensdauer – standardmäßig 10 Minuten. Der Client muss regelmäßig eine Refresh-Anfrage senden, um die Allokation zu verlängern. Die Lebensdauer wird in Sekunden im Attribut LIFETIME angegeben. Wenn kein Refresh empfangen wird, entfernt der Server die Allokation und gibt die weitergeleitete Adresse frei. Empfohlenes Aktualisierungsintervall – 5 Minuten (300 Sekunden) als Schutz gegen den Verlust von Refresh-Paketen.

TURN-Server in WebRTC konfigurieren

In WebRTC wird der TURN-Server über die RTCPeerConnection-Konfiguration im iceServers-Array konfiguriert. TURN-Server können UDP-, TCP- oder TLS-Transport verwenden. Die Authentifizierung verwendet in der Regel zeitlich begrenzte Anmeldeinformationen (TURN-Anmeldeinformationen), die auf dem Anwendungsserver mit einer eingeschränkten Gültigkeitsdauer generiert werden.

Betrachten Sie ein Beispiel für die TURN-Server-Konfiguration in JavaScript mit HMAC-SHA1-Token-Authentifizierung.

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

In diesem Beispiel wird der TURN-Server zusammen mit einem STUN-Server in einer einzigen ICE-Konfiguration angegeben. Der ICE-Prozess versucht zunächst, Host-Kandidaten und von STUN erhaltene srflx-Kandidaten zu verwenden. Wenn die direkte Verbindung fehlschlägt, wechselt ICE automatisch zum vom TURN-Server erhaltenen Relay-Kandidaten. Der Parameter iceTransportPolicy: "all" aktiviert Relay-Kandidaten – der alternative Wert "relay" deaktiviert alle Kandidaten außer TURN, was für Tests nützlich ist.

TURN-Server-Authentifizierung

Um unbefugte Nutzung zu verhindern, benötigt der TURN-Server eine Authentifizierung. Der Standardansatz sind zeitlich begrenzte Anmeldeinformationen, die auf dem Anwendungsserver mit HMAC-SHA1 generiert werden. Der Anwendungsserver verschlüsselt den Benutzernamen mit dem geheimen Schlüssel des TURN-Servers und gibt den Benutzernamen und die Anmeldeinformationen an den Client zurück. Der Client übergibt sie an die RTCPeerConnection-Konfiguration, und der Browser verwendet sie bei der Erstellung einer Allokation auf dem TURN-Server. Wenn die Anmeldeinformationen ablaufen, erhält der Client neue vom Anwendungsserver.

TURN vs. STUN: Vergleich

TURN und STUN lösen verwandte NAT-Traversal-Aufgaben, unterscheiden sich jedoch grundlegend in Mechanismus und Kosten. TURN leitet Datenverkehr weiter und fungiert als Vermittler, während STUN nur bei der Bestimmung der externen Adresse für eine direkte P2P-Verbindung hilft. Die Wahl zwischen ihnen hängt vom NAT-Typ der Peers und den Leistungsanforderungen ab.

In der Praxis wird der TURN-Server nur für Verbindungen verwendet, bei denen P2P nicht möglich ist. Laut Google (WebRTC-Statistiken, 2023) benötigen etwa 15–20 % aller WebRTC-Verbindungen eine TURN-Weiterleitung. Die restlichen 80–85 % stellen die Konnektivität über STUN oder lokale Host-Kandidaten her. Bei der Entwicklung einer Anwendung sollten Sie ein Budget für TURN-Datenverkehr in Höhe von 15–20 % des gesamten Medienvolumens einplanen, wenn Ihre Zielgruppe Benutzer aus Unternehmensnetzwerken und Regionen mit strengen NAT-Einschränkungen umfasst.

Kosten und Leistung des TURN-Servers

Der TURN-Server verbraucht erhebliche Ressourcen, da der gesamte Medienverkehr durch ihn läuft. Jeder aktive Anruf mit TURN-Weiterleitung nutzt die Serverbandbreite, die dem gesamten Mediendurchsatz (eingehender + ausgehender Strom) entspricht. Für einen HD-Videoanruf (720p) kann dies 1,5–2,5 Mbps pro Verbindung in jede Richtung betragen, also insgesamt 3–5 Mbps Gesamtverkehr durch den TURN-Server.

Es gibt mehrere Bereitstellungsoptionen für die TURN-Infrastruktur. Kostenlose öffentliche TURN-Server werden für die Produktion aufgrund fehlender Qualitäts- und Sicherheitsgarantien nicht empfohlen. Kommerzielle Anbieter (Twilio Network Traversal Service, Xirsys, Metered) bieten TURN als Dienst mit Preis pro Gigabyte an – die typischen Kosten betragen 0,005–0,02 $ pro Gigabyte. Selbsthosting mit coturn (Open-Source-TURN-Server) erfordert einen Server mit ausreichender Bandbreitenkapazität und Überwachungseinrichtung.

• coturn – der beliebteste Open-Source-TURN-Server, der in den meisten Produktionssystemen verwendet wird und UDP-, TCP-, TLS- und DTLS-Transport unterstützt.
• Twilio – ein kommerzieller Dienst, der TURN + STUN mit verkehrsabhängiger Preisgestaltung und Authentifizierung über zeitlich begrenzte Token bereitstellt.
• Xirsys – ein spezialisierter TURN-Anbieter mit einem globalen Servernetzwerk und detaillierten Nutzungsanalysen.
• Metered.ca – ein TURN-Dienst mit einem kostenlosen Limit von bis zu 50 GB pro Monat und Pay-as-you-go darüber hinaus.
• Selbstgehostetes coturn – volle Kontrolle über die Konfiguration, erfordert jedoch Serveradministration und Überwachungseinrichtung.

Bei der Wahl einer TURN-Server-Lösung sollten Sie die geografische Verteilung der Benutzer, die Verkehrskosten und die Sicherheitsanforderungen berücksichtigen. Für Anwendungen mit Tausenden gleichzeitiger Anrufe kann selbstgehostetes coturn auf Servern mit einem breiten Kanal (1+ Gbit/s) kostengünstiger sein als kommerzielle Anbieter. Für kleine Projekte mit Dutzenden von Benutzern sind kommerzielle TURN-Dienste aufgrund des fehlenden Verwaltungs- und Überwachungsaufwands vorzuziehen.