Совсем недавно к нам поступил запрос на разработку приложения для онлайн школы фитнеса и главная функция это трансляция тренировки учителем на неограниченное количество участников, я сразу вспомнил о технологии WebRTC которая замечательно справляется с этой задачей.
Подробнее про WebRTC вы можете почитать по этой ссылке https://webrtc.org/?hl=ru&ref=vc.ru
Я же сейчас расскажу только в общих чертах как устроена технология, данная технология позволяет соединить два браузера между собой для общения в реальном времени, представьте что у нас есть 2 пользователя Петя и Вася, Петя хочет позвонить Васе и поговорить с ним по видеосвязи, а так же хочет иметь возможность передавать во время встречи текстовые сообщения и файлы, все это позволяет реализовать WebRTC
Есть 3 варианта конфигурации такого приложения: использование STUN серверов, использование TURN серверов и использование обоих, для этого в объекте RTCPeerConnection предусмотрено свойство iceTransportPolicy которое способно принимать 2 значения: all (STUN + TURN) и relay (только TURN)
Зачем нужны STUN и TURN сервера? STUN сервер позволяет Пете узнать IP Васи, а Васе узнать IP Пети, и если их устройства не находятся за NAT, то в таком случае их браузеры успешно увидят друг друга и смогут договориться об открытии коннекшена (идеально когда они оба находятся в одной сети) , но в реальности наши устройства не имеют статичных IP и зачастую находятся за NAT и одним STUN сервером здесь не обойтись.
TURN сервер имеет статичный IP адрес, Петя и Вася подключаются к нему и TURN сервер успешно выполняет функцию ретранслятора пакетов данных, Петя и Вася могут общаться друг с другом находясь за NAT, главное чтобы они видели TURN сервер.
Мы на пальцах разобрали то, как устроены STUN и TURN сервера, но только ими здесь не обойтись, нам нужен еще сигнальный сервер, это тот, кто поможет Пете передать предложение (Offer) Васе, а Васе передать ответ (Answer) Пете, только после этого обмена их браузеры смогут наладить соединение и начать передачу данных. Но что если к ним захочет присоединиться Толя (это уже видеоконференция, many-to-many, когда все трое будут видеть друг друга) , Толя должен попросить сигнальный сервер сообщить Пете и Васе, чтобы те выслали предложение (Offer) Толе, а Толя в свою очередь должен передать Пете и Васе ответ (Answer) , так все трое смогут общаться друг с другом в режиме реального времени.
Важный момент, когда Петя формирует Offer он должен дождаться пока свойство соединения signalingState будет равно have-local-offer и iceGatheringState будет равно complete, только тогда он может выслать Offer Васе, а Вася в свою очередь должен передать Answer только тогда когда его соединение получить статус iceGatheringState равный complete
Для демонстрации того, что мы способны реализовать задачу мы за неделю сделали простой прототип который вы можете посмотреть тут https://call.opensoft.asia это абсолютно рабочее приложение для проведения видеоконференций, которое мы показали заказчику и после успешно заключили договор на внедрение этой технологии в его приложение.
Вывод
Подводя итоги, хотел бы сказать что эта технология дает безграничные возможности по разработке приложений для общения, обучения и проведения каких либо мероприятий, помимо этого существуют библиотеки позволяющие соединять браузер с сервером по WebRTC (ссылка ниже) и передавать данные туда в реальном времени, на базе этой технологии можно строить мессенджеры или чаты поддержки на сайтах, возможности просто безграничны!
