WebTransport: streams i datagramy dla realtime nad HTTP/3

Trzy ważne możliwości

WebTransport może przenosić:

bidirectional streams
unidirectional streams
datagrams

Streams są reliable.

Datagrams są unreliable: mogą zginąć i nie są mechanizmem wymagającym retransmisji każdego pakietu.

To pozwala dopasować semantykę transportu do rodzaju danych.

Nie wszystkie dane są równie ważne

Wyobraźmy sobie grę.

Chat

"meet at point B"

Chcemy reliable delivery.

Inventory update

ammo: 30 -> 29

Również potrzebujemy poprawności.

Player position

x=10
x=11
x=12
x=13

Jeżeli x=11 zginie, ale dotrze x=13, retransmisja starej pozycji może być niepotrzebna.

Dla takiego ruchu datagram może być lepszym modelem.

reliable stream -> important ordered state
datagram        -> ephemeral latest-state update

Multiple streams

WebSocket daje jeden logiczny ordered channel.

Jeżeli aplikacja przesyła:

large file chunk
chat message
control message

wszystko przechodzi przez jeden model kolejności aplikacyjnej.

WebTransport pozwala tworzyć niezależne streams.

session
├── stream A: file
├── stream B: chat
├── stream C: control
└── datagrams: positions

To pozwala ograniczyć niepożądane zależności pomiędzy różnymi klasami ruchu.

QUIC eliminuje transportowy head-of-line blocking pomiędzy niezależnymi streams: utrata danych jednego streamu nie musi zatrzymać dostarczania danych innego.

Browser API

Uproszczony start:

const transport =
  new WebTransport("https://example.com:4433/wt");

await transport.ready;

Możemy następnie tworzyć streams albo korzystać z datagrams.

Przykładowo:

const stream =
  await transport.createBidirectionalStream();

const writer = stream.writable.getWriter();

To bardziej stream-oriented API niż WebSocket.send().

WebTransport nie jest „WebSocket v2”

Nie powinno się wybierać WebTransport tylko dlatego, że jest nowszy.

WebSocket:

simple
mature
widely understood
excellent for message-oriented full duplex

WebTransport:

multiple independent streams
unreliable datagrams
HTTP/3 / QUIC semantics
more transport choices exposed to application

Większa kontrola oznacza więcej decyzji.

Aplikacja musi wiedzieć, które dane:

• muszą dotrzeć,
• muszą zachować kolejność,
• mogą być porzucone,
• powinny mieć własny stream.

Stan wsparcia

WebTransport jest obecnie oznaczony przez MDN jako Baseline 2026 i działa w aktualnych generacjach głównych przeglądarek, ale starsze klienty mogą go nie obsługiwać.

To nadal ma znaczenie przy projektowaniu produktu o szerokim zakresie kompatybilności.

WebTransport wymaga też infrastruktury wspierającej HTTP/3/WebTransport po stronie serwera i ścieżki sieciowej.

Kiedy rzeczywiście warto?

Dobry sygnał to sytuacja, gdy samo:

bidirectional messages

jest zbyt mało precyzyjne.

Na przykład potrzebujemy jednocześnie:

reliable ordered stream
+
independent file stream
+
loss-tolerant high-frequency updates

Wtedy model WebTransport zaczyna odpowiadać rzeczywistemu modelowi danych.

Dla klasycznego:

chat
notifications
collaborative CRUD

WebSocket albo SSE mogą pozostać prostszym rozwiązaniem.

Doszliśmy więc do punktu, w którym mamy kilka poprawnych mechanizmów.

Ostatnie pytanie nie brzmi już:

co potrafi platforma?

Brzmi:

jak wybrać najmniejszy mechanizm, który spełnia wymagania naszego przepływu danych?