WebTransport Guide: Streams, Datagrams, HTTP/3 und wann es sinnvoll ist

WebTransport ist eine Browser-API für bidirektionale Client-Server-Kommunikation über HTTP/3. Sie bietet Web-Apps zwei Transportarten in einer Verbindung: zuverlässige Streams und unzuverlässige Datagrams.

Das macht WebTransport für Low-Latency-Anwendungen interessant, aber es ist kein direkter Ersatz für jeden WebSocket- oder WebRTC-Anwendungsfall. Die beste Bewertung beginnt beim Traffic-Muster, das Ihre Anwendung braucht.

Was WebTransport ist

WebTransport lässt einen Browser zu einem HTTP/3-Server verbinden und Daten austauschen über:

Zuverlässige Streams: geordnete Byte-Streams für Daten, die korrekt ankommen müssen.
Unzuverlässige Datagrams: Best-Effort-Nachrichten für Daten, bei denen niedrige Latenz wichtiger ist als garantierte Zustellung.

Es läuft in sicheren Kontexten, daher sollten Sie HTTPS voraussetzen. Außerdem hängt es von HTTP/3-Unterstützung im Browser, Server, Netzwerkpfad, CDN und Proxy-Schichten ab.

Referenzen:

Das Denkmodell

Stellen Sie sich eine WebTransport-Verbindung als eine Session vor, die mehrere unabhängige Kanäle tragen kann.

Browser
  WebTransport session
    reliable stream: chat message, file chunk, control command
    reliable stream: another independent operation
    datagram: player position, sensor update, live cursor
HTTP/3 server

Der wichtige Punkt: Unterschiedliche Daten können unterschiedliche Zustellregeln nutzen. Eine Zahlungsbestätigung sollte nicht wie ein Positionsupdate im Spiel gesendet werden. Ein Positionsupdate sollte nicht hinter einem großen Dateitransfer warten.

Streams vs Datagrams

Merkmal	Streams	Datagrams
Zustellung	Zuverlässig	Best Effort
Reihenfolge	Innerhalb eines Streams geordnet	Nicht garantiert
Am besten für	Dateien, Befehle, Chat, Transaktionen	Spielzustand, Telemetrie, Live-Cursor
Verlustbehandlung	Transport kümmert sich um Zuverlässigkeit	App muss Verlust tolerieren
Datentyp	Byte-Chunks	Einzelne Nachrichten

Nutzen Sie Streams, wenn Korrektheit zählt. Nutzen Sie Datagrams, wenn der neueste Wert wichtiger ist als jeder alte Wert.

WebTransport vs WebSocket

WebSocket ist für viele Apps weiterhin der einfachere Standard. Es ist breit eingesetzt, leicht zu proxien und hat ein ausgereiftes Ökosystem.

WebTransport wird interessant, wenn Sie brauchen:

Mehrere unabhängige Streams in einer Session.
Unzuverlässige Nachrichten mit niedriger Latenz.
Weniger Head-of-Line-Blocking zwischen unabhängigen Datenflüssen.
Einen modernen Client-Server-Transport auf HTTP/3-Basis.

Nutzen Sie WebSocket, wenn:

Ein zuverlässiger geordneter Nachrichtenstrom reicht.
Sie maximale Kompatibilität mit vorhandener Infrastruktur brauchen.
Server, CDN oder Unternehmensnetzwerke HTTP/3 nicht zuverlässig handhaben.
Sie den einfachsten Betriebspfad möchten.

Migrieren Sie eine funktionierende WebSocket-App nicht nur, weil WebTransport neuer ist. Migrieren Sie nur, wenn Ihr Traffic-Muster von Streams, Datagrams oder HTTP/3-Verhalten profitiert.

WebTransport vs WebRTC Data Channels

WebRTC Data Channels sind für Peer-to-Peer- oder medienlastige Echtzeitsysteme gebaut. WebTransport ist Client-Server.

Nutzen Sie WebRTC, wenn:

Browser direkt Peer-to-Peer kommunizieren müssen.
Audio-/Video-Aushandlung ohnehin Teil der App ist.
Sie NAT-Traversal-Muster der WebRTC-Infrastruktur brauchen.

Nutzen Sie WebTransport, wenn:

Der Browser mit Ihrem Server spricht, nicht direkt mit einem anderen Browser.
Sie eine Web-Platform-Streams-API möchten.
Sie nicht den kompletten WebRTC-Stack brauchen.

Wenn Sie bereits ein stabiles WebRTC-Setup haben, vereinfacht WebTransport möglicherweise nicht genug für einen Rewrite.

Einfaches Client-Muster

Prüfen Sie immer Feature Support, bevor Sie WebTransport verwenden.

async function connectWebTransport(url) {
  if (!("WebTransport" in globalThis)) {
    throw new Error("WebTransport is not available in this browser.");
  }

  const transport = new WebTransport(url);

  transport.closed
    .then(() => {
      console.log("WebTransport closed normally.");
    })
    .catch((error) => {
      console.error("WebTransport closed unexpectedly:", error);
    });

  await transport.ready;
  return transport;
}

