WebRTC: mi ez, felépítése és működési elve

Mi az a WebRTC

A WebRTC (Web Real-Time Communication) egy nyílt forráskódú projekt, amelyet a Google indított 2011-ben, és a W3C (JavaScript API) és az IETF (protokollok) szabványosított. A fő feladat alacsony késleltetésű kommunikáció biztosítása böngészők és alkalmazások között pluginok vagy harmadik féltől származó szoftverek telepítése nélkül.

A hagyományos megoldásokkal (RTMP, HLS) ellentétben, ahol a video áthalad a szerveren, a WebRTC peer-to-peer felépítést használ: az adatok közvetlenül a résztvevők között kerülnek továbbításra. Ez 200-500 ms késleltetést biztosít a HLS 3-10 másodpercével szemben — kritikus különbség hang- és videohívások, játékstreaming és távoli sebészet esetén.

A Google WebRTC Team (2025) szerint a technológiát olyan alkalmazásokban használják, amelyek összesen több mint 5 milliárd telepítéssel rendelkeznek: Google Meet, WhatsApp, Discord, Telegram, Zoom (részben). A telehealth és edtech területén működő kockázati tőkés startupok több mint 85%-a választja a WebRTC-t elsődleges valós idejű szállítási módként.

A mobilfejlesztés 2013-ban kapott teljesen funkcionális WebRTC-t a libjingle_peerconnection megjelenésével — egy natív implementációval Android és iOS rendszerekhez. Jelenleg mindkét platform rendelkezik stabil SDK-kkal, amelyek támogatják a H.264 és VP8 hardveres kódolását, a kamerát, a mikrofont és az eszköz hangszóróit.

WebRTC felépítése és protokolljai

A WebRTC felépítése három szintből áll. A felső szint — JavaScript API (vagy natív API mobilplatformokhoz), a középső — szállítási protokollok, az alsó — kodekek és biztonság. Minden szint megoldja a saját feladatát, de mindegyik szükséges a kapcsolat létrehozásához.

Fő WebRTC API-k

MediaStream (getUserMedia) — audio és video rögzítése az eszköz mikrofonjáról és kamerájáról. RTCPeerConnection — P2P kapcsolat kezelése: kódolás, szállítás, bitráta alkalmazkodás. RTCDataChannel — tetszőleges adatok (szöveg, fájlok, bináris üzenetek) továbbítása ugyanazon a csatornán.

// JavaScript API WebRTC (böngésző példa)
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);

Valós idejű protokollok

A WebRTC SRTP (Secure Real-Time Transport Protocol)-t használ audio és video számára — az RTP biztonságos verzióját AES-128 titkosítással. A munkamenet kezelése SCTP (Stream Control Transmission Protocol)-n keresztül történik DTLS-en át. Minden adatfolyam kötelezően titkosított: a WebRTC-ben nincs nem biztonságos mód.

• SRTP/SRTCP — médiafolyamok titkosított továbbítása replay támadások elleni védelemmel
• DTLS-SRTP — titkosítási kulcsok létrehozása Datagram TLS-en keresztül UDP felett
• SCTP — megbízható vagy részben megbízható adatszállítás a DataChannel számára
• ICE (Interactive Connectivity Establishment) — keretrendszer a hálózati út megtalálásához a felek között
• Trickle ICE — az ICE növekményes verziója, ahol a jelöltek felfedezésükkor kerülnek elküldésre, felgyorsítva a kapcsolat létrehozását

NAT traversal: ICE, STUN és TURN

A WebRTC fő technikai nehézsége a P2P kapcsolat létrehozása a NAT (Network Address Translation) mögött található eszközök között. Különleges mechanizmusok nélkül az eszközök nem tudnak közvetlenül egymáshoz fordulni, mert helyi IP-címeik nem láthatók az internetről.

STUN — a nyilvános cím meghatározása

STUN (Session Traversal Utilities for NAT) — szerver, amely válaszol a „mi a nyilvános IP-címem és portom?” kérdésre. Az ügyfél kérést küld a STUN szervernek, a szerver látja a nyilvános címét és visszaadja az ügyfélnek. A Google nyilvánosan fenntartja a STUN szervert stun:stun.l.google.com:19302.

// WebRTC iOS-en — ICE szerverek konfigurálása
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 kapcsolat

TURN (Traversal Using Relays around NAT) — átjátszó szerver azokra az esetekre, amikor a STUN nem segít (szimmetrikus NAT vagy vállalati tűzfalak). Ebben a módban minden adat áthalad a TURN szerveren — ez csökkenti a sebességet és növeli a késleltetést, de 99%-os esetben garantálja a kapcsolatot.

