Как стать автором
Обновить

Комментарии 28

> Тогда клиенты будут знать друг о друге с правильными IP-адресами, и смогут установить P2P соединение.

= не очень понятно, как все-таки предлагается установить р2р соединение между двумя клиентами за NAT (без ретранслятора). Ну знаете вы их внешние IP-адреса, дальше что? Внешние порты, которые будут назначены при NAT, заранее все равно неизвестны.
Внешний назначенный ip + порт stun отправляет обратным пакетом в сторону клиента, в последствии на этот же порт отправляются данные от других клиентов. Выглядит это приблизительно так:
1. клиент отправляет пакет стану c целью «пробить дырку» в нате и узнать свой порт + ip
2. стан получает пакет, и отправляет реальный внешний порт + ip обратно.
3. клиент получает свои пробитые порт + ip (реальные) формирует ice кандидата и отправляет кандидата через сигналинг другому пиру
Проблема в том, что этот определенный STUN-ом внешний порт будет действителен только для обмена между клиентом и STUN-сервером. Когда это все пойдет сигнальному серверу или противоположному пиру, внешний порт будет уже другим. Обычно же сейчас в conntrack сессия идентифицируется 4 значениями — src IP+port, dst IP+port…
Более того, в больших NAT-ах и внешний IP также может выдаваться разный, из пула…

Если говорить о Linux — то да, нужны будут дополнительные костыли. Во всяких Cisco включается Full Cone NAT — и пакеты уже с любого IP на ваш внешний IP:Port (в варианте Port-Restricted) либо просто IP пробрасываются вам внутрь.

Понятно, спасибо! Т.е. как ни крути нужен определенный более мягкий тип NAT…

Не знаю какой у моего провайдера NAT но похоже что для всех UDP пакетов с одного порта он выдаёт один и тот-же внешний порт вне зависимости от адреса назначения. Более того. Это тот же порт который я задал в клиенте.


Попробовал сменить порт на более популярный. Результат тот же.

НЛО прилетело и опубликовало эту надпись здесь
Это больше для организаций чем для обычных пользователей. А у юр.лица, как правило, есть статический IP. Обычный юзер заинтересован весь этот WebRTC выпилить из своего браузера.

Почему?

Потому что есть более удобные способы.

С просмотром видео из интернета в браузере тоже раньше были проблемы но доработали и теперь это удобней скачивания или просмотра в отдельном плеере.


Думаю и эту технологию доработают до уровня когда ей приятно будет пользоваться.

Тут если доработают, то всё равно заблокируют, так как должен быть контроль со стороны спецслужб, а в P2P такого нет. Приятно ей будет пользоваться, когда она станет доступна и в оффлайн режиме (когда один из собеседников случайно выйдет и передаваемая инфа сохранится на стороннем сервере), а это уже участие третьей стороны.
А видео из торрентов или DC в браузере так же можно было бы пускать, если б сделали, например с начала воспроизведения последовательно шла загрузка с сервера или самого быстрого пира (с выделением P2P-клиентом определённой полосы пропускания, что бы просмотр не опережал загрузку), а с конца записи и в начало с P2P пиров. После встречи этих двух кусков, просмотр переключался на загруженное с P2P.
Тут если доработают, то всё равно заблокируют, так как должен быть контроль со стороны спецслужб, а в P2P такого нет.
ой, всё
Какие способы Вы имеете в виду?
Например обычный телефон и/или вайбер.

А где опыт использования? В заголовке обещали.


Обычное описание webrtc, которое есть на миллионе других сайтов. И при том не самое лучшее. Вот нафига оно нужно?

НЛО прилетело и опубликовало эту надпись здесь
Leono А Яндекс сейчас использует WebRTC где-то или пока только эксперименты?

Тоже хочу поделиться своей имплементацией STUN, но уже на go:
gortc/stun (сам протокол, клиент с поддержкой RTO, хорошо покрыт тестами, включая end-to-end и fuzzing), gortc/turn (уже для TURN, влючая ChannelData), ну и собствено сервер: gortc/gortcd (поддержка STUN, TURN, e2e тесты через relayed webrtc).


А еще есть парсер RFC 4566 SDP.

Почему у Яндекса еще нет публичных STUN серверов? Все были бы вам благодарны.
Но это же всё будет работать только дома или на своей симке, верно? В гостинице или аэропорту придётся опять доставать скайп, потому что в местной беспроводной сети все порты кроме 80 и 443 будут закрыты?

Если TURN сервер будет на 443 порту и работать через TCP/TLS (на случай блока UDP), то должен подойти в качестве релея в таком случае.

О! Это уже интересно. Если теперь научить HAProxy узнавать протокол TURN сервера (как протокол называется?), то может выйти что-то толковое!

Можно просто отдельный TURN сервер поставить, не обязательно же мультиплексировать на 443 порту.


Узнавать нужно будет STUN и TURN ChannelData.

У меня на домашнем сервере, где я хочу это всё водружать, только один IP и только один 443 порт. Другие порты могут быть заблокированы в гостинице/аэропорту.
Конечно, для себя лично я могу настроить vpn, но хотелось бы раздавать сервис и другим знакомым/друзьям без необходимости настраивать vpn.
Если нет желания разбираться со всей этой низкоуровневой историей, то можно взять Voximplant, а освободившееся время потратить на более полезные вещи — UX-приложения, архитектуру решения и тд.
Проприетарная и платная против свободной бесплатной опенсорсоной.
Что же выбрать. Я даже не знаю…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий