WebRTC: звонки и обмен данными прямо в браузере

WebRTC, Web Real-Time Communication, — набор возможностей браузера, который позволяет передавать звук, видео и произвольные данные напрямую между участниками. Именно он стоит за многими видеовстречами в браузере, голосовыми чатами на сайтах и сервисами, где файл передаётся из одного окна в другое без загрузки на сервер. Разработчику доступно три основных объекта: захват камеры и микрофона, само соединение между узлами и канал данных.

Важно, что сервер в схеме не исчезает совсем. Он нужен для знакомства сторон, а иногда и для пересылки трафика. Но основной поток при возможности идёт напрямую, что уменьшает задержку и нагрузку на инфраструктуру сервиса.

До того как соединение заработает, браузеры должны обменяться сведениями друг о друге: какие кодеки поддерживаются, какие сетевые адреса можно использовать, какими ключами шифровать. Стандарт WebRTC намеренно не определяет способ этой передачи, её называют сигнализацией, и каждый сервис реализует её по-своему, чаще всего через WebSocket. Описание сеанса оформляется в формате SDP.

После обмена описаниями стороны переходят к самому трудному этапу: найти работающий сетевой путь. Оба участника, как правило, находятся за NAT, у них частные адреса, и напрямую достучаться друг до друга нельзя.

Эту задачу решает механизм ICE. Каждый браузер собирает список адресов-кандидатов: собственные локальные, внешний адрес, который сообщает сервер STUN, и адрес ретранслятора. Затем стороны пробуют пары кандидатов по очереди и выбирают лучшую работающую. Сервер STUN лёгок: он просто отвечает, с какого адреса и порта пришёл запрос, помогая узнать, как вас видят снаружи.

Если прямой путь невозможен, например при строгом NAT или в корпоративной сети, трафик направляется через сервер TURN. Это ретранслятор: он принимает поток от одного участника и передаёт другому. Он надёжнее, но добавляет задержку и стоит сервису денег, поэтому его используют в последнюю очередь. Подробнее про трансляцию адресов написано на странице про NAT.

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

Шифрование в WebRTC обязательно и не отключается. Ключи согласуются рукопожатием DTLS, это вариант TLS для датаграмм, а аудио и видео затем защищаются протоколом SRTP, о чём сказано на странице про RTP. Каналы данных шифруются тем же DTLS. Поэтому даже если трафик идёт через ретранслятор, сервер TURN содержимого не видит.

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

Часто считают, что WebRTC работает только между двумя людьми. Групповые конференции строят через медиасервер, который принимает потоки от всех и раздаёт их участникам, потому что прямая сеть из десятков участников слишком нагружает каждого. Второе допущение: он вызывает утечку личных данных сам по себе. Риск связан с раскрытием адресов, а не с устройством протокола, и им управляют настройками браузера.

Статистику своего звонка легко увидеть. В браузерах на основе Chromium откройте страницу chrome://webrtc-internals в соседней вкладке во время встречи: там отображаются выбранные кандидаты, число потерянных пакетов, джиттер и битрейт. В Firefox аналогичная страница называется about:webrtc.

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