WebRTC: peerkapcsolat, adatcsatorna és a WebTransport

Célok

A lecke végére el tudod magyarázni, miben más a WebRTC adatcsatorna, mint a kliens–szerver módszerek, mi a signaling, az ICE, a STUN és a TURN szerepe, és hogyan viszonyul hozzá a WebTransport.

Miért kell?

A korábbi módszerek mind a kliens és egy központi szerver közötti kommunikációt oldják meg. Vannak helyzetek, ahol két kliens közvetlen kapcsolata hasznosabb (például hívások, játékok, fájlcsere), vagy ahol a késleltetés fontosabb, mint a minden adat garantált megérkezése. A WebRTC erre a két igényre ad eszközt.

Mi a WebRTC?

A WebRTC az RFC 8831 szerint olyan keretrendszer, amely a böngészők közötti közvetlen, interaktív kommunikációt teszi lehetővé hanggal, képpel és adattal. A DataChannel a nem-média adatok átvitele: az RFC 8831 szerint a Stream Control Transmission Protocol (SCTP) általános adatátviteli szolgáltatásként szolgál a böngészők közötti peer-to-peer adatcserére. Az MDN szerint a DataChannel adatát automatikusan a DTLS (a TLS datagramos változata) védi.

Signaling, ICE, STUN, TURN

A WebRTC nem tud kapcsolatot létrehozni egy közbenső szerver nélkül. Az MDN szerint ez a signaling (jelzéscsatorna): bármilyen csatorna, amelyen a felek a kapcsolat felépítése előtt információt cserélnek; hogy melyik, az rajtad múlik (az MDN példái között levél, képeslap vagy postagalamb is szerepel). A felek munkamenet-leírást (session description, SDP formátumban) cserélnek: az egyik ajánlatot (offer) készít, a másik választ (answer) küld.

Az ICE (Interactive Connectivity Establishment) az a protokoll, amely lehetővé teszi, hogy két eszköz közvetítő segítségével akkor is kapcsolatot találjon, ha NAT (Network Address Translation, címfordítás) választja el őket. Az ICE-jelöltek leírják a lehetséges kapcsolati utakat. A STUN (Session Traversal Utilities for NAT) segít a hálózati címhelyzet feltárásában (az ún. „server reflexive” jelölt); a TURN (Traversal Using Relays around NAT) közvetít, ha közvetlen út nem jön létre (a „relay” jelölt). A „peer-to-peer” tehát nem garantálja, hogy minden adat közvetítő nélkül megy; a közvetítő kapacitása és költsége a terv része.

sequenceDiagram
  participant A as Peer A
  participant J as Signaling-csatorna
  participant B as Peer B
  A->>J: Ajánlat (offer)
  J->>B: Ajánlat
  B->>J: Válasz (answer)
  J->>A: Válasz
  A-->>B: Közvetlen DataChannel (vagy TURN-közvetítéssel)

Rendezés és megbízhatóság

A DataChannel beállítható rendezett vagy rendezetlen működésre (alapértelmezés: rendezett), korlátozott újraküldésre (maxRetransmits) vagy korlátozott élettartamra (maxPacketLifeTime); a két utóbbi nem használható egyszerre. Ez alkalmazási jelentést igényel: egy gyorsan elavuló pozícióadatnál az újraküldés rosszabb lehet az elvesztésnél, egy dokumentum-módosításnál nem. Az MDN szerint az üzenetméret legyen mérsékelt: nagy üzenet fejblokkolást okozhat más csatornákon, és az alapértelmezett legnagyobb üzenet, ha az SDP nem ad mást, 64 kilobájt.

Hogyan viszonyul a WebSockethez?

A signaling szállítására tetszőleges csatorna használható: HTTP, vagy a tartós kétirányú WebSocket (10. fejezet), ha gyorsan kell jelzéseket cserélni. A WebRTC és a WebSocket tehát nem versenytársak: az egyik peer-to-peer adatcsatornát, a másik kliens–szerver csatornát ad, és gyakran együtt használják őket.

WebTransport röviden

A WebTransport az MDN szerint a WebSocket „modern frissítése”: a kliens és a szerver között HTTP/3 felett több adatfolyamot, egy- és kétirányú megbízható streameket, valamint megbízhatatlan, UDP-szerű datagramokat tud továbbítani. Az MDN szerint a funkció 2026 márciusa óta „Baseline”, azaz az aktuális eszközökön és böngészőverziókon működik, de egyes részeinek támogatottsága eltérő, és csak biztonságos (HTTPS) környezetben érhető el. Szerveroldalon HTTP/3-támogatás kell, ezért nem elég egy WebSocket-végpont URL-jét átírni. A WebRTC DataChannellel szemben a WebTransport kliens–szerver kapcsolat.

Jellemzők

Szempont	WebRTC DataChannel
Irány	Kétirányú, peerek között
Kezdeményező	Bármelyik peer (az ajánlat küldője indít)
Kapcsolat tartóssága	Tartós, a signaling után közvetlen
Késleltetés	Alacsony, ha közvetlen út van; TURN-nél a közvetítőn át
Terhelés	A peerek között oszlik; TURN-közvetítés a közvetítő szerveren
Hibatűrés	Beállítható: rendezett/rendezetlen, korlátozott újraküldés
Mikor jó?	Közvetlen peerkommunikáció, gyorsan elavuló adat, kisebb szerverterhelés
Mikor nem?	Központi, hiteles üzleti állapot; ahol a kliens által közölt adat nem fogadható el ellenőrzés nélkül

Gyakori tévhitek

Állítás	Pontosítás
„A WebRTC mindig közvetlen, szerver nélküli.”	Signaling kell, és TURN közvetíthet.
„A DataChannel mindig megbízható és rendezett.”	Beállítható; az alapértelmezés rendezett.
„A WebRTC kiváltja a WebSocketet.”	Más modell (peer vs. kliens–szerver), gyakran együtt használják.
„A WebTransport csak átnevezett WebSocket.”	Más szállítás (HTTP/3), több stream és datagram.

Röviden

• A WebRTC peerek közti adatcsatornát ad; a kapcsolat felépítéséhez signaling kell.
• Az ICE, STUN és TURN a NAT mögötti utat keresi, illetve közvetít.
• A DataChannel megbízhatósága és rendezése beállítható.
• A WebTransport kliens–szerver kapcsolat HTTP/3 felett, streamekkel és datagramokkal.

Ellenőrző kérdések

1. Mire való a signaling, és ki határozza meg a szállítását?
2. Mikor szükséges a TURN?
3. Miért nem fogadható el hiteles tényként a peer által közölt állapot?

Források

• RFC 8831: WebRTC Data Channels — az adatcsatorna és az SCTP használata.
• WebRTC connectivity (MDN) — signaling, ICE, STUN, TURN, SDP.
• Using WebRTC data channels (MDN) — csatorna, pufferelés, üzenetméret, DTLS.
• WebTransport API (MDN) — stream és datagram, támogatás.