HTTP/1.1, HTTP/2, HTTP/3: что изменилось и что это значит для стриминга

Опубликовано: 2026-05-20 · Время чтения: 28 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-20 со стандартами: IETF RFC 9112 (HTTP/1.1, июнь 2022), RFC 9113 (HTTP/2, июнь 2022), RFC 9114 (HTTP/3, июнь 2022), RFC 9110 (HTTP Semantics, июнь 2022), RFC 9204 (QPACK: Field Compression for HTTP/3, июнь 2022), RFC 7541 (HPACK, май 2015), RFC 9000 (QUIC v1, май 2021), Apple HLS Authoring Specification revision 2025-09, и снимки данных Cloudflare Radar / W3Techs за апрель–май 2026.

TL;DR

HTTP – это прикладной протокол, на котором едет 99 % видео в публичном интернете: каждый HLS-манифест, каждый DASH-сегмент, каждый запрос ключа, каждый аналитический бикон. HTTP/1.1 (RFC 9112) – текстовый протокол, один запрос за раз на одно TCP-соединение, и до сих пор дефолт для половины длинного хвоста веба в 2026 году. HTTP/2 (RFC 9113) – бинарный, мультиплексированный на одном TCP-соединении, и всё ещё страдает от TCP-уровневого head-of-line blocking – один потерянный пакет стопорит все одновременные стримы. HTTP/3 (RFC 9114) заменяет TCP на QUIC поверх UDP, убирает блокировку на транспорте, даёт каждому запросу свой независимый стрим и в 2026 году по умолчанию включён на каждом крупном CDN. Для стриминг-продукта правило простое: отдавайте HTTP/3 первым с автоматическим фолбэком на HTTP/2 и затем HTTP/1.1, никогда не полагайтесь на HTTP/2 server push (он мёртв во всех мейнстрим-браузерах с 2024 года) и проектируйте origin и плеер под тот профиль задержки сегмента, который реально есть у вашей аудитории.

Зачем это понимать

Видео в публичном интернете – это, почти без исключений, видео поверх HTTP. Live-HLS-стрим – это последовательность HTTP GET за .m3u8-плейлистами и .ts / .m4s-сегментами. Эпизод Netflix – последовательность HTTP GET за .mpd и CMAF-сегментами DASH. Телемедицинская сессия, которая пишется в облачное хранилище, загружает запись HTTP PUT'ами. WebRTC-продукт по-прежнему использует HTTP для сигнального канала, для API учёток TURN, для аналитики. Версия HTTP под всем этим – 1.1, 2 или 3 – задаёт пол времени запуска плеера, частоту ребуферов и поведение в момент, когда телефон уходит из Wi-Fi на 5G. Продакт-менеджер, основатель или инженер-лид, который ошибётся с дефолтом в 2026 году, отгрузит плеер, который на мобильных будет на 400–800 миллисекунд медленнее, чем мог бы. Это разница между метрикой запуска, за которую борд хвалит, и метрикой, к которой борд задаёт вопросы. Эта статья объясняет, что именно делает каждая версия, где каждая выигрывает и проигрывает и как выбрать правильные дефолты для стриминг-продукта в 2026 году.

Что такое HTTP, в одном абзаце

HTTP – Hypertext Transfer Protocol – это прикладной протокол, который определяет, как клиент (браузер, видеоплеер, мобильное приложение) запрашивает у сервера ресурс и как сервер отвечает. Он сидит наверху сетевого стэка: над транспортом (TCP или QUIC), над слоем безопасности (TLS), над сетью (IP). У каждого HTTP-запроса есть метод (GET, POST, PUT, DELETE), URL и набор заголовков; у каждого ответа – код статуса (200, 304, 404), набор заголовков и тело. Семантика – что запрос значит, что значат коды статусов – не менялась с 1990-х и теперь кодифицирована в одном документе, RFC 9110 (июнь 2022). Что менялось – это то, как этот семантический разговор кодируется на проводе и как запросы мультиплексируются, когда их одновременно много. Это «на проводе» – и есть то, что мы имеем в виду под «HTTP/1.1», «HTTP/2» и «HTTP/3». Для стриминг-продукта кодировка определяет время до первого кадра, частоту ребуферов и стоимость каждого дополнительного одновременного стрима, который открывает плеер.

