Une explication et une pratique approfondies de STUN/TURN/TURNS/SFU dans WebRTC

12 avril 2025

table des matières

Qu'est-ce que WebRTC ?

WebRTC (Web Real-Time Communication) est une technologie ouverte qui permet la communication en temps réel de la voix, de la vidéo et des données entre navigateurs. Elle est en cours de standardisation par diverses entreprises, dont Google, comme mécanisme permettant la communication P2P via des API JavaScript uniquement, sans nécessiter de plug-ins ou de logiciels supplémentaires.

WebRTC se compose de trois composants principaux :

obtenirUserMedia:Une API pour acquérir de l'audio et de la vidéo à partir d'appareils tels que des caméras et des microphones.
RTCPeerConnection:Une API principale pour établir une communication entre pairs et échanger des médias et des données.
RTCDataChannel:Un canal de données qui peut être utilisé pour envoyer des fichiers, discuter, etc.

Ces API permettent le développement de nombreuses applications en temps réel telles que les appels vidéo, les conférences audio, le partage de fichiers, etc. Cependant, dans les communications réelles, il existe des problèmes avec la traversée NAT et les pare-feu, il est donc essentiel de comprendre et de mettre en œuvre des technologies de traversée NAT telles que STUN/TURN/TURNS.

Différences et rôles de STUN, TURN et TURNS

Pour obtenir une connexion pair à pair stable avec WebRTC, un mécanisme de traversée NAT est essentiel. Cet article détaille les différences techniques, les scénarios d'utilisation, ainsi que les avantages et les inconvénients des technologies STUN, TURN et TURNS.

STUN est un protocole utilisé principalement pour déterminer l'adresse externe d'un utilisateur dans un environnement NAT, tandis que TURN fait office de serveur relais lorsqu'une connexion directe est impossible. TURNS, quant à lui, chiffre ses communications avec TLS et utilise le même numéro de port 443 que HTTPS, ce qui permet de communiquer derrière des pare-feu stricts, comme sur les réseaux d'entreprise.

En comprenant les caractéristiques de chacun et en les utilisant de manière appropriée, vous pouvez augmenter le taux de réussite et la qualité des communications WebRTC.

Rôle et fonctionnalités de STUN (UDP)

STUN (Session Traversal Utilities for NAT) est un protocole qui permet aux clients deAdresse IP et port externesIl s'agit d'un protocole simple permettant de connaître l'adresse IP d'un PC. Par exemple, si un PC est derrière un NAT, il ne connaît pas sa propre adresse IP globale, mais il peut obtenir « son adresse IP : port vu de l'extérieur » en interrogeant le serveur STUN.

Le serveur STUN agit comme un miroir, renvoyant les informations source de la requête reçue telles quelles. Ainsi, le client peut connaître sa propre adresse IP globale et le numéro de port attribué par le NAT (Server Reflexive Candidate).

La communication STUN s'effectue généralement via UDP, le port par défaut étant 3478 (UDP/3478). Comme elle nécessite une communication UDP légère et mono-coup, elle présente une faible surcharge, une faible latence et une charge serveur quasi nulle. Par conséquent, dans les environnements où la communication UDP est autorisée, la traversée NAT via STUN est tentée en premier.

Scénarios d'utilisation de STUN

Il est efficace dans les environnements où la traversée NAT est nécessaire, mais où la communication UDP elle-même n'est pas bloquée, comme les réseaux domestiques et les lignes mobiles. Si STUN peut obtenir l'adresse IP externe de l'autre appareil, les clients peuvent établir une communication directe (pair à pair). Comme le chemin de communication est direct, les délais sont réduits et la qualité est maintenue à un niveau élevé. De plus, comme le serveur ne participe qu'à l'échange d'informations IP, les coûts sont très faibles. Par exemple, pour les jeux en ligne ou les appels vidéo, si les deux appareils sont dans un NAT relativement ouvert, STUN suffit à établir une connexion pair à pair.

Limites et inconvénients du STUN

STUN est simplement un moyen de « trouver sa propre adresse externe » et, selon le type de NAT et les restrictions du pare-feu, il peut être impossible de se connecter en utilisant uniquement ce moyen. En particulier, dans les environnements NAT symétriques ou avec pare-feu strict, les paquets provenant de l'autre partie peuvent ne pas atteindre l'adresse obtenue par STUN, rendant la communication impossible.

