Как сервер STUN получает IP-адрес / порт и как они используются? - PullRequest
Новая
       38

Как сервер STUN получает IP-адрес / порт и как они используются?

0 голосов
/ 23 февраля 2019

Я пытаюсь понять, как работает WebRTC, и мне трудно понять роль STUN.

Из того, что я понимаю, читая о STUN на различных веб-страницах, таких как rfc5389 или просматривая презентацию Google 2013 года по WebRTC , единственное, что STUN, похоже, делает, это сообщает клиенту, какой у него публичный IP-адрес / порт.

Однако, глядя на то, как можно реализоватьсервер STUN предполагает, что они гораздо более вовлечены, и, кажется, включает в себя такие вещи, как поддержка возврата при отказе для UDP, TCP и TLS-TCP и подтверждение связи, когда клиент и сервер сообщают о том, что они ожидают от своего IP-адреса, и проверяютэто против того, что другая сторона говорит, что их IP-адрес.Например, в отдельных случаях проект stunserver *1000* jselbi содержит более 50 файлов C ++.

  1. Значит, STUN должен делать больше, чем просто сообщать об общедоступном IP-адресе / порте?

Кроме того, мне не имеет смысла, почему клиент WebRTC даженужно знать свой публичный IP-адрес.В видео презентации Google (во время 19:46) показывает двух пиров, которые хотят общаться друг с другом из-за NAT, и каждый пир также общается с сервером сигнализации.Эта схема показывает, что каждый сервер сигнализации не знает общедоступный IP-адрес / порт партнера.Но эта диаграмма должна быть неправильной: она показывает, что узел разговаривает напрямую с сервером сигнализации, но косвенно общается с сервером STUN через NAT.В действительности одноранговый узел будет также общаться с сервером сигнализации через NAT, и поэтому сервер сигнализации уже будет знать общедоступный IP-адрес / порт партнера.

Исходя из этого, возникают проблемы, с которыми у меня возникают проблемы.являются:

Любой запрос от клиента к серверу сигнализации будет включать публичный IP-адрес / порт этого клиента в заголовок IP запроса.То же самое верно, когда клиент общается с сервером STUN, поэтому сервер STUN может ответить публичным IP-адресом / портом ... Это верно?

Кажется,мне, что способ, которым эти два пира могут тогда говорить друг с другом, состоит в том, чтобы перехватить открытое соединение между одноранговым узлом и сервером STUN: узел открывает соединение с сервером STUN.Сервер STUN отвечает, указав, какой IP-адрес / порт был настроен для этого запроса.И затем этот IP-адрес / порт затем перенаправляется на удаленный одноранговый узел, где удаленный одноранговый узел начинает отправлять сообщения по соединению, которое было первоначально открыто для сервера STUN ... Это правильно?

... или я совершенно не понял, что происходит?

1 Ответ

0 голосов
/ 23 февраля 2019

  1. Серверы STUN играют очень простую роль - возвращать общедоступный IP-адрес и порт, на который они получили пакет UDP, клиенту.То, на что вы смотрите, - это сервер, который реализует TURN (также описанный в https://tools.ietf.org/html/rfc5766)), который является расширением STUN, которое позволяет клиенту открывать порт udp на сервере и передавать данные.

  2. Соединение с сервером сигнализации выполняется по протоколу TCP, и на него не влияет NAT. Сервер сигнализации видит входящее соединение TCP, но эти данные бесполезны для установления соединения извне.

  3. Да. Ну, почти, тракт мультимедиа использует UDP, поэтому соединения отсутствуют. Большинство NAT пересылает все, что идет на публичный ip / порт, инициирующей стороне. Симметричные NAT непричина, по которой необходим TURN. Весь процесс называется либо «дыроколом udp», либо более формально ICE (описано в https://tools.ietf.org/html/rfc5245)

  4. Нет, вы получили часть «угон», которая является однойиз основных идей верно. Но NAT сломан больше, чем вы ожидали; -)

...