Server TURN: cos’è, come funziona e dove viene utilizzato

Cos’è un server TURN

Server TURN (Traversal Using Relays around NAT) è un servizio di rete definito in RFC 5766 e aggiornato in RFC 8656 che ritrasmette traffico UDP e TCP tra due client quando una connessione P2P diretta è impossibile a causa di restrizioni NAT o firewall. Nell’architettura WebRTC, il server TURN funge da meccanismo di fallback finale, garantendo la connettività in qualsiasi condizione di rete.

A differenza di STUN, che comunica semplicemente a un client il suo indirizzo esterno, il server TURN partecipa attivamente alla trasmissione dei dati. Ogni peer stabilisce una connessione al server TURN e gli invia i propri dati multimediali. Il server TURN, a sua volta, inoltra questi dati all’altro peer. Di conseguenza, non esiste una connessione diretta tra i peer — tutto il traffico passa attraverso il server relay, garantendo la consegna anche sotto le restrizioni NAT più severe.

Protocollo TURN

TURN è un’estensione del protocollo STUN. I messaggi TURN utilizzano lo stesso header di 20 byte e lo stesso meccanismo di attributi. La differenza chiave è che TURN definisce nuovi tipi di messaggio (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) e attributi necessari per gestire le allocazioni relay. Il client crea un’allocazione sul server TURN tramite un messaggio Allocate, riceve un indirizzo di trasporto relayed (relayed transport address) e lo utilizza per inviare e ricevere dati attraverso il server.

Come funziona un server TURN

Il server TURN opera attraverso la seguente sequenza di passaggi. Il client invia una richiesta Allocate con autenticazione (username, credential). Il server verifica le credenziali e crea un’allocazione — un legame temporaneo di un indirizzo relayed (IP:porta sul server TURN) al client. Il server restituisce una risposta Allocate con un indirizzo di trasporto relayed — l’indirizzo che altri peer utilizzeranno per inviare dati a questo client attraverso il server TURN.

Dopo la creazione dell’allocazione, il client può inviare dati attraverso il server TURN utilizzando messaggi Send Indication o attraverso canali (ChannelBind). Quando riceve dati dal client, il server TURN verifica i permessi (autorizzazione a inviare dati a peer specifici) e ritrasmette i dati al peer di destinazione. Per ricevere dati in entrata, il client deve prima creare un permesso per il peer da cui si aspetta dati; altrimenti, il server TURN scarterà il pacchetto in arrivo. Un permesso viene creato tramite un messaggio CreatePermission specificando l’indirizzo IP del peer.

Allocazione e durata di vita

Un’allocazione sul server TURN ha una durata di vita limitata — 10 minuti per impostazione predefinita. Il client deve inviare periodicamente una richiesta Refresh per estendere l’allocazione. La durata di vita è specificata in secondi nell’attributo LIFETIME. Se non viene ricevuto alcun Refresh, il server rimuove l’allocazione e libera l’indirizzo relayed. Intervallo di aggiornamento raccomandato — 5 minuti (300 secondi) per proteggersi dalla perdita di pacchetti Refresh.

Configurare un server TURN in WebRTC

In WebRTC, il server TURN viene configurato tramite la configurazione RTCPeerConnection nell’array iceServers. I server TURN possono utilizzare trasporto UDP, TCP o TLS. L’autenticazione utilizza tipicamente credenziali con limiti di tempo (credenziali TURN) generate sul server applicativo con un periodo di validità ristretto.

Consideriamo un esempio di configurazione del server TURN in JavaScript con autenticazione tramite 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);

In questo esempio, il server TURN viene specificato insieme a un server STUN in un’unica configurazione ICE. Il processo ICE tenta prima di utilizzare candidati host e candidati srflx ottenuti da STUN. Se la connessione diretta fallisce, ICE passa automaticamente al candidato relay ottenuto dal server TURN. Il parametro iceTransportPolicy: "all" abilita i candidati relay — il valore alternativo "relay" disabilita tutti i candidati tranne TURN, utile per i test.

Autenticazione del server TURN

Per prevenire usi non autorizzati, il server TURN richiede autenticazione. L’approccio standard sono le credenziali con limiti di tempo generate sul server applicativo utilizzando HMAC-SHA1. Il server applicativo crittografa il nome utente con la chiave segreta del server TURN e restituisce username e credential al client. Il client li passa nella configurazione RTCPeerConnection e il browser li utilizza quando crea un’allocazione sul server TURN. Quando le credenziali scadono, il client ne ottiene di nuove dal server applicativo.

TURN vs STUN: Confronto

TURN e STUN risolvono compiti correlati di NAT traversal, ma differiscono fondamentalmente per meccanismo e costo. TURN ritrasmette il traffico, fungendo da intermediario, mentre STUN aiuta solo a determinare l’indirizzo esterno per una connessione P2P diretta. La scelta tra di essi dipende dal tipo NAT dei peer e dai requisiti di prestazione.

In pratica, il server TURN viene utilizzato solo per le connessioni in cui P2P è impossibile. Secondo Google (statistiche WebRTC, 2023), circa il 15–20% di tutte le connessioni WebRTC richiedono la ritrasmissione TURN. Il restante 80–85% stabilisce la connettività tramite STUN o candidati host locali. Quando si progetta un’applicazione, è necessario pianificare un budget per il traffico TURN pari al 15–20% del volume totale dei media se il pubblico include utenti di reti aziendali e regioni con severe restrizioni NAT.

Costo e prestazioni del server TURN

Il server TURN consuma risorse significative poiché tutto il traffico multimediale passa attraverso di esso. Ogni chiamata attiva con ritrasmissione TURN utilizza la larghezza di banda del server pari al throughput totale del traffico multimediale (flusso in entrata + in uscita). Per una chiamata video HD (720p), possono essere 1,5–2,5 Mbps per connessione in ciascuna direzione, per un totale di 3–5 Mbps di traffico complessivo attraverso il server TURN.

Esistono diverse opzioni di distribuzione per l’infrastruttura TURN. I server TURN pubblici gratuiti non sono raccomandati per la produzione a causa della mancanza di garanzie di qualità e sicurezza. I fornitori commerciali (Twilio Network Traversal Service, Xirsys, Metered) offrono TURN come servizio con prezzo per gigabyte — il costo tipico è di $0,005–0,02 per gigabyte. L’auto-hosting con coturn (server TURN open-source) richiede un server con capacità di larghezza di banda sufficiente e configurazione di monitoraggio.

• coturn — il server TURN open-source più popolare, utilizzato nella maggior parte dei sistemi di produzione, supporta trasporto UDP, TCP, TLS e DTLS.
• Twilio — un servizio commerciale che fornisce TURN + STUN con prezzi basati sul traffico e autenticazione tramite token con scadenza temporale.
• Xirsys — un fornitore TURN specializzato con una rete globale di server e analisi dettagliate sull’utilizzo.
• Metered.ca — un servizio TURN con un limite gratuito fino a 50 GB al mese e pagamento a consumo oltre tale limite.
• coturn auto-hosted — controllo completo sulla configurazione, ma richiede amministrazione del server e configurazione del monitoraggio.

Quando si sceglie una soluzione server TURN, considerare la geografia degli utenti, il costo del traffico e i requisiti di sicurezza. Per applicazioni con migliaia di chiamate simultanee, il coturn auto-hosted su server con canale ampio (1+ Gbps) può essere più economico dei fornitori commerciali. Per progetti piccoli con decine di utenti, i servizi TURN commerciali sono preferibili a causa dell’assenza di spese di amministrazione e monitoraggio.