WebTransport и WHIP-over-WebTransport

Последняя проверка: 2026-05-21 по черновику W3C WebTransport (Working Draft от 25 марта 2026; редакторы: N. Jaju, V. Vasiliev, J.-I. Bruaroey); драфту IETF draft-ietf-webtrans-http3-15 от 2 марта 2026 (авторы: A. Frindell, E. Kinnear, V. Vasiliev); драфту IETF draft-ietf-webtrans-overview-12 от января 2026; материалам рабочей группы IETF WISH и RFC 9725; уставу рабочей группы IETF MOQ и драфту draft-ietf-moq-transport-17 от 2 марта 2026; справочнику MDN по WebTransport; записям Chrome Platform Status; release notes Safari 26.4; release notes Firefox 114; и инженерным блогам Cloudflare и Meta о WebTransport-ингесте, опубликованным с 2024 по май 2026.

TL;DR

WebTransport – это браузерный транспорт поверх HTTP/3 и QUIC, который даёт JavaScript выбор между надёжными потоками (streams) и ненадёжными датаграммами (datagrams), без собственного сокета и без head-of-line блокировки. В марте 2026 Safari 26.4 вышел с WebTransport «из коробки» – после этой даты WebTransport получил статус Baseline (работает во всех современных браузерах без полифилов), и стеки ингеста, построенные на нём, перестали быть демо. Формальной спецификации «WHIP-over-WebTransport» нет и, скорее всего, не появится: рабочая группа WISH остаётся при RFC 9725 (WHIP поверх обычного HTTP), а рабочая группа MOQ доводит до ума Media over QUIC Transport – это драфт-17 от 2 марта 2026, в §1.1 которого прямо сказано, что MOQT «работает поверх QUIC и WebTransport». Эта статья – каноническая справка о том, что такое WebTransport, что в API на самом деле выставлено, где он стоит между WebRTC и Media over QUIC, и что в 2026 году подразумевают, когда говорят «WHIP-over-WebTransport».

Зачем это нужно

Если вы выбираете транспорт ингеста для продукта, которому нужна суб-секундная задержка из браузера, в 2026 году выбор уже не «WebRTC или ждать». WebTransport даёт браузеру чистую низкоуровневую трубу к серверу с тем же QUIC-стеком, что обслуживает HTTP/3, и хорошо сочетается с WebCodecs API: вы получаете возможность отправлять сырые кадры H.264, HEVC, AV1 или Opus, которые сами же и кодировали. Это принципиально другая модель по сравнению с WebRTC – нет SDP, нет Interactive Connectivity Establishment (механизма поиска сетевого пути через NAT), нет согласования кодеков, нет встроенного джиттер-буфера – и именно эту модель выбрало следующее поколение стриминговых протоколов, в первую очередь Media over QUIC.

Статья адресована продакт-менеджеру, основателю и стриминговому инженеру, которые слышали «WebTransport», «WHIP-over-WebTransport» и «Media over QUIC» в одном предложении и хотят понять, какая из этих фраз описывает реальный документ, какая – направление развития рабочей группы, а какая – тактическую ставку конкретного вендора в этом квартале. Вы выйдете из текста с ясной моделью того, что такое WebTransport, чем он отличается от WebRTC и WebSockets, и с защищаемым ответом на вопрос «стоит ли строить на нём прямо сейчас».

Что такое WebTransport – на одну страницу

WebTransport – это веб-API и протокол передачи данных, позволяющие веб-странице открывать к серверу мультиплексированное защищённое соединение с низкой задержкой поверх HTTP/3. Веб-API определён в W3C WebTransport Working Draft от 25 марта 2026 и выставляет в JavaScript единственный класс WebTransport. Вы конструируете его с URL по схеме https://, ждёте промис ready, после чего открываете надёжные байтовые потоки (createBidirectionalStream(), createUnidirectionalStream()) или отправляете ненадёжные датаграммы через атрибут datagrams. Под этим всем – QUIC, шифрованный транспорт из IETF RFC 9000, который уже несёт мировой HTTP/3 трафик.

Передача по проводу – это WebTransport over HTTP/3, описан в draft-ietf-webtrans-http3-15 (2 марта 2026, IETF, состояние Working Group Last Call). Клиент открывает HTTP/3 extended CONNECT – запрос со специальным заголовком :protocol = "webtransport-h3" – и ответ 2xx от сервера устанавливает «сессию» WebTransport внутри уже существующего HTTP/3 соединения. С этого момента в сессии можно открывать сколько угодно двунаправленных и однонаправленных QUIC-потоков, и отправлять и принимать QUIC-датаграммы по RFC 9221. Все потоки и датаграммы одной сессии демультиплексируются по Session ID – конкретно это идентификатор того QUIC-стрима, по которому ушёл сам CONNECT.

