Serveur TURN : ce que c’est, comment ça fonctionne et où ça s’utilise

Qu’est-ce qu’un serveur TURN

Serveur TURN (Traversal Using Relays around NAT) est un service réseau défini dans la RFC 5766 et mis à jour dans la RFC 8656 qui relaie le trafic UDP et TCP entre deux clients lorsqu’une connexion P2P directe est impossible en raison de restrictions NAT ou de pare-feux. Dans l’architecture WebRTC, le serveur TURN agit comme mécanisme de secours final, garantissant la connectivité dans toutes les conditions réseau.

Contrairement à STUN, qui indique simplement à un client son adresse externe, le serveur TURN participe activement à la transmission des données. Chaque pair établit une connexion avec le serveur TURN et lui envoie ses données multimédia. Le serveur TURN, à son tour, transmet ces données à l’autre pair. En conséquence, il n’y a pas de connexion directe entre les pairs — tout le trafic passe par le serveur relais, garantissant la livraison même sous les restrictions NAT les plus strictes.

Protocole TURN

TURN est une extension du protocole STUN. Les messages TURN utilisent le même en-tête de 20 octets et le même mécanisme d’attributs. La différence clé est que TURN définit de nouveaux types de messages (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) et des attributs nécessaires à la gestion des allocations relais. Le client crée une allocation sur le serveur TURN via un message Allocate, reçoit une adresse de transport relayée (relayed transport address) et l’utilise pour envoyer et recevoir des données via le serveur.

Comment fonctionne un serveur TURN

Le serveur TURN fonctionne selon la séquence d’étapes suivante. Le client envoie une demande Allocate avec authentification (username, credential). Le serveur vérifie les identifiants et crée une allocation — une liaison temporaire d’une adresse relayée (IP:port sur le serveur TURN) au client. Le serveur renvoie une réponse Allocate avec une adresse de transport relayée — l’adresse que les autres pairs utiliseront pour envoyer des données à ce client via le serveur TURN.

Après la création de l’allocation, le client peut envoyer des données via le serveur TURN en utilisant des messages Send Indication ou via des canaux (ChannelBind). Lors de la réception de données du client, le serveur TURN vérifie les permissions (autorisation d’envoyer des données à des pairs spécifiques) et relaie les données au pair cible. Pour recevoir des données entrantes, le client doit d’abord créer une permission pour le pair dont il attend des données ; sinon, le serveur TURN rejettera le paquet entrant. Une permission est créée via un message CreatePermission spécifiant l’adresse IP du pair.

Allocation et durée de vie

Une allocation sur le serveur TURN a une durée de vie limitée — 10 minutes par défaut. Le client doit envoyer périodiquement une demande Refresh pour prolonger l’allocation. La durée de vie est spécifiée en secondes dans l’attribut LIFETIME. Si aucun Refresh n’est reçu, le serveur supprime l’allocation et libère l’adresse relayée. Intervalle de rafraîchissement recommandé — 5 minutes (300 secondes) pour se protéger contre la perte de paquets Refresh.

Configurer un serveur TURN dans WebRTC

Dans WebRTC, le serveur TURN est configuré via la configuration RTCPeerConnection dans le tableau iceServers. Les serveurs TURN peuvent utiliser le transport UDP, TCP ou TLS. L’authentification utilise généralement des identifiants à durée limitée (identifiants TURN) générés sur le serveur d’application avec une période de validité restreinte.

Considérons un exemple de configuration de serveur TURN en JavaScript avec authentification par jeton 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);

Dans cet exemple, le serveur TURN est spécifié avec un serveur STUN dans une seule configuration ICE. Le processus ICE tente d’abord d’utiliser les candidats host et les candidats srflx obtenus de STUN. Si la connexion directe échoue, ICE bascule automatiquement vers le candidat relay obtenu du serveur TURN. Le paramètre iceTransportPolicy: "all" active les candidats relay — la valeur alternative "relay" désactive tous les candidats sauf TURN, ce qui est utile pour les tests.

