WebRTC: co to je, architektura a princip fungování

Co je WebRTC

WebRTC (Web Real-Time Communication) je projekt s otevřeným zdrojovým kódem, který zahájila společnost Google v roce 2011 a standardizovaly W3C (JavaScript API) a IETF (protokoly). Hlavním úkolem je poskytnout komunikaci s nízkou latencí mezi prohlížeči a aplikacemi bez instalace pluginů nebo softwaru třetích stran.

Na rozdíl od tradičních řešení (RTMP, HLS), kde video prochází serverem, WebRTC používá peer-to-peer architekturu: data jsou přenášena přímo mezi účastníky. To poskytuje zpoždění 200-500 ms oproti 3-10 sekundám u HLS — kritický rozdíl pro hlasové a videohovory, streamování her a vzdálenou chirurgii.

Podle Google WebRTC Team (2025) je tato technologie používána v aplikacích s celkovým počtem více než 5 miliard instalací: Google Meet, WhatsApp, Discord, Telegram, Zoom (částečně). Více než 85 % startupů rizikového kapitálu v oblastech telehealth a edtech volí WebRTC jako primární transport v reálném čase.

Mobilní vývoj získal plně funkční WebRTC v roce 2013 s vydáním libjingle_peerconnection — nativní implementace pro Android a iOS. V současnosti mají obě platformy stabilní SDK s podporou hardwarového kódování H.264 a VP8, kamery, mikrofonu a reproduktorů zařízení.

Architektura a protokoly WebRTC

Architektura WebRTC se skládá ze tří úrovní. Horní úroveň — JavaScript API (nebo nativní API pro mobilní platformy), střední — transportní protokoly, spodní — kodeky a zabezpečení. Každá úroveň řeší svůj úkol, ale všechny jsou nezbytné pro navázání spojení.

Hlavní API WebRTC

MediaStream (getUserMedia) — zachycení audia a videa z mikrofonu a kamery zařízení. RTCPeerConnection — správa P2P spojení: kódování, transport, adaptace přenosové rychlosti. RTCDataChannel — přenos libovolných dat (text, soubory, binární zprávy) stejným kanálem.

// JavaScript API WebRTC (příklad v prohlížeči)
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);

Protokoly reálného času

WebRTC používá SRTP (Secure Real-Time Transport Protocol) pro audio a video — zabezpečenou verzi RTP s šifrováním AES-128. Správa relace probíhá přes SCTP (Stream Control Transmission Protocol) přes DTLS. Každý datový tok je povinně šifrován: ve WebRTC neexistuje nezabezpečený režim.

• SRTP/SRTCP — šifrovaný přenos mediálních toků s ochranou proti replay útokům
• DTLS-SRTP — nastavení šifrovacích klíčů přes Datagram TLS přes UDP
• SCTP — spolehlivé nebo částečně spolehlivé doručování dat pro DataChannel
• ICE (Interactive Connectivity Establishment) — framework pro nalezení síťové cesty mezi peery
• Trickle ICE — inkrementální verze ICE, kde jsou kandidáti odesíláni při jejich objevení, což urychluje navázání spojení

NAT traversal: ICE, STUN a TURN

Hlavní technickou obtíží WebRTC je navázání P2P spojení mezi zařízeními, která jsou za NAT (Network Address Translation). Bez speciálních mechanismů se zařízení nemohou přímo obrátit jedno na druhé, protože jejich místní IP adresy nejsou z internetu viditelné.

STUN — určení veřejné adresy

STUN (Session Traversal Utilities for NAT) — server, který odpovídá na otázku „jaká je moje veřejná IP adresa a port?”. Klient odešle požadavek na STUN server, server vidí jeho veřejnou adresu a vrátí ji klientovi. Google veřejně provozuje STUN server stun:stun.l.google.com:19302.

// WebRTC na iOS — konfigurace ICE serverů
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 — relay spojení

TURN (Traversal Using Relays around NAT) — retransmisní server pro případy, kdy STUN nepomáhá (symetrický NAT nebo firemní firewally). V tomto režimu všechna data procházejí přes TURN server — to snižuje rychlost a zvyšuje zpoždění, ale zaručuje spojení v 99 % případů.