Три значения SETTINGS должны совпасть, прежде чем сервер вообще будет считаться поддерживающим протокол: SETTINGS_WT_ENABLED больше нуля, SETTINGS_ENABLE_CONNECT_PROTOCOL равно единице (из RFC 9220) и SETTINGS_H3_DATAGRAM равно единице (из расширения HTTP-Datagram). На уровне QUIC сервер дополнительно должен анонсировать max_datagram_frame_size > 0 (RFC 9221) и пустой transport parameter reset_stream_at. Браузер, который не увидит хотя бы одно из этого, даже не начнёт открывать сессию. Поэтому «мы поддерживаем WebTransport» – это не однострочное изменение конфига сервера.

Что делает WebTransport интересным для стриминга – это одновременная доступность двух режимов доставки на одном соединении. Надёжные потоки ведут себя как TCP (протокол, гарантирующий доставку и сохраняющий порядок), но каждый поток независим – потеря пакета на потоке 7 не блокирует поток 8, как это было бы на одном TCP-соединении. Ненадёжные датаграммы ведут себя как UDP (протокол «выстрелил и забыл») – пакеты могут переупорядочиться или потеряться, и приложение само решает, что с этим делать. Live-видеоприложение использует датаграммы для медиа-кадров, где свежесть важнее полноты, и надёжные потоки – для управляющих сообщений, где потеря недопустима. То же разделение всегда делал WebRTC через RTP и Stream Control Transmission Protocol; разница в том, что WebTransport выставляет оба режима как именованные JavaScript-примитивы, а не прячет их внутри RTCPeerConnection.

Нажмите, чтобы увеличить

Чем WebTransport не является

WebTransport не peer-to-peer. Нет Interactive Connectivity Establishment, нет STUN-сервера, нет TURN-сервера, нет сбора кандидатов, нет обмена SDP. Строго клиент-сервер: браузер открывает URL https:// так же, как это сделал бы обычный HTTP/3 запрос. Это не ограничение, а фича: убрав весь механизм NAT-обхода, мы убрали самую дорогую операционную головную боль WebRTC.

WebTransport также не медиа-протокол. Спецификация определяет транспорт – байты внутрь, байты наружу – и ничего не говорит ни про кодеки, ни про пакетизацию, ни про джиттер-буфер, ни про политику ретрансмиссии, ни про то, как разложить видеокадр на потоки и датаграммы. Эту работу нужно выполнять сверху: либо в коде вашего приложения (путь WebTransport + WebCodecs), либо внутри медиа-транспорта более высокого уровня, который вы строите поверх WebTransport (путь Media over QUIC).

И, наконец, WebTransport ещё не дописан. Документ W3C по-прежнему имеет статус Working Draft, а HTTP/3-маппинг находится в Working Group Last Call по состоянию на март 2026 – это значит, что небольшие ломающие изменения ещё могут попасть в спецификацию до Recommendation или RFC. Серверные библиотеки иногда отстают от Chromium и Firefox на одну ревизию драфта, что приводит к сбоям рукопожатия; W3C-«объяснение» прямо предупреждает, что «и протокол, и API ещё могут существенно измениться».

Поддержка в браузерах в 2026 – почему Baseline изменил расчёты

До 2025 года WebTransport работал в Chrome и Edge начиная с 97-й версии, в Firefox с 114-й и больше нигде. Не хватало Safari – а это весь iOS, плюс десктопный Safari, плюс каждое WKWebView-приложение на macOS. Протокол, который не работает в Safari, – это протокол, который нельзя отгрузить массовой аудитории. Поэтому любой честный ответ на «использовать ли WebTransport» с 2022 по 2025 был «пока нет».

Safari 26.4 вышел в марте 2026 с включённым по умолчанию WebTransport. Один этот релиз перевёл WebTransport из режима «превью в Chromium и Firefox» в Baseline – терминологию веб-платформы для «работает во всех основных браузерах без полифилов». С точки зрения продуктового решения момент, когда веб-API становится Baseline, – это момент, когда его возможности можно обещать клиенту, а не A/B-тестировать. Для WebTransport переход в Baseline случился в марте 2026; это самая чёткая отметка «production-ready» для браузерного ингеста на WebTransport.