De plus, la communication UDP elle-même peut être bloquée sur les réseaux d'entreprise, auquel cas les requêtes STUN n'atteignent pas l'appareil. En résumé, STUN est un mécanisme permettant de déterminer si une communication directe est possible et ne fonctionne pas dans les environnements où elle est physiquement impossible. C'est pourquoi STUN est utilisé dans ICE (décrit ci-dessous) pour identifier les candidats à la première étape, et est conçu pour revenir à TURN (décrit ci-dessous) si STUN est insuffisant.

Rôle et fonctionnalités de TURN (UDP)

TURN (Traversal Using Relays around NAT) est un protocole qui agit comme un relais lorsque la communication directe est impossible avec STUN. Le serveur TURN agit comme un point de relais accessible à tous entre le partenaire de communication et l'autre partie, transférant les paquets. Le client se connecte au serveur TURN et obtient une adresse IP et un port de relais, appelés « candidat relais ». L'échange de médias et de données avec l'autre partie s'effectue ensuite via ce serveur TURN.

TURN communique également normalement via UDP. Ainsi, tant que ce protocole est utilisé, il peut relayer les paquets multimédias de manière similaire à une communication directe. Par défaut, le protocole TURN est accepté sur le port 3478 (UDP), comme STUN. Même si le numéro de port UDP est restreint par la politique de pare-feu, TURN peut également être exécuté sur un port autorisé tel que UDP/443. Tant que le protocole UDP est utilisé, le relais offre des performances temps réel supérieures à celles du protocole TCP.

Scénarios d'utilisation de TURN

TURN est essentiel lorsqu'une connexion directe ne peut être établie. Par exemple,C'est le cas lorsque l'une ou les deux parties se trouvent derrière un pare-feu d'entreprise strict, ou lorsque les deux parties ont des NAT symétriques et que le perforation UDP échoue.Dans un tel environnement, la communication n'est pas possible sans relais via un serveur TURN, donc TURN fonctionne comme une sorte de dernier recours.

WebRTC vise à permettre à tous les pairs de communiquer directement. Même si cela n'est pas possible, la communication peut se poursuivre en utilisant TURN. En pratique, la stratégie générale consiste à essayer d'abord de se connecter directement à STUN, puis à ne basculer sur le relais TURN qu'en cas d'échec. Par exemple, lors d'une visioconférence sur un réseau interne, si les deux parties ne peuvent pas communiquer directement, la communication bascule automatiquement vers le serveur TURN, permettant à l'utilisateur de poursuivre la conversation sans même s'en rendre compte.

Avantages de TURN

Le principal avantage réside dans la fiabilité. Quel que soit l'environnement NAT ou pare-feu utilisé, tant que la communication entre le client et le serveur TURN est établie, une communication pair à pair est possible. De plus, TURN étant une extension de STUN en termes de protocole, une implémentation serveur unique (comme coturn, décrite ci-dessous) peut traiter les requêtes STUN et TURN. Une fois la connexion établie, les médias suivants sont relayés sous forme de flux, ce qui, du point de vue de l'utilisateur, garantit une communication fluide, à l'exception de quelques retards.

Inconvénients de TURN

Ses principaux inconvénients sont la consommation de ressources et la latence. Avec TURN, toutes les données audio et vidéo doivent transiter par le serveur, ce qui requiert une bande passante et une puissance de traitement considérables côté serveur. Par exemple, si l'on suppose qu'un appel vidéo individuel consomme une bande passante unidirectionnelle de 1 Mbit/s, un simple calcul permet de supposer que 1 000 utilisateurs l'utilisent simultanément, une bande passante relais de 1 Gbit/s est nécessaire. Cela engendre des coûts d'exploitation élevés pour un serveur TURN, et les services à grande échelle nécessitent la préparation et la mise à l'échelle de plusieurs serveurs relais TURN.

De plus, plus le chemin de communication est long, plus le délai est important, ce qui entraîne un décalage temporel et une baisse de la qualité vidéo et audio. De plus, comparée à la communication pair-à-pair utilisant STUN, la communication via TURN n'est pas strictement pair-à-pair ; elle est donc légèrement inférieure en termes de confidentialité (bien que les serveurs TURN ne relaient généralement que des RTP/datagrammes non chiffrés et n'en interprètent pas le contenu).