const transport = await connectWebTransport("https://example.com:4433/wt");

In Produktion sollte das mit Fallback-Logik umschlossen werden. Wenn WebTransport nicht verfügbar ist oder die Verbindung fehlschlägt, wechseln Sie je nach Feature zu WebSocket, Server-Sent Events oder normalem HTTP.

Datagrams senden

Datagrams eignen sich für häufige Statusupdates, bei denen alte Nachrichten schnell wertlos werden.

const writer = transport.datagrams.writable.getWriter();
const encoder = new TextEncoder();

await writer.write(encoder.encode(JSON.stringify({
  type: "cursor",
  x: 240,
  y: 180,
  t: Date.now()
})));

Gestalten Sie Datagram-Payloads so, dass jede Nachricht für sich stehen kann. Verlassen Sie sich nicht darauf, alle vorherigen Datagrams zu erhalten.

Gute Datagram-Payloads:

Aktuelle Spielerposition.
Neueste Cursor-Position.
Sensorwert.
Typing- oder Presence-Heartbeat.
Live-Preview-Zustand.

Schlechte Datagram-Payloads:

Zahlungsaktionen.
Kontoänderungen.
Geordnete Dokumentänderungen.
Alles, was auditierbar sein muss.

Zuverlässige Streams verwenden

Streams sind besser, wenn der Empfänger alle Bytes in Reihenfolge erhalten muss.

const stream = await transport.createBidirectionalStream();
const writer = stream.writable.getWriter();
const reader = stream.readable.getReader();
const encoder = new TextEncoder();
const decoder = new TextDecoder();

await writer.write(encoder.encode("hello"));

const { value } = await reader.read();
if (value) {
  console.log(decoder.decode(value));
}

await writer.close();

Erstellen Sie getrennte Streams für unabhängige Vorgänge. So blockiert ein großer Transfer keine kleine Control Message.

Produktions-Checkliste

Vor dem Versand prüfen Sie den gesamten Pfad:

Browser-Support für Ihre Zielgruppe.
HTTP/3-Unterstützung auf dem Server.
TLS-Zertifikat und sicherer Kontext.
UDP- und QUIC-Verhalten durch Firewalls und Unternehmensnetzwerke.
CDN- oder Reverse-Proxy-Support.
Load-Balancing-Verhalten für langlebige Sessions.
Monitoring für Verbindungsfehler, Retry-Rate und Fallback-Nutzung.
Backpressure-Handling für Streams.
Nachrichtengrößenlimits für Datagrams.
Authentifizierung und Autorisierung beim Session-Start.

Der schwierigste Teil ist oft nicht die Browser-API, sondern Netzwerk- und Server-Deployment.

Fallback-Strategie

Ein praktischer Fallback-Plan sieht so aus:

Try WebTransport
  if unavailable or connection fails:
    use WebSocket for bidirectional reliable messaging
  if WebSocket is not needed:
    use Server-Sent Events for server push
  if real-time is optional:
    use fetch polling

Halten Sie das Produktverhalten konsistent, auch wenn der Transport wechselt. Ein Dashboard kann etwa mit langsamem Polling weiter funktionieren; ein Spiel muss den Echtzeitraum vielleicht deaktivieren, wenn kein Low-Latency-Transport verfügbar ist.

Wann WebTransport gut passt

WebTransport lohnt sich, wenn Ihre App zuverlässige und schnelle Best-Effort-Daten kombiniert:

Multiplayer-Spielzustand plus zuverlässige Match-Events.
Collaborative Editing Cursors plus zuverlässige Dokumentoperationen.
Live-Dashboards mit häufiger Telemetrie plus zuverlässige Control Commands.
Remote-Gerätesteuerung mit Statusupdates und Command Streams.
Mediennahe Apps, die serverseitige Echtzeit-Datenkanäle brauchen.

Das gemeinsame Muster ist gemischter Traffic. Manche Daten müssen ankommen. Andere Daten müssen frisch sein.

Wann nicht verwenden

Vermeiden Sie WebTransport, wenn:

Eine normale REST- oder fetch-API reicht.
Ein einzelner WebSocket-Stream das Problem sauber löst.
Sie breite Kompatibilität mit älteren Browsern brauchen.
Ihr Deployment-Stack HTTP/3 nicht zuverlässig unterstützt.
Browser-zu-Browser-Peer-to-Peer-Kommunikation nötig ist.
Ihr Team keine Transport-Fallbacks betreiben möchte.

Neuere Transporttechnik ist nur nützlich, wenn sie echten Produktschmerz reduziert.

Zusammenfassung

WebTransport gibt Browser-Apps einen modernen HTTP/3-Client-Server-Transport mit zuverlässigen Streams und unzuverlässigen Datagrams. Sein Wert liegt nicht darin, WebSocket überall zu ersetzen. Sein Wert liegt darin, dass eine Session verschiedene Arten von Echtzeitdaten mit unterschiedlichen Zustellanforderungen tragen kann.

Nutzen Sie es, wenn Ihre App diese Flexibilität wirklich braucht, und liefern Sie es mit Feature Detection, Fallbacks und Produktionsmonitoring aus.