Является ли STUN-сервер абсолютно необходимым для webrtc, когда у меня есть сигнальный сервер на основе socket.io?

Сервер STUN НЕ является сервером сигнализации.

Целью сервера сигнализации является передача информации между одноранговыми узлами в начале сеанса (как они могут отправить предложение, не зная, кому отправить?). Эта информация включает SDP, которые создаются для предложений и ответов, а также любых Ice Candidates, созданных любой из сторон.

Причина наличия STUN-сервера в том, чтобы два одноранговых узла могли отправлять мультимедиа друг другу. Потоки мультимедиа не будут попадать на ваш сервер сигнализации, а вместо этого будут идти прямо к другой стороне (определение однорангового соединения), исключением из этого будет случай, когда используется сервер TURN.

Медиа не могут волшебным образом пройти через NAT или брандмауэр, потому что две стороны не имеют прямого доступа друг к другу (как если бы они были в одной локальной сети).

Короче говоря, сервер STUN необходим в большинстве случаев, когда две стороны не находятся в одной сети (для получения допустимых кандидатов на подключение для одноранговой потоковой передачи мультимедиа), а сервер сигнализации является ВСЕГДА необходимы (независимо от того, находятся ли они в разных сетях или нет), чтобы можно было согласовать и установить соединение. Хорошее объяснение процесса подключения и потоковой передачи

STUN используется для реализации протокола ICE, который пытается найти рабочий сетевой путь между двумя клиентами. ICE также будет использовать серверы ретрансляции TURN (если они настроены в RTCPeerConnection) в случаях, когда два клиента (из-за ограничений NAT / брандмауэра) не могут установить прямое одноранговое соединение.

Серверы STUN используются для идентификации внешнего адреса, используемого компьютером в Интернете (адрес вне NAT), и для попытки настроить сопоставление портов, используемое одноранговым узлом (если NAT не является «симметричным») - - обращение к серверу STUN сообщит вам внешний IP-адрес и порт, которые нужно попробовать использовать в ICE. Это кандидаты ICE, включенные в SDP или в сообщения trickle-ICE.

Для почти гарантированного подключения сервер должен иметь серверы TURN (желательно с поддержкой UDP и TCP TURN, хотя UDP предпочтительнее). Обратите внимание, что в отличие от STUN, TURN может использовать значительную пропускную способность, и поэтому размещение может стоить денег. К счастью, большинство подключений удается без использования сервера TURN (т.е. они работают в одноранговой сети).

NAT (преобразование сетевых адресов) используется для преобразования "частного IP", который действителен только в локальной сети, в "общедоступный IP", который действителен в глобальной сети. Проблема в том, что "общедоступный IP" виден только извне, поэтому нам нужен STUN. или сервер TURN, чтобы отправить вам "общедоступный IP-адрес". Этот процесс позволяет одноранговому узлу WebRTC получить общедоступный адрес для себя, а затем передать его другому узлу через механизм сигнализации.

Сервер STUN используется для получения внешнего сетевого адреса. Серверы TURN используются для ретрансляции трафика в случае сбоя прямого (однорангового) соединения. для получения дополнительной информации вы также можете обратиться к ссылке ниже: https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling

В вашем случае вам понадобится STUN. Большинство клиентов будут находиться за NAT, поэтому вам понадобится STUN, чтобы получить общедоступный IP-адрес клиентов. Но если бы оба ваших клиента не находились за NAT, вам не понадобился бы STUN. В общем, нет, STUN-сервер не требуется. Я знаю это, потому что я успешно подключил 2 узла WebRTC без оглушающего сервера. Я использовал пример кода из aiortc, python WebRTC / Библиотека ORTC, в которой оба клиента работали локально на моем ноутбуке. Канал сигнализации использовал мою ручную копипасту. Я буквально скопировал SD (описание сеанса) от одного узла к другому. Затем скопировал SD со 2-го однорангового узла на 1-й еще раз.

Из ICE RFC (RFC8445), который использует WebRTC

Агент ICE ДОЛЖЕН собирать кандидатов, рефлексивных по отношению к серверу и ретранслируемых. Однако использование серверов STUN и TURN может быть ненужным в определенных сетях, а использование серверов TURN может быть дорогостоящим, поэтому некоторые развертывания могут отказаться от их использования.

Неясно, является ли STUN требованием для ICE, но выше сказано, что может быть ненужным.

Однако сигнализация тут ни при чем. На самом деле этот вопрос возникает из-за непонимания того, что делает STUN и как STUN взаимодействует с сигнализацией. Я бы сказал, что остальные 3 ответа на самом деле не отвечают на эти 2 проблемы.

Предварительное условие: ознакомьтесь с основными концепциями NAT. STUN - это инструмент для обхода NAT, поэтому вы должны понимать его.

Сигнализация: вкратце, в WebRTC вам необходимо реализовать свою собственную стратегию сигнализации. Вы можете вручную ввести описание локального сеанса, созданное одним одноранговым узлом на другом узле, использовать WebSockets, socket.io или любые другие методы (я видел шутку о том, что можно использовать дымовые сигналы, но как вы собираетесь передать следующее описание сеанса (также известное как сообщение SDP) через дымовой сигнал ...). Опять же, я скопировал что-то очень похожее на то, что показано ниже:

 v=0
 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
 s=
 c=IN IP4 host.anywhere.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 m=video 51372 RTP/AVP 31
 a=rtpmap:31 H261/90000
 m=video 53000 RTP/AVP 32
 a=rtpmap:32 MPV/90000

Когда оба одноранговых узла не за NAT, вам не нужен STUN-сервер, поскольку IP-адреса указаны в описании сеанса (поле c= выше, известное как данных подключения), сгенерированных каждым одноранговым узлом, будет достаточно, чтобы каждый одноранговый узел отправлял дейтаграммы или пакеты друг другу. В приведенном выше примере они предоставили доменное имя вместо IP-адреса, host.anywhere.com, но это можно преобразовать в запись A. (Изучите DNS для получения дополнительной информации).

Почему в этом случае не нужен STUN-сервер? Из RFC8445:

Есть разные типы кандидатов; некоторые из них получены из физических или логических сетевых интерфейсов, а другие можно обнаружить с помощью STUN и TURN.

Если вы не используете NAT, клиент уже знает IP-адрес, к которому одноранговые узлы могут напрямую обращаться, поэтому дополнительные кандидаты ICE, которые генерирует STUN, не будут полезны (он просто даст вам тот же IP-адрес, о котором вы уже знаете).

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

Он предоставляет конечной точке средство для определения IP-адреса и порта, выделенного NAT, который соответствует ее частному IP-адресу и порту.

STUN в основном позволяет клиенту узнать, какой IP-адрес. Если вы размещали сервер Call of Duty на своем ноутбуке и порт перенаправлял порт на ваш компьютер в настройках маршрутизатора, вам все равно приходилось искать свой общедоступный IP-адрес на веб-сайте, например https://whatismyipaddress.com/. STUN позволяет клиенту делать это самостоятельно, без доступа к браузеру.

Наконец, как STUN взаимодействует с сигнализацией? Кандидаты ICE генерируются локально и с помощью STUN (для получения общедоступных IP-адресов клиентов, когда они находятся за NAT) и даже TURN. Описания сеанса отправляются партнеру по сигнальному каналу. Если вы не используете STUN, вы можете обнаружить, что все кандидаты ICE, сгенерированные ICE, терпят неудачу, и соединение (кроме сигнального канала) не создается.