30 секунд истории версий HTTP

HTTP/0.9 (1991) был протоколом в одну строку: GET /index.html, и сервер возвращал документ. HTTP/1.0 (RFC 1945, май 1996) добавил заголовки, коды статусов и content types – разговор стал согласуемым. HTTP/1.1 (RFC 2068, январь 1997; ревизии через RFC 2616 в 1999, потом RFC 7230–7235 в 2014, потом RFC 9112 в июне 2022) добавил persistent connections, request pipelining (на практике брошенный), виртуальный хостинг через заголовок Host, chunked transfer encoding, range requests (фича, благодаря которой HTTP-стриминг вообще возможен) и семантику кэширования. HTTP/2 (RFC 7540, май 2015; ревизия в RFC 9113, июнь 2022) – это семантика HTTP/1.1 поверх нового бинарного фрейминга, с мультиплексированными стримами на одном TCP-соединении, header compression (HPACK) и злосчастной фичей server push. HTTP/3 (RFC 9114, июнь 2022) переносит ту же семантику на QUIC (RFC 9000, май 2021) – UDP-транспорт с TLS 1.3, независимыми стримами и без TCP-овской blocking-проблемы. Четыре версии, три из них в продакшене. Задача стриминг-инженера – знать, чего стоит и что даёт каждая.

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

HTTP/1.1 подробно – и почему он всё ещё актуален в 2026

Что нужно помнить про HTTP/1.1, который в 2026 году по-прежнему обслуживает около 27 % измеренного веб-трафика, – это то, что протокол двигает один запрос за раз на соединение. TCP-соединение остаётся открытым между запросами – это и есть «persistent connection», и с RFC 9112 это поведение по умолчанию, без заголовка Connection: Keep-Alive – но цикл «запрос-ответ» последовательный. Клиент отправляет запрос, ждёт от сервера полный ответ, затем отправляет следующий. Браузеры обходили серийный лимит, открывая параллельные TCP-соединения к одному хосту: шесть на origin в большинстве десктопных браузеров, четыре – на мобильных.

Есть фича pipelining – клиент отправляет несколько запросов подряд, не дожидаясь первого ответа, а сервер отвечает в том же порядке. RFC 9112 её всё ещё определяет, но на практике каждый крупный браузер отключил pipelining десять лет назад и больше не включал. Причина: pipelining в HTTP/1.1 связан жёстким порядком «запрос-ответ», и один медленный ответ стопорит каждый последующий ответ в том же соединении. Это называется head-of-line blocking на прикладном уровне и это тот самый первородный грех, который HTTP/2 был спроектирован починить.

Для видеоплеера последствия конкретные. Типичная ABR-сессия по HTTP/1.1 открывает шесть TCP-соединений к CDN edge и переиспользует их под манифест, ключ и фетчи сегментов. Время первого кадра определяется тремя круговыми рейсами TCP- и TLS-хендшейков до того, как можно запросить первый манифест, плюс RTT на сам манифест, плюс RTT на первый сегмент. На линке с 80 мс RTT это пол в 320–400 мс до того, как декодер увидит первый байт. Recovery потерь происходит на TCP-уровне прозрачно для HTTP. Range requests (заголовок Range: bytes=…) делают возможной загрузку по байтовым диапазонам, что использует каждый современный HLS- и DASH-плеер для адресации внутри фрагментированного MP4.

Сильные стороны HTTP/1.1 в 2026 году – простота и универсальность. Его говорит каждый балансировщик, каждый reverse proxy, каждый CDN, каждое встраиваемое устройство. Слабые стороны – лимит в шесть соединений на origin и последовательный цикл «запрос-ответ». Для видеоплеера, тянущего десяток ресурсов манифеста, ключей, аудио и видео в первую секунду воспроизведения, эти шесть соединений становятся бутылочным горлышком.

HTTP/2 подробно – мультиплексирование, HPACK и кладбище server push

HTTP/2, стандартизованный в RFC 7540 в мае 2015 и заменённый RFC 9113 в июне 2022, сохранил семантику HTTP и сменил формат «на проводе». Текстовое «заголовки, пустая строка, тело» HTTP/1.1 стало бинарным потоком фреймов. У каждого фрейма есть идентификатор стрима и тип – HEADERS, DATA, SETTINGS, WINDOW_UPDATE, RST_STREAM, PRIORITY, PING, GOAWAY, PUSH_PROMISE. Несколько стримов едут на одном TCP-соединении одновременно. Главный практический выигрыш: плеер может выдать десятки одновременных запросов на одном соединении без head-of-line blocking на прикладном уровне.

