RTMP на выходе: почему он действительно умирает

Последняя проверка: 2026-05-21. Источники: Adobe RTMP 1.0 Specification (21 декабря 2012, архив rtmp.veriskope.com), официальное объявление Adobe о прекращении поддержки Flash (25 июля 2017), страницы окончания поддержки Adobe и Microsoft с датой 31 декабря 2020, уведомление AWS об отказе от CloudFront RTMP-дистрибуций (17 декабря 2019, вступает в силу с 31 декабря 2020), рекомендации Akamai и Wowza по переходу с Flash и RTMP, W3C Media Source Extensions Candidate Recommendation, спецификация HTML video (W3C / WHATWG), Enhanced RTMP v2 Release Version (Veovera Software Organization, 2024), текущее состояние поддержки HLS / DASH / LL-HLS в Chrome, Firefox, Safari и Edge.

TL;DR

RTMP как протокол доставки – участок от сервера до плеера у зрителя – умирал постепенно с 2007 года, когда Apple представила первый iPhone без поддержки Flash, и фактически прекратил существование в январе 2021 года, когда крупные браузеры окончательно удалили плагин Flash. Современные браузеры не поддерживают RTMP, стандарты больше не определяют его как протокол доставки, CDN-операторы отключили свои RTMP-дистрибутивные решения, а экосистема воспроизведения видео сошлась на HLS, DASH и WebRTC поверх обычного HTTP или QUIC. Те места, где RTMP-выход ещё сохраняется в 2026 году, – это десктопные приложения, разработанные до 2015 года, небольшой сегмент систем видеонаблюдения и внутренняя broadcast-инфраструктура, а также редкие переходные мосты внутри вендорских пайплайнов, которые сами вендоры активно устраняют. Если в 2026 году новый продукт для потокового видео рассматривает RTMP в качестве протокола доставки – ответ однозначный: «нет». Вы транскодируете на origin-сервере и отдаёте контент по HLS, LL-HLS, DASH или WebRTC.

Почему это важно

Если вы продакт-менеджер, основатель или руководитель эксплуатации, выбирающий сторону воспроизведения для live-продукта, в 2026 году вы всё ещё столкнётесь с RTMP – в документации вендоров, в архитектурных схемах прошлого, в предложениях подрядчиков, которые десятилетиями работают в этой области, и в любой системе, построенной на медиа-сервере 2015 года. Важно понимать две вещи: RTMP на стороне вывода действительно устарел – это не модный тренд, а технологический факт; выбор его для нового продукта означает движение в тупик. Эта статья – канонический справочник Блока 4 по RTMP как доставке: что значит «доставка» в этом контексте, когда и как RTMP умер на стороне воспроизведения, почему современная веб-платформа не может его воскресить, где он ещё встречается в 2026 году и что использовать вместо него. Парная статья – RTMP в 2026: мёртвый протокол, неубиваемый стандарт по умолчанию – описывает сторону контрибьюции, где RTMP жив и здоров; эта статья посвящена стороне egress, где он уже ушёл.

Контрибьюция и доставка – почему у слова "RTMP" две жизни

Протокол реального времени для обмена сообщениями, сокращённо RTMP, – это прикладной протокол, работающий поверх TCP. Его разработала компания Macromedia в 2002 году, а в декабре 2012 года Adobe опубликовала открытую спецификацию. Протокол решает две внешне схожие, но на системном уровне принципиально разные задачи. Различие между ними – главная мысль этой статьи.

Первая задача – контрибьюция, или ингест: энкодер на площадке, в студии или в телефоне отправляет live-видеопоток на медиа-сервер. Это путь от источника к серверу. В 2026 году RTMP по-прежнему остаётся стандартом по умолчанию: OBS Studio, Wirecast, FFmpeg, любой аппаратный энкодер – от Teradek до Blackmagic Web Presenter, любая социальная платформа – от YouTube Live до TikTok – используют RTMP для передачи данных по маршруту «энкодер → сервер». Подробнее эту сторону мы разбираем в статье RTMP в 2026.

Вторая задача – доставка, или egress: медиа-сервер передаёт live-поток всем зрителям в публичном интернете. Это путь от сервера к плееру. Когда-то RTMP выполнял и эту функцию: в эпоху, когда Adobe Flash Player был установлен в 98% браузеров, связка «Flash + RTMP» была стандартом для воспроизведения live-видео на веб-страницах. Эта эпоха постепенно завершилась между 2010 и 2021 годами и не вернётся. Статья – про RTMP-доставку.