Цифры, сверенные с caniuse.com и страницей публикаций рабочей группы W3C по состоянию на май 2026: Chrome 97+ (с января 2022), Edge 98+ (февраль 2022), Firefox 114+ (июнь 2023), Safari 26.4+ (март 2026), Opera 83+ (февраль 2022), Samsung Internet 18+ (середина 2022). На мобильных это означает Chrome на Android 97+, Firefox на Android 114+ и Safari на iOS 26.4+.

Как WebTransport сравнивается с WebRTC и WebSockets

Самый понятный способ позиционировать WebTransport – поставить его рядом с двумя протоколами, к которым JavaScript-разработчик тянулся до его появления. Напомним: WebSockets – это старый браузер-серверный примитив поверх TCP с текстовыми и бинарными сообщениями, строго упорядоченной и гарантированной доставкой. WebRTC – браузерный примитив для медиа (аудио, видео, дата-каналы), спроектированный для peer-to-peer работы с встроенным NAT-обходом.

Картина понятна. WebSockets выигрывает в универсальности и простоте; везде, где достаточно базового упорядоченного канала, в 2026 году WebSockets остаётся безопасным дефолтом. WebRTC выигрывает, когда нужен настоящий peer-to-peer медиа-канал, когда аудитория достаточно мала, чтобы Selective Forwarding Unit (сервер, размножающий поток одного публикатора на множество подписчиков) был избыточен, или когда вам нужен проверенный годами медиа-стек, который не надо писать самому. WebTransport выигрывает, когда клиент – это браузер, а пункт назначения – ваш сервер, когда вы хотите сами управлять медиа-конвейером и когда суб-секундная задержка важнее готовых медиа-фичей.

Числовой пример: конвейер ингеста на WebTransport

Допустим, вы хотите взять видеопоток с веб-камеры в браузере и доставить его на сервер с минимально возможной glass-to-glass задержкой, пользуясь только современными веб-API. Вот бюджет задержки по строкам.

Камера снимает на 30 кадров в секунду, интервал между кадрами – 1 секунда, делённая на 30, равно 33,3 миллисекунды.

Каждый кадр кодируется WebCodecs в H.264 с таргетом 2,5 мегабита в секунду; современный аппаратный кодер тратит 8–12 мс на key-frame и 4–8 мс на P-frame. Возьмём среднее значение кодера 8 мс.

Каждый закодированный кадр отправляется как одна WebTransport-датаграмма; кадры, выходящие за безопасный MTU 1200 байт, фрагментируются на несколько датаграмм с прикладным sequence number. Wire time на 100-мегабитном домашнем апстриме для 10-килобайтного кадра – 10000 байт умножить на 8 бит на байт и поделить на 100 миллионов бит в секунду, равно 800 микросекунд, плюс один RTT QUIC-уровня на ack-eliciting frames. При 20-миллисекундном RTT до ближайшего edge получаем округлённо 20 мс в проводе.

Серверный decode-and-forward на Go с библиотекой WebTransport занимает 3–5 мс. Возьмём 4 мс.

Итого contribution-задержка от появления кадра на камере до момента «у сервера есть кадр»: 33,3 + 8 + 20 + 4 = 65,3 мс, или примерно один кадр на 30 fps.

WebRTC-конвейер, делающий ту же работу, на contribution-стороне даёт 80–120 мс, потому что RTCPeerConnection добавляет ICE connectivity check (10–50 мс, платится один раз на старте сессии) и прогрев джиттер-буфера (40–80 мс, платится при каждом рестарте). У WebTransport в стационарном режиме contribution-задержка примерно равна WebRTC; задержка установки ниже, потому что ICE-проверки выполнять не надо.

Что на самом деле означает «WHIP-over-WebTransport» в 2026

Это раздел, в котором тема перестаёт быть аккуратной. Драфта IETF под названием «WHIP-over-WebTransport» не существует. Поиск по datatracker IETF в мае 2026 не находит документа с таким именем ни в WISH, ни где-либо ещё. Два выхода рабочей группы WISH – это RFC 9725, описывающий WHIP поверх обычного HTTP, и draft-ietf-wish-whep-03, описывающий WHEP-egress поверх обычного HTTP. WebTransport нигде в этих текстах не упоминается.

То, что подразумевают под «WHIP-over-WebTransport» на практике, – это одна из двух близких вещей.