История header compression – отдельная глава. HPACK (RFC 7541) сжимает HTTP-заголовки, используя статическую таблицу частых имён и значений, плюс динамическую таблицу, которая учится на реальных заголовках соединения. Степень сжатия высокая – много запросов сегментов различаются только URL'ом, – но у HPACK есть известная слабость: поскольку динамическая таблица разделяется между всеми стримами, обновление HPACK на одном стриме может стопорнуть декодирование каждого последующего стрима, пока обновление не доедет. Это head-of-line blocking прикладного уровня, прокравшийся обратно через дверь header compression. HTTP/3 это починил через QPACK; об этом ниже.

HTTP/2 также ввёл server push. Сервер мог проактивно слать ресурсы, которые клиент ещё не запросил, – каноничный пример: CSS и JavaScript, которые сервер знал, что только что отданная HTML их запросит. Для стриминга server push кратковременно был основой Low-Latency HLS: в оригинальной спецификации LL-HLS Apple от 2019 года HTTP/2 push требовался для того, чтобы partial-segment delivery работало без лишнего RTT. В сентябре 2023 Apple убрала требование HTTP/2 push из HLS Authoring Specification и заменила его на механизм #EXT-X-PRELOAD-HINT, потому что браузеры перестали поддерживать push. Chrome 106 (октябрь 2022) выключил server push по умолчанию. Firefox 132 (октябрь 2024) убрал поддержку полностью. К 2026 году server push мёртв во всех мейнстрим-браузерах. Если вы читаете статью, в которой HTTP/2 push указан как фича low-latency стриминга, – статья устарела, посмотрите её дату.

Жёстче ограничение HTTP/2 – то, которое он не мог починить, потому что починка жила ниже протокола: TCP head-of-line blocking. Многочисленные стримы HTTP/2 едут поверх одного TCP-байт-потока. TCP отдаёт байты по порядку. Если 47-й пакет любого стрима потерян, буфер TCP-получателя держит каждый последующий пакет – на каждом стриме – пока 47-й не дойдёт. На чистом проводном линке с потерями 0.01 % это незаметно. На 4G-телефоне с 1 % потерь это разница между буфером, который дёргается каждые несколько секунд, и буфером, который держится ровно. Каждая академическая работа про HTTP/2 поверх сотовой сети флагала это с 2016 года. Починка требовала ухода с TCP. Починка – это HTTP/3.

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

HTTP/3 подробно – семантика HTTP поверх QUIC, без TCP-налога

HTTP/3 (RFC 9114, июнь 2022) сохраняет семантику HTTP, сохраняет бинарный фрейминг, который ввёл HTTP/2, и меняет одну вещь снизу: транспорт. Там, где HTTP/2 шёл поверх TCP + TLS, HTTP/3 идёт поверх QUIC (RFC 9000, май 2021). QUIC – это UDP-транспорт, интегрирующий TLS 1.3, мультиплексирующий независимые стримы без ограничения порядка TCP и переживающий смену IP-адреса клиента. У нас есть отдельная статья про сам QUIC: QUIC: новый транспортный уровень; этот раздел сфокусирован на том, что меняется, когда HTTP едет поверх QUIC, а не поверх TCP.

Три изменения важны для стриминг-продукта.

Во-первых, хендшейк становится дешевле. HTTP/2 + TLS 1.3 поверх TCP – это три RTT до первого байта данных: TCP-хендшейк (1 RTT), TLS-хендшейк (1 RTT в TLS 1.3) и сам первый запрос (1 RTT). HTTP/3 поверх QUIC сливает транспортный и криптографический хендшейки в один 1-RTT обмен, а при возобновлении использует QUIC 0-RTT и шлёт первый запрос в самом первом пакете. На мобильном линке с 80 мс RTT экономия на холодном старте – 160 мс; на тёплом – все 240 мс.

Во-вторых, head-of-line blocking чинится на транспорте. Каждый HTTP/3-запрос – это один двунаправленный QUIC-стрим. Потерянный пакет на стриме A задерживает A и только A. Плеер, тянущий три сегмента параллельно, видит, как один из них стопорится на один RTT, а два других продолжают без перерыва. На линке с потерями 1 % это разница между P95 загрузки сегмента в 800 мс и в 280 мс.

В-третьих, соединение переживает смену сети. TCP-соединение умирает в момент изменения любого из (client IP, client port, server IP, server port). QUIC-соединение идентифицируется непрозрачным 64-битным Connection ID, и клиент может перейти на новый IP, а сервер валидирует новый путь коротким обменом PATH_CHALLENGE / PATH_RESPONSE. Пользователь идёт с Wi-Fi в лифт и оттуда на 5G, и плеер не видит ни одного буферного события. На HTTP/2 over TCP эта же миграция – это 2–5 секунд переподключения.

История header compression тоже улучшилась. HTTP/3 использует QPACK (RFC 9204), наследника HPACK, специально спроектированного, чтобы избежать head-of-line blocking на динамической таблице. QPACK гоняет обновления состояния компрессии по выделенным однонаправленным стримам, отделяя их от стримов данных запросов и ответов, – поэтому застрявшее обновление состояния никогда не задержит ответ. Расплата – чуть худший коэффициент сжатия, но риска blocking больше нет.

Что не меняется – это семантика HTTP. Тот же GET на /manifest.m3u8 возвращает тот же плейлист, с теми же заголовками, теми же кодами статусов, тем же поведением кэширования. Плееру, который уже знает HTTP/2, не нужны изменения логики, чтобы потреблять HTTP/3 – подложенная библиотека договаривается о версии с сервером, а приложение видит тот же объект ответа. Это та операционная история, которая позволяет каждому крупному CDN включить HTTP/3 одной строчкой конфига.

Где версии HTTP реально сидят в стриминг-сессии

Версия HTTP согласуется в начале соединения. Клиент предлагает то, что поддерживает; сервер выбирает наивысшую общую. На современном соединении браузер–CDN в 2026 году согласование выглядит так:

1. Клиент открывает HTTPS-соединение. Он шлёт TLS ClientHello, в котором рекламирует ALPN-идентификаторы – h3, h2, http/1.1. ALPN (Application-Layer Protocol Negotiation, RFC 7301) – это TLS-расширение, которое позволяет договориться о версии HTTP внутри самого TLS-хендшейка, без лишнего RTT.
2. Если клиент рекламировал h3 и сервер ранее вернул заголовок Alt-Svc, сообщивший клиенту, на какой UDP-порт пробовать, – клиент параллельно открывает QUIC-соединение на UDP/443 и устраивает гонку с TCP/TLS-соединением. Кто первый, того и время; второе отбрасывается.
3. Сервер отвечает выбранным ALPN-идентификатором. Версия HTTP теперь зафиксирована на всю жизнь соединения.

Для стриминг-сессии это значит: первое соединение свежего клиента с edge может откатиться на HTTP/2, потому что клиент ещё не выучил Alt-Svc-подсказку. Последующие соединения – а они начнутся быстро, потому что каждый манифест, ключ, сегмент и аналитический бикон идёт через CDN – используют HTTP/3. Браузеры кэшируют Alt-Svc-подсказки на время сессии браузера, иногда дольше. CDN, который хочет, чтобы HTTP/3 «прилипал», ставит долгие Alt-Svc ma= (max-age); Cloudflare, Fastly и Akamai по умолчанию кэшируют на многонедельный срок.

Другая важная деталь: HTTP/3 на UDP/443 иногда блокируется корпоративными файрволами и middleboxes, которые пропускают только TCP/443. Браузер в этом случае молча уходит на HTTP/2 поверх TCP. Для стриминг-продукта, чья аудитория – потребители на домашних сетях и мобильных операторах, HTTP/3 дотягивается почти до всех. Для B2B SaaS-продукта с аудиторией в корпоративных офисах – план «HTTP/2 over TCP – рабочая версия». Тестируйте из внутри представительной сети заказчика до того, как обещать HTTP/3 в SLA.

Сравнительная таблица – HTTP/1.1 vs HTTP/2 vs HTTP/3 для стриминга