Один протокол – на проводе. Две принципиально разные задачи – по разные стороны медиа-сервера. Контрибьюция жива; доставка умерла. Если вам кто-то говорит: «RTMP мёртв» – уточните, какую сторону он имеет в виду. В девяти случаях из десяти он прав насчёт доставки, а по поводу контрибьюции ошибается.

Четырнадцатилетний путь к смерти – как именно умирала доставка по RTMP

Смерть RTMP как протокола доставки не была одномоментным событием. Это был 14-летний процесс, начавшийся ещё до того, как большинство нынешних инженеров стриминга закончили университет. Он прошёл через производителей браузеров, разработчиков оборудования, операторов CDN и стандартизирующие организации – и завершился лишь в январе 2021 года. Приведённая ниже хронология является канонической.

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

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

2007 – iPhone без Flash. Решение Apple не включать Flash в iOS стало первым случаем, когда воспроизведение RTMP стало невозможным на массовом потребительском устройстве. Письмо Стива Джобса Thoughts on Flash (2010) окончательно и публично закрепило этот отказ. Каждый iPhone, iPad и Apple TV с 2007 года требовали альтернативного способа воспроизведения; собственный ответ Apple – HTTP Live Streaming, представленный в 2009 году и стандартизированный как IETF RFC 8216 в 2017 году.

2009–2012 – приходит HTTP-основанный ABR. Apple выпустила HLS в 2009 году, Microsoft – Smooth Streaming в 2008-м, Adobe – HTTP Dynamic Streaming в 2010-м, а ISO опубликовала Dynamic Adaptive Streaming over HTTP – MPEG-DASH, ISO/IEC 23009-1 – в 2012 году. Все эти протоколы доставляли видео по обычному HTTP, используя манифест и короткие сегменты. Ни один из них не требовал плагина, все работали на любом стандартном CDN и поддерживали переключение битрейта в реальном времени. Техническое превосходство над RTMP было очевидным: более низкая стоимость CDN, отсутствие необходимости в плагине, отсутствие проблемы head-of-line blocking, встроенная адаптация битрейта и простое кэширование. Как только появились альтернативы, единственным аргументом в пользу RTMP для воспроизведения оставалась лишь установленная база Flash – а она уже сокращалась.

2015 – W3C Media Source Extensions становятся Candidate Recommendation. W3C Media Source Extensions (сокращённо MSE) дали JavaScript возможность подавать поток медиа-сегментов напрямую в HTML5-элемент <video>. Это техническая основа, на которой работают такие библиотеки, как hls.js, Shaka Player, dash.js и Video.js, воспроизводя HLS и DASH в любом современном браузере без плагинов. MSE сделали плагинную модель воспроизведения принципиально устаревшей: тег <video> в сочетании с MSE и библиотекой JavaScript объёмом около 200 КБ способен делать всё то же, что раньше обеспечивали Flash и RTMP – на любом устройстве и без установки.

Июль 2017 – Adobe объявляет Flash EOL. Adobe – совместно с Apple, Microsoft, Google, Facebook и Mozilla – публично пообещала прекратить поддержку Flash Player 31 декабря 2020 года. Объявление дало экосистеме три с половиной года на миграцию.

Декабрь 2019 – AWS объявляет об отключении CloudFront RTMP. Amazon CloudFront, крупнейший CDN в мире, сообщил клиентам, что все RTMP-дистрибуции CloudFront будут удалены 31 декабря 2020 года, а запросы к старым эндпоинтам будут отклоняться. Это событие больше всего из всех закрыло коммерческую перспективу доставки через RTMP: если AWS не может доставить ваш RTMP-поток до зрителя, у вас просто нет пути доставки. Akamai и Wowza в том же году опубликовали аналогичные рекомендации.

26 января 2021 – Firefox 85 и Chrome 88 удаляют Flash. Последние крупные браузеры окончательно убрали Flash из своих сборок, и в западной веб-экосистеме больше не осталось потребительских устройств, способных воспроизводить RTMP нативно. В 2021 году оставшиеся точки воспроизведения RTMP располагались внутри нативных приложений, включавших собственный RTMP-клиент; в открытом вебе доставка через RTMP завершилась.

Почему современная веб-платформа не может воскресить RTMP

Читатель, никогда не писавший браузерный код, вполне может задать логичный вопрос: если RTMP технически надёжный протокол для трансляции видео в реальном времени, а браузеры раньше поддерживали его через Flash, почему бы им не внедрить нативную поддержку сегодня? Ответ состоит из трёх уровней и требует внимательного разбора.

