Servidor TURN: qué es, cómo funciona y dónde se utiliza

Qué es un Servidor TURN

Servidor TURN (Traversal Using Relays around NAT) es un servicio de red definido en RFC 5766 y actualizado en RFC 8656 que retransmite tráfico UDP y TCP entre dos clientes cuando la conexión P2P directa es imposible debido a restricciones de NAT o cortafuegos. En la arquitectura WebRTC, el servidor TURN actúa como mecanismo de reserva final, garantizando la conectividad en cualquier condición de red.

A diferencia de STUN, que simplemente informa a un cliente de su dirección externa, el servidor TURN participa activamente en la transmisión de datos. Cada par establece una conexión con el servidor TURN y le envía sus datos multimedia. El servidor TURN, a su vez, reenvía estos datos al otro par. Como resultado, no existe una conexión directa entre pares — todo el tráfico pasa a través del servidor de retransmisión, lo que garantiza la entrega incluso bajo las restricciones NAT más estrictas.

Protocolo TURN

TURN es una extensión del protocolo STUN. Los mensajes TURN utilizan el mismo encabezado de 20 bytes y el mecanismo de atributos. La diferencia clave es que TURN define nuevos tipos de mensajes (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) y atributos necesarios para gestionar las asignaciones de retransmisión. El cliente crea una asignación en el servidor TURN mediante un mensaje Allocate, recibe una dirección de transporte retransmitida (relayed transport address) y la utiliza para enviar y recibir datos a través del servidor.

Cómo funciona un Servidor TURN

El servidor TURN opera siguiendo la siguiente secuencia de pasos. El cliente envía una solicitud Allocate con autenticación (username, credential). El servidor verifica las credenciales y crea una asignación — un enlace temporal de una dirección retransmitida (IP:puerto en el servidor TURN) al cliente. El servidor devuelve una respuesta Allocate con una dirección de transporte retransmitida — la dirección que otros pares utilizarán para enviar datos a este cliente a través del servidor TURN.

Después de crear la asignación, el cliente puede enviar datos a través del servidor TURN usando mensajes Send Indication o mediante canales (ChannelBind). Al recibir datos del cliente, el servidor TURN verifica los permisos (autorización para enviar datos a pares específicos) y retransmite los datos al par objetivo. Para recibir datos entrantes, el cliente debe crear primero un permiso para el par del que espera datos; de lo contrario, el servidor TURN descartará el paquete entrante. Un permiso se crea mediante un mensaje CreatePermission especificando la dirección IP del par.

Asignación y tiempo de vida

Una asignación en el servidor TURN tiene un tiempo de vida limitado — 10 minutos por defecto. El cliente debe enviar periódicamente una solicitud Refresh para extender la asignación. El tiempo de vida se especifica en segundos en el atributo LIFETIME. Si no se recibe ningún Refresh, el servidor elimina la asignación y libera la dirección retransmitida. Intervalo de actualización recomendado — 5 minutos (300 segundos) para protegerse contra la pérdida de paquetes Refresh.

Configurar un Servidor TURN en WebRTC

En WebRTC, el servidor TURN se configura mediante la configuración de RTCPeerConnection en el array iceServers. Los servidores TURN pueden usar transporte UDP, TCP o TLS. La autenticación normalmente utiliza credenciales con límite de tiempo (credenciales TURN) generadas en el servidor de la aplicación con un período de validez restringido.

Considere un ejemplo de configuración del servidor TURN en JavaScript con autenticación mediante 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);

En este ejemplo, el servidor TURN se especifica junto con un servidor STUN en una única configuración ICE. El proceso ICE primero intenta usar candidatos host y candidatos srflx obtenidos de STUN. Si la conexión directa falla, ICE cambia automáticamente al candidato relay obtenido del servidor TURN. El parámetro iceTransportPolicy: "all" habilita los candidatos relay — el valor alternativo "relay" deshabilita todos los candidatos excepto TURN, lo que es útil para pruebas.

Autenticación del Servidor TURN

Para evitar el uso no autorizado, el servidor TURN requiere autenticación. El enfoque estándar son las credenciales con límite de tiempo generadas en el servidor de la aplicación mediante HMAC-SHA1. El servidor de la aplicación cifra el nombre de usuario con la clave secreta del servidor TURN y devuelve el nombre de usuario y la credencial al cliente. El cliente los pasa a la configuración de RTCPeerConnection, y el navegador los utiliza al crear una asignación en el servidor TURN. Cuando las credenciales caducan, el cliente obtiene otras nuevas del servidor de la aplicación.

TURN vs STUN: Comparación

TURN y STUN resuelven tareas relacionadas de travessía NAT, pero difieren fundamentalmente en mecanismo y costo. TURN retransmite tráfico, actuando como intermediario, mientras que STUN solo ayuda a determinar la dirección externa para una conexión P2P directa. La elección entre ellos depende del tipo de NAT de los pares y los requisitos de rendimiento.

En la práctica, el servidor TURN se utiliza solo para conexiones donde P2P es imposible. Según Google (estadísticas de WebRTC, 2023), aproximadamente el 15–20% de todas las conexiones WebRTC requieren retransmisión TURN. El 80–85% restante establece conexión a través de STUN o candidatos host locales. Al diseñar una aplicación, debe presupuestar el tráfico TURN al 15–20% del volumen total de medios si su audiencia incluye usuarios de redes corporativas y regiones con estrictas restricciones NAT.

Costo y rendimiento del Servidor TURN

El servidor TURN consume recursos significativos ya que todo el tráfico multimedia pasa a través de él. Cada llamada activa con retransmisión TURN utiliza el ancho de banda del servidor igual al rendimiento total del tráfico multimedia (flujo entrante + saliente). Para una videollamada en HD (720p), esto puede ser de 1,5–2,5 Mbps por conexión en cada dirección, totalizando 3–5 Mbps de tráfico general a través del servidor TURN.

Existen varias opciones de implementación para la infraestructura TURN. Los servidores TURN públicos gratuitos no se recomiendan para producción debido a la falta de garantías de calidad y seguridad. Los proveedores comerciales (Twilio Network Traversal Service, Xirsys, Metered) ofrecen TURN como servicio con precio por gigabyte — el costo típico es de $0,005–0,02 por gigabyte. El autoalojamiento con coturn (servidor TURN de código abierto) requiere un servidor con suficiente capacidad de ancho de banda y configuración de monitoreo.

• coturn — el servidor TURN de código abierto más popular, utilizado en la mayoría de los sistemas de producción, admite transporte UDP, TCP, TLS y DTLS.
• Twilio — un servicio comercial que proporciona TURN + STUN con precio basado en tráfico y autenticación mediante tokens con límite de tiempo.
• Xirsys — un proveedor TURN especializado con una red global de servidores y análisis detallados de uso.
• Metered.ca — un servicio TURN con un límite gratuito de hasta 50 GB por mes y pago por uso más allá de ese límite.
• coturn autoalojado — control total sobre la configuración, pero requiere administración del servidor y configuración de monitoreo.

Al elegir una solución de servidor TURN, considere la geografía del usuario, el costo del tráfico y los requisitos de seguridad. Para aplicaciones con miles de llamadas simultáneas, el coturn autoalojado en servidores con un canal amplio (1+ Gbps) puede ser más rentable que los proveedores comerciales. Para proyectos pequeños con docenas de usuarios, los servicios TURN comerciales son preferibles debido a la falta de gastos generales de administración y monitoreo.