Видеозвонки через WebRTC: как работают и почему безопаснее Zoom

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

Технология, которая стоит за большинством современных видеозвонков в браузере, называется WebRTC. Именно она позволяет вам звонить без установки приложений, плагинов и прочего софта. Просто браузер — и всё. И именно она делает звонки потенциально безопаснее, чем привычные Zoom или Teams.

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

WebRTC простым языком

WebRTC расшифровывается как Web Real-Time Communication — коммуникация в реальном времени через веб. Это открытый стандарт, который позволяет браузерам обмениваться аудио, видео и данными напрямую, без промежуточных серверов.

Ключевое слово здесь — «напрямую». Когда вы звоните через Zoom, ваше видео сначала уходит на сервер Zoom, там обрабатывается и отправляется собеседнику. Сервер видит ваш поток. Zoom видит ваш поток. WebRTC в базовом варианте работает иначе: ваш браузер устанавливает прямое соединение с браузером собеседника. Peer-to-peer. Без посредников.

Технология появилась в 2011 году как проект Google, а в 2021-м стала официальным стандартом W3C и IETF. Сегодня WebRTC поддерживается в Chrome, Firefox, Safari, Edge и вообще во всём, что имеет веб-движок. На мобильных — тоже. Даже в приложениях, которые не являются браузерами, можно использовать WebRTC через нативные библиотеки.

Что WebRTC умеет из коробки:

• Захват медиа. Доступ к камере и микрофону через стандартный API (getUserMedia).
• Передача медиа. Кодирование, передача и декодирование аудио и видео в реальном времени.
• Передача данных. Произвольные данные через DataChannel — для чата, обмена файлами, совместного рисования.
• NAT traversal. Обход сетевых ограничений — это важно, потому что большинство устройств находятся за NAT и напрямую недоступны.
• Шифрование. Обязательное шифрование всех потоков. Не опциональное, не «можно включить в настройках», а обязательное по спецификации.

Последний пункт стоит подчеркнуть. В WebRTC нельзя передать незашифрованный медиапоток. Это встроено в протокол на уровне архитектуры. У разработчика просто нет возможности отключить шифрование, даже если он захочет. Сравните с решениями, где шифрование — это «галочка в настройках», которую администратор может случайно или намеренно не активировать.

Как работает P2P в браузере

Давайте пройдём по шагам, что происходит, когда вы нажимаете кнопку «Позвонить» в приложении, использующем WebRTC.

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

Прежде чем установить прямое соединение, браузеры должны «познакомиться». Для этого используется сигнальный сервер — он передаёт метаданные между участниками: какие кодеки поддерживаются, какие IP-адреса доступны, параметры шифрования. Сам медиапоток через сигнальный сервер не идёт — только информация о том, как установить соединение.

Протокол сигнализации WebRTC не определяет — можно использовать WebSocket, HTTP, XMPP, хоть почтовых голубей. Это гибкость: каждая платформа выбирает то, что ей подходит.

Шаг 2: ICE (Interactive Connectivity Establishment)

Это самая хитрая часть. Большинство устройств находятся за NAT (Network Address Translation) — домашний роутер, корпоративный файрвол, провайдерский NAT. Устройство знает свой локальный IP (вроде 192.168.1.42), но собеседник не может подключиться к этому адресу напрямую.

ICE решает эту проблему через набор кандидатов:

• Host candidates — локальные адреса устройства.
• Server reflexive candidates — внешний IP, полученный через STUN-сервер (специальный сервер, который говорит: «вот так тебя видят снаружи»).
• Relay candidates — адрес TURN-сервера, который будет ретранслировать трафик, если прямое соединение невозможно.

Браузеры пробуют все варианты и выбирают лучший. В идеальном случае — прямое соединение. Если NAT слишком строгий (симметричный NAT, двойной NAT, корпоративный файрвол) — используется TURN-сервер для ретрансляции. Но даже через TURN трафик остаётся зашифрованным — сервер видит только зашифрованные пакеты.

Шаг 3: DTLS Handshake и SRTP

