Уточнение STUN и TURN

Question

Мне нужно установить соединение между сервером и клиентами, которое может находиться за любым типом NAT. Для этого у меня есть выделенный хост в Интернете с чистым IP-адресом для размещения сервера STUN/TURN. Я не буду использовать WebRTC, я просто хочу использовать сервер STUN/TURN для обмена сообщениями между клиентами и сервером. После прочтения RFC, SO и т. Д. У меня остались некоторые вопросы:

1. В каком случае используется STUN? По моему мнению, STUN используется только для Full-cone NAT. Во всех остальных случаях должен использоваться сервер TURN из-за ограничения хоста и/или порта. Это верно?
2. Кажется, мне нужен сигнальный сервер для уведомления клиентов о адресе сервера и наоборот. Но как только клиент/сервер отправляет сообщение на сервер сигнализации, я знаю их внешний хост: порт, поэтому я позволяю каждой стороне знать другой хост: порт, каждая сторона может отправлять сообщения на этот сервер сигнализации, содержащий данные узла-хоста: порт , который сервер сигнализации может использовать для определения того, для какого сообщения это сообщение, и перенаправить его соответствующему партнеру. На первый взгляд эта логика кажется мне довольно прямой, и мой сигнальный сервер становится сервером TURN - это то, как реализуется сервер TURN? Но если это так, я не понимаю, зачем мне нужен сервер TURN, такой как «coturn», «reTurn» и т. Д.? Я знаю, что они реализуют ICE, но как этот ICE будет работать, если мой сервер сигнализации получил сообщение от конкретного хоста: порт однорангового узла, так что это единственный кандидат, который можно использовать для соединения с одноранговым узлом?
3. В случае ограниченного NAT (порт, адрес или симметричный), как долго внешний (клиентский) порт клиента открыт на маршрутизаторе для приема дейтаграмм UDP? Я читал, что клиент TURN отправляет на сервер обновления сообщений, чтобы сохранить канал открытым, так ли клиент также предотвращает закрытие портов?

Answer 1

1. STUN может преодолеть P2P соединения для большинства NATs кроме симметричного сорта, которые имеют непредсказуемое отображение порта. Для последнего требуется TURN.

2. Сигнализация обычно выполняется с использованием TCP и другого сокета. P2P-носитель обычно является UDP. Так что это различие. Вы можете обнаружить IP-адрес с помощью службы сигнальных серверов, но вы не сможете надежно обнаружить порт. Даже если оба являются TCP, вы, вероятно, хотите отдельное подключение сокета для службы сигнализации, чем носитель.

3. Из опыта: от 1-2 минут. Иногда дольше. При отсутствии данных, текущих в обоих направлениях, сохраняйте сообщения, которые текут каждые 45 секунд, чтобы не дать сеансу упасть.