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 году новый продукт live-видео рассматривает RTMP для доставки – ответ "нет": вы транскодируете на origin-сервере и отдаёте по HLS, LL-HLS, DASH или WebRTC.

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

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

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

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

Первая задача – контрибьюция, или ингест: энкодер на площадке, в студии или в телефоне отправляет 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-летний процесс, начавшийся до того, как большинство нынешних streaming-инженеров закончили университет; он прошёл через производителей браузеров, производителей железа, 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-based 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, бесплатный adaptive bitrate, простое кэширование. Как только альтернативы появились, единственным аргументом за 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 плюс библиотека на 200 КБ JavaScript умеют всё то же, что когда-то делали Flash и RTMP, – на любом устройстве и без установки.

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

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

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

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

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

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

Не та история с кодеками. RTMP в редакции Adobe 2012 года формально поддерживает H.264 и AAC и почти ничего больше. Расширения Enhanced RTMP, финализированные Veovera в 2024-м, добавляют HEVC, AV1, VP9 и сигнализацию HDR – но это codec-extension flags для пайплайнов ингеста; в 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. Если продукт требует sub-second latency, добавьте WHEP endpoint, отдающий тот же поток по WebRTC.

Экономика улучшается. RTMP-egress требовал stateful TCP-сокет на каждого зрителя на всё время просмотра. HLS / DASH-egress требует последовательности stateless HTTP GET, которые любой CDN кеширует бесплатно. Live-аудитория в миллион человек на RTMP означала бы миллион одновременных сокетов до origin или RTMP-aware 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 endpoint тем плеером, что у него есть. "Fallback" работает только в том случае, если вы выпускаете нативное приложение, тянущее за собой RTMP-клиент. А в этот момент вы построили параллельный native-стек, чтобы поддержать протокол, который открытая веб-платформа уже заменила. Экономика никогда не сходится. Если вам действительно нужна задержка ниже, чем даёт HLS, правильный ответ в 2026 году – LL-HLS, LL-DASH или WebRTC-доставка; каждый из них работает в современном браузере без плагина.

Где Фора Софт

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

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

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

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

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