После установки соединения браузеры выполняют DTLS-рукопожатие (Datagram Transport Layer Security). Это как TLS (тот самый «замочек» в адресной строке), но для UDP. По результатам генерируются ключи для SRTP (Secure Real-time Transport Protocol), которым шифруются аудио- и видеопотоки.

Всё. Соединение установлено. Видео и аудио идут напрямую между браузерами (или через TURN, но всё равно зашифровано end-to-end от DTLS).

Безопасность: SRTP, DTLS и почему Zoom проигрывает

Здесь начинается самое интересное. Давайте сравним подходы к безопасности.

WebRTC: шифрование по умолчанию

В WebRTC шифрование — не опция. Каждый медиапоток защищён SRTP с ключами, сгенерированными через DTLS. Это означает:

• Данные шифруются на устройстве отправителя.
• Расшифровываются только на устройстве получателя.
• Промежуточные серверы (если используется TURN) видят только зашифрованный трафик.
• Отключить шифрование невозможно на уровне протокола.

Zoom: история скандалов

Zoom долго заявлял о «сквозном шифровании», пока в 2020 году не выяснилось, что это не совсем правда. Данные шифровались при передаче (encryption in transit), но расшифровывались на серверах Zoom. Компания имела техническую возможность видеть содержимое звонков. После скандала Zoom добавил реальное E2EE, но с ограничениями: оно работает не во всех режимах и должно быть явно включено.

Кроме того, часть серверов Zoom находилась в Китае, что вызвало вопросы у компаний, работающих с конфиденциальными данными. Для российских компаний, подчиняющихся 152-ФЗ, хранение данных на зарубежных серверах — отдельная головная боль.

Microsoft Teams: шифрование с оговорками

Teams шифрует данные при передаче и при хранении. Но сквозного шифрования звонков в классическом понимании нет — Microsoft имеет технический доступ к расшифровке. Для организаций, которым важен полный контроль, это существенный минус.

Почему self-hosted WebRTC — это другой уровень

Когда вы разворачиваете платформу на основе WebRTC на собственных серверах, ситуация меняется кардинально. Сигнальный сервер — ваш. TURN-сервер — ваш. Данные не покидают вашу инфраструктуру. Никакой третьей стороны, которая теоретически может получить доступ к вашим звонкам.

Именно поэтому компании, работающие с чувствительной информацией — банки, медицина, госсектор, оборонка — всё чаще выбирают self-hosted решения на WebRTC вместо облачных Zoom и Teams. Это не паранойя, а разумная политика безопасности.

Адаптивный битрейт: звонок, который не рвётся

Знакомая ситуация: звонок идёт нормально, потом кто-то из домашних начинает качать фильм — и картинка рассыпается на пиксели, звук начинает заикаться, а через минуту звонок вообще отваливается. С WebRTC такое тоже бывает, но реже. И вот почему.

WebRTC использует механизм адаптивного битрейта. Браузер постоянно мониторит состояние сети: пропускную способность, задержку, потерю пакетов. Если сеть ухудшается, кодировщик автоматически снижает качество видео — уменьшает разрешение, частоту кадров, битрейт. Если сеть восстанавливается — качество растёт обратно.

Это работает через несколько механизмов:

• REMB (Receiver Estimated Maximum Bitrate). Получатель оценивает максимальный битрейт, который он может принять, и сообщает отправителю.
• Transport-CC (Transport-wide Congestion Control). Более современный метод — получатель отправляет подробную обратную связь о каждом пакете, а отправитель сам решает, как адаптировать битрейт.
• Simulcast. Отправитель кодирует видео в нескольких разрешениях одновременно (например, 1080p, 720p, 360p). Сервер или получатель выбирает подходящее.

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

Ещё один важный момент — кодеки. WebRTC поддерживает VP8, VP9, H.264 и AV1 для видео, Opus для аудио. Opus — это вообще золотой стандарт: он адаптивный, работает на битрейтах от 6 до 510 Кбит/с и при этом обеспечивает отличное качество голоса даже на 16 Кбит/с. Для сравнения: телефонный звонок использует около 64 Кбит/с, а Opus на этом битрейте звучит лучше, чем телефон на в два раза большем.