Медиа-стек браузера спроектирован под HTTP, а не под сокет. Современный браузер воспроизводит видео двумя способами: либо задаёт атрибут src у элемента <video> (HTTP URL), либо передаёт байты в <video> через Media Source Extensions. Оба подхода предполагают, что данные поступают по HTTP – HTTP/1.1, HTTP/2 или HTTP/3. RTMP работает на долгоживущем TCP-сокете на порту 1935 с бинарным handshake и собственной сессионной моделью, не похожей на HTTP. Интеграция RTMP в медиа-стек браузера потребовала бы создания параллельного транспортного слоя, отдельного менеджера сессий, собственной обвязки кодеков и альтернативной модели безопасности. Ни один из производителей браузеров не располагает инженерными ресурсами для такой разработки, а пользовательская выгода от неё слишком мала, чтобы оправдать затраты.

Не та история с кодеками. RTMP в редакции Adobe 2012 года формально поддерживает H.264 и AAC – и почти ничего больше. Расширения Enhanced RTMP, финализированные Veovera в 2024 году, добавляют HEVC, AV1, VP9 и сигнализацию HDR – но это флаги расширения кодеков для пайплайнов ингеста; в 2026 году каждое E-RTMP-внедрение в мире – это контрибьюция, а не доставка. Современные браузеры и телевизоры декодируют HEVC, AV1 и Dolby Vision аппаратно; они ожидают, что эти кодеки будут приходить в fMP4-сегментах, указанных в манифестах HLS или DASH, а не в кастомном бинарном контейнере.

Не та модель безопасности и эксплуатации. RTMP проектировался для эпохи доверенных Flash-приложений внутри изолированных сред. У него отсутствует нативная поддержка certificate pinning, тонкая защита контента и интеграция с современными возможностями CDN – такой как аналитика логов, переключение mid-stream, управление трафиком (content steering), токенизированные URL и так далее. HLS и DASH получают всё это «бесплатно» благодаря HTTP; RTMP пришлось бы изобретать заново.

Резюме неприятно для поклонников протокола: даже если бы разработчик браузера захотел вернуть RTMP, каждый слой современной веб-платформы – транспорт, кодеки, безопасность, наблюдаемость, экономика – работает в противоположном направлении. Веб ушёл вперёд и не оглядывается.

Где RTMP-доставка ещё мелькает в 2026

Честно про длинный хвост: RTMP-egress в 2026 году не исчезнет. Просто он не будет находиться там, где новый продукт должен на него рассчитывать. Остаточные карманы стоит обозначить, чтобы вы могли их распознать в схемах от подрядчиков.

Чего вы не увидите в 2026 году: ни одного крупного стриминг-сервиса, передающего RTMP в браузер; ни одной социальной платформы, транслирующей RTMP зрителям; ни одного коммерческого CDN, продающего RTMP-egress как продукт; ни одного стандарта, описывающего новое поведение для воспроизведения по RTMP; ни одной поддерживаемой эталонной реализации. На этом протокол фактически вышел на пенсию.

Рабочий пример – что приходит на смену RTMP при модернизации

Сделаем сравнение конкретным. Предположим, вам достался live-видеопродукт образца 2014 года: он принимает RTMP от аппаратного энкодера и одновременно отдаёт RTMP во Flash-плеер, встроенный в браузер на стороне зрителя. Flash больше не поддерживается, браузеры отказываются от этого протокола, аудитория постепенно сокращается. Что именно вы предлагаете взамен?

Контрибьюция остаётся. Аппаратный энкодер продолжает отправлять RTMPS – TLS-обёрнутый вариант RTMP на порту 443 – на ваш origin-сервер. На этом этапе в 2026 году никаких изменений не требуется.

Доставка заменяется. На origin-сервере входящий RTMP-трафик транскодируется в фрагментированные MP4-сегменты и упаковывается в формат Common Media Application Format (CMAF). Далее origin предоставляет две параллельные поверхности доставки: HLS-манифест для браузеров и устройств Apple, а также DASH-манифест для Android и Smart TV. Если продукт требует задержки менее одной секунды, добавьте WHEP-эндпоинт, транслирующий тот же поток по протоколу WebRTC.

Экономика улучшается. RTMP-egress требовал stateful TCP-сокет для каждого зрителя на всё время просмотра. HLS / DASH-egress использует последовательность stateless HTTP GET, которые любой CDN кеширует бесплатно. Live-аудитория в миллион человек на RTMP означала бы миллион одновременных сокетов до origin или RTMP-совместимого edge; та же аудитория на HLS требует от edge раздать файл сегмента продолжительностью 4–6 секунд примерно 250 000 раз в минуту, причём каждый POP отдаёт его из кеша. Разница в стоимости – на порядок в пользу HTTP, и это, а не уход Flash, и есть истинная причина миграции индустрии.

