В аудио- и видеосвязи через Интернет нет ничего нового. Skype был одним из первых инструментов, сделавших его доступным еще в 2003 году, и вскоре такие видеочаты стали доступны прямо из браузера. WebRTC - относительно новая технология, обеспечивающая простую и безопасную видеосвязь в браузере. Так что же это такое, как это работает и почему революционизирует видеосвязь?

WebRTC - это набор протоколов, стандартов и API-интерфейсов JavaScript. В то время как большинство решений для видеосвязи полагаются на проприетарное программное обеспечение или, в лучшем случае, подключаемые модули для браузера, WebRTC позволяет осуществлять такой обмен напрямую и исключительно через браузер. Это означает, что вы получаете ссылку, нажимаете на нее и, не скачивая ничего, можете начать видеозвонок онлайн.

Я сказал, что WebRTC новый, но на самом деле ему почти 10 лет. Впервые он был выпущен в 2011 году, но, как всегда для крупных веб-стандартов, потребовалось некоторое время, чтобы внедрить его во все основные браузеры. Safari начал поддерживать его только в 2017 году, и хотя Firefox и Chrome поддерживали его дольше, различия в их реализации сделали некоторые функции непригодными для использования в разных браузерах. Но теперь он надежно работает даже в браузерах, по крайней мере, в основных, и на мобильных устройствах.

Аудио и видео движки

Первым вызовом для такого проекта была работа с видео- и аудиопотоками. Это то, над чем работала компания под названием Global IP Solutions, когда они были куплены Google в 2010 году. Чтобы видеоконференция была возможна между браузерами, браузеры сначала должны получить доступ к оборудованию пользователя. После получения видео- и аудиопотоков от оборудования браузеры должны кодировать их, улучшать (например, устранять шум), обрабатывать их качество и отправлять их по сети с изменением битрейта и пропускной способности.

При получении потока браузер должен декодировать его и отображать для пользователя с приемлемым качеством, даже если условия в сети могут быть плохими, а пакеты могут быть задержаны или потеряны. Для его работы были разработаны протоколы и стандарты, и теперь браузеры берут на себя всю эту работу. При реализации инструмента через WebRTC разработчик имеет доступный JavaScript API MediaStream, из которого он просто может получить уже улучшенный и закодированный поток.

Установите соединение между браузерами

Сигнализация

Следующая задача заключалась в том, чтобы на самом деле разрешить соединения между браузерами. Для установления соединения между клиентами необходимо обмениваться информацией трех типов:

  • Медиа-данные: каким типом мультимедиа вы хотите поделиться (только аудио или видео), с какими ограничениями (например, качество).
  • Данные управления сеансом: открыть и закрыть сообщение.
  • Сетевые данные: пользователям необходимо получить IP-адреса и порты друг друга и проверить, могут ли они установить одноранговое соединение.

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

Конкретно, допустим, вы хотите установить соединение WebRTC между Бобом и Алисой. Боб и Алиса зарегистрированы на вашем веб-сайте и нажимают кнопку, чтобы начать видеочат. Им обоим сначала необходимо установить соединение с сервером websocket. Затем Боб запрашивает аудио- и видеопотоки из MediaStream API, создает предложение WebRTC и отправляет его Алисе через среду передачи сигналов, в данном примере сервер веб-сокета. Такое предложение представляет собой строку, содержащую информацию о медиа-данных. Алиса получает это предложение, запрашивает свои аудио- и видеопотоки, создает ответ и отправляет его Бобу.

Алиса и Боб обменялись медиаданными и уведомили друг друга о том, что они хотят начать видеочат. Но здесь возникает следующая проблема: нам нужно прямое одноранговое соединение, а не соединение через сервер websocket. Как установить такую ​​связь?

ЛЕД

Интернет состоит из компьютеров, которые обмениваются данными по сети. Соединить два компьютера вместе - не такая уж большая проблема. Дело в том, что вы обычно подключаете клиента к серверу. Сервер имеет хорошо известный IP-адрес, а клиент (компьютер, запрашивающий веб-сайт) точно знает, куда отправлять свои запросы. Однако при подключении двух клиентов они сначала должны найти IP-адреса друг друга, и это сложнее, чем кажется.

Из-за исторического отсутствия IP-адресов (только около 4 миллиардов адресов было доступно с IPv4), пользователи группируются под одним общедоступным адресом, за маршрутизатором, транслирующим адреса в проходящих через него пакетах. Этот процесс называется преобразованием сетевых адресов (NAT). Существуют разные типы NAT, но некоторые из них выделяют публичный IP-адрес и порт для UDP-потоков (что нам нужно). WebRTC использует структуру ICE (Interactive Connectivity Establishment) для обнаружения и передачи общедоступного IP-адреса пользователя своему партнеру.

ICE делает это с помощью сервера STUN (Session Traversal Utilities for NAT). Такой сервер ничего особенного не делает, вы просто отправляете ему запросы. Если вы находитесь за NAT, запрос пройдет через него, и NAT установит для него свой публичный адрес и порт. Сервер STUN получает этот запрос и возвращает его вам, теперь у вас есть публичный адрес и порт NAT. В лучшем случае этого достаточно. Вы сообщаете этот адрес своему партнеру, он отправляет вам свой адрес, и вы устанавливаете одноранговое соединение.

Но не все NAT позволяют установить одноранговое соединение. Некоторые назначают общедоступный IP-адрес и порт каждому внешнему источнику. Это означает, что публичный адрес и порт, которые были выделены для сообщений от сервера TURN, не будут работать для однорангового узла, с которым вы пытаетесь установить соединение. В таких случаях вам нужно другое решение: обмен данными должен проходить через сервер TURN. TURN расшифровывается как Traversal Using Relays around NAT. Как следует из названия, соединение будет проходить через сервер ретрансляции и технически больше не является одноранговым соединением.

Хорошая новость в том, что вам не нужно заботиться об этом самостоятельно. Агент ICE позаботится об этом исследовании и принятии решений за вас, проверяет возможность прямого подключения и, если это невозможно, устанавливает подключение через сервер TURN. Агент ICE предлагает кандидатов, единственное, что вам нужно сделать, это отправить этих кандидатов по сигнальной среде. После выбора лучшего кандидата устанавливается соединение WebRTC, и пользователи могут начать свой видеозвонок.

Это все, что нужно знать, чтобы понять основы WebRTC. Если вы хотите узнать больше о NAT, ICE, STUN и TURN, прочтите эту статью. В нем более подробно рассказывается и на примерах кода JavaScript показано, как это обрабатывается в приложении, использующем WebRTC.

Чтобы создать свой собственный видеочат с использованием WebRTC, вы можете прочитать эту серию статей:

Каждый шаг довольно подробный. Я работаю над более кратким руководством, показывающим, как установить соединение WebRTC (шаги 1, 2 и 3) в нескольких строках кода. статья выйдет в ближайшее время, вы можете дождаться ее, если хотите быстро погрузиться в реализацию собственного видеочата через WebRTC.