SFU vs MCU: архитектура групповых звонков

P2P отлично работает для звонков один на один. Но что делать, когда в звонке 5, 10, 50 участников? Чистый P2P не масштабируется: каждый участник должен отправлять свой поток каждому другому участнику. При 10 участниках — это 9 исходящих потоков у каждого. Мощная нагрузка на канал и процессор.

Для групповых звонков используются серверные архитектуры:

SFU (Selective Forwarding Unit)

Каждый участник отправляет свой медиапоток на сервер. Сервер перенаправляет каждому участнику потоки остальных. Ключевое: сервер не декодирует и не перекодирует видео. Он просто пересылает зашифрованные пакеты. Это значит, что сервер не видит содержимое звонка — только маршрутизирует трафик.

Плюсы SFU:

• Низкая нагрузка на сервер (не нужно перекодировать).
• Низкая задержка (нет этапа декодирования/кодирования).
• Сохраняется шифрование потоков.
• Хорошо масштабируется (серверу нужен только канал, а не CPU для кодирования).

Минусы SFU:

• Каждый клиент получает N-1 потоков и должен декодировать их все.
• При большом количестве участников — большая нагрузка на клиентское устройство.

MCU (Multipoint Conferencing Unit)

Сервер получает все потоки, декодирует, смешивает в один «картинку» (композицию) и отправляет каждому участнику один объединённый поток. Участник получает только один поток независимо от количества людей в звонке.

Плюсы MCU:

• Минимальная нагрузка на клиент (один поток).
• Работает даже на слабых устройствах.
• Предсказуемая нагрузка на канал клиента.

Минусы MCU:

• Огромная нагрузка на сервер (декодирование + кодирование всех потоков).
• Выше задержка (из-за перекодирования).
• Сервер видит расшифрованное видео — E2EE невозможен.
• Дорого масштабировать.

Что выбирают на практике

Большинство современных платформ используют SFU. Zoom использует модифицированную SFU-архитектуру. Google Meet — SFU. Discord — SFU. Причина простая: SFU даёт лучший баланс между качеством, задержкой и безопасностью.

MCU остаётся актуальным для сценариев, где клиентские устройства совсем слабые (старые телефоны, тонкие клиенты) или когда нужно записывать звонок в одном потоке на сервере. Но для типичного корпоративного сценария — SFU выигрывает.

WebRTC vs Zoom vs Teams: подробное сравнение

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

Несколько комментариев к таблице. По задержке WebRTC выигрывает в P2P-режиме, потому что трафик не делает крюк через облачный сервер на другом континенте. При использовании SFU задержка сопоставима с Zoom, но если SFU-сервер стоит в вашей локальной сети — она будет значительно ниже.

По максимальному количеству участников WebRTC уступает Zoom и Teams. Но давайте честно: сколько у вас звонков на 500+ человек? Для большинства компаний 50–100 человек в звонке — потолок. И WebRTC с хорошей SFU-инфраструктурой это спокойно тянет.

По стоимости WebRTC-решение на своих серверах обходится в стоимость инфраструктуры. Для команды из 100 человек это может быть один-два сервера — несколько тысяч рублей в месяц. Сравните с Zoom по $13–22 за человека: $1 300–2 200 в месяц. Разница — на порядок.

Ограничения WebRTC

Было бы нечестно рассказывать только о плюсах. У WebRTC есть свои ограничения, и о них стоит знать.

NAT и корпоративные файрволы

В корпоративных сетях с жёстким файрволом WebRTC P2P может не работать. Симметричный NAT, заблокированные UDP-порты, DPI (Deep Packet Inspection) — всё это может помешать установить прямое соединение. В таких случаях нужен TURN-сервер. TURN решает проблему, но добавляет задержку и нагрузку на сервер.

