Comunicação de Baixa Latência no Navegador com WebTransport

Se você já construiu um jogo multiplayer, um painel de telemetria ao vivo ou uma ferramenta de colaboração em tempo real, provavelmente já atingiu o limite do que os WebSockets podem fazer confortavelmente. Um único fluxo ordenado funciona bem até deixar de funcionar — e quando um pacote lento bloqueia tudo que vem atrás dele, os usuários sentem isso imediatamente.

A API WebTransport foi projetada exatamente para este problema. Ela fornece aos navegadores um canal de comunicação de baixa latência sobre HTTP/3 que suporta tanto streams confiáveis quanto datagramas não confiáveis — sem o bloqueio head-of-line que vem com transportes baseados em TCP.

O Que a API WebTransport Realmente Faz

WebTransport estabelece uma conexão com um servidor HTTP/3 e expõe dois primitivos de comunicação distintos:

• Datagramas — pacotes não confiáveis, não ordenados e de baixo overhead. Pense em UDP, mas com criptografia e controle de congestionamento integrados.
• Streams — canais de dados confiáveis e ordenados. Múltiplos streams podem executar em paralelo sobre uma única conexão sem bloquear uns aos outros.

A principal diferença arquitetural em relação aos WebSockets é que o WebTransport opera sobre QUIC, um protocolo de transporte baseado em UDP. O QUIC trata cada stream independentemente, então um stream travado não atrasa os outros. WebSockets, construídos sobre TCP, não têm tal isolamento — uma mensagem lenta bloqueia toda a conexão.

Streams e Datagramas do WebTransport: Semântica de Entrega

Compreender as garantias de entrega é crítico antes de escolher qual primitivo usar.

Datagramas podem ser descartados ou chegar fora de ordem. Eles são limitados em tamanho pelo MTU do caminho. Use-os quando a atualidade importa mais do que a completude — entrada de jogos, leituras de sensores, posições de cursor.

Streams garantem entrega ordenada e confiável dentro de um determinado stream. Você pode abrir streams unidirecionais (cliente-para-servidor ou servidor-para-cliente) ou streams bidirecionais. Importante: a ordenação é garantida apenas dentro de um único stream, não entre múltiplos streams.

const transport = new WebTransport("https://example.com:4999/game")
await transport.ready

// Enviar um datagrama de baixa latência
const writer = transport.datagrams.writable.getWriter()
await writer.write(new Uint8Array([1, 2, 3]))

// Abrir um stream bidirecional confiável
const stream = await transport.createBidirectionalStream()
const streamWriter = stream.writable.getWriter()
await streamWriter.write(new Uint8Array([4, 5, 6]))

WebTransport vs WebSockets: Quando Usar Cada Um

Não é uma história de substituição — é uma história de adequação.

WebSockets continuam sendo a ferramenta certa quando você precisa de um único fluxo de mensagens confiável e a compatibilidade ampla importa. WebTransport ganha seu lugar quando sua aplicação genuinamente se beneficia de multiplexação ou pode tolerar entrega parcial.

Canais de dados WebRTC oferecem capacidades similares, mas requerem negociação ICE, servidores STUN/TURN e overhead significativo de configuração. WebTransport é mais simples para cenários cliente-servidor e funciona dentro de Web Workers.

Suporte de Navegadores e Requisitos de Infraestrutura

WebTransport requer um contexto seguro (HTTPS) e um servidor compatível com HTTP/3. É bem suportado em navegadores baseados em Chromium (Chrome, Edge) e ganhou suporte no Firefox. O suporte no Safari chegou mais recentemente. Ainda não é considerado universalmente baseline, então a detecção de recursos é essencial. Detalhes atuais de suporte podem ser verificados em webstatus.dev.

if ("WebTransport" in window) {
  // Usar WebTransport
} else {
  // Fallback para WebSocket
}

Para desenvolvimento local, webtransport.day fornece um servidor de eco mantido pela comunidade contra o qual você pode testar sem precisar configurar sua própria infraestrutura HTTP/3.

Conclusão

WebTransport não substitui WebSockets — ele estende o que é possível no navegador. O valor real é arquitetural: você agora pode enviar dados não confiáveis e sensíveis ao tempo junto com mensagens de controle confiáveis sobre uma única conexão, sem que um afete o outro. Para aplicações em tempo real onde latência e throughput ambos importam, essa é uma capacidade significativa para ter disponível.

Perguntas Frequentes

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.