En général, TURN ne doit être utilisé qu'en cas de nécessité. En effet, la plupart des communications WebRTC peuvent être connectées directement via STUN, et les statistiques de Google montrent qu'environ 861 appels TP3T au total sont établis sans relais (peer-to-peer). Seuls les 141 TP3T restants nécessitent TURN, mais il est important de disposer d'une infrastructure TURN pour ces 141 TP3T.

Rôle et fonctionnalités de TURNS (TLS sur TCP/443)

TURNS est l'abréviation de « TURN over TLS » et est un protocole qui crypte la communication relais à l'aide du protocole TURN avec TLS (Transport Layer Security).Communication TURN sécurisée par TLS (HTTPS)et sert souvent sur le port TCP 443.Le port 443 est le même numéro de port que HTTPS, il peut donc facilement traverser les pare-feu d'entreprise et permet de contourner facilement les proxys et la censure..

Par exemple, un réseau d'entreprise interne peut autoriser uniquement les communications externes sur les ports 80 et 443, mais même dans ce cas, il existe de fortes chances que les communications puissent passer si le serveur TURN utilise les communications TLS sur le port 443. De plus, comme les communications sont cryptées à l'aide de TLS, elles sont sécurisées et difficiles à intercepter pour des tiers.

Dans WebRTC, les paramètres"urls": "tours:toursserveur:443"Dans le schéma URI :tours:Vous pouvez utiliser ce serveur TURN chiffré TLS en spécifiant

Scènes où TURNS est utilisé

TURNS est utile pour la communication WebRTC dans des environnements très restreints, comme les réseaux d'entreprise, où tous les autres moyens sont bloqués. Même dans les environnements où tous les ports UDP et TCP généraux sont bloqués, de nombreuses politiques autorisent la communication de la même manière que la communication HTTPS. TURN sur le port TLS 443 constitue donc un dernier recours.

Il est également utilisé dans les situations où certains ports sont fermés sur les réseaux locaux sans fil publics, ou lorsque seule la communication TLS est possible côté client.D'abord UDP, si cela ne fonctionne pas alors TCP, si cela ne fonctionne pas alors TLS vers 443« Elle se positionne comme l’étape finale d’un repli progressif.

Avantages de TURNS

Son principal avantage réside dans sa haute résistance aux pare-feu. Les communications chiffrées TLS sont difficiles à distinguer du HTTPS standard ; elles sont donc plus susceptibles de passer à travers des filtres stricts. En particulier, lors de l'introduction d'un système de webconférence dans une entreprise, il est nécessaire d'autoriser les connexions externes depuis le réseau interne, mais les communications TLS via TCP/443 sont plus susceptibles d'être acceptées dans le cadre des politiques de sécurité. De plus, grâce au chiffrement, la confidentialité des communications avec le serveur relais est assurée (*Cependant, le contenu lui-même, comme la vidéo, est souvent déjà chiffré au niveau de la couche WebRTC).

Inconvénients de TURNS

Le principal inconvénient réside dans la baisse des performances. Outre le délai et la charge de TURN, il faut tenir compte de la surcharge de TLS et TCP. TCP est un transport fiable et dispose d'un mécanisme de retransmission en cas de perte de paquets, mais il n'est pas adapté aux médias en temps réel. En cas de perte, la lecture vidéo et audio peut être perturbée.

De plus, TCP est sujet au blocage en tête de ligne en raison de l'ordre des paquets,La gigue (fluctuation) augmente également par rapport à l'UDP.De plus, le traitement du chiffrement et du déchiffrement TLS sollicite davantage le processeur. Par conséquent, un délai supplémentaire de 50 ms ou plus a été signalé, provoquant un décalage perceptible par les utilisateurs. En particulier, lors des visioconférences, ce délai accru peut ralentir le rythme des conversations et entraîner des décalages temporels notables.

De cette façon, TURNS peut être considéré comme une méthode de « dernier recours » en termes de qualité, mais c'est aussi une bouée de sauvetage fiable dans les situations où il n'y a pas d'autre option que d'établir une communication.

Ces dernières années, une nouvelle approche (TURN over QUIC) qui fonctionne sur le port UDP 443 et utilise DTLS/QUIC au lieu de TLS a été envisagée, mais elle est toujours en cours de normalisation et n'est pas couramment utilisée.

Flux de communication lorsque UDP STUN n'est pas disponible

Nous allons expliquer étape par étape le déroulement du traitement ICE WebRTC lorsque STUN sur UDP n'est pas disponible. Prenons l'exemple d'un blocage total d'UDP, par exemple sur un réseau d'entreprise, et voyons comment la négociation ICE se résorbe.

