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

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

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

networking turn stun nat-traversal
person rightaway717    schedule 10.07.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

person selbie    schedule 16.07.2016
comment
спасибо за ответ. 1) Насколько я понимаю, если используется STUN, то реле не используется, поэтому одноранговый узел подключается напрямую к клиенту, когда он получает клиентский хост: порт, используя сервер сигнализации. Но как это возможно без ретрансляции, если у однорангового узла есть другой хост: порт, отличный от STUN-сервера, к которому подключается этот клиент, таким образом, в случае чего-либо, кроме Full-Cone NAT, это прямое соединение от однорангового узла к клиенту будет отклонено, поскольку только Full-Cone NAT разрешает подключение любого хоста: порта к прослушиваемому порту? 2) Не могли бы вы уточнить, почему я не могу надежно обнаружить порт этим методом? - person rightaway717; 20.07.2016