TURN Server: wat het is, hoe het werkt en waar het wordt gebruikt

Wat is TURN Server

TURN Server (Traversal Using Relays around NAT) — is een netwerkservice gedefinieerd in RFC 5766 en bijgewerkt in RFC 8656, die UDP- en TCP-verkeer tussen twee clients doorstuurt wanneer een directe P2P-verbinding onmogelijk is vanwege NAT-beperkingen of firewalls. In de WebRTC-architectuur fungeert de TURN-server als een laatste reservemechanisme dat verbinding garandeert in elke netwerkomstandigheid.

In tegenstelling tot STUN, dat de client alleen zijn externe adres vertelt, neemt de TURN-server actief deel aan de gegevensoverdracht. Elke peer maakt een verbinding met de TURN-server en stuurt zijn mediagegevens ernaartoe. De TURN-server stuurt deze gegevens op zijn beurt door naar de andere peer. Het resultaat is dat er geen directe verbinding is tussen peers — al het verkeer gaat via de relayserver, wat levering garandeert, zelfs onder de strengste NAT-beperkingen.

TURN-protocol

TURN is een uitbreiding van het STUN-protocol. TURN-berichten gebruiken dezelfde 20-byte header en hetzelfde attribuutmechanisme. Het belangrijkste verschil is dat TURN nieuwe berichttypen definieert (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) en attributen die nodig zijn voor het beheer van relay-toewijzingen. De client maakt een toewijzing op de TURN-server via het Allocate-bericht, ontvangt een relay-transportadres (relayed transport address) en gebruikt dit om gegevens via de server te verzenden en ontvangen.

Hoe werkt de TURN-server

De TURN-server werkt volgens de volgende stappen. De client verzendt een Allocate-verzoek met authenticatie (username, credential). De server controleert de inloggegevens en maakt een toewijzing — een tijdelijke koppeling van het relay-adres (IP:poort op de TURN-server) aan de client. De server retourneert een Allocate-antwoord met het relayed transport address — het adres dat andere peers zullen gebruiken om gegevens naar deze client te sturen via de TURN-server.

Na het maken van de toewijzing kan de client gegevens verzenden via de TURN-server met behulp van Send Indication-berichten of via kanalen (ChannelBind). Bij ontvangst van gegevens van de client controleert de TURN-server de machtigingen (permissions) en stuurt de gegevens door naar de doelpeer. Om inkomende gegevens te ontvangen, moet de client vooraf een machtiging aanmaken voor de peer van wie hij gegevens verwacht, anders zal de TURN-server het binnenkomende pakket weigeren. De machtiging wordt aangemaakt via het CreatePermission-bericht met opgave van het IP-adres van de peer.

Toewijzing en levensduur

Een toewijzing op de TURN-server heeft een beperkte levensduur — standaard 10 minuten. De client moet periodiek een Refresh-verzoek verzenden om de toewijzing te verlengen. De levensduur wordt in seconden opgegeven in het LIFETIME-attribuut. Bij afwezigheid van Refresh verwijdert de server de toewijzing en geeft het relay-adres vrij. Aanbevolen vernieuwingsinterval is 5 minuten (300 seconden) ter bescherming tegen verlies van Refresh-pakketten.

Configuratie van TURN-server in WebRTC

In WebRTC wordt de TURN-server geconfigureerd via de RTCPeerConnection-configuratie in de iceServers-array. TURN-servers kunnen zowel UDP als TCP of TLS-transport gebruiken. Voor authenticatie worden meestal tijdelijke inloggegevens (TURN credentials) gebruikt, gegenereerd op de applicatieserver en beperkt in tijd.

Laten we een voorbeeld bekijken van het configureren van een TURN-server in JavaScript met authenticatie via HMAC-SHA1-token.

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 dit voorbeeld wordt de TURN-server samen met de STUN-server gespecificeerd in een uniforme ICE-configuratie. Het ICE-proces zal eerst proberen host-kandidaten en van STUN verkregen srflx-kandidaten te gebruiken. Als de directe verbinding mislukt, schakelt ICE automatisch over naar de relay-kandidaat die van de TURN-server is verkregen. De parameter iceTransportPolicy: "all" staat relay-kandidaten toe — de alternatieve waarde "relay" verbiedt alle kandidaten behalve TURN, wat handig is voor testen.