Практическое решение: если вы разворачиваете мессенджер на своём сервере, TURN-сервер тоже ставится внутри периметра. Проблема файрвола исчезает — всё в одной сети.

Масштабирование групповых звонков

Для больших конференций (100+ участников) нужна серьёзная SFU-инфраструктура. Один SFU-сервер может обслуживать 50–200 участников в зависимости от мощности. Для больших мероприятий может потребоваться каскадирование SFU-серверов — это нетривиальная задача.

Запись звонков

В P2P-режиме записать звонок на сервере невозможно — данные не проходят через сервер. Для записи нужен либо SFU, который сохраняет потоки, либо клиентская запись (на устройстве участника). Это не баг, а фича безопасности, но для компаний, которым нужна запись звонков для compliance, это ограничение.

Качество на мобильных устройствах

Мобильные браузеры поддерживают WebRTC, но с ограничениями. Safari на iOS долго отставал по функциональности (хотя в 2025–2026 году ситуация заметно улучшилась). Аппаратное ускорение кодирования/декодирования на мобильных — не всегда стабильно. Для лучшего опыта на мобильных лучше использовать нативные приложения с WebRTC-библиотеками.

Нет встроенного signaling

WebRTC не определяет протокол сигнализации. Это гибкость, но и сложность: разработчик должен сам реализовать signaling-сервер, протокол обнаружения участников, управление сессиями. Для конечного пользователя это незаметно, но для разработки — дополнительная работа.

Как b8q реализует WebRTC

В b8q видеозвонки — это не отдельный модуль, прикрученный сбоку. Это часть единого коммуникационного пространства, построенного на WebRTC.

Архитектура

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

Для групповых звонков используется SFU на основе медиасервера. SFU не декодирует потоки — только маршрутизирует зашифрованные пакеты. Это значит, что даже в групповом режиме содержимое звонка недоступно серверу.

Интеграция с чатом

Звонок начинается в один клик из чата. Участники канала видят уведомление и присоединяются одним нажатием. Во время звонка доступен чат — можно отправлять ссылки, файлы, фрагменты кода. После звонка можно создать задачу на канбан-доске или записать решение в документ — всё в том же пространстве.

Адаптивность

b8q использует Simulcast: видео кодируется в трёх разрешениях одновременно. Если у участника слабый канал — SFU автоматически переключает его на поток с меньшим разрешением. Если канал восстанавливается — переключает обратно. Переход бесшовный, без прерываний.

Self-hosted

При установке b8q на собственный сервер все компоненты — signaling, SFU, TURN — разворачиваются в вашей инфраструктуре. Видеопоток не покидает периметр организации. Это полное соответствие 152-ФЗ и любым внутренним политикам безопасности.

Системные требования для SFU-сервера вполне скромные: 4 CPU, 8 ГБ RAM хватает для 50 одновременных участников видеозвонков. Для команд до 200 человек (с учётом того, что не все звонят одновременно) — одного сервера достаточно.

Демонстрация экрана

WebRTC поддерживает Screen Sharing через getDisplayMedia API. В b8q можно шарить экран, отдельное окно или вкладку браузера. Причём демонстрация идёт тоже через WebRTC — с тем же шифрованием и адаптивным битрейтом. Качество автоматически подстраивается: для текста — выше разрешение, ниже FPS; для видео — наоборот.

Заключение

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

Для корпоративного использования WebRTC даёт три ключевых преимущества:

• Безопасность. Шифрование обязательно. При self-hosted развёртывании данные не покидают инфраструктуру.
• Стоимость. Нет помесячной оплаты за пользователя — только стоимость серверов.
• Независимость. Нет зависимости от зарубежного вендора, который может отключить сервис в любой момент.

У технологии есть ограничения — масштабирование, NAT traversal, сложность разработки. Но для команд до 200–300 человек эти ограничения решаются стандартными средствами.

Если для вас важны безопасность видеозвонков, контроль над данными и независимость от зарубежных сервисов — WebRTC-решение на собственных серверах стоит рассмотреть. В b8q это уже реализовано и работает из коробки.