Servidor TURN: o que é, como funciona e onde é usado

O que é um Servidor TURN

Servidor TURN (Traversal Using Relays around NAT) é um serviço de rede definido na RFC 5766 e atualizado na RFC 8656 que retransmite tráfego UDP e TCP entre dois clientes quando a conexão P2P direta é impossível devido a restrições de NAT ou firewalls. Na arquitetura WebRTC, o servidor TURN atua como mecanismo de fallback final, garantindo conectividade em qualquer condição de rede.

Ao contrário do STUN, que simplesmente informa a um cliente seu endereço externo, o servidor TURN participa ativamente na transmissão de dados. Cada par estabelece uma conexão com o servidor TURN e envia seus dados de mídia para ele. O servidor TURN, por sua vez, encaminha esses dados para o outro par. Como resultado, não existe conexão direta entre pares — todo o tráfego passa pelo servidor de retransmissão, garantindo a entrega mesmo sob as restrições NAT mais rigorosas.

Protocolo TURN

TURN é uma extensão do protocolo STUN. As mensagens TURN usam o mesmo cabeçalho de 20 bytes e mecanismo de atributos. A diferença chave é que o TURN define novos tipos de mensagem (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) e atributos necessários para gerenciar alocações de retransmissão. O cliente cria uma alocação no servidor TURN através de uma mensagem Allocate, recebe um endereço de transporte retransmitido (relayed transport address) e o usa para enviar e receber dados através do servidor.

Como funciona um Servidor TURN

O servidor TURN opera através da seguinte sequência de etapas. O cliente envia uma solicitação Allocate com autenticação (username, credential). O servidor verifica as credenciais e cria uma alocação — uma ligação temporária de um endereço retransmitido (IP:porta no servidor TURN) ao cliente. O servidor retorna uma resposta Allocate com um endereço de transporte retransmitido — o endereço que outros pares usarão para enviar dados a este cliente através do servidor TURN.

Após criar a alocação, o cliente pode enviar dados através do servidor TURN usando mensagens Send Indication ou através de canais (ChannelBind). Ao receber dados do cliente, o servidor TURN verifica as permissões (autorização para enviar dados a pares específicos) e retransmite os dados ao par alvo. Para receber dados de entrada, o cliente deve primeiro criar uma permissão para o par do qual espera dados; caso contrário, o servidor TURN descartará o pacote de entrada. Uma permissão é criada através de uma mensagem CreatePermission especificando o endereço IP do par.

Alocação e tempo de vida

Uma alocação no servidor TURN tem um tempo de vida limitado — 10 minutos por padrão. O cliente deve enviar periodicamente uma solicitação Refresh para estender a alocação. O tempo de vida é especificado em segundos no atributo LIFETIME. Se nenhum Refresh for recebido, o servidor remove a alocação e libera o endereço retransmitido. Intervalo de atualização recomendado — 5 minutos (300 segundos) para proteção contra perda de pacotes Refresh.

Configurar um Servidor TURN no WebRTC

No WebRTC, o servidor TURN é configurado através da configuração RTCPeerConnection no array iceServers. Servidores TURN podem usar transporte UDP, TCP ou TLS. A autenticação normalmente usa credenciais com limite de tempo (credenciais TURN) geradas no servidor da aplicação com período de validade restrito.

Considere um exemplo de configuração do servidor TURN em JavaScript com autenticação via 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);

Neste exemplo, o servidor TURN é especificado junto com um servidor STUN em uma única configuração ICE. O processo ICE primeiro tenta usar candidatos host e candidatos srflx obtidos do STUN. Se a conexão direta falhar, o ICE muda automaticamente para o candidato relay obtido do servidor TURN. O parâmetro iceTransportPolicy: "all" habilita candidatos relay — o valor alternativo "relay" desabilita todos os candidatos exceto TURN, o que é útil para testes.

Autenticação do Servidor TURN

Para evitar uso não autorizado, o servidor TURN requer autenticação. A abordagem padrão são credenciais com limite de tempo geradas no servidor da aplicação usando HMAC-SHA1. O servidor da aplicação criptografa o nome de usuário com a chave secreta do servidor TURN e retorna o nome de usuário e a credencial ao cliente. O cliente os passa na configuração RTCPeerConnection, e o navegador os usa ao criar uma alocação no servidor TURN. Quando as credenciais expiram, o cliente obtém novas do servidor da aplicação.

TURN vs STUN: Comparação

TURN e STUN resolvem tarefas relacionadas de travessia NAT, mas diferem fundamentalmente em mecanismo e custo. TURN retransmite tráfego, atuando como intermediário, enquanto STUN apenas ajuda a determinar o endereço externo para uma conexão P2P direta. A escolha entre eles depende do tipo NAT dos pares e requisitos de desempenho.

Na prática, o servidor TURN é usado apenas para conexões onde P2P é impossível. De acordo com o Google (estatísticas WebRTC, 2023), aproximadamente 15–20% de todas as conexões WebRTC requerem retransmissão TURN. Os restantes 80–85% estabelecem conectividade através de STUN ou candidatos host locais. Ao projetar uma aplicação, você deve orçar o tráfego TURN em 15–20% do volume total de mídia se seu público incluir usuários de redes corporativas e regiões com restrições NAT rigorosas.

Custo e desempenho do Servidor TURN

O servidor TURN consome recursos significativos já que todo o tráfego de mídia passa por ele. Cada chamada ativa com retransmissão TURN usa a largura de banda do servidor igual à vazão total de tráfego de mídia (fluxo de entrada + saída). Para uma chamada de vídeo HD (720p), isso pode ser 1,5–2,5 Mbps por conexão em cada direção, totalizando 3–5 Mbps de tráfego geral através do servidor TURN.

Existem várias opções de implantação para infraestrutura TURN. Servidores TURN públicos gratuitos não são recomendados para produção devido à falta de garantias de qualidade e segurança. Provedores comerciais (Twilio Network Traversal Service, Xirsys, Metered) oferecem TURN como serviço com preço por gigabyte — o custo típico é $0,005–0,02 por gigabyte. Auto-hospedagem com coturn (servidor TURN de código aberto) requer um servidor com capacidade de largura de banda suficiente e configuração de monitoramento.

• coturn — o servidor TURN de código aberto mais popular, usado na maioria dos sistemas de produção, suporta transporte UDP, TCP, TLS e DTLS.
• Twilio — um serviço comercial que fornece TURN + STUN com preço baseado em tráfego e autenticação via tokens com limite de tempo.
• Xirsys — um provedor TURN especializado com rede global de servidores e análise detalhada de uso.
• Metered.ca — um serviço TURN com limite gratuito de até 50 GB por mês e pagamento conforme o uso além disso.
• coturn auto-hospedado — controle total sobre a configuração, mas requer administração do servidor e configuração de monitoramento.

Ao escolher uma solução de servidor TURN, considere a geografia do usuário, custo de tráfego e requisitos de segurança. Para aplicações com milhares de chamadas simultâneas, o coturn auto-hospedado em servidores com canal amplo (1+ Gbps) pode ser mais econômico que provedores comerciais. Para projetos pequenos com dezenas de usuários, serviços TURN comerciais são preferíveis devido à falta de custos administrativos e de monitoramento.