Guía de WebTransport: streams, datagrams, HTTP/3 y cuándo usarlo

WebTransport es una API del navegador para comunicación bidireccional cliente-servidor sobre HTTP/3. Ofrece a las apps web dos estilos de transporte en una conexión: streams confiables y datagrams no confiables.

Eso lo hace útil para aplicaciones de baja latencia, pero no es reemplazo directo para todos los casos de WebSocket o WebRTC. La mejor forma de evaluarlo es empezar por el patrón de tráfico que necesita tu app.

Qué es WebTransport

WebTransport permite que un navegador se conecte a un servidor HTTP/3 e intercambie datos usando:

Streams confiables: flujos ordenados de bytes para datos que deben llegar correctamente.
Datagrams no confiables: mensajes best-effort para datos donde la baja latencia importa más que la entrega garantizada.

Funciona en contextos seguros, así que debes asumir que HTTPS es requerido. También depende de soporte HTTP/3 en navegador, servidor, ruta de red, CDN y capas de proxy.

Documentación de referencia:

El modelo mental

Piensa en una conexión WebTransport como una sesión que puede llevar varios canales independientes.

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

El punto importante es que distintos datos pueden usar distintas reglas de entrega. Una confirmación de pago no debe enviarse como una posición de juego. Una posición de juego no debería esperar detrás de una transferencia de archivo grande.

Streams vs Datagrams

Característica	Streams	Datagrams
Entrega	Confiable	Best effort
Orden	Ordenado dentro de un stream	No garantizado
Mejor para	Archivos, comandos, chat, transacciones	Estado de juego, telemetría, cursores en vivo
Manejo de pérdida	El transporte maneja confiabilidad	La app debe tolerar pérdida
Tipo de dato	Chunks de bytes	Mensajes discretos

Usa streams cuando la corrección importa. Usa datagrams cuando el valor más reciente importa más que cada valor anterior.

WebTransport vs WebSocket

WebSocket sigue siendo la opción simple para muchas apps. Está ampliamente desplegado, es fácil de proxyear y tiene un ecosistema maduro.

WebTransport se vuelve interesante cuando necesitas:

Varios streams independientes en una sesión.
Mensajes no confiables de baja latencia.
Menos head-of-line blocking entre flujos no relacionados.
Un transporte cliente-servidor moderno basado en HTTP/3.

Usa WebSocket cuando:

Solo necesitas un flujo confiable y ordenado de mensajes.
Necesitas máxima compatibilidad con infraestructura existente.
Tu servidor, CDN o redes corporativas no manejan HTTP/3 de forma confiable.
Quieres el camino operativo más simple.

No migres una app WebSocket que funciona solo porque WebTransport es más nuevo. Migra solo cuando tu patrón de tráfico se beneficia de streams, datagrams o comportamiento HTTP/3.

WebTransport vs WebRTC Data Channels

Los data channels de WebRTC están diseñados para sistemas peer-to-peer o tiempo real con mucho media. WebTransport es cliente-servidor.

Usa WebRTC cuando:

Los navegadores deben comunicarse peer-to-peer.
La negociación de audio/video ya forma parte de la app.
Necesitas patrones de NAT traversal manejados por infraestructura WebRTC.

Usa WebTransport cuando:

El navegador habla con tu servidor, no directamente con otro navegador.
Quieres una API Streams al estilo web platform.
No necesitas todo el stack WebRTC.

Si ya tienes un setup WebRTC estable, WebTransport quizá no simplifique lo suficiente para justificar reescritura.

Patrón básico de cliente

Siempre detecta soporte antes de usar WebTransport.

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");

En producción, envuélvelo con lógica de fallback. Si WebTransport no está disponible o la conexión falla, cambia a WebSocket, Server-Sent Events o HTTP normal según la función.

Enviar datagrams

Los datagrams son buenos para actualizaciones frecuentes de estado donde los mensajes viejos pierden valor rápido.

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()
})));

Diseña payloads de datagram para que cada mensaje pueda entenderse por sí mismo. No dependas de recibir todos los datagrams anteriores.

Buenos payloads de datagram:

Posición actual del jugador.
Ubicación más reciente del cursor.
Lectura de sensor.
Heartbeat de escritura o presencia.
Estado de vista previa en vivo.

Malos payloads de datagram:

Acciones de pago.
Cambios de cuenta.
Ediciones de documento ordenadas.
Cualquier cosa que deba auditarse.

Usar streams confiables

Los streams son mejores cuando el receptor debe obtener todos los bytes en orden.

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();

Crea streams separados para operaciones no relacionadas. Así una transferencia grande no bloquea un mensaje pequeño de control.

Checklist de producción

Antes de lanzar WebTransport, revisa toda la ruta:

Soporte de navegador para tu audiencia.
Soporte HTTP/3 en el servidor.
Certificado TLS y contexto seguro.
Comportamiento de UDP y QUIC en firewalls y redes corporativas.
Soporte de CDN o reverse proxy.
Comportamiento de load balancing para sesiones largas.
Monitoreo de fallas de conexión, tasa de retry y uso de fallback.
Manejo de backpressure para streams.
Límites de tamaño de mensajes para datagrams.
Autenticación y autorización al inicio de sesión.

La parte más difícil a menudo no es la API del navegador. Es el despliegue de red y servidor.

Estrategia de fallback

Un plan práctico se ve así:

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

Mantén consistente el comportamiento del producto aunque cambie el transporte. Por ejemplo, un dashboard puede seguir funcionando con polling más lento; un juego quizá deba desactivar la sala en tiempo real si no hay transporte de baja latencia.

Cuándo WebTransport encaja bien

Vale la pena evaluar WebTransport cuando tu app mezcla datos confiables y datos best-effort de baja latencia:

Estado de juego multijugador más eventos de partida confiables.
Cursores de edición colaborativa más operaciones de documento confiables.
Dashboards en vivo con telemetría frecuente más comandos confiables.
Control remoto de dispositivos con estados y streams de comandos.
Apps cercanas a media que necesitan canales de datos en tiempo real del servidor.

El patrón común es tráfico mixto. Algunos datos deben llegar. Otros deben estar frescos.

Cuándo no usarlo

Evita WebTransport cuando:

Una API REST o fetch normal es suficiente.
Un solo stream WebSocket resuelve el problema limpiamente.
Necesitas amplia compatibilidad con navegadores antiguos.
Tu stack de despliegue no puede soportar HTTP/3 de forma confiable.
Necesitas comunicación peer-to-peer entre navegadores.
Tu equipo no quiere operar fallbacks a nivel transporte.

La tecnología de transporte más nueva solo sirve cuando reduce un dolor real del producto.

Resumen

WebTransport da a las apps de navegador un transporte cliente-servidor moderno sobre HTTP/3 con streams confiables y datagrams no confiables. Su valor no es reemplazar WebSocket en todas partes. Su valor es que una sesión puede llevar distintos tipos de datos en tiempo real con distintas necesidades de entrega.

Úsalo cuando tu app realmente necesite esa flexibilidad, y lánzalo con detección de soporte, fallbacks y monitoreo de producción.