À quoi servent les serveurs STUN et TURN
WebRTC fait fonctionner les appels vidéo, le partage d’écran et les transferts de fichiers entre navigateurs. Avant que deux appareils puissent communiquer directement, chacun doit savoir à quelle adresse joindre l’autre. Or la plupart des appareils se trouvent derrière une box domestique ou un pare-feu d’entreprise, avec des adresses privées traduites par NAT. Les serveurs STUN et TURN résolvent ce problème :
- STUN indique à un appareil comment il est vu depuis Internet : son adresse IP publique et son port. Grâce à cette information, deux pairs peuvent souvent se connecter directement.
- TURN sert de relais lorsqu’une connexion directe est impossible, par exemple derrière un NAT symétrique, des pare-feu stricts ou des réseaux qui n’autorisent que TCP.
Lancer le test
- Saisissez l’URL du serveur avec le préfixe stun:, turn: ou turns: (par exemple stun:server.example.com:3478 ou turn:server.example.com:3478?transport=tcp).
- Pour les serveurs TURN, renseignez le nom d’utilisateur et l’identifiant. Si vous utilisez des identifiants à durée limitée, vérifiez qu’ils n’ont pas expiré.
- Ajoutez d’autres serveurs si nécessaire et lancez le test. Votre navigateur collecte les candidats ICE et les liste chacun avec son type, son adresse, son protocole et le temps qu’il a mis à arriver.
Si vous n’avez pas votre propre serveur, utilisez l’option permettant de tester nos serveurs pour voir à quoi ressemble un résultat fonctionnel.
Lire les types de candidats
Chaque ligne du résultat est un candidat ICE. Sa signification dépend de son type :
- host : l’adresse locale de l’appareil. Les navigateurs modernes la masquent derrière un nom .local aléatoire par souci de confidentialité.
- srflx : l’adresse publique renvoyée par le serveur STUN. Si vous en voyez une, STUN fonctionne.
- relay : l’adresse de relais allouée par le serveur TURN. Si vous en voyez une, TURN et l’authentification fonctionnent.
- prflx : une adresse découverte lors des vérifications de connectivité ; rarement visible dans un test unilatéral.
La colonne de temps indique combien de millisecondes après le début chaque candidat est arrivé. Elle donne une idée de la distance et de la charge du serveur ; des temps de plusieurs centaines de millisecondes peuvent retarder sensiblement l’établissement d’un appel.
Problèmes courants
- Aucun candidat relay : nom d’utilisateur ou mot de passe erroné, static-auth-secret différent côté serveur, ou port TURN bloqué par un pare-feu.
- Fonctionne uniquement en UDP : pour les utilisateurs sur des réseaux restreints, ajoutez ?transport=tcp ou turns: (TLS) sur le port 443.
- turns: échoue mais turn: fonctionne : le certificat TLS est peut-être invalide, expiré ou ne correspond pas au nom d’hôte.
- Adresse srflx inattendue : avec le CGNAT ou un VPN, l’adresse publique appartient à votre FAI ou à votre fournisseur VPN.
Le test s’exécute entièrement dans votre navigateur ; les identifiants saisis ne servent qu’à votre navigateur pour se connecter au serveur indiqué. Pour voir votre IP publique et l’état des fuites WebRTC, consultez Quelle est mon adresse IP. Pour mesurer la perte de paquets réelle sur un canal de données WebRTC, essayez le test de perte de paquets, et vérifiez la latence de base avec le test de ping avant d’optimiser la qualité des appels dans votre propre application.