Le client envoie une requête IP externe (UDP/3478) au serveur STUN :
Client WebRTC (navigateur)serveurs de glaceUne demande de liaison (demande de vérification de l'adresse externe) est envoyée au serveur STUN spécifié via le port UDP 3478. Il s'agit de la première étape de la collecte des candidats ICE et, en cas de succès, le serveur renvoie sa propre adresse IP globale et son numéro de port, et est ajouté à la liste des candidats en tant que candidat réflexif du serveur (candidat srflx).
Les paquets UDP sont bloqués par le pare-feu et aucune réponse n'est reçue :
Dans ce cas, les paramètres du pare-feu réseau empêchent les communications UDP d'atteindre l'extérieur. Par conséquent, les requêtes adressées au serveur STUN n'atteignent pas ce dernier, ou la réponse n'atteint pas le client. Par conséquent, le clientRéponse STUN non reçueL'adresse IP externe est inconnue. L'agent ICE attend une réponse pendant un certain temps, puis expire. Du point de vue de l'utilisateur, la connexion est toujours en cours de traitement et aucun message d'erreur ne s'affiche, mais en réalité,Impossible de rassembler les candidatsCela se produit actuellement.
La vérification de la connexion directe ICE échoue car aucun candidat Server Reflexive n'est disponible :
Normalement, si STUN réussit, le client dispose d'un serveur réflexif (votre adresse IP globale) en plus de l'hôte (votre adresse IP locale) et vérifie la connexion en la combinant avec celle du pair distant. Cependant, en l'absence d'adresse IP globale candidate suite à un échec STUN,Les candidats aux connexions directes entre pairs sont extrêmement limitésPar exemple, si les deux parties ne disposent que d'adresses IP privées, elles ne pourront pas se joindre, même en essayant de se connecter. ICE déterminera alors que la communication directe est impossible. Si le serveur ICE (TURN) n'est pas configuré, l'ensemble du système ICE sera considéré comme un échec à ce stade et la connexion WebRTC ne sera pas établie (la console développeur afficheraL'ICE a échouéet ... etÉtat de la connexion ICE : échecetc. seront affichés).
Tenter d'obtenir des candidats au relais TURN (via TCP/TLS/443) :
Même si l’acquisition directe de candidats par STUN échoue,serveurs de glaceSi un serveur TURN est spécifié dansProchaines étapesDans cet exemple, comme UDP n'est pas disponible, le client essaiera de se connecter au serveur TURN en utilisant TCP ou TLS (par exemple,tours:turn.example.com:443(Si configuré, le protocole TLS démarrera.) Heureusement, le pare-feu autorise la communication HTTPS sur TCP 443, la connexion TURN via TLS est donc réussie. Le client sécurise une adresse relais sur le serveur TURN.Candidat au relaisL'autre côté obtiendra des candidats relais, qui sont des « candidats virtuels pour la communication via le serveur TURN ». Parallèlement, l'autre côté (le côté distant) obtiendra également des candidats relais, ou, si le réseau est sans problème, des candidats directs ou STUN. Dans tous les cas, si au moins un côté possède des candidats relais, l'autre côté peut tenter de se connecter à ce serveur TURN.
Établissement de la connexion ICE (ou échec éventuel) via relais :
Une fois que les deux homologues ont des candidats disponibles (un ou les deux candidats relais dans cet exemple), ICE les utilise pour vérifier la connexion. Une fois la communication établie via le serveur TURN avec le serveur, elle peut être relayée, de sorte que le canal multimédia est ouvert même si le protocole UDP ne passe pas directement entre les homologues. Cela permet aux communications vidéo et audio entre les utilisateurs de commencer. Une fois la connexion établie, une surcharge est générée par TCP sur TLS, mais la conversation elle-même est possible. À l'inverse, en cas de défaillance (par exemple, si un proxy d'entreprise détecte et bloque une communication TLS non HTTP, ou si l'authentification du serveur TURN échoue), ICE échouera et la connexion sera abandonnée. L'application doit détecter cette situation et signaler à l'utilisateur que la connexion n'était pas possible, etc.

