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 «из коробки» – после этой даты технология получила статус 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, и отлично работает с API WebCodecs: теперь можно отправлять сырые кадры 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) и пустой транспортный параметр 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, плюс каждое приложение на macOS, использующее WKWebView. Протокол, который не поддерживается в 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

Допустим, вы хотите получить видеопоток с веб-камеры в браузере и передать его на сервер с минимально возможной задержкой от экрана до экрана, используя только современные веб-API. Ниже – разбивка задержки по этапам.

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

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

Каждый закодированный кадр передаётся как одна WebTransport-датаграмма; кадры, превышающие безопасный MTU в 1200 байт, фрагментируются на несколько датаграмм с прикладным номером последовательности. Время передачи на 100-мегабитном домашнем апстриме для кадра объёмом 10 килобайт составляет: 10 000 байт умножить на 8 бит в байте и разделить на 100 миллионов бит в секунду – получается 800 микросекунд, плюс один RTT на уровне QUIC для фреймов, вызывающих подтверждение. При RTT в 20 миллисекунд до ближайшего 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-соединения (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 для ингеста, если разрабатывать его с нуля поверх 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 по этому паттерну демонстрировали заявленные субсекундные задержки от экрана до экрана. Паттерн работает уже сегодня – его внедрение требует написания прикладного кода, а не поддержки браузерами.

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

Паттерн три: MOQT поверх WebTransport, езжайте на волне. Берёте раннюю реализацию MOQT-ретранслятора (Rust-стек от Cloudflare 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 поверх QUIC и упускаете главное преимущество WebTransport – независимые потоки и ненадёжные датаграммы.

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

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

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

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

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

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

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

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

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

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

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

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

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