A valós idejű webalkalmazásokban nem minden adat egyforma. Egy chatüzenetnek biztosan és sorrendben kell célba érnie; egy egérkurzor vagy egy játékos pillanatnyi pozíciója viszont akkor is használhatatlan lehet, ha fél másodperccel később hibátlanul megérkezik. A WebSocket egyetlen, rendezett és megbízható csatornát ad. A WebTransport API ehhez képest ugyanabban a kapcsolatban kínál megbízható streameket és eldobható datagramokat is.

Nem gyorsabb WebSocket, hanem többféle garancia
A WebSocket üzenethatárokat őriz meg, de a teljes kapcsolat egy rendezett byte-folyamra épül. TCP-n egy elveszett csomag pótlásáig a mögötte levő adatok sem haladhatnak tovább. A QUIC, amelynek működését az RFC 9000 írja le, streamekre bontja az átvitelt: egy stream vesztesége nem kényszeríti várakozásra a többit. A WebTransport ezt teszi elérhetővé böngészős JavaScriptből, jelenleg HTTP/3 fölött.
A kapcsolatban három, egymástól tudatosan eltérő eszköz van. A kétirányú stream jó például dokumentum-műveletekhez vagy megbízható állapotváltásokhoz. Az egyirányú stream egy nagyobb, önálló adatfolyamhoz illik, amikor nem kell visszirányú forgalom. A datagram kicsi, nem megbízható és nem rendezett csomag: érkezhet késve, kétszer vagy egyáltalán nem. Az utóbbi nem hiba, hanem a választott szemantika; a HTTP-datagramok alapját az RFC 9297 rögzíti.
Mit küldj datagramként?
Jó jelölt az olyan információ, amelyet egy újabb minta felülír: kurzorpozíció, húzás közbeni előnézet, kameranézet, hang- vagy játékállapot telemetriája. Ha a 42. pozíció-frissítés elveszett, a 43. rendszerint többet ér, mint az újraküldés miatti késleltetés. A kliensnek ilyenkor érdemes sorszámot vagy időbélyeget tenni az üzenetbe, és a régebbi mintát eldobni.
Nem jó datagram a pénzmozgás, a chatüzenet, a szerkesztési művelet vagy bármilyen „pontosan egyszer” üzleti esemény. Ezekhez nem elég az, hogy a hálózat többnyire működik: az alkalmazásnak tudnia kell, mi érkezett meg és milyen sorrendben. Használj hozzá megbízható streamet, vagy maradj a bevált HTTP/WebSocket megoldásnál. Egy hasznos minta a hibrid protokoll: a kezdeti teljes állapot és a javító szinkron megbízható streamen megy, a gyakori, eldobható delta pedig datagramon.
A stream nem üzenetsor
Itt van a kevésbé nyilvánvaló rész. A WebTransport stream byte-folyam. Egy write() hívásból a másik oldalon nem szükségszerűen egy read() lesz: az átviteli réteg összevonhat vagy feldarabolhat adatot. A WebTransport specifikáció ezért kimondja, hogy a write-határok nem üzenethatárok. Saját protokollhoz hosszmezős keretezés, sorvégekkel tagolt formátum vagy más egyértelmű framing kell. Ha ezt kihagyod, a rövid helyi teszt még zöld lehet, terhelés alatt viszont véletlenszerűen összeragadt JSON-okkal találkozol.
Datagramnál a határ megmarad, de a méretet nem szabad készpénznek venni. A használható maximumot a kapcsolat és az útvonal befolyásolja; nagy objektumot ezért ne darabolj vakon UDP-szerű csomagokra. Vagy tervezz kis, önálló frissítéseket, vagy tedd a nagy, garantáltan megérkező adatot streamre.
A szerveroldal a valódi belépési küszöb
A böngészőben a kapcsolat new WebTransport(httpsUrl) formában nyílik; a konstruktor HTTPS-t vár, tehát ez biztonságos kontextushoz kötött. Ettől még nem lesz egy meglévő WebSocket endpoint WebTransport-képes. A szervernek értenie kell a WebTransport protokollt, a peremnek pedig valóban HTTP/3-forgalmat kell eljuttatnia hozzá. A reverse proxy, CDN, konténerhálózat és UDP-alapú HTTP/3 útvonal ugyanúgy része a megvalósításnak, mint a frontend.
A WebTransport over HTTP/3 protokollleírása jelenleg még IETF-draft, a webes API specifikációja is fejlődik. Ez nem ok arra, hogy ne kísérletezz vele, de ok arra, hogy az alkalmazás üzletileg kritikus útvonalát ne csak erre építsd. Az MDN szerint a WebTransport 2026 márciusától Baseline az aktuális böngészőkben; régebbi eszközökhöz továbbra is kell feature detection és visszaesési út.
Mikor éri meg?
Ha ma egy WebSocketen kevered a kritikus műveleteket a nagy gyakoriságú, lejáró frissítésekkel, a WebTransport jó tervezési eszköz lehet: külön megfogalmazhatod, melyik adat milyen kézbesítési garanciát igényel. Átlagos értesítésekhez, adminfelülethez vagy chathez viszont a WebSocket egyszerűbb és érettebb választás. A WebTransport legnagyobb nyeresége nem az, hogy minden csomag gyorsabb lesz, hanem hogy végre nem kell ugyanazzal a megbízhatósági szerződéssel küldened minden adatot.