Voici le déroulement de la négociation ICE dans les environnements difficiles où UDP est inutilisable. En résumé, les candidats sont testés dans l'ordre « Hôte → STUN → TURN », et en cas d'échec, la connexion échoue. Il est important que les développeurs comprennent ce comportement et incluent au minimum un serveur TURN/TURNS dans la liste des serveurs ICE, afin que, même dans le pire des cas, la communication puisse être établie. De plus, lors des requêtes des utilisateurs, un dépannage est nécessaire, par exemple en déduisant un problème lié à l'environnement réseau (blocage UDP, par exemple) à partir d'informations telles que « Échec ICE » et en vérifiant les paramètres de serveur TURN manquants.

Création et configuration d'un serveur STUN/TURN/TURNS à l'aide de coturn

Si vous souhaitez configurer votre propre serveur STUN/TURN, utilisez l'implémentation open source. tournerL'utilisation de coturn est courante. coturn est une implémentation serveur prenant en charge STUN et TURN, et peut également prendre en charge TURNS (TLS) selon les paramètres. Cet article explique comment installer coturn sur un serveur Linux et créer un serveur prenant en charge STUN/TURN/TURNS, ainsi que les points de configuration. Il décrit également le fichier de configuration standard (turnserver.conf) est également affiché.

Installation et configuration de base

installer

Pour Ubuntu et Debian,apteVous pouvez installer le paquet coturn depuis. Par exemple, utilisez la commande suivante pour l'installer et le configurer pour un démarrage automatique.

# Ubuntu/Debianの場合
sudo apt-get install coturn
sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn
sudo systemctl enable --now coturn

Cela démarrera le serveur coturn en tant que démon. Par défaut, le fichier de configuration sera exécuté. /etc/turnserver.conf Cela chargera le fichier, et vous pourrez ensuite le modifier (faites une sauvegarde avant de le modifier, juste pour plus de sécurité).

Paramètres de base

turnserver.confMaintenant, définissez les éléments suivants :

royaume et nom du serveur : Il s'agit du nom de domaine ou d'identification du serveur TURN. Il peut être utilisé pour l'authentification d'un client WebRTC, mais il peut s'agir de n'importe quelle chaîne. Exemple : royaume=exemple.com,nom-du-serveur=exemple.com.
port d'écoute : Numéro de port UDP à utiliser pour écouter TURN et STUN. La valeur par défaut est 3478.écoute-ipVous pouvez également vous lier à une carte réseau spécifique avec0.0.0.0Nous acceptons tout.
port d'écoute tls : Il s'agit du numéro de port TCP à utiliser pour l'écoute TLS (TURNS). Généralement, 443 ou 5349 est spécifié. Exemple : tls-listening-port=443.
IP externe : Si le serveur lui-même est derrière un NAT, spécifiez sa propre adresse IP globale (cela permet au serveur de reconnaître le mappage entre l'adresse IP interne et l'adresse IP externe). Cela n'est pas nécessaire si le serveur possède une adresse IP globale directe.
Méthode d'authentification : WebRTC utilise des informations d'identification à long terme pour TURN, donclt-cred-mech(Mécanisme d'accréditation à long terme) est activé.utilisateur=nom d'utilisateur:mot de passeou définissez le nom d'utilisateur et le mot de passe au formatutiliser-auth-secret(Cette dernière est une authentification basée sur des jetons, qui est efficace pour améliorer la sécurité, mais nous allons ici montrer une authentification utilisateur statique simple à titre d'exemple.)
Paramètres du journal : Pour le dépannagefichier journalSpécifiez le chemin du fichier journal dansverbeuxVous souhaiterez peut-être activer la journalisation détaillée.

Paramètres du pare-feu