Паттерн постоянный: каждая версия унаследовала сильные стороны предыдущей и добавила починку бутылочного горлышка, которое предыдущая обнажила. Бутылочное горлышко HTTP/1.1 – последовательная модель запроса; HTTP/2 починил её мультиплексированием. Бутылочное горлышко HTTP/2 – TCP HoL blocking; HTTP/3 починил сменой транспорта. Бутылочное горлышко HTTP/3 – узкая полоса корпоративных сетей, блокирующих UDP/443; паттерн раскатки 2026 года – HTTP/3 с фолбэком на HTTP/2 – с этим справляется.

Рабочий пример – время до первого кадра на 4G-телефоне

Основатель спрашивает, почему MVP стриминг-продукта на 4G-телефоне в Сан-Паулу показывает TTFF 1,4 секунды, тогда как тот же плеер на проводном десктопе в том же здании показывает 480 мс. Телефонный линк рапортует 90 мс RTT до CDN edge и 1,2 % потерь в пик.

Шаг один: посчитать стоимость на HTTP/2 + TLS 1.3 over TCP. Плееру нужно (1) открыть TCP-соединение к CDN edge (1 RTT = 90 мс), (2) пройти TLS 1.3-хендшейк (1 RTT = 90 мс), (3) забрать манифест (1 RTT = 90 мс), (4) забрать ключ дешифрования (1 RTT = 90 мс – в принципе параллельно, но URL ключа лежит в манифесте, поэтому раньше шага 3 он не стартует), (5) забрать первый сегмент (1 RTT = 90 мс). Чистый RTT-расход: 5 × 90 = 450 мс. Прибавим recovery потерь: одно 1,2 % событие на самом длинном фетче (сегменте), один TCP-retransmission timeout около 90 мс. Прибавим серверную обработку около 50 мс. Прибавим декодную раскладку плеера около 150 мс. Итого: 450 + 90 + 50 + 150 = 740 мс – а плеер рапортует 1,4 с, значит есть вторая загрузка сегмента или начальная заливка буфера, которую мы не учли. Порядок величины: 800–1500 мс – это именно то, что чувствует телефон.

Шаг два: посчитать тот же путь на HTTP/3 + QUIC. (1) QUIC-хендшейк сворачивает транспорт и TLS в один RTT (1 RTT = 90 мс; 0 RTT, если плеер уже был и у него есть session ticket – назовём 0–90 мс). (2) Манифест, ключ и первый сегмент идут на QUIC-стримах; после получения манифеста ключ и сегмент стартуют параллельно на двух QUIC-стримах. Ограничено самым медленным фетчем: 1 RTT + 1 RTT = 180 мс. (3) 1,2 %-я потеря задевает один из трёх фетчей; остальные два завершаются без задержки. Итого: 90 + 180 + 50 + 150 = 470 мс на холодном старте; 0 + 180 + 50 + 150 = 380 мс на тёплом.

Шаг три: разница – 320–1000 мс TTFF. Код плеера не меняется. HTTP/3-эндпоинт на CDN – одна строка конфига. Поддержка QUIC в телефоне встроена в media stack iOS 15+ и Android 10+.

Это та самая выигрышная история, которая не требует переписывания плеера: вопрос «отдаём ли мы HTTP/3 с edge», а не «переписываем ли мы стриминг-стэк».

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

Что HTTP/3 НЕ чинит

Стоит явно проговорить пределы HTTP/3, потому что маркетинг тянет их переоценить.

HTTP/3 не чинит throughput на высокоскоростных линках с малыми потерями. Работа на ACM Web Conference 2024 измерила, что QUIC-имплементации теряют до 45 % throughput по сравнению с HTTP/2, когда пропускная способность линка переваливает за 500 Мбит/с, потому что путь обработки QUIC-пакетов работает в userspace и платит за-пакетную syscall-стоимость, которой нет у kernel-based TCP-стека. На гигабитном оптическом канале к одному клиенту HTTP/2 over TCP сегодня может обгонять HTTP/3. QUIC-стэки ускоряются – io_uring, kernel-bypass-пути, GSO/GRO offload закрывают разрыв, – но в 2026 он не ноль.

HTTP/3 не чинит middlebox-блокировку UDP. Корпоративные сети, которые делают DPI через TLS-strip, школы, блокирующие нестандартные порты, отельные Wi-Fi с ломаным UDP – каждая из этих историй тихо опускает клиента на HTTP/2 over TCP. Откат сделан мягко, но выигрыши для этой части аудитории – мимо.

