Опыт использования WebRTC. Лекция Яндекса

[nitro2005]

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

= не очень понятно, как все-таки предлагается установить р2р соединение между двумя клиентами за NAT (без ретранслятора). Ну знаете вы их внешние IP-адреса, дальше что? Внешние порты, которые будут назначены при NAT, заранее все равно неизвестны.

[korniltsev]

Внешний назначенный ip + порт stun отправляет обратным пакетом в сторону клиента, в последствии на этот же порт отправляются данные от других клиентов. Выглядит это приблизительно так:
1. клиент отправляет пакет стану c целью «пробить дырку» в нате и узнать свой порт + ip
2. стан получает пакет, и отправляет реальный внешний порт + ip обратно.
3. клиент получает свои пробитые порт + ip (реальные) формирует ice кандидата и отправляет кандидата через сигналинг другому пиру

[nitro2005]

Проблема в том, что этот определенный STUN-ом внешний порт будет действителен только для обмена между клиентом и STUN-сервером. Когда это все пойдет сигнальному серверу или противоположному пиру, внешний порт будет уже другим. Обычно же сейчас в conntrack сессия идентифицируется 4 значениями — src IP+port, dst IP+port…
Более того, в больших NAT-ах и внешний IP также может выдаваться разный, из пула…

[Chupaka]

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

[nitro2005]

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

[ivan386]

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

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

[Hixon10]

Есть группа способов, как обеспечить p2p соединение без транслятора:
1) UPnP и NAT-PMP.
2) en.wikipedia.org/wiki/UDP_hole_punching
3) en.wikipedia.org/wiki/TCP_hole_punching

[grey_rat]

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

[ivan386]

Почему?

[grey_rat]

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

[ivan386]

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

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

[grey_rat]

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

[igordata]

Тут если доработают, то всё равно заблокируют, так как должен быть контроль со стороны спецслужб, а в P2P такого нет.

ой, всё

[apapacy]

Какие способы Вы имеете в виду?

[grey_rat]

Например обычный телефон и/или вайбер.

[BugM]

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

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

[igordata]

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

[cy-ernado]

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

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

[karantir]

Почему у Яндекса еще нет публичных STUN серверов? Все были бы вам благодарны.

[sena]

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

[cy-ernado]

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

[sena]

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

[cy-ernado]

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

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

[sena]

У меня на домашнем сервере, где я хочу это всё водружать, только один IP и только один 443 порт. Другие порты могут быть заблокированы в гостинице/аэропорту.
Конечно, для себя лично я могу настроить vpn, но хотелось бы раздавать сервис и другим знакомым/друзьям без необходимости настраивать vpn.

[aylarov]

Если нет желания разбираться со всей этой низкоуровневой историей, то можно взять Voximplant, а освободившееся время потратить на более полезные вещи — UX-приложения, архитектуру решения и тд.

[BugM]

Проприетарная и платная против свободной бесплатной опенсорсоной.
Что же выбрать. Я даже не знаю…