A TURN a WebRTC infrastruktúra legdrágább összetevője, mivel a szerver az összes médiaforgalmat átengedi magán. A Coturn Project (2025) szerint egy tipikus 8 vCPU és 16 GB RAM-mal rendelkező TURN szerver körülbelül 200 egyidejű audiohívást vagy 40 HD minőségű videohívást kezel.

ICE folyamat

Az ICE összegyűjti az összes lehetséges jelöltet (helyi IP, nyilvános IP STUN-on keresztül, relay TURN-on keresztül), és prioritás szerint próbál kapcsolatot létrehozni. Amint legalább egy jelöltpár (helyi-távoli) átmegy a connectivity check ellenőrzésen, a kapcsolat létrejöttnek tekinthető.

• Host candidates — az eszköz helyi IP-címe az alhálózatban (leggyorsabb, de nem működik NAT mögött)
• Server Reflexive candidates — nyilvános IP a STUN szerveren keresztül
• Relay candidates — a TURN szerver címe, amelyen keresztül az átjátszás történik (leglassabb, legmegbízhatóbb)

WebRTC mobilalkalmazásokban

A mobilfejlesztéshez a Google fenntartja a libWebRTC-t — egy natív könyvtárat Android (AAR) és iOS (XCFramework) rendszerekhez. A könyvtár tartalmazza a teljes protokollvermet, a kodekeket (VP8, VP9, H.264, AV1) és a hardveres kódolási/dekódolási gyorsítást.

WebRTC Androidon

Az Android SDK a PeerConnectionFactory, PeerConnection, MediaStream osztályokat biztosítja. Az alkalmazás létrehoz egy gyárat, konfigurálja a videokodekeket, rögzíti a kamerafolyamot a VideoCapturer-en keresztül, és SDP offer/answer segítségével peer-to-peer kapcsolatot hoz létre.

// Android WebRTC — inicializálás
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-en

Az iOS SDK Objective-C API-t használ a RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack wrapper-ekkel. A H.264 hardveres kódolása a VideoToolboxon keresztül érhető el. A video megjelenítéséhez RTCMTLVideoView (Metal) vagy RTCVideoRenderer használatos.

// iOS WebRTC — video rögzítése a kameráról
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Kamera kiválasztása (elülső/hátsó)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Rögzítés indítása maximális FPS-sel
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

A gyártásban használt videohívásokhoz a mobilalkalmazások általában SDK wrapper-eket használnak a libWebRTC felett: Twilio Video, Agora, Daily.co. Ezek az SDK-k egyszerűsítik a jelzést, a szobakezelést, és kész UI komponenseket biztosítanak a résztvevők video rácsának megjelenítéséhez.

Jelzés és kapcsolat létrehozása

A WebRTC nem specifikálja a jelzési protokollt — az SDP (Session Description Protocol) üzenetek cseréjét a felek között. A fejlesztő maga választja meg a jelzés szállítási módját: WebSocket, MQTT, SIP, XMPP vagy REST API. A jelzés szállítja az offer-t, answer-t és ICE jelölteket az egyik féltől a másikhoz.

SDP Offer/Answer csere

A folyamat az offer létrehozásával kezdődik (a kezdeményező leírja média képességeit), amely jelzésen keresztül továbbítódik a második félhez, aki answer-rel válaszol. Az SDP csere után mindkét fél elindítja az ICE-t és megkezdi a DTLS-SRTP-t a folyam titkosításához.

// Android — offer létrehozása és küldése
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 elküldése a jelzőszerverre
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Jelzési protokollok

A mobilalkalmazásokban a legnépszerűbb jelzés a WebSocket-en keresztül történik — egy kétirányú csatorna TCP felett, amely állandó kapcsolatot tart a szerverrel. A jelzőszerver gyakran egy külön mikroszolgáltatás (Node.js, Golang, Elixir), amely a szoba résztvevői között irányítja az üzeneteket.

• WebSocket — állandó kétirányú kapcsolat, minimális többletterhelés, szabványos választás jelzéshez
• SIP over WebSocket — szabványos VoIP protokoll, integrálódik a meglévő telefoninfrastruktúrával
• MQTT — könnyű pub/sub protokoll IoT és gyenge hálózatok számára, de nagyobb késleltetéssel
• Matrix / XMPP — decentralizált protokollok adatvédelmi követelményekkel rendelkező alkalmazások számára

Az ICE és DTLS-SRTP befejezése után a jelzés már nem vesz részt az adattovábbításban — minden médiaforgalom közvetlenül P2P (vagy TURN relay-en keresztül) történik. A jelzőszerver kikapcsolható anélkül, hogy megszakítaná az aktív hívásokat. Ez a WebRTC decentralizált felépítésének kulcsfontosságú előnye.