Côté serveur, pour STUN/TURNPort UDP 3478, et pour TURN/TLSPort TCP 443(ou 5349) doit être ouvert. De plus, le relais TURN utilise par défaut la plage de ports UDP 10 000-20 000 ; ouvrez donc également cette plage de ports sur le serveur (si nécessaire).port minimaletmax-port(La portée peut être modifiée avec

Vous trouverez ci-dessous un exemple qui reflète les paramètres de base ci-dessus./etc/turnserver.confVoici un exemple :

# TURNサーバの名称とレルム（ドメイン）
realm=example.com
server-name=example.com

# ネットワーク設定
listening-ip=0.0.0.0           # すべてのIPアドレスで待受
external-ip=203.0.113.10       # サーバのグローバルIP（必要な場合）

# ポート設定
listening-port=3478            # STUN/TURN用 UDPポート
tls-listening-port=443         # TLS用 TCPポート (443番)
min-port=10000                 # 中継に使用するポート範囲（下限）
max-port=20000                 # 中継に使用するポート範囲（上限）

# ログ設定
log-file=/var/log/turnserver.log
verbose                        # 詳細ログを有効化
fingerprint                    # パケットにfingerprint属性を付与

# 認証設定（長期認証方式）
lt-cred-mech                   # 長期認証を有効化
user=webrtcuser:secretpass123  # ユーザ名:パスワード を設定

# TLS/SSL証明書の指定
cert=/etc/letsencrypt/live/example.com/fullchain.pem   # サーバ証明書
pkey=/etc/letsencrypt/live/example.com/privkey.pem     # 秘密鍵

Dans ce qui précède, le domaineexemple.comNous obtenons un certificat Let's Encrypt et l'utilisons pour les paramètres TLS.lt-cred-mechActiver l'authentification à long terme avecutilisateurCela configure une authentification simple par nom d'utilisateur/mot de passe.utiliser-auth-secretetsecret d'authentification statiqueLa méthode recommandée consiste à utiliser une méthode basée sur des jetons pour émettre des informations d’identification temporaires, mais nous n’aborderons pas ce sujet ici.

Précautions lors de l'utilisation de TLS

Lors de l'exécution de coturn sur le port 443, soyez vigilant quant aux permissions de port dans un environnement Linux. Les ports inférieurs à 1024 sont dits privilégiés et ne peuvent généralement pas être ouverts sans les privilèges root. Le paquet Ubuntu coturn utilise par défautserveur tournantParce qu'il est exécuté par un utilisateur, il ne peut pas se lier au port 443 tel quel./etc/default/coturnChanger l'utilisateur en cours d'exécution en root, ousetcapAvec la commandeserveur tournantau fichier exécutableservice de liaison cap_netIl existe un moyen d'accorder des autorisations. Par exemple, dans ce dernier cas,sudo setcap cap_net_bind_service=+ep /usr/bin/turnserverEn exécutant cette commande, même les utilisateurs non root pourront se connecter aux ports de faible numéro. Spécifiez également le chemin d'accès correct au fichier de certificat (cert/pkey) et définissez les permissions du fichier pour que l'utilisateur coturn puisse le lire. Après avoir modifié les paramètres,sudo systemctl restart coturnRedémarrez le service et vérifiez les journaux pour détecter d’éventuelles erreurs.

Contrôle de fonctionnement

Après avoir démarré le serveur coturn, nous le testerons à l'aide d'un client STUN pour vérifier son fonctionnement, et essaierons également de nous connecter à ICE depuis l'application WebRTC dans le navigateur.stunclientcommande(apt-get installe stun-client(Disponible pour l'installation àstunclient <IP du serveur> 3478Vous pouvez essayer d'obtenir votre adresse IP externe en exécutant la commande suivante. De plus, dans votre navigateur, les candidats ICE seront répertoriés dans le journal des outils de développement.srflx(Serveur Réflexif) candidats etrelaisVérifiez si vous recevez un candidat. Sinon, essayez les solutions suivantes :

Les ports nécessaires sont-ils ouverts dans les paramètres du pare-feu du serveur (iptables ou groupes de sécurité cloud) ?
Les informations d'URI, de port et d'authentification correctes sont-elles définies dans les paramètres du serveur ICE côté client (décrits ci-dessous) ?
turnserver.confderoyaumeAssurez-vous que les paramètres correspondent à l'authentification du client. (Ceci ne pose généralement pas de problème dans la version navigateur de WebRTC, car le domaine est attribué automatiquement. Cependant, soyez prudent si vous avez une implémentation personnalisée.)
journal de bord (/var/log/turnserver.log) et vérifiez s'il y a une erreur d'authentification (MAUVAIS UTILISATEURS'il y a une erreur telle que celle ci-dessus, le nom d'utilisateur/mot de passe ne correspond pas.

Avec les paramètres ci-dessus en place, vous aurez votre propre serveur STUN/TURN/TURNS en cours d'exécution et pourrez prendre en charge les connexions WebRTC dans divers environnements réseau.

Exemple de paramètres du serveur ICE pour le client WebRTC (JavaScript)

Pour utiliser réellement le serveur STUN/TURN que nous venons de construire sur l'application WebRTC (navigateur),Paramètres des serveurs ICEDans l'API WebRTC de JavaScript,RTCPeerConnectionVous pouvez spécifier une liste de serveurs STUN/TURN lors de la génération d'un fichier . Nous allons maintenant présenter un exemple de code concret spécifiant tous les serveurs STUN/TURN/TURNS et expliquer sa signification.

Commencez par créer un objet de configuration pour le serveur ICE. Saisissez le nom de domaine de votre serveur.turn.example.com(Remplacer si nécessaire). STUN ne nécessite pas d'authentification, donc seul l'URI est spécifié. TURN/TURNS nécessite une authentification, donc le nom d'utilisateur et le mot de passe sont également spécifiés.

const iceConfig = {
  iceServers: [
    // 1. STUNサーバ（UDP/3478）
    { urls: 'stun:turn.example.com:3478' },
    // 2. TURNサーバ（UDP/443経由）
    { urls: 'turn:turn.example.com:443?transport=udp', username: 'webrtcuser', credential: 'secretpass123' },
    // 3. TURNサーバ（TCP/443 + TLS = TURNS）
    { urls: 'turns:turn.example.com:443', username: 'webrtcuser', credential: 'secretpass123' }
  ]
};
const pc = new RTCPeerConnection(iceConfig);

Ci-dessusserveurs de glaceLe tableau comporte trois entrées.

ÉTOURDIR: étourdir:turn.example.com:3478
Spécifie l'adresse de votre propre serveur STUN (si le port est omis, le port 3478 est utilisé). STUN permet de déterminer la traversée NAT et d'obtenir les candidats. Le navigateur interroge d'abord ce serveur via UDP pour obtenir les candidats réflexifs du serveur.
TOUR (UDP) : tour:tour.exemple.com:443?transport=udp
Créez votre propre serveur TURNPort UDP 443Il s'agit du paramètre à utiliser. Le nom d'utilisateur défini précédemment dans coturn comme information d'authentification.utilisateur Webet mot de passesecretpass123Le paramètre de requête est spécifié.?transport=udp(Si non spécifié, le navigateur essaiera d'abord UDP, et si cela échoue, essaiera également TCP.) Avec ce paramètre, même si une connexion directe utilisant STUN normal échoue, vous pouvez obtenir un candidat pour le relais TURN sur le port UDP 443.
TOUR (TLS/TCP) : tours:turn.example.com:443
TOURNER avec TLSIl s'agit du paramètre du serveur TURNS. Le nom d'utilisateur et le mot de passe sont également spécifiés ici. Le navigateur établira une connexion TLS à cette entrée sur le port TCP 443 pour obtenir un relais TURN candidat. Il s'agit du relais candidat de dernier recours, et il est possible d'établir une communication même si la communication via UDP est impossible.

RTCPeerConnectionLorsque l'agent ICE génère le serveur ICE, il tente de se connecter aux serveurs ICE spécifiés dans l'ordre et collecte les candidats. L'agent ICE obtient d'abord les candidats STUN (srflx), puis les candidats TURN (relais) en parallèle. L'algorithme ICE combine ensuite ces candidats, effectue une vérification de connexion et sélectionne la route optimale. Les développeurs n'ont pas besoin de connaître d'autres procédures.

indiquer: Comme mentionné ci-dessusPréparez plusieurs candidatsest important. Par exemple,étourdir:Si vous spécifiez uniquement TURN (UDP), aucun candidat ne sera trouvé dans un environnement où UDP est bloqué, et la connexion échouera. De même, si vous spécifiez uniquement TURN (UDP), la connexion échouera dans un environnement où seul TCP est autorisé. Par conséquent, si possible,tourner:ettours:En incluant les deux dans le serveur ICE, la redondance est assurée, permettant de trouver au moins un candidat valide dans n'importe quel environnement (bien entendu, le serveur TURN doit prendre en charge UDP et TCP/TLS). Le client (navigateur) sélectionne automatiquement un chemin disponible, l'ordre de la liste n'est donc pas un problème majeur. Si je devais dire :Politique de transport sur la glacederelaisSauf indication contraire, le navigateur privilégiera les connexions directes. Ainsi, si vous saisissez une entrée STUN, vous éviterez d'utiliser inutilement le serveur TURN. De plus, si des serveurs non pertinents (adresses inexistantes, etc.) sont saisis dans la liste des serveurs ICE, des retards peuvent survenir en raison d'un dépassement de délai. Il est donc préférable de ne saisir que ceux qui sont réellement disponibles.

Enfin, exécutons l’application WebRTC avec ce paramètre et vérifions l’état de la connexion.peerConnection.getStats()ouchrome://webrtc-internalsVous pouvez vérifier le candidat ICE et l'état de la connexion avec (Chrome). Si tout fonctionne comme prévu, le serveur devrait automatiquement revenir à une connexion directe (P2P) dans un environnement où UDP est disponible, et à une connexion via TURN/TLS dans un environnement où cela est difficile.

Différence entre SFU et TURN

Les relais WebRTC peuvent être divisés en deux catégories : « TURN » et « SFU », mais leurs rôles, configurations et utilisations diffèrent sensiblement. Voici un résumé des différences techniques.

TURN : Le relais comme alternative au peer-to-peer

TURN (Traversal Using Relays around NAT) est un serveur relais auxiliaire utilisé dans les environnements où la communication P2P WebRTC est impossible. Le serveur TURN agit entre les homologues et relaie les paquets lorsque STUN ne fonctionne pas en raison de la NAT ou de pare-feu. Chaque homologue envoyant un flux à chaque partenaire de communication individuellement, la configuration est de type maillé et TURN se positionne comme un « pinch hitter ».

composition: Chaque utilisateur transmet à tous les autres utilisateurs via un relais (en fait un maillage)
Évolutivité: Faible (plus il y a de monde, plus la charge est élevée)
Contenus diffusés:Transfert de paquets simple uniquement, aucune analyse ou optimisation des médias

SFU : Relais efficace pour les appels multipartites

SFU (Selective Forwarding Unit) est un serveur relais intelligent utilisé dans les conférences Web multi-participants.Chaque client envoie un flux à la SFU, qui le transmet de manière sélective à d’autres participants.Il effectue également la détection des haut-parleurs, le réglage de la qualité de l'image et l'optimisation de la latence, permettant une diffusion évolutive et hautes performances.

composition: Type étoile où chaque client est connecté à une SFU
Évolutivité:Cher (une seule transmission même si le nombre de personnes augmente)
Contenus diffusés:Le contrôle de la destination du transfert et l'optimisation du support sont possibles

Tableau comparatif entre TURN et SFU

Caractéristiques	TOURNER	Université Simon Fraser
But	Alternatives lorsque la traversée NAT n'est pas possible	Communication en temps réel entre de nombreuses personnes
Configuration de la communication	Maillage (transmission entre eux)	Type étoile (une transmission)
Fonction relais	Relais simple (transparent)	Transfert sélectif et optimisation disponibles
Évolutivité	faible	cher
Contrôle des médias	aucun	Oui (par exemple, détection du haut-parleur, réglage de la résolution)

TURN n'est qu'un dernier recours lorsque la communication P2P n'est pas possible, et constitue un relais qui complète le maillage P2P.SFU est une architecture de relais conçue pour être efficace dès le départ pour les appels multipartites.Étant donné que les deux ont des rôles fondamentalement différents, il est important de ne pas les confondre lors de la conception.

résumé

Cet article fournit une explication détaillée pour les utilisateurs WebRTC intermédiaires à avancés sur les différences techniques entre STUN, TURN et TURNS, ainsi que sur le moment où les utiliser, comment créer un serveur à l'aide de coturn et quelques exemples de code, et comment ICE se comporte dans des environnements réseau difficiles.

ÉTOURDIRIl est léger et permet une communication directe dans les environnements NAT.TOURNERfournit une bouée de sauvetage pour la communication dans les situations difficiles ; etTOURSEn combinant ces éléments, il devient possible d’utiliser WebRTC même dans des environnements particuliers comme au sein d’une entreprise.

Chacune de ces méthodes présente des avantages et des inconvénients. Il est donc préférable de se connecter directement à STUN autant que possible et d'utiliser le relais TURN uniquement en cas d'absolue nécessité. Dans le développement d'applications WebRTC, en préparant plusieurs routes dans les paramètres du serveur ICE, comme présenté ici, et en configurant et en utilisant correctement coturn côté serveur, vous pouvez assurer des communications stables en temps réel dans divers environnements réseau.

WebRTC est un domaine complexe qui combine les API de navigateur et les technologies réseau, mais comprendre le fonctionnement de STUN/TURN et ICE est essentiel pour créer des applications fiables.

Nous espérons que vous utiliserez les informations de cet article pour relever le défi de la traversée NAT dans vos produits. Vos utilisateurs pourront ainsi bénéficier de communications fluides grâce à un traitement des connexions intelligemment conçu en arrière-plan, sans même s'en rendre compte.

URLをコピーしました！