Что такое WebRTC

WebRTC (Web Real-Time Communication) — это технология, которая позволяет передавать звук, видео и данные напрямую между пользователями. Она работает прямо в браузере или уже встроена в мобильные приложения.

Представьте, вы заходите на сайт — и сразу можете:

позвонить другу по видеосвязи,
отправить файл,
поговорить голосом, как в Zoom — но без установки дополнительных программ или плагинов.

Если вы используете браузер, ничего скачивать не нужно — всё работает прямо на сайте.

В мобильных приложениях WebRTC также может применяться для связи в реальном времени — уже на уровне встроенной логики.

Примеры:

Видеозвонки через браузер — например, Google Meet, Discord Web или Яндекс Телемост.
Кнопка «Позвонить консультанту» на сайте (если звонок происходит прямо в браузере, без перехода в телефон или мессенджер).
В онлайн-играх — для передачи голоса или данных между игроками напрямую.
Быстрый файлообмен через браузер, без серверов-посредников.
Интерактивные доски и инструменты для совместной работы в реальном времени.

Ключевые особенности WebRTC:

P2P-связь (peer-to-peer): данные передаются напрямую между клиентами, что снижает задержку и нагрузку на сервер.
Поддержка аудио- и видеосвязи: позволяет реализовать видеозвонки, голосовые чаты, трансляции.
Передача произвольных данных: можно передавать файлы, текст и другую информацию через RTCDataChannel.

Немного подробнее про peer-to-peer

Представьте, что вы звоните другу:

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

В интернете:

Когда вы открываете сайт — вы общаетесь через сервер (он передаёт сообщения между вами).
Когда работает P2P — ваш браузер напрямую соединяется с другим браузером. Без сервера посередине.

Как работает WebRTC:

Чтобы два браузера могли передавать звук, видео или данные напрямую, они проходят три основных этапа:

Обмениваются информацией о себе (Signaling) — чтобы понять, как связаться.
Устанавливают соединение (NAT Traversal) — несмотря на роутеры и фаерволы.
Передают данные напрямую (Media/Data Channels) — по защищённому каналу.

Рассмотрим подробнее каждый этап:

Signaling (сигнализация)

участники обмениваются через сторонний канал (например, WebSocket или HTTP) следующими данными:

SDP-описанием

SDP (Session Description Protocol) — это формат сообщения, в котором участники WebRTC описывают свои параметры связи: какие кодеки поддерживают, как будут передавать звук/видео, на каких портах, и т.д.

ICE-кандидатами

Это возможные пути для соединения: IP-адрес (локальный, внешний или от STUN/TURN-сервера), порт и тип соединения (UDP или TCP). Браузер собирает такие варианты, чтобы выбрать наилучший способ подключения и установить прямую связь.

Важно: канал для сигнализации — это не сама связь между пользователями, а просто технический способ обменяться параметрами. После этого он больше не нужен.

NAT Traversal

Браузеры пробуют соединиться напрямую, несмотря на роутеры, IP-шлюзы и фаерволы.

STUN — помогает браузеру определить его внешний IP-адрес и порт.
TURN — запасной вариант: если напрямую соединиться не удаётся, он пересылает данные между браузерами.

Media/Data Channels

После успешного соединения начинается прямая передача данных между браузерами:

звук
видео
файлы или текстовые сообщения

Канал защищён и зашифрован — никто посторонний не сможет подслушать или вмешаться.

Как WebRTC поддерживает качество связи

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

1. Много ICE-кандидатов → выбирается лучший путь

Когда соединение устанавливается, браузер собирает несколько вариантов путей (ICE-кандидатов), по которым можно связаться с другим участником. Это как список маршрутов, по которым можно доехать до одного и того же места.

Примеры таких путей:

локальный IP-адрес — если оба браузера находятся в одной сети (например, в офисе);
публичный IP через STUN-сервер — чтобы узнать внешний адрес за пределами роутера;
TURN-сервер — используется как последний вариант, если прямой связи не получилось.

Как выбирается лучший путь?

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

2. Мониторинг качества и адаптация (QoS)

Во время звонка WebRTC постоянно следит за качеством связи:

сколько теряется пакетов (переданных данных),
какова задержка передачи,
насколько равномерно приходят пакеты — если задержка «скачет», это называется джиттером.

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

Если WebRTC замечает, что качество ухудшается — он автоматически подстраивается:

снижает разрешение видео (например, с HD до SD),
уменьшает частоту кадров (движения становятся менее плавными),
если совсем плохо — отключает видео и оставляет только звук.

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

Браузер не сохраняет ничего в файл, а использует прямо «на лету» — эти показатели помогают WebRTC внутри выбрать подходящий битрейт, кодек, настройки передачи.

То есть все решения принимаются автоматически и мгновенно, чтобы вы этого даже не заметили.

3. Автопереподключение при обрыве

Если соединение неожиданно прерывается (например, пользователь ушёл из Wi‑Fi в мобильную сеть или сигнал временно пропал), WebRTC не завершает звонок, а:

автоматически обнаруживает потерю связи,
повторно собирает ICE-кандидатов — новые возможные маршруты соединения,
пытается восстановить прямую P2P-связь без участия пользователя.

Переход происходит мягко и незаметно для человека — видео/аудио могут немного подзависнуть, но звонок не «обрывается» и не требует переподключения вручную.

4. Защищённые и надёжные каналы

В WebRTC всё, что передаётся между браузерами, обязательно шифруется — и сигнал, и медиа (аудио/видео), и данные.

Что используется для защиты:

DTLS (Datagram Transport Layer Security) — это протокол шифрования, который защищает сигнальные сообщения (в том числе установку соединения, обмен ключами и управление сессией).

Похож на TLS (тот, что в HTTPS), но адаптирован для передачи по UDP.

SRTP (Secure Real-time Transport Protocol) — протокол, который шифрует само аудио и видео.

Он гарантирует, что никто не сможет «подслушать» или изменить поток во время звонка.

Таким образом, даже если кто-то перехватит трафик — он не сможет его расшифровать или вмешаться в передачу.

5. TURN-сервер как надёжный запасной путь

Иногда браузеры не могут установить прямое P2P-соединение — например, если один из участников сидит за строгим фаерволом или NAT-блоком.

В таких случаях на помощь приходит TURN-сервер (Traversal Using Relays around NAT). Он работает как промежуточная точка: пересылает весь трафик между браузерами через себя, обеспечивая стабильную связь даже в самых сложных сетевых условиях.

Плюсы:

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

Минусы:

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

TURN используется только при необходимости — WebRTC всегда сначала пытается установить прямую связь.

Теперь, когда мы разобрались, как WebRTC устанавливает и поддерживает соединение, давайте посмотрим на техническую сторону.

Для сигнализации чаще всего используется WebSocket или HTTP(S) POST/GET — на этом этапе идёт обмен SDP и ICE-кандидатами.
А вот медиа и данные передаются по UDP-соединениям, напрямую между браузерами, с использованием SRTP и DTLS.
Иногда может использоваться TURN-сервер, если прямое соединение невозможно — тогда поток идёт через него, но всё равно зашифрован.

Как это тестировать?

Можно смотреть статистику WebRTC-сессии через инструменты браузера:

В Chrome: chrome://webrtc-internals

Или через getStats() в JS API.

Тестирование проводится с помощью сниферов (Wireshark, Charles).

Обсудить статью, узнать больше можно в телеграм канале «Тестировщики нужны».