HTTP/3 не чинит латентность одного фетча сегмента на чистом линке. Если RTT 80 мс, а сегмент длится 4 секунды, минимальная сквозная задержка от origin до плеера всё равно ограничена длительностью сегмента, а не версией HTTP. Версия HTTP улучшает оверхед – хендшейк, header compression, мультиплексирование, recovery потерь, – но не уменьшает сам сегмент. Low-latency HLS, LL-DASH и Media over QUIC – это протоколы, которые атакуют пол длительности сегмента; HTTP/3 – это транспорт, на котором они едут.

HTTP/3 не чинит цены медленного origin. Плеер, тянущий манифест с CDN, чей origin отвечает 800 мс, увидит эти 800 мс серверной стоимости вне зависимости от версии HTTP. Выигрыши HTTP/3 – на сетевой стороне; выигрыши на стороне origin приходят от архитектуры CDN, origin shielding и just-in-time packaging.

Adoption в 2026 – цифры без хайпа

Картина внедрения в 2026 году тоньше, чем подсказывают пресс-релизы. Заголовочные цифры из снимков Cloudflare Radar и W3Techs за апрель–май 2026:

• Доля HTTP/2 в измеренном веб-трафике: примерно 51 %.
• Доля HTTP/3: примерно 21 %.
• Доля HTTP/1.1: примерно 27 %.
• HTTP/3 достиг пика в 22 % в январе 2026 и с тех пор медленно снижается, так как часть трафика возвращается на HTTP/2 на широкополосных линках.
• HTTP/3 наиболее распространён на mobile-доминирующих рынках – Италия 30 %, Бразилия 29 %, Индия 29 %, – где edge CDN агрессивно подталкивают HTTP/3, потому что он выигрывает на high-RTT, lossy линках.
• Meta отдаёт около 75 % своего трафика через QUIC/HTTP/3 (Meta engineering blog, 2024–2026).
• Все крупные CDN – Cloudflare, Fastly, Akamai, AWS CloudFront, Google Cloud CDN, Azure Front Door, BunnyCDN, KeyCDN – в 2026 году поддерживают HTTP/3 по умолчанию через одну строчку конфига.
• Все крупные браузеры отгрузили HTTP/3 к 2022 году, кроме Safari, который выкатил его в iOS 17 / macOS Sonoma в 2023.

Два чтения одних и тех же данных. Оптимист читает HTTP/3 как дефолт современного интернета – каждый крупный CDN, каждый крупный браузер, каждый mobile-first рынок. Пессимист читает плато в 21 % как свидетельство того, что HTTP/2 over TCP «достаточно хорош» для большей части трафика, что enterprise UDP-блокировка – реальный потолок и что просадка throughput на широкополосных линках – реальная цена. Оба прочтения верны; задача статьи – дать цифры, которые можно повторить на planning-встрече без перебарщивания.

Как стриминг-протоколы реально используют HTTP

Заголовочные стриминг-протоколы все используют HTTP как носитель, но они используют разные комбинации фич HTTP.

HLS (HTTP Live Streaming, RFC 8216, плюс HLS Authoring Specification Apple) использует HTTP GET для мастер-плейлиста (.m3u8), вариантных плейлистов, сегментов (.ts или .m4s) и любых ключей шифрования. Range requests используются для адресации внутри CMAF-фрагментов. Кэширование управляется стандартными Cache-Control-заголовками. LL-HLS добавляет тег #EXT-X-PRELOAD-HINT, query-параметры _HLS_msn (media-segment number) и _HLS_part для blocking playlist reloads и механизм rendition reports. Ни одно из этого не специфично для HTTP/2 или HTTP/3 – это HTTP-семантика, которая работает на любой версии формата на проводе. Подробно – в HLS подробно: m3u8, сегменты, мультивариантные плейлисты.

DASH (ISO/IEC 23009-1) использует HTTP GET для манифеста (.mpd), инициализационных сегментов и медиа-сегментов. Byte-range запросы используются для профиля CMAF, full-segment запросы – для профиля segment-list. LL-DASH добавляет chunked transfer encoding для sub-segment delivery – сервер начинает стримить сегмент по мере его производства, используя Transfer-Encoding: chunked в HTTP/1.1 или эквивалентный фрейминг в HTTP/2. Подробно – в MPEG-DASH подробно: MPD, периоды, adaptation sets, representations.

