WebTransport: streams, datagrams, HTTP/3 и когда это использовать

WebTransport — это браузерная API для двусторонней клиент-серверной коммуникации поверх HTTP/3. Она дает веб-приложениям два стиля транспорта в одном соединении: надежные streams и ненадежные datagrams.

Это полезно для low-latency приложений, но не является прямой заменой для каждого случая WebSocket или WebRTC. Лучший способ оценить WebTransport — начать с traffic pattern, который нужен вашему приложению.

Что такое WebTransport

WebTransport позволяет браузеру подключиться к HTTP/3-серверу и обмениваться данными через:

Надежные streams: упорядоченные byte streams для данных, которые должны прийти корректно.
Ненадежные datagrams: best-effort сообщения для данных, где низкая задержка важнее гарантированной доставки.

Он работает в secure contexts, поэтому HTTPS следует считать обязательным. Также нужна поддержка HTTP/3 в браузере, сервере, сетевом пути, CDN и proxy слоях.

Справочные материалы:

Ментальная модель

Думайте о WebTransport соединении как о session, которая может нести несколько независимых каналов.

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

Главная идея: разные данные могут использовать разные правила доставки. Подтверждение платежа не должно отправляться как обновление позиции игрока. Обновление позиции не должно ждать за большой передачей файла.

Streams vs Datagrams

Свойство	Streams	Datagrams
Доставка	Надежная	Best effort
Порядок	Упорядочено внутри stream	Не гарантируется
Лучше для	Файлов, команд, чата, транзакций	Game state, telemetry, live cursors
Обработка потерь	Transport обеспечивает надежность	App должна терпеть потери
Тип данных	Byte chunks	Отдельные сообщения

Используйте streams, когда важна корректность. Используйте datagrams, когда самый новый value важнее всех старых.

WebTransport vs WebSocket

WebSocket остается более простым вариантом по умолчанию для многих приложений. Он широко внедрен, проще проходит через proxy и поддерживается зрелой экосистемой.

WebTransport становится интересным, когда нужны:

Несколько независимых streams в одной session.
Ненадежные low-latency сообщения.
Меньше head-of-line blocking между независимыми потоками данных.
Современный client-server transport на основе HTTP/3.

Используйте WebSocket, когда:

Нужен только один надежный упорядоченный поток сообщений.
Нужна максимальная совместимость с текущей инфраструктурой.
Сервер, CDN или корпоративные сети не поддерживают HTTP/3 надежно.
Нужен самый простой операционный путь.

Не мигрируйте рабочее WebSocket-приложение только потому, что WebTransport новее. Мигрируйте только когда traffic pattern выигрывает от streams, datagrams или поведения HTTP/3.

WebTransport vs WebRTC Data Channels

WebRTC data channels созданы для peer-to-peer или media-heavy real-time систем. WebTransport — client-server.

Используйте WebRTC, когда:

Браузеры должны общаться peer-to-peer.
Audio/video negotiation уже часть приложения.
Нужны NAT traversal patterns, которые берет на себя WebRTC-инфраструктура.

Используйте WebTransport, когда:

Браузер говорит с вашим сервером, а не напрямую с другим браузером.
Нужна web-platform-style Streams API.
Не нужен полный WebRTC stack.

Если у вас уже есть стабильная WebRTC-система, WebTransport может не дать достаточно упрощения для переписывания.

Базовый клиентский паттерн

Всегда проверяйте поддержку перед использованием 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");

В production оберните это fallback-логикой. Если WebTransport недоступен или подключение не удалось, переключайтесь на WebSocket, Server-Sent Events или обычный HTTP в зависимости от функции.

Отправка datagrams

Datagrams хорошо подходят для частых обновлений состояния, где старые сообщения быстро теряют ценность.

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

Проектируйте payloads datagram так, чтобы каждое сообщение было самостоятельным. Не рассчитывайте получить все предыдущие datagrams.

Хорошие datagram payloads:

Текущая позиция игрока.
Последняя позиция курсора.
Показание сенсора.
Typing или presence heartbeat.
Состояние live preview.

Плохие datagram payloads:

Платежные действия.
Изменения аккаунта.
Упорядоченные правки документа.
Все, что должно быть audit-ready.

Использование надежных Streams

Streams лучше, когда получатель должен получить все bytes по порядку.

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

Создавайте отдельные streams для независимых операций. Тогда большая передача не будет блокировать маленькое control message.

Production checklist

Перед запуском WebTransport проверьте весь путь:

Поддержка браузеров для вашей аудитории.
Поддержка HTTP/3 на сервере.
TLS certificate и secure context.
Поведение UDP и QUIC через firewalls и корпоративные сети.
Поддержка CDN или reverse proxy.
Load balancing для long-lived sessions.
Monitoring connection failure, retry rate и fallback usage.
Backpressure handling для streams.
Message size limits для datagrams.
Authentication и authorization при старте session.

Самая сложная часть часто не browser API, а network и server deployment.

Fallback стратегия

Практичный fallback plan:

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

Сохраняйте product behavior последовательным даже при смене транспорта. Например, dashboard может работать с более медленным polling; игре может понадобиться отключить real-time room, если low-latency transport недоступен.

Когда WebTransport подходит

WebTransport стоит оценить, когда приложение смешивает надежные данные и low-latency best-effort данные:

Multiplayer game state плюс надежные match events.
Collaborative editing cursors плюс надежные document operations.
Live dashboards с частой telemetry плюс надежные control commands.
Remote device control со status updates и command streams.
Media-adjacent apps, которым нужны server-side real-time data channels.

Общий паттерн — mixed traffic. Некоторые данные должны прийти. Некоторые должны быть свежими.

Когда не использовать

Избегайте WebTransport, когда:

Обычного REST или fetch API достаточно.
Один WebSocket stream решает задачу чисто.
Нужна широкая совместимость со старыми браузерами.
Deployment stack не может надежно поддерживать HTTP/3.
Нужна browser-to-browser peer-to-peer коммуникация.
Команда не хочет обслуживать transport-level fallbacks.

Более новая transport technology полезна только тогда, когда снижает реальную product pain.

Итог

WebTransport дает браузерным приложениям современный HTTP/3 client-server transport с надежными streams и ненадежными datagrams. Его ценность не в том, чтобы заменить WebSocket везде. Ценность в том, что одна session может нести разные виды real-time данных с разными требованиями к доставке.

Используйте его, когда приложению действительно нужна эта гибкость, и поставляйте с feature detection, fallbacks и production monitoring.