WebRTC: co to jest, architektura i zasada działania

Co to jest WebRTC

WebRTC (Web Real-Time Communication) — to projekt o otwartym kodzie źródłowym, zainicjowany przez Google w 2011 roku i standaryzowany przez W3C (JavaScript API) oraz IETF (protokoły). Głównym zadaniem jest zapewnienie niskolatencyjnej komunikacji między przeglądarkami i aplikacjami bez instalowania wtyczek lub dodatkowego oprogramowania.

W przeciwieństwie do tradycyjnych rozwiązań (RTMP, HLS), gdzie wideo przechodzi przez serwer, WebRTC wykorzystuje architekturę peer-to-peer: dane są przesyłane bezpośrednio między uczestnikami. Zapewnia to opóźnienie 200-500 ms wobec 3-10 sekund u HLS — różnica krytyczna dla połączeń głosowych i wideo, streamingu gier i zdalnej chirurgii.

Według Google WebRTC Team (2025), technologia jest używana w aplikacjach z łączną liczbą ponad 5 miliardów instalacji: Google Meet, WhatsApp, Discord, Telegram, Zoom (częściowo). Ponad 85% startupów venture capital w obszarach telehealth i edtech wybiera WebRTC jako podstawowy transport czasu rzeczywistego.

Rozwój mobilny otrzymał w pełni funkcjonalny WebRTC w 2013 roku wraz z wydaniem libjingle_peerconnection — natywnej implementacji dla Android i iOS. Obecnie obie platformy mają stabilne SDK z obsługą sprzętowego kodowania H.264 i VP8, kamery, mikrofonu i głośników urządzenia.

Architektura i protokoły WebRTC

Architektura WebRTC składa się z trzech poziomów. Górny poziom to JavaScript API (lub natywne API dla platform mobilnych), środkowy — protokoły transportowe, dolny — kodeki i bezpieczeństwo. Każdy poziom rozwiązuje swoje zadanie, ale wszystkie są niezbędne do nawiązania połączenia.

Główne API WebRTC

MediaStream (getUserMedia) — przechwytywanie audio i wideo z mikrofonu i kamery urządzenia. RTCPeerConnection — zarządzanie połączeniem P2P: kodowanie, transport, adaptacja przepływności. RTCDataChannel — przesyłanie dowolnych danych (tekst, pliki, komunikaty binarne) tym samym kanałem.

// JavaScript API WebRTC (przykład przeglądarkowy)
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);

Protokoły czasu rzeczywistego

WebRTC wykorzystuje SRTP (Secure Real-Time Transport Protocol) dla audio i wideo — zabezpieczoną wersję RTP z szyfrowaniem AES-128. Zarządzanie sesją odbywa się przez SCTP (Stream Control Transmission Protocol) przez DTLS. Każdy strumień danych jest obowiązkowo szyfrowany: w WebRTC nie ma niezabezpieczonego trybu.

• SRTP/SRTCP — szyfrowana transmisja strumieni medialnych z ochroną przed atakami replay
• DTLS-SRTP — ustanawianie kluczy szyfrowania przez Datagram TLS przez UDP
• SCTP — niezawodne lub częściowo niezawodne dostarczanie danych dla DataChannel
• ICE (Interactive Connectivity Establishment) — framework do znajdowania ścieżki sieciowej między peerami
• Trickle ICE — inkrementalna wersja ICE, gdzie kandydaci są wysyłani w miarę ich wykrywania, przyspieszając nawiązywanie połączenia

NAT traversal: ICE, STUN i TURN

Główną trudnością techniczną WebRTC jest nawiązanie połączenia P2P między urządzeniami znajdującymi się za NAT (Network Address Translation). Bez specjalnych mechanizmów urządzenia nie mogą bezpośrednio się do siebie zwrócić, ponieważ ich lokalne adresy IP nie są widoczne z Internetu.

STUN — określanie publicznego adresu

STUN (Session Traversal Utilities for NAT) — serwer, który odpowiada na pytanie „jaki jest mój publiczny IP i port?”. Klient wysyła zapytanie do serwera STUN, serwer widzi jego publiczny adres i zwraca go klientowi. Google publicznie utrzymuje serwer STUN stun:stun.l.google.com:19302.

// WebRTC na iOS — konfiguracja serwerów 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 — połączenie przekaźnikowe

TURN (Traversal Using Relays around NAT) — serwer retransmisyjny dla przypadków, gdy STUN nie pomaga (symetryczny NAT lub firmowe firewalle). W tym trybie wszystkie dane przechodzą przez serwer TURN — zmniejsza to prędkość i zwiększa opóźnienie, ale gwarantuje połączenie w 99% przypadków.

