WebRTC: что это, архитектура и принцип работы

Что такое WebRTC

WebRTC (Web Real-Time Communication) — это проект с открытым исходным кодом, инициированный Google в 2011 году и стандартизированный W3C (JavaScript API) и IETF (протоколы). Основная задача — обеспечить низколатентную связь между браузерами и приложениями без установки плагинов или стороннего ПО.

В отличие от традиционных решений (RTMP, HLS), где видео проходит через сервер, WebRTC использует peer-to-peer архитектуру: данные передаются напрямую между участниками. Это даёт задержку 200-500 мс против 3-10 секунд у HLS — разница, критичная для голосовых и видеозвонков, стриминга игр и удалённой хирургии.

По данным Google WebRTC Team (2025), технология используется в приложениях с общей аудиторией более 5 миллиардов установок: Google Meet, WhatsApp, Discord, Telegram, Zoom (частично). Более 85% венчурных стартапов в сфере telehealth и edtech выбирают WebRTC как базовый транспорт реального времени.

Мобильная разработка получила полноценный WebRTC в 2013 году с выходом libjingle_peerconnection — нативной реализации для Android и iOS. Сейчас обе платформы имеют стабильные SDK с поддержкой аппаратного кодирования H.264 и VP8, камеры, микрофона и динамиков устройства.

Архитектура и протоколы WebRTC

Архитектура WebRTC состоит из трёх уровней. Верхний уровень — JavaScript API (или нативный API для мобильных платформ), средний — транспортные протоколы, нижний — кодеки и безопасность. Каждый уровень решает свою задачу, но все они обязательны для установки соединения.

Основные API WebRTC

MediaStream (getUserMedia) — захват аудио и видео с микрофона и камеры устройства. RTCPeerConnection — управление P2P соединением: кодирование, транспорт, адаптация битрейта. RTCDataChannel — передача произвольных данных (текст, файлы, бинарные сообщения) по тому же каналу.

// JavaScript API WebRTC (браузерный пример)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Протоколы реального времени

WebRTC использует SRTP (Secure Real-Time Transport Protocol) для аудио и видео — защищённая версия RTP с шифрованием AES-128. Управление сессией идёт по SCTP (Stream Control Transmission Protocol) через DTLS. Каждый поток данных шифруется обязательно: в WebRTC нет незащищённого режима.

• SRTP/SRTCP — шифрованная передача медиа-потоков с защитой от повторного воспроизведения (replay attack)
• DTLS-SRTP — установка ключей шифрования через Datagram TLS поверх UDP
• SCTP — надёжная или частично надёжная доставка данных для DataChannel
• ICE (Interactive Connectivity Establishment) — фреймворк для поиска сетевого пути между пирами
• Trickle ICE — инкрементальная версия ICE, где кандидаты отправляются по мере обнаружения, ускоряя установку соединения

NAT traversal: ICE, STUN и TURN

Главная техническая сложность WebRTC — установка P2P-соединения между устройствами, которые находятся за NAT (Network Address Translation). Без специальных механизмов устройства не могут напрямую обратиться друг к другу, потому что их локальные IP-адреса не видны из интернета.

STUN — определение публичного адреса

STUN (Session Traversal Utilities for NAT) — сервер, который отвечает на вопрос "какой мой публичный IP и порт?". Клиент отправляет запрос на STUN-сервер, сервер видит его публичный адрес и возвращает его клиенту. Google публично поддерживает STUN-сервер stun:stun.l.google.com:19302.

// WebRTC на iOS — настройка ICE серверов
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — релейное соединение

TURN (Traversal Using Relays around NAT) — сервер-ретранслятор для случаев, когда STUN не помогает (симметричный NAT или корпоративные файрволы). В этом режиме все данные проходят через TURN-сервер — это снижает скорость и увеличивает задержку, но гарантирует соединение в 99% случаев.

TURN — самый дорогой компонент инфраструктуры WebRTC, так как сервер пропускает через себя весь медиа-трафик. По данным Coturn Project (2025), типовой TURN-сервер на 8 vCPU и 16 ГБ RAM обрабатывает около 200 одновременных аудио-звонков или 40 видеозвонков в HD-качестве.

Процесс ICE

ICE собирает все возможные кандидаты (локальный IP, публичный IP через STUN, релейный через TURN) и пытается установить соединение в порядке приоритета. Как только хотя бы одна пара кандидатов (локальный-удалённый) проходит проверку connectivity check, соединение считается установленным.

• Host candidates — локальный IP адрес устройства в подсети (самый быстрый, но не работает за NAT)
• Server Reflexive candidates — публичный IP, полученный через STUN сервер
• Relay candidates — адрес TURN-сервера, через который идёт ретрансляция (самый медленный, самый надёжный)

WebRTC в мобильных приложениях

Для мобильной разработки Google поддерживает libWebRTC — нативную библиотеку для Android (AAR) и iOS (XCFramework). Библиотека включает весь стек протоколов, кодеки (VP8, VP9, H.264, AV1) и аппаратное ускорение кодирования/декодирования.

WebRTC на Android

Android SDK предоставляет классы PeerConnectionFactory, PeerConnection, MediaStream. Приложение создаёт фабрику, настраивает видео-кодеки, захватывает поток с камеры через VideoCapturer и устанавливает пиринг через SDP offer/answer.

// Android WebRTC — инициализация
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC на iOS

iOS SDK использует Objective-C API с обёртками RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Аппаратное кодирование H.264 доступно через VideoToolbox. Для отображения видео используется RTCMTLVideoView (Metal) или RTCVideoRenderer.

// iOS WebRTC — захват видео с камеры
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Выбор камеры (передняя/задняя)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Запуск захвата с максимальным FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Для видеозвонков в production мобильные приложения обычно используют SDK-обёртки над libWebRTC: Twilio Video, Agora, Daily.co. Эти SDK упрощают сигнализацию, управление комнатами и предоставляют готовые UI-компоненты для отображения видео-сетки участников.

Сигнализация и установка соединения

WebRTC не специфицирует протокол сигнализации — обмен SDP (Session Description Protocol) сообщениями между пирами. Разработчик сам выбирает транспорт для сигнализации: WebSocket, MQTT, SIP, XMPP или REST API. Сигнализация доставляет offer, answer и ICE-кандидаты от одного пира к другому.

SDP обмен Offer/Answer

Процесс начинается с создания offer (инициатор описывает свои медиа-возможности), передаётся через сигнализацию второму пиру, который отвечает answer. После обмена SDP каждый пир устанавливает ICE и запускает DTLS-SRTP для шифрования потока.

// Android — создание и отправка offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Отправка sdp.description на сигналинг-сервер
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Протоколы сигнализации

Для мобильных приложений наиболее популярна сигнализация через WebSocket — двунаправленный канал поверх TCP, который держит постоянное соединение с сервером. Сервер сигнализации — часто отдельный микросервис (Node.js, Golang, Elixir), который маршрутизирует сообщения между участниками комнаты.

• WebSocket — постоянное двунаправленное соединение, минимальный overhead, стандартный выбор для сигнализации
• SIP over WebSocket — стандартный протокол VoIP, интегрируется с существующей телефонной инфраструктурой
• MQTT — лёгкий pub/sub протокол для IoT и слабых сетей, но с большей задержкой
• Matrix / XMPP — децентрализованные протоколы для приложений с требованием приватности

После завершения ICE и DTLS-SRTP сигнализация больше не участвует в передаче данных — весь медиа-трафик идёт напрямую P2P (или через TURN-релей). Сервер сигнализации может быть выключен, не прерывая активные звонки. Это ключевое преимущество децентрализованной архитектуры WebRTC.