Веб-плееры (hls.js, Shaka Player, dash.js, Video.js v10) шлют каждый запрос через браузерный fetch()-API. Браузер договаривается о версии HTTP на каждом соединении. Код плеера не меняется между HTTP/2 и HTTP/3; браузер обслуживает подложенный транспорт. Плеер, впрочем, может наблюдать поведение мультиплексирования через performance timings – PerformanceResourceTiming.nextHopProtocol сообщает h3, h2 или http/1.1 на каждый ресурс.

WebTransport и Media over QUIC – это не HTTP/3, это родные ему протоколы, которые едут поверх QUIC напрямую. Они делят подложенный транспорт с HTTP/3 (тот же QUIC-стэк, тот же TLS 1.3, та же миграция соединения), но говорят свои собственные протоколы поверх. Стриминг-продукт 2026 года, использующий MoQ для ингеста и HTTP/3 для дистрибуции, гоняет оба по одному QUIC-соединению к edge.

Типовые ошибки и подводные камни

• Считать «HTTP/3 включён» бинарным флагом. Многие CDN дают тоглить HTTP/3 на уровне глобального аккаунта, зоны или пути. Убедитесь, что тоггл покрывает каждое имя хоста в стриминг-пайплайне – origin манифестов, origin сегментов, key server, аналитический эндпоинт, бикон. Один HTTP/2-only хост в цепочке убивает выигрыш.
• Забыть про кэширование Alt-Svc. Первое соединение свежего клиента не пойдёт на HTTP/3, потому что клиент ещё не выучил Alt-Svc-подсказку. Последующие – пойдут. Если плееры агрессивно переиспользуют соединения, это незаметно; если плеер открывает новое соединение на сегмент – латентность первого сегмента остаётся на HTTP/2. Ставьте Alt-Svc: h3=":443"; ma=2592000 (30 дней) на edge.
• Полагаться на HTTP/2 server push для low-latency стриминга. Chrome 106 (октябрь 2022) выключил его. Firefox 132 (октябрь 2024) убрал. Safari никогда не отгружал push в полной мере. Apple убрала требование push из LL-HLS в сентябре 2023 и заменила на preload hints. Если ваш low-latency стэк всё ещё использует push, он везёт мёртвую фичу.
• Путать HTTP/3 и QUIC. HTTP/3 – это один протокол поверх QUIC. WebTransport и Media over QUIC – это другие протоколы поверх того же QUIC. Команда, которая их путает, спланирует раскатку HTTP/3 и пропустит возможности WebTransport и MoQ.
• Считать, что HTTP/3 всегда выигрывает. На гигабитных проводных клиентах HTTP/2 over TCP может обгонять HTTP/3 в 2026 году из-за стоимости userspace-vs-kernel обработки QUIC. Выигрыш реален на мобильных и lossy-линках; на чистом проводном – маленький или отрицательный. Измерьте свою аудиторию до того, как заявлять глобальное улучшение.
• Неправильно читать глобальную долю HTTP/3. 21 % – это доля всего измеренного веб-трафика, включая длинный хвост статических сайтов, у которых нет повода обновляться. Доля среди крупных видеоэндпоинтов (Meta, Twitch, видео через Cloudflare, современные CDN) много выше, часто больше 60 %. Используйте правильный бенчмарк под правильное сравнение.
• Игнорировать middlebox UDP-блокировку. Корпоративные офисные сети, школьные, государственные и часть отельных Wi-Fi блокируют UDP/443. Для consumer-стриминга это редко проблема; для B2B SaaS и enterprise-ориентированных телемедицинских и e-learning продуктов – да. Тестируйте из внутри представительной сети заказчика.

Как раскатать HTTP/3 на стриминг-продукте в 2026

Прагматичная трёхшаговая раскатка для команды, которая уже гоняет HTTP/2 over TCP.

1. Включите HTTP/3 на CDN edge. Каждый крупный CDN – Cloudflare, Fastly, Akamai, AWS CloudFront, Google Cloud CDN, Azure Front Door, BunnyCDN, KeyCDN – поддерживает HTTP/3 одной строкой конфига. Включите для каждого хоста стриминг-пайплайна. Подтвердите, что edge отдаёт заголовок Alt-Svc: h3. Соберите метрики до/после: TTFF, частоту ребуферов, P95 загрузки сегмента.