Первая – вариант WHIP, в котором обмен SDP происходит по двунаправленному стриму WebTransport вместо HTTP POST. Мотивация в том, что сегодня браузерный WHIP-клиент вынужден открывать одно HTTP/1.1 или HTTP/2 соединение для POST, а затем поднимать отдельный WebRTC PeerConnection для медиа – два соединения, два рукопожатия, два пути по сети. Вариант WHIP-over-WebTransport позволил бы браузеру открыть одно HTTP/3 соединение, выполнить SDP-обмен через управляющий стрим внутри него и нести медиа через датаграммы или однонаправленные стримы на том же соединении. Прототипы у нескольких вендоров существуют; ни один не принят рабочей группой IETF.

Вторая – и в 2026 это интерпретация важнее – это проект Media over QUIC Transport (MOQT), сейчас draft-ietf-moq-transport-17 от 2 марта 2026. Media over QUIC – это рабочая группа IETF, созданная в 2022 году для нового медиа-транспорта, который работает нативно на QUIC и WebTransport, имеет publish-subscribe-семантику, опциональные промежуточные relay-узлы для CDN-подобной раздачи и чёткое разделение транспорта (MOQT) и медиа-контейнеров (Low Overhead Media Container, WARP и др.). MOQT – это то, чем «WHIP-over-WebTransport» всегда должен был стать; это явный ответ на вопрос «как должен выглядеть чистый WebRTC-replacement протокол ингеста, если строить его с нуля поверх QUIC».

Media over QUIC Transport draft 17, §1.1, прямо называет варианты транспорта: "MOQT runs over QUIC and WebTransport, which have similar functionality." Именно это предложение лежит за каждым разговором о «WebTransport для стриминга» в 2026. Браузерный ответ на «как мне завести live-медиа в relay-сеть в 2026 году» – это уже не WHIP, а MOQT-over-WebTransport. Нативный ответ – MOQT-over-QUIC.

MOQT мы подробно разбираем в Media over QUIC (MoQ): поворотная точка 2026 года и в общем дереве протоколов доставки. По общим вопросам выбора ингест-протокола смотрите Как выбрать ингест-протокол в 2026: дерево решений.

Нажмите, чтобы увеличить

Что строить на WebTransport уже сегодня – три рабочих паттерна

Паттерн один: WebTransport + WebCodecs, всё своими руками. Вы захватываете поток через getUserMedia, конвертируете MediaStreamTrack в сырые VideoFrame и AudioData через MediaStreamTrackProcessor, кодируете каждый кадр в VideoEncoder, отправляете закодированные чанки через WebTransport-датаграмму или однонаправленный стрим, и декодируете на сервере. Репозитории Meta facebookexperimental/webcodecs-capture-play и facebookexperimental/go-media-webtransport-server – это публичные референсные реализации. Twitch и YouTube Live отгружали прототипы по этому паттерну с заявленными суб-секундными цифрами glass-to-glass. Паттерн работает уже сегодня; работа по его внедрению – это код приложения, а не поддержка браузеров.

Паттерн два: WHIP сегодня, WHIP-over-WebTransport завтра. Используйте WHIP, стандартизированный в RFC 9725, уже сейчас – он работает, он совместим, любой современный кодер его говорит – а WebTransport добавляйте параллельным путём ингеста, как только появится драфт и Safari накопит год стабильного поведения. Это консервативный выбор. Большая часть продакшен-стриминговых платформ в 2026 идёт именно этим путём.

Паттерн три: MOQT поверх WebTransport, езжайте на волне. Берёте раннюю MOQT-relay реализацию (Cloudflare-овский Rust-стек cloudflare/moq-rs, MOQT-поддержку Ant Media с 2025, референсный Go-сервер mengelbart/moqtransport), строите браузерную сторону на W3C WebTransport API + WebCodecs и принимаете риск изменений драфта в обмен на то, чтобы оказаться на протоколе, вокруг которого сознательно строится следующее поколение CDN. Это агрессивный выбор; подходит проектам с горизонтом 12–24 месяца и командой, способной отслеживать ревизии драфтов.

Частая ошибка: воспринимать WebTransport как «WebSocket побыстрее»

Самая распространённая ошибка команд, начинающих с WebTransport, – предположение, что это «WebSocket, но поверх QUIC». Архитектурно это не так. WebSockets даёт один надёжный упорядоченный канал сообщений; WebTransport даёт много независимых надёжных байтовых стримов плюс ненадёжные датаграммы на одном соединении. Если вы прямо портируете WebSocket-протокол в один двунаправленный стрим WebTransport, вы построили WebSocket-over-QUIC и оставили главное преимущество WebTransport – независимые стримы и ненадёжные датаграммы – за бортом.