TURN — najdroższy komponent infrastruktury WebRTC, ponieważ serwer przepuszcza przez siebie cały ruch medialny. Według Coturn Project (2025), typowy serwer TURN na 8 vCPU i 16 GB RAM obsługuje około 200 jednoczesnych połączeń audio lub 40 połączeń wideo w jakości HD.

Proces ICE

ICE zbiera wszystkie możliwe kandydatury (lokalny IP, publiczny IP przez STUN, przekaźnikowy przez TURN) i próbuje nawiązać połączenie według priorytetu. Gdy tylko choć jedna para kandydatów (lokalny-zdalny) przejdzie test łączności connectivity check, połączenie uważa się za nawiązane.

• Host candidates — lokalny adres IP urządzenia w podsieci (najszybszy, ale nie działa za NAT)
• Server Reflexive candidates — publiczny IP uzyskany przez serwer STUN
• Relay candidates — adres serwera TURN, przez który odbywa się retransmisja (najwolniejszy, najbardziej niezawodny)

WebRTC w aplikacjach mobilnych

Do rozwoju mobilnego Google utrzymuje libWebRTC — natywną bibliotekę dla Android (AAR) i iOS (XCFramework). Biblioteka zawiera cały stos protokołów, kodeki (VP8, VP9, H.264, AV1) oraz sprzętowe przyspieszenie kodowania/dekodowania.

WebRTC na Androidzie

Android SDK udostępnia klasy PeerConnectionFactory, PeerConnection, MediaStream. Aplikacja tworzy fabrykę, konfiguruje kodeki wideo, przechwytuje strumień z kamery przez VideoCapturer i nawiązuje połączenie peer-to-peer przez SDP offer/answer.

// Android WebRTC — inicjalizacja
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 na iOS

iOS SDK wykorzystuje Objective-C API z wrapperami RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Sprzętowe kodowanie H.264 jest dostępne przez VideoToolbox. Do wyświetlania wideo używany jest RTCMTLVideoView (Metal) lub RTCVideoRenderer.

// iOS WebRTC — przechwytywanie wideo z kamery
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Wybór kamery (przód/tył)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Uruchomienie przechwytywania z maksymalnym FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

W przypadku połączeń wideo w produkcji aplikacje mobilne zwykle korzystają z nakładek SDK na libWebRTC: Twilio Video, Agora, Daily.co. SDK te upraszczają sygnalizację, zarządzanie pokojami i udostępniają gotowe komponenty UI do wyświetlania siatki wideo uczestników.

Sygnalizacja i nawiązywanie połączenia

WebRTC nie specyfikuje protokołu sygnalizacji — wymiany wiadomości SDP (Session Description Protocol) między peerami. Deweloper sam wybiera transport do sygnalizacji: WebSocket, MQTT, SIP, XMPP lub REST API. Sygnalizacja dostarcza offer, answer i kandydatów ICE od jednego peera do drugiego.

Wymiana SDP Offer/Answer

Proces rozpoczyna się od utworzenia offer (inicjator opisuje swoje możliwości medialne), jest przekazywany przez sygnalizację do drugiego peera, który odpowiada answer. Po wymianie SDP każdy peer uruchamia ICE i rozpoczyna DTLS-SRTP do szyfrowania strumienia.

// Android — tworzenie i wysyłanie 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)
            // Wysyłanie sdp.description do serwera sygnalizacji
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Protokoły sygnalizacji

W aplikacjach mobilnych najpopularniejsza jest sygnalizacja przez WebSocket — dwukierunkowy kanał przez TCP, który utrzymuje stałe połączenie z serwerem. Serwer sygnalizacji to często osobny mikrousługa (Node.js, Golang, Elixir), który routuje wiadomości między uczestnikami pokoju.

• WebSocket — stałe dwukierunkowe połączenie, minimalny narzut, standardowy wybór do sygnalizacji
• SIP over WebSocket — standardowy protokół VoIP, integruje się z istniejącą infrastrukturą telefoniczną
• MQTT — lekki protokół pub/sub dla IoT i słabych sieci, ale z większym opóźnieniem
• Matrix / XMPP — zdecentralizowane protokoły dla aplikacji wymagających prywatności

Po zakończeniu ICE i DTLS-SRTP sygnalizacja nie uczestniczy już w przesyłaniu danych — cały ruch medialny odbywa się bezpośrednio P2P (lub przez przekaźnik TURN). Serwer sygnalizacji może być wyłączony bez przerywania aktywnych połączeń. To kluczowa zaleta zdecentralizowanej architektury WebRTC.