TURN je nejdražší komponentou infrastruktury WebRTC, protože server přes sebe propouští veškerý mediální provoz. Podle Coturn Project (2025) typický TURN server s 8 vCPU a 16 GB RAM zpracovává přibližně 200 současných audio hovorů nebo 40 videohovorů v HD kvalitě.

Proces ICE

ICE shromáždí všechny možné kandidáty (lokální IP, veřejnou IP přes STUN, relay přes TURN) a pokouší se navázat spojení podle priority. Jakmile alespoň jeden pár kandidátů (lokální-vzdálený) projde kontrolou konektivity connectivity check, je spojení považováno za navázané.

• Host candidates — lokální IP adresa zařízení v podsíti (nejrychlejší, ale nefunguje za NAT)
• Server Reflexive candidates — veřejná IP získaná přes STUN server
• Relay candidates — adresa TURN serveru, přes který probíhá retransmise (nejpomalejší, nejspolehlivější)

WebRTC v mobilních aplikacích

Pro mobilní vývoj Google udržuje libWebRTC — nativní knihovnu pro Android (AAR) a iOS (XCFramework). Knihovna obsahuje celý zásobník protokolů, kodeky (VP8, VP9, H.264, AV1) a hardwarové urychlení kódování/dekódování.

WebRTC na Androidu

Android SDK poskytuje třídy PeerConnectionFactory, PeerConnection, MediaStream. Aplikace vytvoří továrnu, nakonfiguruje video kodeky, zachytí proud z kamery přes VideoCapturer a naváže peer-to-peer spojení přes SDP offer/answer.

// Android WebRTC — inicializace
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 používá Objective-C API s obaly RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Hardwarové kódování H.264 je dostupné přes VideoToolbox. Pro zobrazení videa se používá RTCMTLVideoView (Metal) nebo RTCVideoRenderer.

// iOS WebRTC — snímání videa z kamery
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Výběr kamery (přední/zadní)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Spuštění snímání s maximálním FPS
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Pro videohovory v produkci mobilní aplikace obvykle používají SDK obaly nad libWebRTC: Twilio Video, Agora, Daily.co. Tato SDK zjednodušují signalizaci, správu místností a poskytují hotové UI komponenty pro zobrazení video mřížky účastníků.

Signalizace a navázání spojení

WebRTC nespecifikuje protokol signalizace — výměnu SDP (Session Description Protocol) zpráv mezi peery. Vývojář si sám vybírá transport pro signalizaci: WebSocket, MQTT, SIP, XMPP nebo REST API. Signalizace doručuje offer, answer a ICE kandidáty od jednoho peera k druhému.

Výměna SDP Offer/Answer

Proces začíná vytvořením offer (iniciátor popisuje své mediální možnosti), je přenesen signalizací k druhému peerovi, který odpovídá answer. Po výměně SDP každý peer spustí ICE a zahájí DTLS-SRTP pro šifrování toku.

// Android — vytvoření a odeslání 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)
            // Odeslání sdp.description na signalizační server
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Signalizační protokoly

V mobilních aplikacích je nejoblíbenější signalizace přes WebSocket — obousměrný kanál přes TCP, který udržuje trvalé spojení se serverem. Signalizační server je často samostatná mikroslužba (Node.js, Golang, Elixir), která směruje zprávy mezi účastníky místnosti.

• WebSocket — trvalé obousměrné spojení, minimální režie, standardní volba pro signalizaci
• SIP over WebSocket — standardní VoIP protokol, integruje se se stávající telefonní infrastrukturou
• MQTT — lehký pub/sub protokol pro IoT a slabé sítě, ale s větším zpožděním
• Matrix / XMPP — decentralizované protokoly pro aplikace s požadavky na soukromí

Po dokončení ICE a DTLS-SRTP se signalizace již neúčastní přenosu dat — veškerý mediální provoz jde přímo P2P (nebo přes TURN relay). Signalizační server může být vypnut bez přerušení aktivních hovorů. To je klíčová výhoda decentralizované architektury WebRTC.