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: один потерянный пакет останавливает все одновременные стримы. 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 миллисекунд медленнее, чем мог бы. Это разница между метрикой запуска, за которую борд хвалит, и метрикой, по которой борд задаёт вопросы. Эта статья объясняет, что делает каждая версия HTTP, в каких сценариях она выигрывает и проигрывает, и как выбрать правильные дефолты для стримингового продукта в 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) добавил заголовки, коды состояния и типы содержимого – теперь общение стало структурированным. HTTP/1.1 (RFC 2068, январь 1997; ревизии – RFC 2616 в 1999, затем RFC 7230–7235 в 2014, и наконец RFC 9112 в июне 2022) ввёл постоянные соединения, пайплайнинг запросов (на практике не прижился), виртуальный хостинг через заголовок Host, чанковую передачу данных, запросы по диапазонам (функция, без которой HTTP-стриминг невозможен) и семантику кэширования. HTTP/2 (RFC 7540, май 2015; ревизия – RFC 9113, июнь 2022) – это семантика HTTP/1.1 поверх нового бинарного фрейминга: мультиплексированные потоки на одном TCP-соединении, сжатие заголовков (HPACK) и, увы, неудачная фича server push. HTTP/3 (RFC 9114, июнь 2022) переносит ту же семантику на QUIC (RFC 9000, май 2021) – транспортный протокол на базе UDP с встроенным TLS 1.3, независимыми потоками и отсутствием проблемы блокировки TCP. Четыре версии, три из которых используются в продакшене. Задача стриминг-инженера – понимать, что даёт и сколько стоит каждая из них.

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

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 мс это даёт около 320–400 мс до того, как декодер получит первый байт. Восстановление потерь происходит на уровне TCP прозрачно для HTTP. Запросы по диапазонам (заголовок 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).

История сжатия заголовков – отдельная глава. HPACK (RFC 7541) сжимает HTTP-заголовки, используя статическую таблицу с часто встречающимися именами и значениями, а также динамическую таблицу, которая адаптируется под реальные заголовки соединения. Степень сжатия высока – ведь многие запросы отличаются друг от друга лишь URL, – однако у HPACK есть известная уязвимость: поскольку динамическая таблица общая для всех стримов, обновление HPACK на одном стриме может блокировать декодирование всех последующих стримов до тех пор, пока это обновление не будет доставлено. Это – блокировка «головы очереди» на прикладном уровне, которая вновь появилась благодаря механизму сжатия заголовков. 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, но меняет одну ключевую вещь на транспортном уровне: вместо TCP + TLS он использует 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, но не влияет на другие. Плеер, скачивающий три сегмента параллельно, видит, как один из них замирает на один RTT, а два других продолжают загружаться без задержек. На линии с потерей пакетов 1 % это разница между 800 мс и 280 мс в 95-м перцентиле времени загрузки сегмента.

В-третьих, соединение выдерживает смену сети. 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 секунд на переподключение.

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

Что не меняется – это семантика 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 с fallback на HTTP/2 – с этим справляется.

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

Основатель спрашивает, почему у MVP стриминг-продукта на 4G-устройстве в Сан-Паулу время первого кадра (TTFF) составляет 1,4 секунды, тогда как на проводном десктопе в том же здании – всего 480 мс. Сетевой линк телефона показывает RTT до CDN edge 90 мс и до 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 мс. Добавим время на восстановление от потерь: одно событие с вероятностью 1,2 % на самом длинном запросе (сегменте), один TCP-таймаут на повторную передачу – около 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 в телефоне встроена в медиа-стек iOS 15+ и Android 10+.

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

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

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

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

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

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

HTTP/3 не устраняет задержку при передаче одного сегмента по идеальной линии. Если RTT составляет 80 мс, а длительность сегмента – 4 секунды, минимальная сквозная задержка от источника до плеера всё равно ограничена длительностью этого сегмента, а не версией HTTP. Версия HTTP улучшает оверхед – хендшейк, сжатие заголовков, мультиплексирование, восстановление после потерь, – но не сокращает саму длительность сегмента. 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 наиболее распространён на рынках с преобладанием мобильных устройств – Италия 30 %, Бразилия 29 %, Индия 29 %, – где edge CDN активно продвигают HTTP/3, поскольку он лучше работает на каналах с высокой задержкой и потерями пакетов.
• 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, каждый популярный браузер, каждый рынок, ориентированный на мобильные устройства. Пессимист же интерпретирует плато на уровне 21 % как доказательство того, что HTTP/2 поверх TCP «достаточно хорош» для большинства трафика, что блокировка UDP на уровне предприятий – реальный барьер, а снижение пропускной способности на широкополосных каналах – реальная плата за прогресс. Оба взгляда имеют право на существование; цель статьи – предоставить цифры, которые можно использовать на планировании без преувеличений.

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

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

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

DASH (ISO/IEC 23009-1) использует HTTP GET для получения манифеста (.mpd), инициализационных и медиа-сегментов. Запросы по байтовым диапазонам применяются в профиле CMAF, а запросы полных сегментов – в профиле segment-list. LL-DASH добавляет поддержку chunked transfer encoding для доставки суб-сегментов: сервер начинает стримить сегмент сразу после его создания, используя 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, аннулирует все преимущества.
• Забыть про кэширование 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 в 2026 году может превосходить HTTP/3 из-за накладных расходов на обработку QUIC в пользовательском пространстве по сравнению с ядром. Преимущество реально на мобильных и нестабильных каналах; на чистом проводном соединении оно может быть небольшим или отсутствовать. Измерьте свою аудиторию перед тем, как заявлять о глобальном улучшении.
• Неправильно интерпретировать глобальную долю HTTP/3. 21 % – это доля всего измеренного веб-трафика, включая множество статических сайтов, которым нет смысла обновляться. Доля среди крупных видеоэндпоинтов (Meta, Twitch, видео через Cloudflare, современные CDN) значительно выше – часто более 60 %. Используйте корректные бенчмарки для адекватного сравнения.
• Игнорировать блокировку UDP middlebox. Корпоративные офисные сети, школьные, государственные и часть отельных 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. Убедитесь, что фолбэк работает от начала до конца. Лучший тест – изолированная лабораторная сеть с заблокированным UDP/443 на файрволе: подключитесь, запустите стрим, убедитесь, что воспроизведение идёт, и что метрики QoE в допустимых пределах. Если фолбэк не работает, вы только что обнаружили инцидент, который ждёт своего часа – первого корпоративного клиента.

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

Где Фора Софт используется

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

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

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

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

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

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

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