Clarification STUN et TURN

Question

Je dois établir une connexion entre un serveur et des clients qui peuvent être derrière n'importe quel type de NAT. À cet effet, j'ai un hôte dédié sur Internet avec IP propre pour l'hébergement du serveur STUN/TURN. Je ne vais pas utiliser WebRTC, je veux juste utiliser le serveur STUN/TURN pour la messagerie entre les clients et un serveur. Après avoir lu RFC, SO, etc. J'ai quelques questions non clarifiées:

1. Dans quel cas STUN est utilisé? À mon avis, STUN est utilisé uniquement pour le NAT en cône plein. Dans tous les autres cas, le serveur TURN doit être utilisé en raison d'une restriction d'hôte et/ou de port. Est-ce exact?
2. Il semble que j'ai besoin d'un serveur de signalisation pour informer les clients de l'adresse du serveur et vice versa. Mais dès que le client/serveur envoie un message au serveur de signalisation, je connais leur hôte externe: port, donc je laisse chaque camp savoir l'autre côté: port, chaque camp peut envoyer des messages à ce serveur de signalisation contenant l'hôte du pair: données du port , que le serveur de signalisation peut utiliser pour détecter le destinataire de ce message et l'envoyer au correspondant correspondant. A première vue, cette logique me semble assez simple et mon serveur de signalisation devient un serveur TURN. Est-ce ainsi que le serveur TURN est implémenté? Mais si oui, je ne comprends pas, pourquoi aurais-je besoin d'un serveur TURN comme "coturn", "reTurn", etc? Je sais qu'ils implémentent ICE, mais comment cette ICE fonctionnera, si mon serveur de signalisation a reçu un message de l'hôte concret: port d'un pair, donc c'est le seul candidat qui peut être utilisé pour la connexion avec le pair?
3. En cas de NAT restreint (port, adresse ou symétrique), combien de temps un port externe (public) du client est-il ouvert sur le routeur pour recevoir les datagrammes UDP? J'ai lu que client TURN envoie des messages d'actualisation au serveur pour garder le canal ouvert, est-ce la façon dont le client empêche également la fermeture des ports?

Answer 1

1. STUN peut combler les connexions P2P pour la plupart des NAT à l'exception de la variété symétrique, qui ont le mappage de port imprévisible. TURN est nécessaire pour ce dernier.

2. La signalisation est généralement effectuée avec TCP et un socket différent. Les médias P2P sont généralement UDP. Donc, il y a cette distinction. Vous pourriez découvrir l'adresse IP avec l'aide des serveurs de signalisation, mais vous ne pourrez pas découvrir le port de manière fiable. Même si les deux sont TCP, vous voulez probablement une connexion socket distincte pour le service de signalisation que le média.

3. De mon expérience: n'importe où de 1-2 minutes. Parfois plus longtemps. En l'absence de données circulant dans les deux sens, gardez en vie les messages qui circulent toutes les 45 secondes pour éviter que la session ne tombe.