![Рис 1. Одновременная работа в редакторе блок схем с помощью WebRTC Рис 1. Одновременная работа в редакторе блок схем с помощью WebRTC](https://habrastorage.org/getpro/habr/upload_files/0ac/926/6f4/0ac9266f460a3bf629a1f7071ce7ef61.png)
WebRTC позволяет браузерам обмениваться информацией напрямую без сервера. Можно передавать видео, звук и данные.
Для соединения браузеры должны обменяться параметрами соединения: SDP и ICECandidate-ами
SDP описывает требования к соединению - т.е. что будет передаваться: видео/аудио/текст, какие кодеки поддерживаются. ICECandidate-ы это адреса, куда можно посылать пакеты.
Для WebRTC соединения нужно:
Обменяться требованиями к соединению.
Обменяться адресами.
![Рис 2. Установка WebRTC соединения, ICECandidates посылаются отдельно. Открыть схему. Рис 2. Установка WebRTC соединения, ICECandidates посылаются отдельно. Открыть схему.](https://habrastorage.org/getpro/habr/upload_files/ff5/1be/a3f/ff51bea3f05e053c0980c57fbac47e24.png)
Обмен параметрами соединения называется Signaling
Обменяться параметрами можно вручную через мессенджер или сделать сигнальный сервер.
Соединения между браузерами еще нет, но нужно обменяться начальными параметрами - см. Рис 2.
Параметры представлены в виде строк. Их можно отправлять друг другу вручную, например через мессенджер.
Можно автоматизировать. Сделать сигнальный сервер, который будет пересылать параметры между клиентами.
Обмен требованиями к соединению: SDPOffer, SDPAnswer
Требования к соединению зависят от задачи. Например, для видеосвязи браузеры должны выбрать кодек, который оба поддерживают. В браузерах есть API для формирования SDP.
См. Рис 2. “Session descriptors exchange”.
Алиса формирует SDPOffer с указанием поддерживаемых кодеков. Отправляет Бобу.
Боб получает SDPOffer и на его основе формирует SDPAnswer: выбирает кодек который есть у него и в SDPOffer. Нельзя сформировать SDPAnswer без SDPOffer. Боб отправляет SDPAnswer Алисе.
Алиса устанавливает SDPAnswer: для трансляции будет использоваться кодек из SDPAnswer.
Обмен адресами: ICECandidate-ами
ICECandidate-ов может быть несколько. Например, один адрес в локальной сети, другой - во внешней. Чтобы узнать свой адрес нужен STUN сервер.
См. Рис 2. “Address exchange”.
Алиса узнает свои адреса, по которым она может получать пакеты. И отправляет их Бобу. Боб выбирает из полученных адресов-кандидатов.
У Алисы может быть несколько адресов. Например, один адрес в локальной сети, другой - во внешней. Если Боб в той же локальной сети, Алиса и Боб соединятся по локальному адресу.
Браузер не знает свой адрес. Чтобы узнать свой адрес браузер делает запрос к специальному STUN серверу. STUN сервер сообщает браузеру его (браузера) внешний адрес. Есть публичные STUN сервера, например у Google.
Хорошая статья про узнавание своих адресов: Просто о WebRTC.
Можно сразу получить все свои ICECandidate-ы и отправить в составе SDP
В этом случае Боб сразу получает все необходимые параметры для соединения. Но, даже зная все ICECandidate-ы Алисы, не может ответить по WebRTC. Все равно нужно передать SDPAnswer через signaling.
![Рис 3. Установка WebRTC соединения, ICECandidates посылаются в составе SDP Рис 3. Установка WebRTC соединения, ICECandidates посылаются в составе SDP](https://habrastorage.org/getpro/habr/upload_files/d4a/140/a99/d4a140a9997533c502be3a47fe3900ae.png)
Боб не может отправить SDPAnswer по WebRTC. Пока Алиса не установит SDPAnswer - WebRTC не случится. Почему так - не понятно.
Из-за этого ограничения приходится делать сигнальный сервер. Если бы не ограничение, Алиса могла бы отправить Бобу ссылку с зашитыми параметрами. Боб мог бы получить из ссылки все что нужно и сразу установить WebRTC.
Комментарии (8)
SUNsung
19.09.2023 19:14И как всегда промодчали про самую большую проблему поддержки.
И даже если браузер поддерживает - на уровне системы может не дать создать слушатель на порт.
В итоге на уровне js это решается костылем с "мастер сервером" и в 90% весь трафик в итоге и идет через мастер-сервер
Alex_BBB Автор
19.09.2023 19:14даже если браузер поддерживает
Все поддерживают
https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection#browser_compatibility
> в 90% весь трафик в итоге и идет через мастер-сервер
Откуда статистика?SUNsung
19.09.2023 19:14Из жизни.
Как то загорелся создать веб-приложение для обмена внутри локальной сети.
Многие грабли оставили мне след...
В итоге все сделалось "по старинке" на вебсокетах с обрашением на один из мастер-серверов по айпишнику.
А три мастер-сервера синхронизировались между собой при помощи NATS
NutsUnderline
19.09.2023 19:14+3это то самое что настоятельно рекомендуют отключать чтобы не палить свой IP ?
savostin
«Без сервера» , но нужно 2 сервера.
MiraclePtr
Они нужны только для установления соединения, дальше (если повезёт, ага) все работает уже без них
tmv002
Ну как и с SIP, для установления соединения нужен сервер, а далее абоненты могут общаться напрямую (it depends on)
huaw
Топливо нужно только чтобы разогнать ракету, а дальше она летит уже без него.
Факт в том, чтоб без доп серверов никуда, и это огромная проблема.
Причём была инициатива Гугла сделать socket API в браузерах, но воз и ныне, к сожалению. Посчитали, что это будет небезопасно.
Пофиг на эту безопасность, дайте возможность хотя бы тем, кто готов принять риски!