Охват улучшается. Как только вы запускаете HLS и DASH, ваш поток воспроизводится в любом браузере на любой ОС и любом устройстве, выпущенном примерно с 2016 года, без установки дополнительных программ. Аудитория «RTMP через Flash» – это те, у кого ещё был установлен Flash; к 2026 году её не останется.

Арифметика для типичного 1080p-потока – давайте проговорим вслух:

RTMP egress  : 1 сокет на зрителя × 10 000 зрителей = 10 000 открытых TCP
               сокетов на origin или в RTMP-aware edge.

HLS  egress  : 4 c сегмент × 15 сегментов/мин = 1 файл, записанный на edge на
               каждый 4-секундный отрезок, и отданный из кеша всем, кто его
               запросил. Запросов к origin: ~15 в минуту, не 10 000.

Полоса      : обе схемы доставляют 6 Mbps каждому зрителю = 60 Gbps суммарно.
               Коммодити HTTP-доставка: ~$0.005–0.020 за GB по tier-1
               контрактам. RTMP-aware edge: обычно квотируется в 3–10× дороже,
               если квотируется вообще, потому что вендор держит stateful-уровень.

Вы используете HLS и DASH. Оставляете RTMPS для ингеста. Полностью убираете RTMP с egress-интерфейса. Это и есть канонический паттерн модернизации образца 2026 года.

Типичная ошибка – «оставим RTMP как fallback»

Инженеры иногда предлагают оставить RTMP-доставку «на всякий случай, если HLS отвалится» или «для зрителей, которым нужна низкая задержка». Это ошибочное представление, и его стоит озвучить прямо.

Браузеры не поддерживают RTMP. Зритель, у которого внезапно пропал HLS-поток, не может восстановить соединение через RTMP – его плеер не подключится к вашему RTMP-эндпоинту. «Fallback» работает только в случае, если вы выпускаете нативное приложение с встроенным RTMP-клиентом. А тогда вы создаёте параллельный нативный стек, чтобы поддерживать протокол, который открытая веб-платформа уже заменила. Экономика никогда не складывается. Если вам действительно нужна задержка ниже, чем у HLS, правильный выбор в 2026 году – LL-HLS, LL-DASH или WebRTC-доставка; каждый из них работает в современном браузере без плагинов.

Где Фора Софт

Мы разрабатываем live-видеопродукты для видеостриминга, видеоконференций, OTT, e-learning, телемедицины, видеонаблюдения и AR/VR. Проекты по отказу от RTMP-доставки к нам поступают как задачи модернизации: на входе – стек 2013–2016 годов, принимающий RTMP и передающий его в Flash-плеер или нестандартный мобильный клиент с поддержкой RTMP. Мы перепрофилируем сторону доставки на HLS и DASH, а для аудитории, чувствительной к задержкам, нередко добавляем WHEP-эндпоинт. Контрибьюция, как правило, остаётся на RTMPS; меняется только egress. Если у вас есть продукт, который всё ещё отдаёт RTMP зрителю, и нужен независимый взгляд на план миграции – приходите.

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

• RTMP на стороне приёмника (контрибьюции) в 2026 году ещё жив; RTMP на стороне доставки – уже мёртв. Никогда не смешивайте эти две стороны, говоря «RTMP мёртв».
• Его упадок длился 14 лет – с 2007 по 2021 год – и завершился полным удалением Flash из Chrome 88 и Firefox 85 в январе 2021 года.
• Современные браузеры воспроизводят видео через HTML5 <video> и MSE; TCP-ориентированный транспорт RTMP в эту архитектуру не вписывается.
• AWS CloudFront, Akamai и другие CDN уровня tier-1 отключили свои RTMP-решения для дистрибуции к 31 декабря 2020 года.
• HTTP-ориентированные технологии ABR (HLS, DASH, CMAF) выигрывают по цене, охвату, наблюдаемости, поддержке кодеков и адаптивной отдаче битрейта.
• Для новых продуктов в прямом эфире в 2026 году egress-интерфейс – это HLS, DASH и опционально WHEP; RTMP в этой схеме не используется.

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

• RTMP в 2026: мёртвый протокол, неубиваемый стандарт по умолчанию – парная статья о стороне контрибьюции.
• HLS подробный разбор – каноничная замена RTMP-egress, подробно.
• Семейное древо протоколов доставки – где каждый современный протокол распределения занимает место в ландшафте 2026 года.