Authentification du serveur TURN

Pour empêcher toute utilisation non autorisée, le serveur TURN nécessite une authentification. L’approche standard consiste à générer des identifiants à durée limitée sur le serveur d’application en utilisant HMAC-SHA1. Le serveur d’application chiffre le nom d’utilisateur avec la clé secrète du serveur TURN et renvoie le nom d’utilisateur et l’identifiant au client. Le client les transmet à la configuration RTCPeerConnection, et le navigateur les utilise lors de la création d’une allocation sur le serveur TURN. Lorsque les identifiants expirent, le client en obtient de nouveaux auprès du serveur d’application.

TURN vs STUN : Comparaison

TURN et STUN résolvent des tâches connexes de traversée NAT, mais diffèrent fondamentalement par leur mécanisme et leur coût. TURN relaie le trafic, agissant comme intermédiaire, tandis que STUN aide seulement à déterminer l’adresse externe pour une connexion P2P directe. Le choix entre eux dépend du type NAT des pairs et des exigences de performance.

En pratique, le serveur TURN est utilisé uniquement pour les connexions où le P2P est impossible. Selon Google (statistiques WebRTC, 2023), environ 15 – 20% de toutes les connexions WebRTC nécessitent un relais TURN. Les 80 – 85% restants établissent la connectivité via STUN ou des candidats host locaux. Lors de la conception d’une application, vous devez budgétiser le trafic TURN à 15 – 20% du volume multimédia total si votre public inclut des utilisateurs de réseaux d’entreprise et de régions aux restrictions NAT strictes.

Coût et performance du serveur TURN

Le serveur TURN consomme des ressources importantes car tout le trafic multimédia passe par lui. Chaque appel actif avec relais TURN utilise la bande passante du serveur égale au débit total du trafic multimédia (flux entrant + sortant). Pour un appel vidéo HD (720p), cela peut représenter 1,5 – 2,5 Mbps par connexion dans chaque direction, soit un total de 3 – 5 Mbps de trafic global via le serveur TURN.

Il existe plusieurs options de déploiement pour l’infrastructure TURN. Les serveurs TURN publics gratuits ne sont pas recommandés pour la production en raison de l’absence de garanties de qualité et de sécurité. Les fournisseurs commerciaux (Twilio Network Traversal Service, Xirsys, Metered) proposent TURN en tant que service avec un prix au gigaoctet — le coût typique est de 0,005 – 0,02 $ par gigaoctet. L’auto-hébergement avec coturn (serveur TURN open-source) nécessite un serveur avec une capacité de bande passante suffisante et une configuration de surveillance.

• coturn — le serveur TURN open-source le plus populaire, utilisé dans la plupart des systèmes de production, prend en charge les transports UDP, TCP, TLS et DTLS.
• Twilio — un service commercial fournissant TURN + STUN avec une tarification basée sur le trafic et une authentification via des jetons à durée limitée.
• Xirsys — un fournisseur TURN spécialisé avec un réseau mondial de serveurs et des analyses d’utilisation détaillées.
• Metered.ca — un service TURN avec une limite gratuite jusqu’à 50 Go par mois et un paiement à l’utilisation au-delà.
• coturn auto-hébergé — contrôle total sur la configuration, mais nécessite une administration du serveur et une configuration de surveillance.

Lors du choix d’une solution de serveur TURN, tenez compte de la géographie des utilisateurs, du coût du trafic et des exigences de sécurité. Pour les applications avec des milliers d’appels simultanés, le coturn auto-hébergé sur des serveurs avec un canal large (1+ Gbps) peut être plus rentable que les fournisseurs commerciaux. Pour les petits projets avec des dizaines d’utilisateurs, les services TURN commerciaux sont préférables en raison de l’absence de frais d’administration et de surveillance.