Низколатентная коммуникация в браузере с WebTransport

Если вы когда-либо разрабатывали многопользовательскую игру, дашборд телеметрии в реальном времени или инструмент для совместной работы, вы наверняка сталкивались с ограничениями возможностей WebSockets. Единственный упорядоченный поток работает нормально до тех пор, пока не перестаёт — и когда один медленный пакет блокирует всё, что идёт за ним, пользователи это сразу ощущают.

WebTransport API разработан именно для решения этой проблемы. Он предоставляет браузерам низколатентный канал связи поверх HTTP/3, который поддерживает как надёжные потоки, так и ненадёжные датаграммы — без блокировки начала очереди (head-of-line blocking), характерной для транспортов на основе TCP.

Что на самом деле делает WebTransport API

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

• Датаграммы — ненадёжные, неупорядоченные пакеты с низкими накладными расходами. Представьте себе UDP, но со встроенным шифрованием и контролем перегрузки.
• Потоки — надёжные, упорядоченные каналы данных. Множественные потоки могут работать параллельно через одно соединение без взаимной блокировки.

Ключевое архитектурное отличие от WebSockets заключается в том, что WebTransport работает поверх QUIC — транспортного протокола на основе UDP. QUIC обрабатывает каждый поток независимо, поэтому заблокированный поток не задерживает другие. WebSockets, построенные на TCP, не имеют такой изоляции — одно медленное сообщение блокирует всё соединение целиком.

Потоки и датаграммы WebTransport: семантика доставки

Понимание гарантий доставки критически важно перед выбором того, какой примитив использовать.

Датаграммы могут быть потеряны или прийти не по порядку. Их размер ограничен MTU пути. Используйте их, когда свежесть данных важнее полноты — игровой ввод, показания датчиков, позиции курсора.

Потоки гарантируют упорядоченную, надёжную доставку в рамках данного потока. Вы можете открывать однонаправленные потоки (клиент-сервер или сервер-клиент) или двунаправленные потоки. Важно отметить, что упорядоченность гарантируется только внутри одного потока, а не между несколькими потоками.

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

// Отправка низколатентной датаграммы
const writer = transport.datagrams.writable.getWriter()
await writer.write(new Uint8Array([1, 2, 3]))

// Открытие надёжного двунаправленного потока
const stream = await transport.createBidirectionalStream()
const streamWriter = stream.writable.getWriter()
await streamWriter.write(new Uint8Array([4, 5, 6]))

WebTransport vs WebSockets: когда использовать каждый из них

Это не история о замене — это история о соответствии задаче.

WebSockets остаются правильным инструментом, когда вам нужен единственный надёжный поток сообщений и важна широкая совместимость. WebTransport занимает своё место, когда ваше приложение действительно выигрывает от мультиплексирования или может допустить частичную доставку.

Каналы данных WebRTC предлагают аналогичные возможности, но требуют согласования ICE, серверов STUN/TURN и значительных накладных расходов на настройку. WebTransport проще для сценариев клиент-сервер и работает внутри Web Workers.

Поддержка браузерами и требования к инфраструктуре

WebTransport требует безопасного контекста (HTTPS) и сервера с поддержкой HTTP/3. Он хорошо поддерживается в браузерах на основе Chromium (Chrome, Edge) и получил поддержку в Firefox. Поддержка Safari появилась относительно недавно. Он ещё не считается универсально базовым, поэтому обнаружение функциональности обязательно. Текущие детали поддержки можно проверить на webstatus.dev.

if ("WebTransport" in window) {
  // Использовать WebTransport
} else {
  // Откат на WebSocket
}

Для локальной разработки webtransport.day предоставляет поддерживаемый сообществом эхо-сервер, с которым вы можете тестировать без развёртывания собственной HTTP/3 инфраструктуры.

Заключение

WebTransport не заменяет WebSockets — он расширяет возможности браузера. Реальная ценность заключается в архитектуре: теперь вы можете отправлять ненадёжные, чувствительные ко времени данные вместе с надёжными управляющими сообщениями через одно соединение, без взаимного влияния. Для приложений реального времени, где важны и латентность, и пропускная способность, это значимая возможность.

Часто задаваемые вопросы

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.