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.