Comments 3
> WebRTC — это JavaScript API в современных браузерах для видеозвонков.
> А еще для голосовых звонков, шаринга экрана, пробития NAT,
> раскрытия локального адреса и других интересных штук.
Одной из таких интересных штук, если я правильно понимаю, является возможность соединения браузеров между собой. Однако во всех описаниях процесс установки соединения двух браузеров описывается так, что браузерам никак не обойтись без вспомогательных серверов (STUN, а порою даже и TURN), т.к. браузеры находятся внутри NAT (часто симметричного) и этот NAT им приходится «пробивать».
А что, если браузерам настолько сильно повезло, что они находятся внутри одной локальной сети 192.168.0.0/24 и благодаря этому никакие NATы им «пробивать» не требуется?
Как браузеру_А передать браузеру_Б текстовое сообщение «Привет, это браузер_А»?
Предположим, что:
1. В локальной сети находится 192.168.0.0/24 всего 2 хоста: 192.168.0.1 и 192.168.0.2
2. В браузер_А 1-го хоста загружена страница_А и она «знает», что браузер_Б работает на хосте 192.168.0.2. Ну, например, в её JS-коде написано что-то типа var ip_B = '192.168.0.2';
3. В браузер_Б 2-го хоста загружена страница_Б и ожидает подключения от кого угодно, в частности от страницы_А.
А теперь, внимание, вопрос:
Какие действия в javascript станицы_А и какие действия в javascript страницы_Б надо выполнить, чтобы:
1. страница_А отправила в страницу_Б текстовое сообщение «Привет из страницы_А»
2. страница_Б приняла это сообщение и куда-то его отобразила, например в alert(s)
Ну и дополнительно:
Может ли страница_Б в сеансе запроса страницы_А дать ответ странице_А сразу же, пока запросное соединение страницы_А ещё не завершено (по аналогии http-запросов браузеров к веб-серверам)?
Ну и специальные ограничения задачи, чтобы не было попыток страниц установить соединение через дополнительные серверы, а чтобы эти страницы соединялись между собой по настоящему напрямую:
1. Браузеры из сети 192.168.0.0/24 не имеют доступа за пределы этой сети
2. Внутри этой сети не работают ни STUN-серверы, ни TURN, ни ещё какие-либо другие серверы и помощники соединения между браузерами.
> А еще для голосовых звонков, шаринга экрана, пробития NAT,
> раскрытия локального адреса и других интересных штук.
Одной из таких интересных штук, если я правильно понимаю, является возможность соединения браузеров между собой. Однако во всех описаниях процесс установки соединения двух браузеров описывается так, что браузерам никак не обойтись без вспомогательных серверов (STUN, а порою даже и TURN), т.к. браузеры находятся внутри NAT (часто симметричного) и этот NAT им приходится «пробивать».
А что, если браузерам настолько сильно повезло, что они находятся внутри одной локальной сети 192.168.0.0/24 и благодаря этому никакие NATы им «пробивать» не требуется?
Как браузеру_А передать браузеру_Б текстовое сообщение «Привет, это браузер_А»?
Предположим, что:
1. В локальной сети находится 192.168.0.0/24 всего 2 хоста: 192.168.0.1 и 192.168.0.2
2. В браузер_А 1-го хоста загружена страница_А и она «знает», что браузер_Б работает на хосте 192.168.0.2. Ну, например, в её JS-коде написано что-то типа var ip_B = '192.168.0.2';
3. В браузер_Б 2-го хоста загружена страница_Б и ожидает подключения от кого угодно, в частности от страницы_А.
А теперь, внимание, вопрос:
Какие действия в javascript станицы_А и какие действия в javascript страницы_Б надо выполнить, чтобы:
1. страница_А отправила в страницу_Б текстовое сообщение «Привет из страницы_А»
2. страница_Б приняла это сообщение и куда-то его отобразила, например в alert(s)
Ну и дополнительно:
Может ли страница_Б в сеансе запроса страницы_А дать ответ странице_А сразу же, пока запросное соединение страницы_А ещё не завершено (по аналогии http-запросов браузеров к веб-серверам)?
Ну и специальные ограничения задачи, чтобы не было попыток страниц установить соединение через дополнительные серверы, а чтобы эти страницы соединялись между собой по настоящему напрямую:
1. Браузеры из сети 192.168.0.0/24 не имеют доступа за пределы этой сети
2. Внутри этой сети не работают ни STUN-серверы, ни TURN, ни ещё какие-либо другие серверы и помощники соединения между браузерами.
Такой фокус я показывал в Амстердаме на мастер классе по WebRTC, передавая SDP пакеты между двумя Edge через notepad :) К сожалению, многие реализации WebRTC тупо не работают без STUN сервера. Даже если она браузера в локалке и они смогут P2P напрямую.
Не получится. Нужен сигнальный сервер (не STUN и не TURN), который передаст данные между браузеромА и браузеромБ. Одного IP мало — нужно передать ключи аутентификации, порты, ну и так далее.
Сигнальный сервер может быть любым и располагаться где угодно.
Сигнальный сервер может быть любым и располагаться где угодно.
Sign up to leave a comment.
Небольшое расследование: как YouTube использует WebRTC для стриминга