Authenticatie van de TURN-server

Om ongeautoriseerd gebruik te voorkomen, vereist de TURN-server authenticatie. De standaardbenadering is het gebruik van tijdelijke inloggegevens (time-limited credentials), gegenereerd op de applicatieserver met HMAC-SHA1. De applicatieserver versleutelt de gebruikersnaam met de geheime sleutel van de TURN-server en retourneert de gebruikersnaam en het wachtwoord aan de client. De client geeft deze door in de RTCPeerConnection-configuratie en de browser gebruikt ze bij het aanmaken van een toewijzing op de TURN-server. Na het verlopen van de inloggegevens ontvangt de client nieuwe van de applicatieserver.

TURN vs STUN: vergelijking

TURN en STUN lossen vergelijkbare NAT-traversal-taken op, maar verschillen fundamenteel in mechanisme en kosten. TURN stuurt verkeer door en fungeert als tussenpersoon, terwijl STUN alleen helpt bij het bepalen van het externe adres voor een directe P2P-verbinding. De keuze ertussen wordt bepaald door het NAT-type van de peers en de prestatie-eisen.

In de praktijk wordt de TURN-server alleen gebruikt voor verbindingen waarbij P2P onmogelijk is. Volgens Google-gegevens (WebRTC-statistieken, 2023) vereist ongeveer 15–20% van alle WebRTC-verbindingen TURN-doorsturing. De overige 80–85% worden tot stand gebracht via STUN of lokale host-kandidaten. Bij het ontwerpen van de applicatie moet een budget worden gereserveerd voor TURN-verkeer ter grootte van 15–20% van het totale mediagegevensvolume, als het publiek gebruikers uit bedrijfsnetwerken en regio's met strenge NAT-beperkingen omvat.

Kosten en prestaties van TURN-server

De TURN-server verbruikt aanzienlijke resources omdat al het mediaverkeer erdoorheen gaat. Elke actieve oproep met TURN-doorsturing gebruikt serverbandbreedte gelijk aan de totale mediadoorvoer (inkomende + uitgaande stroom). Voor een video-oproep in HD-kwaliteit (720p) kan dit 1,5–2,5 Mb/s per verbinding in elke richting zijn, oftewel 3–5 Mb/s totaal verkeer via de TURN-server.

Er zijn verschillende opties voor het implementeren van TURN-infrastructuur. Gratis openbare TURN-servers worden niet aanbevolen voor productie vanwege het ontbreken van kwaliteits- en veiligheidsgaranties. Commerciële aanbieders (Twilio Network Traversal Service, Xirsys, Metered) bieden TURN als dienst met betaling per gigabyte verkeer — de typische kostprijs is $0,005–0,02 per gigabyte. Een eigen implementatie op basis van coturn (open-source TURN-server) vereist een server met voldoende bandbreedte en het configureren van monitoring.

• coturn — de populairste open-source TURN-server, gebruikt in de meeste productiesystemen, ondersteunt UDP-, TCP-, TLS- en DTLS-transport.
• Twilio — commerciële dienst die TURN + STUN biedt met betaling per verkeer en authenticatie via tijdelijke tokens.
• Xirsys — gespecialiseerde TURN-provider met een wereldwijd servernetwerk en gedetailleerde gebruiksanalyses.
• Metered.ca — TURN-dienst met een gratis limiet tot 50 GB per maand en betaling voor overschrijding.
• Self-hosted coturn — volledige controle over de configuratie, maar vereist serverbeheer en het instellen van beschikbaarheidsmonitoring.

Bij het kiezen van een oplossing voor de TURN-server moet rekening worden gehouden met de geografie van gebruikers, de verkeerskosten en de beveiligingseisen. Voor applicaties met duizenden gelijktijdige oproepen kan self-hosted coturn op servers met een brede bandbreedte (1+ Gb/s) voordeliger zijn dan commerciële aanbieders. Voor kleine projecten met tientallen gebruikers hebben commerciële TURN-diensten de voorkeur vanwege het ontbreken van beheers- en monitoringskosten.