Правильный порт – это пересмотр типов сообщений. Управляющие сообщения – на отдельный управляющий стрим. Состояние, которое должно приходить по порядку, – на независимые надёжные стримы (по одному на логический подканал, чтобы медленный канал не блокировал быстрый). Медиа-кадры и другие «свежее лучше, чем полное» – на датаграммы. Слой данных становится шире и тоньше, чем WebSocket-эквивалент, а поведение под потерями кардинально улучшается.

Заметки по безопасности и эксплуатации

WebTransport требует TLS 1.3 – нет ни plain-text режима, ни downgrade. Дефолтная модель доверия использует ту же Web Public Key Infrastructure, что и любая страница https://, поэтому обычный TLS-сертификат от любого браузер-trusted удостоверяющего центра работает. В Working Draft также определена опция serverCertificateHashes, которая позволяет странице явно принять сервер по отпечатку сертификата – это полезно для прототипов против ad-hoc серверов без публично-доверенного сертификата; опция взаимоисключающая с allowPooling, и сертификат должен удовлетворять «специальным требованиям» спецификации (в частности, ограничение по максимальному сроку действия).

С эксплуатационной стороны, серверам WebTransport нужен HTTP/3, что означает доступность UDP-порта 443 от вашей аудитории. В средах, где UDP/443 фильтруется – нетривиальная доля корпоративных сетей и часть мобильных операторов – WebTransport не подключится без автоматического fallback на TCP. Это реальное ограничение, которое уменьшает потолок достижимости WebTransport по сравнению с WebSockets-over-TCP, который ходит везде, где ходит HTTPS. Продакшен-деплой WebTransport в 2026 году должен предусмотреть запасной путь – обычно WebSockets или WebRTC – и измерять долю пользователей, у которых попытка соединения WebTransport проваливается.

Connection migration в QUIC, при котором соединение переживает смену IP-адреса (например, при переходе телефона с Wi-Fi на сотовую сеть), поддерживается прозрачно на серверной стороне. Веб-API не выставляет хук миграции – коду приложения не нужно знать, что нижележащее соединение только что переехало между сетями.

Где здесь Фора Софт

Фора Софт строит live-видео-продукты на каждом contribution-протоколе от RTMP до SRT и WHIP, включая прототипы на WebTransport. Наша работа охватывает стриминговые платформы, e-learning, телемедицину, видеонаблюдение, OTT, конференции и AR/VR-видео. Мы постоянно отслеживаем драфты WebTransport, WHIP и Media over QUIC, потому что правильный ответ клиенту с пятилетней roadmap отличается от правильного ответа клиенту, которому нужно отгрузить продукт в следующем квартале. Когда требования по задержке падают ниже одной секунды, а аудитория browser-first, мы обычно рекомендуем WHIP поверх WebRTC сегодня и плановую миграцию на MOQT-over-WebTransport позже; мы охотно разберём компромиссы для вашего конкретного деплоя.

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

• WebTransport – это HTTP/3-over-QUIC для браузера, выставляющий надёжные стримы и ненадёжные датаграммы на одном соединении.
• Baseline-поддержка появилась в марте 2026 с выходом Safari 26.4 – Chrome, Edge, Firefox и Safari все его поддерживают.
• Никакого «WHIP-over-WebTransport» драфта IETF нет; реальный стандартный путь – это MOQT draft-17.
• WebTransport заменяет транспорт, не медиа-стек – соедините с WebCodecs или MOQT для ингеста видео.
• Потолок достижимости ниже, чем у WebSockets, потому что часть сетей фильтрует UDP-порт 443.

Что почитать дальше

• WebRTC-ингест и стандарт WHIP (RFC 9725)
• QUIC: новый транспортный уровень
• Media over QUIC (MoQ): поворотная точка 2026 года

Что делать дальше

• Поговорить с инженером по стримингу. Разберём вместе с senior-инженером Фора Софт ваш таргет по задержке, профиль аудитории и существующий стек; скажем, имеет ли смысл WebTransport-ингест в этом году или лучше подождать до 2027.
• Посмотреть наши кейсы. Live-видео-проекты Фора Софт на www.forasoft.com показывают, как выбор contribution-протокола разворачивался в продакшене.
• Скачать памятку WebTransport vs WHIP vs MoQ. Одна страница с тем, где каждый протокол выигрывает в 2026 году, со ссылками на конкретные пункты спецификаций. Скачать памятку.