WebTransport: будущее real-time в браузере

Онлайн-шутер. 20 игроков, позиции обновляются 20 раз в секунду. WebSocket: один TCP-пакет потерян - все 400 сообщений/сек замораживаются до retransmit. Spike 100-300мс. В шутере это смерть. WebTransport датаграммы: потеря - следующая позиция придёт через 50мс. Это и есть разница.

• **Google Meet**: эксперименты с WebTransport для снижения jitter видео. QUIC позволяет независимо передавать аудио и видео потоки без взаимной блокировки
• **Cloudflare Workers**: поддержка WebTransport с 2023. Edge-сервера с HTTP/3 + WebTransport для глобального low-latency real-time
• **Unity WebGL**: рассматривает WebTransport как замену WebSocket для браузерных игр. Датаграммы для позиций, надёжные потоки для игровых событий

WebTransport: QUIC вместо TCP для браузеров

2022 год. Chrome и Firefox поддерживают WebTransport - браузерный API поверх HTTP/3 (QUIC). QUIC работает поверх UDP, но с надёжностью TCP и TLS 1.3 встроенными. Ключевое: QUIC устраняет head-of-line blocking, от которого страдает WebSocket (поверх TCP): потеря одного пакета блокирует только один поток, не все.

WebTransport предоставляет два режима: датаграммы (UDP-семантика: быстро, без гарантии) и потоки (TCP-семантика: надёжно, упорядоченно). Можно открыть N независимых потоков - потеря пакета в одном не блокирует другие. Это невозможно в WebSocket: один TCP-поток, одна очередь пакетов.

QUIC-параллель: HTTP/2 multiplexing решил head-of-line blocking на уровне HTTP - несколько запросов по одному TCP-соединению. Но если TCP-пакет теряется, буферизация блокирует ВСЕ HTTP/2 потоки. QUIC решает это на транспортном уровне: каждый QUIC stream независим. WebTransport - это HTTP/2 multiplexing, исправленный.

Датаграммы: unreliable delivery для real-time

Датаграммы - UDP-семантика в браузере. Нет гарантии доставки, нет порядка, нет retransmission. Для real-time данных это плюс: устаревшая позиция игрока в 50 мс не нужна - новая придёт через 50 мс. Retransmit создал бы latency spike, а датаграмма просто теряется. Game-changer для игр, голоса, видео.

MTU ограничение: датаграммы ограничены размером QUIC пакета (~1200 байт). Для больших данных - потоки. Практика: позиции игроков (20-50 байт) → датаграммы. Загрузка карты (MB) → поток. WebRTC DataChannel тоже поддерживает unreliable mode, но WebTransport проще в настройке (нет ICE/STUN/TURN).

Потоки: multiplexing без head-of-line blocking

WebTransport потоки - надёжные, упорядоченные, как TCP, но независимые. Каждый поток - отдельная QUIC stream. Потеря пакета в потоке 'чат' не блокирует поток 'игровые события'. Это решает главную проблему WebSocket: один TCP-поток = одна очередь = head-of-line blocking для всего.

WebTransport vs WebSocket: когда что выбрать

WebTransport не убивает WebSocket - разные задачи. WebSocket: широкая поддержка (все браузеры с 2011), простота, идеален для чатов/уведомлений где latency некритична. WebTransport: cutting-edge (Chrome 97+, Firefox 114+, Safari экспериментально), нужен HTTP/3 сервер, сложнее в настройке, но без head-of-line blocking.

Production-статус: WebTransport используется в Zoom Web Client (для снижения jitter), Google Meet, и экспериментально в онлайн-играх. Cloudflare поддерживает WebTransport на Workers. Основной барьер: HTTP/3 серверная инфраструктура сложнее HTTP/2, и браузерная поддержка пока неполная. Прогноз: через 2-3 года WebTransport станет стандартом для real-time в браузере.

Связанные темы

WebTransport - следующий этап эволюции браузерных real-time протоколов:

• WebSocket Protocol — WebSocket - основной аналог. WebTransport решает head-of-line blocking которого нет в WebSocket
• Сравнение подходов — WebTransport занимает место в матрице: надёжность vs latency vs browser support
• Pub/Sub паттерн — WebTransport потоки и датаграммы реализуют pub/sub и streaming паттерны по-новому

Ключевые идеи

• **WebTransport = QUIC в браузере**: поверх HTTP/3, TLS 1.3 встроен. Устраняет head-of-line blocking TCP.
• **Датаграммы**: unreliable, unordered. UDP-семантика для игровых позиций, голоса, видео - потеря лучше retransmit.
• **Независимые потоки**: N потоков в одном соединении. Потеря пакета в потоке A не блокирует поток B.
• **WebSocket vs WebTransport**: WebSocket - 99% браузеров, просто, для чата. WebTransport - Chrome/Firefox, HTTP/3 нужен, для игр/видео.
• **Статус 2024**: production в Google Meet, Cloudflare. Safari экспериментально. Стандарт через 2-3 года.

Вопросы для размышления

• WebTransport требует HTTP/3 сервер. Как оценить стоимость миграции инфраструктуры (nginx → caddy/quiche) для конкретного проекта?
• Датаграммы ограничены MTU (~1200 байт). Как проектировать игровые сообщения позиций для 60 игроков в этом ограничении?
• WebRTC тоже поддерживает unreliable DataChannel. Когда выбрать WebRTC, а когда WebTransport для браузерной игры?

Связанные уроки

• rt-15 — MQTT - другой end of spectrum: IoT vs браузерный real-time
• rt-04 — WebSocket - основной аналог для сравнения
• rt-17 — WebTransport реализует pub/sub и streaming паттерны с QUIC
• net-03-physical — QUIC поверх UDP - важно понимать network stack
• rt-06 — WebTransport расширяет сравнение протоколов: новое поколение
• net-24-http2-http3