1. Проверьте, что плеер видит HTTP/3. В веб-плеерах читайте PerformanceResourceTiming.nextHopProtocol на каждом фетче и логируйте распределение. В нативных плеерах читайте эквивалент – на iOS HTTPURLResponse отдаёт согласованный протокол; на Android – HttpURLConnection через заголовки ответа. Здоровая раскатка показывает h3 на 60–80 % фетчей в течение недели после включения edge.

1. Аудитируйте путь фолбэка. Часть клиентов (корпоративные сети, старые ОС, ограничивающий Wi-Fi) тихо упадёт на HTTP/2 или HTTP/1.1. Убедитесь, что фолбэк работает end-to-end. Лучший единичный тест – изолированная лабораторная сеть с заблокированным UDP/443 на файрволе: подключиться, проиграть стрим, убедиться, что проигрывается, и что QoE-метрики в допуске. Если фолбэк сломан, вы только что нашли инцидент, который ждёт первого корпоративного заказчика.

Полный чек-лист раскатки – в скачиваемом HTTP/3 Streaming Rollout Checklist.

Где Фора Софт встроена

Мы отгрузили 239+ проектов с 2005 года в видеостриминге, WebRTC-конференциях, OTT / Internet TV, телемедицине, e-learning, видеонаблюдении и AR/VR, – и выбор версии HTTP виден в каждом. На consumer-OTT и live-стриминг-продуктах мы по умолчанию гоняем HTTP/3 на CDN edge с фолбэком на HTTP/2 и измеряем сплит h3 / h2 / http/1.1 как release-gate метрику. На WebRTC-продуктах сигнальный и аналитический каналы едут поверх HTTP/3 рядом с медиа; выигрыши на мобильном переключении с Wi-Fi на 5G особенно заметны. На телемедицинских и e-learning проектах мы относимся к фолбэку на HTTP/2 over TCP как к clinical-grade требованию – консультация, которая упала, потому что enterprise-сеть больницы блокирует UDP/443, – это билейбл-fail, и мы явно тестируем это в лабораторной сети. Паттерн – «HTTP/3 первым с тщательным тестом фолбэка», а не «HTTP/3 везде на скрещенных пальцах».

Ключевые тезисы

• HTTP/1.1 (RFC 9112) – текстовый, последовательный на соединение, обслуживает ~27 % измеренного веб-трафика в 2026.
• HTTP/2 (RFC 9113) – бинарный и мультиплексированный на одном TCP, но всё ещё страдает от TCP HoL blocking.
• HTTP/3 (RFC 9114) гоняет HTTP поверх QUIC, убирает blocking на транспорте и в 2026 является дефолтом всех крупных CDN.
• HTTP/2 server push мёртв во всех крупных браузерах с 2024 года; LL-HLS заменил требование push на preload hints в 2023.
• Выигрыш на мобильных и lossy-линках реален (160–360 мс TTFF); на гигабитном оптоволокне – маленький или отрицательный.
• Adoption в апреле 2026: HTTP/2 ~51 %, HTTP/1.1 ~27 %, HTTP/3 ~21 % – с доминированием HTTP/3 на mobile-first рынках.

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

• QUIC: новый транспортный уровень – транспорт под HTTP/3, WebTransport и MoQ.
• TCP и UDP в стриминге – выбор транспортного уровня, который наследуют версии HTTP.
• HLS подробно: m3u8, сегменты, мультивариантные плейлисты – стриминг-протокол, едущий поверх HTTP каждый день.

Призыв к действию

• Поговорите со стриминг-инженером – забронируйте 30-минутный скоупинг-звонок, чтобы обсудить раскатку HTTP/3, аудит CDN и тестирование плеер-side фолбэка.
• Посмотрите наши кейсы – 239+ отгруженных проектов в видеостриминге, WebRTC, OTT, телемедицине, e-learning, видеонаблюдении и AR/VR.
• Скачайте HTTP/3 Streaming Rollout Checklist – одностраничная карта-памятка по включению HTTP/3 на CDN edge, верификации согласования на плеере и аудиту фолбэка на HTTP/2.