TURN Server: ce este, cum funcționează și unde se utilizează

Ce este TURN Server

TURN Server (Traversal Using Relays around NAT) — este un serviciu de rețeană definit în RFC 5766 și actualizat în RFC 8656, care retransmite traficul UDP și TCP între doi clienți atunci când conexiunea directă P2P este imposibilă din cauza restricțiilor NAT sau a firewall-urilor. În arhitectura WebRTC, serverul TURN acționează ca un mecanism final de rezervă, garantând conexiunea în orice condiții de rețeană.

Spre deosebire de STUN, care doar informează clientul despre adresa sa externă, serverul TURN participă activ la transmiterea datelor. Fiecare pereche stabilește o conexiune cu serverul TURN și îi trimite datele media. Serverul TURN, la rândul său, redirecționează aceste date către cealaltă pereche. Ca rezultat, nu există o conexiune directă între perechi — tot traficul trece prin serverul releu, ceea ce garantează livrarea chiar și în cele mai stricte condiții NAT.

Protocolul TURN

TURN este o extensie a protocolului STUN. Mesajele TURN utilizează același antet de 20 de octeți și același mecanism de atribute. Diferența cheie este că TURN definește noi tipuri de mesaje (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) și atribute necesare pentru gestionarea alocărilor releu. Clientul creează o alocare pe serverul TURN prin mesajul Allocate, primește o adresă de transport releu (relayed transport address) și o utilizează pentru a trimite și primi date prin server.

Cum funcționează serverul TURN

Serverul TURN funcționează conform următoarei secvențe de pași. Clientul trimite o cerere Allocate cu autentificare (username, credential). Serverul verifică datele de autentificare și creează o alocare — o legătură temporară a adresei releu (IP:port pe serverul TURN) cu clientul. Serverul returnează un răspuns Allocate cu adresa de transport releu (relayed transport address) — adresa pe care celelalte perechi o vor utiliza pentru a trimite date acestui client prin serverul TURN.

După crearea alocării, clientul poate trimite date prin serverul TURN folosind mesaje Send Indication sau prin canale (ChannelBind). La primirea datelor de la client, serverul TURN verifică permisiunile (permissions) și retransmite datele către perechea țintă. Pentru a primi date de intrare, clientul trebuie să creeze în prealabil o permisiune pentru perechea de la care așteaptă date, altfel serverul TURN va respinge pachetul de intrare. Permisiunea se creează prin mesajul CreatePermission cu specificarea adresei IP a perechii.

Alocarea și durata de viață

Alocarea pe serverul TURN are o durată de viață limitată — implicit 10 minute. Clientul trebuie să trimită periodic cereri Refresh pentru a prelungi alocarea. Durata de viață este specificată în secunde în atributul LIFETIME. În absența Refresh, serverul șterge alocarea și eliberează adresa releu. Intervalul recomandat de reîmprospătare este de 5 minute (300 de secunde) pentru a preveni pierderea pachetelor Refresh.

Configurarea serverului TURN în WebRTC

În WebRTC, serverul TURN se configurează prin setările RTCPeerConnection în tabloul iceServers. Serverele TURN pot utiliza atât transport UDP, cât și TCP sau TLS. Pentru autentificare se utilizează de obicei date de autentificare temporare (TURN credentials), generate pe serverul aplicației și limitate în timp.

Să analizăm un exemplu de configurare a serverului TURN în JavaScript cu autentificare prin token HMAC-SHA1.

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);

În acest exemplu, serverul TURN este specificat împreună cu serverul STUN într-o configurație ICE unitară. Procesul ICE va încerca mai întâi să utilizeze candidații host și candidații srflx obținuți de la STUN. Dacă conexiunea directă eșuează, ICE va comuta automat la candidatul releu obținut de la serverul TURN. Parametrul iceTransportPolicy: "all" permite candidații releu — valoarea alternativă "relay" interzice toți candidații, cu excepția TURN, ceea ce este util pentru testare.

Autentificarea serverului TURN

Pentru a preveni utilizarea neautorizată, serverul TURN necesită autentificare. Abordarea standard — date de autentificare temporare (time-limited credentials), generate pe serverul aplicației folosind HMAC-SHA1. Serverul aplicației criptează numele de utilizator cu cheia secretă a serverului TURN și returnează clientului numele de utilizator și parola. Clientul le transmite în configurația RTCPeerConnection, iar browserul le utilizează la crearea alocării pe serverul TURN. După expirarea datelor de autentificare, clientul primește altele noi de la serverul aplicației.

TURN vs STUN: comparație

TURN și STUN rezolvă sarcini similare de traversare NAT, dar diferă fundamental prin mecanism și cost. TURN retransmite traficul, acționând ca intermediar, în timp ce STUN doar ajută la determinarea adresei externe pentru conexiunea directă P2P. Alegerea între ele este determinată de tipul NAT al perechilor și cerințele de performanță.

în practică, serverul TURN este utilizat doar pentru conexiunile în care P2P este imposibil. Conform datelor Google (statistici WebRTC, 2023), aproximativ 15–20% din toate conexiunile WebRTC necesită retransmitere TURN. Restul de 80–85% se stabilesc prin STUN sau prin candidații locali host. La proiectarea aplicației, trebuie alocat un buget pentru traficul TURN în proporție de 15–20% din volumul total al datelor media, dacă audiența include utilizatori din rețele corporative și regiuni cu restricții NAT severe.

Costul și performanța serverului TURN

Serverul TURN consumă resurse semnificative, deoarece tot traficul media trece prin el. Fiecare conexiune activă cu retransmitere TURN utilizează lățimea de bandă a serverului egală cu capacitatea totală a traficului media (flux intrare + ieșire). Pentru un apel video în calitate HD (720p), aceasta poate fi de 1,5–2,5 Mb/s per conexiune în fiecare direcție, adică 3–5 Mb/s de trafic total prin serverul TURN.

Există mai multe opțiuni de implementare a infrastructurii TURN. Serverele TURN publice gratuite nu sunt recomandate pentru producție din cauza lipsei garanțiilor de calitate și securitate. Furnizorii comerciali (Twilio Network Traversal Service, Xirsys, Metered) oferă TURN ca serviciu cu plată per gigaoctet de trafic — costul tipic este de $0,005–0,02 per gigaoctet. Implementarea proprie bazată pe coturn (server TURN open-source) necesită un server cu lățime de bandă suficientă și configurarea monitorizării.

• coturn — cel mai popular server TURN open-source, utilizat în majoritatea sistemelor de producție, suportă transport UDP, TCP, TLS și DTLS.
• Twilio — serviciu comercial care oferă TURN + STUN cu plată per trafic și autentificare prin token-uri temporare.
• Xirsys — furnizor specializat de TURN cu o rețeană globală de servere și analitică detaliată a utilizării.
• Metered.ca — serviciu TURN cu limită gratuită de până la 50 GB pe lună și plată pentru depășirea limitei.
• Self-hosted coturn — control complet asupra configurației, dar necesită administrarea serverului și configurarea monitorizării disponibilității.

La alegerea soluției pentru serverul TURN, trebuie să se țină cont de geografia utilizatorilor, costul traficului și cerințele de securitate. Pentru aplicații cu mii de apeluri simultane, self-hosted coturn pe servere cu lățime de bandă largă (1+ Gb/s) poate fi mai economic decât furnizorii comerciali. Pentru proiecte mici cu zeci de utilizatori, serviciile comerciale TURN sunt preferabile datorită lipsei costurilor de administrare și monitorizare.