Content Steering: стандартный способ делать multi-CDN

TL;DR

Content Steering – это небольшой набор дополнений к спецификациям HTTP Live Streaming и MPEG-DASH, позволяющий плееру запросить у удалённого сервера – steering-сервера – какой Content Delivery Network (CDN) использовать для следующего сегмента видео. Он заменяет устаревшие приёмы с Domain Name System и плеер-специфичные списки failover единым совместимым механизмом: для HLS он описан в Apple HLS Content Steering Specification v1.2 (с правками до 2025 года) поверх IETF draft-pantos-hls-rfc8216bis-22 (от 1 мая 2026 года), а для DASH – в ETSI TS 103 998 V1.1.1 (январь 2024 года). Обе спецификации согласованы между собой, поэтому один и тот же steering-сервер может управлять как HLS-, так и DASH-клиентами.

Архитектура в простых словах выглядит так: плеер раз в несколько минут делает дополнительный HTTP-запрос, скачивая крошечный JSON-файл со списком идентификаторов CDN в порядке приоритета. На основе этого списка он решает, к какому CDN обращаться за каждым сегментом, обновляя его по истечении срока действия (Time-To-Live), который задаёт steering-сервер.

Сила content steering в том, что приоритеты можно менять прямо в ходе воспроизведения. Steering-сервер получает телеметрию сразу от множества плееров через спецификацию Common Media Client Data (CTA-5004), а один и тот же код работает в hls.js, Shaka Player, dash.js, нативном Apple AVPlayer, Video.js v10, ExoPlayer и современных плеерах smart TV. Слабость же заключается в том, что steering-сервер становится единственным критическим компонентом на пути доставки, требующим той же операционной надёжности, что и origin-сервер и лицензионный сервер.

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

Десять лет multi-CDN-индустрия представляла собой набор вендор-специфичных решений, которые не взаимодействовали друг с другом: DNS-руление от Cedexis (ныне Citrix Intelligent Traffic Management) и NS1, статические манифесты на стороне плеера в каждой видеоплатформе, а также разнообразные проприетарные протоколы сигнализации внутри плеерных SDK. Ни один из этих подходов не позволял переключать зрителя между CDN в середине сессии без перезапуска плеера, и ни один не предоставлял данные, пригодные для использования CDN-нейтральным аналитическим продуктом. Content steering – это исправление на уровне протокола десятилетнего периода фрагментации.

К 2026 году каждый крупный open-source-плеер (hls.js, dash.js, Shaka Player, Video.js v10 со Streaming Processor Framework, ExoPlayer на Android Media3) включает поддержку content steering, каждый значимый CDN (Akamai, Cloudflare, Fastly, AWS CloudFront, Google Media CDN, Edgio) поддерживает модель pathway, а несколько специализированных вендоров steering-серверов (THEO, MediaMelon, einbliq.io, Touchstream, Broadpeak) предлагают продукты, разработанные в соответствии со спецификацией.

Продакт-менеджер заканчивает эту статью с возможностью задать вопрос: «Мы используем HLS Pathway ID или DASH ServiceLocation, и какой TTL у steering-манифеста?» – и при этом не блефовать. Архитектор – с четырёхкомпонентной архитектурной схемой, чётким пониманием того, как PATHWAY-CLONES позволяет steering-серверу объявить плееру совершенно новый CDN, даже если тот работает уже час, и однозначной картой соответствия полей спецификации и поведения системы. Лид эксплуатации – с каталогом сценариев отказов, планом телеметрии и чек-листом готовности, который прилагается к этой статье.

Content steering – это не новая оптимизация; это lingua franca, которой multi-CDN-индустрии так не хватало.

Определение в один абзац (пока без номеров спецификаций)

Представьте, что ваш плеер – это посетитель кафе. Кафе – это манифест, небольшой текстовый документ, в котором указано, где находится каждый фрагмент видео. До 2021 года манифест указывал посетителю ровно один адрес для каждого фрагмента и одну цепочку резервных вариантов. Content steering добавляет второй документ – короткий список на доске объявлений, которую кафе обновляет каждые пять минут: он показывает, какие поставщики (CDN) в данный момент лучше всего доставляют «кофе». Посетитель смотрит на доску, выбирает поставщика, стоящего первым в списке, и заказывает следующий фрагмент у него. Если порядок поставщиков изменится к следующей проверке, следующий заказ отправится другому поставщику – без необходимости заказывать новое меню, возвращаться в кафе или вести новый разговор. Эта доска объявлений – это steering-манифест. Проверка её по таймеру – это steering. Всё остальное – JSON-ключи, атрибут PATHWAY-ID, параметры запроса CMCD – это просто водопровод.

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

Почему content steering заменяет то, что было до него

Ментальную модель проще всего строить на контрасте.

До content steering multi-CDN-индустрия предлагала три архитектуры с одинаковой формой, но разными режимами отказоустойчивости. DNS-основанный steering – самый старый подход – отвечал на запрос плеера к имени хоста манифеста разными IP-адресами в зависимости от того, какой CDN выбирала политика steering. Управляющей точкой был рекурсивный DNS-резолвер, а время реакции ограничивалось TTL его кэша, который зачастую превышал номинальный TTL из-за минимальных значений, навязываемых провайдерами. Статический failover на стороне плеера передавал список базовых URL CDN через конфигурацию плеера; при сбое запроса плеер последовательно обходил этот список. Каждая реализация работала по-своему, а архитектура не имела представления о глобальном состоянии – она реагировала только на локальные ошибки. Проприетарная сигнализация – индивидуальные решения Netflix, Twitch, YouTube – функционировала на собственных протоколах контроллеров каждой платформы; переносимость отсутствовала.

Хроническая проблема, общая для всех трёх архитектур, – граница посреди сессии. Как только зритель начал смотреть поток, перевод его на другой CDN означал либо перезапуск плеера (из-за DNS – ждать TTL резолвера или разрыв сессии), либо сбой плеера (при статическом failover – ждать, пока запрос завершится ошибкой). Ни одна из архитектур не могла отправить глобальное изменение приоритета плееру, чья сессия уже шла.

Content steering переносит управление на прикладной уровень и освобождает его от зависимости от отказов запросов. Steering-манифест – это небольшой JSON-файл, который плеер периодически опрашивает в соответствии с расписанием, заданным steering-сервером. Когда приоритеты меняются, следующее обновление – как правило, в течение 60–300 секунд – применяет новый порядок. Плееру не требуется перезапуск, не нужно сбрасывать сегмент и не нужно ждать окончания срока действия DNS TTL.

Если кратко: DNS steering срабатывает за минуты (TTL резолверов), статический failover – за секунды до отказа (ошибки плеера), content steering – за секунды, определяемые сервером (TTL JSON-файла, который steering-сервер может установить хоть на 30 секунд, и который dash.js и Shaka Player соблюдают добросовестно).

Сторона HLS – спецификация Apple, тег за тегом

Apple представила HLS Content Steering в редакции HLS Authoring Specification от сентября 2021 года, а сессия WWDC21 «Improve global streaming availability with HLS Content Steering» стала практическим анонсом для разработчиков. Спецификацию обновили на WWDC22 (сессия 10144), добавив семантику Pathway Cloning и PATHWAY-PRIORITY, а текущая версия – HLS Content Steering Specification v1.2 (предварительная v1.2b1 в публикации), согласованная с draft-pantos-hls-rfc8216bis-22 от 1 мая 2026 года. Основную работу выполняют три понятия из словаря.

EXT-X-CONTENT-STEERING – тег в мультимедийном плейлисте

Multivariant-плейлист – манифест верхнего уровня, в котором перечислены все варианты, из которых плеер может выбирать, – получает один новый тег. EXT-X-CONTENT-STEERING является опциональным, встречается не более одного раза в multivariant-плейлисте и содержит два важных атрибута: SERVER-URI (URL steering-манифеста, JSON-документа) и PATHWAY-ID (идентификатор pathway, который плеер должен использовать при запуске до получения первого steering-манифеста).

Разберём пример. Допустим, издатель доставляет через два CDN с идентификаторами cdn-a и cdn-b. Multivariant-плейлист содержит:

#EXTM3U
#EXT-X-VERSION:9
#EXT-X-CONTENT-STEERING:SERVER-URI="https://steering.example.com/manifest?session=xyz",PATHWAY-ID="cdn-a"

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,PATHWAY-ID="cdn-a"
https://cdn-a.example.com/master/1080p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,PATHWAY-ID="cdn-b"
https://cdn-b.example.com/master/1080p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,PATHWAY-ID="cdn-a"
https://cdn-a.example.com/master/720p.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720,PATHWAY-ID="cdn-b"
https://cdn-b.example.com/master/720p.m3u8

Обратите внимание на три момента. Во-первых, один и тот же вариант – 1080p на 5 Mbps – указан дважды, по одному разу для каждого pathway, с разными URL. Каждая строка представляет собой полноценный вариант; группировка обеспечивается именно PATHWAY-ID. Во-вторых, плеер при запуске использует начальный PATHWAY-ID из тега EXT-X-CONTENT-STEERING – здесь cdn-a – до получения первого steering-манифеста. В-третьих, SERVER-URI может содержать токен сессии или идентификатор ассета; steering-сервер использует их, чтобы привязать свои решения к конкретному пользователю.

Манифест управления – JSON-документ

Steering-сервер отвечает на GET-запрос плеера небольшим JSON-объектом. Поля, определённые спецификацией:

{
  "VERSION": 1,
  "TTL": 300,
  "RELOAD-URI": "https://steering.example.com/manifest?session=xyz",
  "PATHWAY-PRIORITY": ["cdn-b", "cdn-a"],
  "PATHWAY-CLONES": []
}

VERSION равен 1 в текущей спецификации; плееры, прочитавшие более высокую версию, обязаны прекратить управление маршрутизацией (steering) и перейти на путь по умолчанию. TTL указывает плееру, сколько секунд ждать до следующего обновления – 300 секунд (5 минут), что является значением по умолчанию от Apple; для прямых трансляций (live-событий) обычно используется 60 секунд, а 30 секунд – практически минимальный порог, ниже которого частота запросов к серверу управления маршрутизацией (steering-серверу) начинает создавать избыточную нагрузку. RELOAD-URI позволяет серверу управления маршрутизацией изменить URL, по которому плеер будет запрашивать обновления – это удобно для обеспечения stickiness, распределения нагрузки на сервер управления маршрутизацией или замены эндпоинта без разрыва сессии. PATHWAY-PRIORITY – упорядоченный список идентификаторов путей (pathway ID), которые плеер должен пробовать в порядке убывания приоритета, от самого высокого к самому низкому.

Семантика: когда плеер получает свежий steering-манифест, он смотрит на PATHWAY-PRIORITY[0] – первую запись – и переключается на этот pathway для следующего сегмента. Если вариант на этом pathway, соответствующий текущему rendition плеера, доступен, плеер использует его; если нет – плеер спускается по PATHWAY-PRIORITY, пока не найдёт подходящий. Разрешение и уровень битрейта текущего варианта не меняются только потому, что сменился pathway – плеер переключается между CDN, а не меняет rendition.

PATHWAY-CLONES – трюк, позволяющий steering-серверу анонсировать совершенно новый CDN посреди сессии

Это та функция, которая обеспечила content steering его преимущество перед DNS-основанным управлением. Допустим, издатель начал сессию с двумя CDN – cdn-a и cdn-b – и где-то посередине сессии решает добавить третий – cdn-c. При DNS-основанной маршрутизации это задача редактирования манифеста: URL нового CDN просто не существуют в уже запущенном multivariant-плейлисте плеера. При content steering сервер маршрутизации может включить cdn-c в следующий steering-манифест через PATHWAY-CLONES:

{
  "VERSION": 1,
  "TTL": 300,
  "PATHWAY-PRIORITY": ["cdn-c", "cdn-b", "cdn-a"],
  "PATHWAY-CLONES": [
    {
      "BASE-ID": "cdn-a",
      "ID": "cdn-c",
      "URI-REPLACEMENT": {
        "HOST": "cdn-c.example.com",
        "PARAMS": {"region": "eu-west"}
      }
    }
  ]
}

Плеер анализирует массив PATHWAY-CLONES и определяет, что cdn-c – это копия cdn-a (именно того самого BASE-ID), в которой изменён хост и добавлен query-параметр. На основе этого плеер формирует URL для вариантов cdn-c, применяя замену URI к каждому URL варианта на основе данных из cdn-a. С точки зрения плеера, cdn-c становится полноценным путём (pathway), на который можно переключиться – без необходимости загружать новый multivariant-плейлист.

Механизм вознаграждает аккуратный дизайн URL на origin: если URL-адреса вариантов каждого CDN следуют одной и той же структуре «путь и имя файла», различаясь только хостом и несколькими query-параметрами, клонирование pathway становится однострочной операцией на steering-сервере, и весь парк плееров мигрирует в пределах одного TTL steering-манифеста. Если же структура URL несогласованна – разные пути и имена файлов на каждом CDN – клонирование pathway невозможно, и издатель вынужден каждый раз пересобирать multivariant-плейлист при добавлении нового CDN.

![Sequence-диаграмма с тремя дорожками: плеер, steering-сервер, CDN-A, CDN-B. Плеер скачивает multivariant-плейлист (содержащий оба pathway), затем скачивает steering-манифест, получает JSON с PATHWAY-PRIORITY=[cdn-a, cdn-b] и начинает запрашивать сегменты у cdn-a. Через пять минут плеер перескачивает steering-манифест; в ответе приоритет перевёрнут на PATHWAY-PRIORITY=[cdn-b, cdn-a]; следующий сегмент уходит к cdn-b без перезапуска плеера.](./images/06_5-content-steering-multi-cdn__02-handshake-sequence.svg) Рис. 2. Полный handshake content steering. Один начальный bootstrap, затем ровная частота маленьких JSON-опросов, содержимому которых плеер подчиняется на самом следующем запросе за сегментом.

Сторона DASH – ETSI TS 103 998 простыми словами

Версия content steering от DASH-IF начала разрабатываться как документ Community Review в конце 2022 года, при этом тесно координировалась с работой Apple над HLS. В январе 2024 года она была опубликована в качестве формальной спецификации European Telecommunications Standards Institute – ETSI TS 103 998 V1.1.1. Цель проектирования была чёткой: один и тот же steering-сервер должен управлять как HLS-, так и DASH-плеером без необходимости вносить изменения в код на стороне сервера. Две спецификации не идентичны – различия в терминологии обусловлены различиями в форматах манифестов, – однако словарь на уровне JSON сделан намеренно совместимым.

Где живёт steering-тег в MPD

Манифест DASH, Media Presentation Description (MPD), – это XML-документ. Элемент content-steering является дочерним по отношению к корневому элементу MPD: ContentSteering

<MPD ...>
  <ContentSteering
      defaultServiceLocation="cdn-a"
      queryBeforeStart="true">
    https://steering.example.com/manifest?session=xyz
  </ContentSteering>
  <Period>
    <AdaptationSet>
      <BaseURL serviceLocation="cdn-a">https://cdn-a.example.com/</BaseURL>
      <BaseURL serviceLocation="cdn-b">https://cdn-b.example.com/</BaseURL>
      <Representation .../>
    </AdaptationSet>
  </Period>
</MPD>

Работу выполняют три понятия. Сам ContentSteering содержит URL steering-сервера в качестве текстового содержимого. defaultServiceLocation выполняет роль стартового PATHWAY-ID в HLS – это CDN, который плеер использует до загрузки первого steering-манифеста. queryBeforeStart (булево значение) указывает плееру, нужно ли блокировать начало воспроизведения на первом ответе steering-сервера (true) или начинать оптимистично со значением по умолчанию и применять steering при следующем обновлении (false). Паттерн с двумя BaseURL и разными значениями serviceLocation – это способ, которым DASH передаёт то, что в HLS выражается двумя записями EXT-X-STREAM-INF с разными атрибутами PATHWAY-ID.

Манифест DASH

JSON, который возвращает DASH-управляющий сервер, намеренно близок к HLS:

{
  "VERSION": 1,
  "TTL": 300,
  "RELOAD-URI": "https://steering.example.com/manifest?session=xyz",
  "SERVICE-LOCATION-PRIORITY": ["cdn-b", "cdn-a"],
  "PATHWAY-PRIORITY": ["cdn-b", "cdn-a"]
}

SERVICE-LOCATION-PRIORITY – нативный ключ DASH; он соответствует атрибуту serviceLocation в элементах BaseURL в MPD. PATHWAY-PRIORITY – алиас, согласованный с HLS, введённый ради совместимости между спецификациями: сервер может публиковать либо один из них, либо оба, либо только SERVICE-LOCATION-PRIORITY, и клиенты, соответствующие спецификации DASH, будут следовать указанным ключам. Ключи VERSION, TTL и RELOAD-URI имеют ту же семантику, что и в HLS.

Практическое следствие для поставщиков steering-серверов: один HTTP-эндпоинт, один JSON-объект – оба семейства клиентов обслужены. Стоимость поддержки DASH в дополнение к HLS на стороне сервера по сути нулевая. На стороне плеера затраты реальны, но ограничены: dash.js, Shaka Player и DASH-движок Video.js v10 реализуют content steering через свой парсер MPD; hls.js, HLS-движок Shaka Player и нативный плеер iOS / tvOS – через парсер мультимедийного плейлиста HLS.

Как на самом деле принимает решение steering-сервер

До этого момента steering-сервер был чёрным ящиком, выдававшим JSON-список в определённом порядке. Возникает вопрос: как он определяет этот порядок? Честный ответ – «зависит от вендора и от телеметрии, которую плееры отправляют обратно». В данных развёртываний 2024–2026 годов можно выделить три основных подхода.

Подход 1 – здоровье и вес. Простейший сервер маршрутизации. Оператор задаёт статический порядок приоритетов и набор health-чеков для каждого CDN: если health-чек CDN не проходит, этот CDN перемещается в конец списка. Взвешенные варианты позволяют реализовывать простые региональные распределения – например, 70% зрителей из США направляются на CDN-A, 30% – на CDN-B. Распределение вычисляется с помощью детерминированного хеша токена сессии. Большинство DIY-решений для маршрутизации используют именно этот подход, поскольку он работает без телеметрии со стороны плеера. Главное ограничение – сервер маршрутизации не получает информации о реальном опыте отдельных пользователей.

Подход 2 – на базе CMCD. Спецификация Common Media Client Data от Consumer Technology Association – CTA-5004, опубликованная в 2020 году, – определяет небольшой набор ключей (длина буфера, пропускная способность, ID контента, ID сессии, количество пропущенных кадров, запрошенный битрейт), которые плеер прикрепляет к каждому запросу медиа-объекта – либо в виде кастомного HTTP-заголовка, либо как query-параметр. Steering-сервер, размещённый перед CDN, может прочитать эти ключи непосредственно из запроса на получение steering-манифеста: спецификация HLS от Apple определяет query-параметры _HLS_pathway (текущий путь плеера) и _HLS_throughput (пропускная способность, измеренная плеером на этом пути), которые steering-сервер может использовать напрямую. Эти данные агрегируются по тысячам одновременных зрителей, что позволяет принимать решения на основе фактической информации. Например, можно заранее перевести зрителей с CDN, производительность которого ухудшается в конкретном регионе, ещё до того, как начнутся массовые события повторной буферизации. Работа Mile-High Video 2024 по референсной реализации в dash.js и пилотный проект quality-aware-multi-CDN от einbliq.io демонстрируют измеримые улучшения QoE: в среднем сокращение времени повторной буферизации на несколько процентов, с более значительным выигрышем для зрителей из нижнего дециля. При этом сравнения проводились с health- и weight-ориентированным steering на той же нагрузке.

Подход 3 – на базе обучения. Недавние академические работы (CADENCE на ACM Multimedia Systems Conference 2026; StreamWise на MMSys 2025; IMAC на MHV 2025) демонстрируют решения на основе multi-agent и reinforcement learning для управления маршрутизацией (steering), которые в контролируемых экспериментах превосходят как подходы health-and-weight, так и методы агрегации CMCD. Ни одно из этих решений пока не получило широкого распространения в 2026 году – операционные риски и высокие требования к обучающим данным заставляют команды, отвечающие за продакшн, продолжать полагаться на эвристики CMCD. Ожидайте появление первых коммерческих продуктов по управлению маршрутизацией на основе обучения в 2026–2027 годах от тех же вендоров, что и поставщики нейронного ABR – Bitmovin, Mux, Visionular.

Подход к решению не связан со спецификацией – она ничего не говорит о том, как генерируется JSON. Спецификация определяет лишь его формат. Интеллект – это задача оператора и именно тот фактор, который отличает вендоров steering-серверов.

Разобранный пример – математика переключения на основе CMCD

Допустим, издатель проводит крупное live-событие с 800 000 одновременных зрителей, распределённых между двумя CDN в соотношении 50/50. TTL steering-манифеста составляет 60 секунд. В момент T = 0 оба CDN работают стабильно. На T = 8 минут edge CDN-A во Франкфурте начинает ограничивать пропускную способность пирингового канала, из-за чего средний throughput, измеряемый по параметру _HLS_throughput, падает с 18 Mbps до 6 Mbps для 60 000 зрителей, направленных на этот CDN.

CMCD-агрегатор steering-сервера фиксирует падение пропускной способности в течение одной минуты – среднее значение по франкфуртской когорте превышает порог срабатывания алерта к T = 9 минутам. Steering-сервер меняет приоритеты для этих 60 000 зрителей: PATHWAY-PRIORITY переключается с ["cdn-a", "cdn-b"] на ["cdn-b", "cdn-a"]. На следующем обновлении steering-манифеста (между T = 9 и T = 10 минутами) каждый затронутый плеер получает новый приоритет и переходит на CDN-B для следующего сегмента.

Арифметика спасённых событий rebuffering:

• До переключения: 60 000 зрителей × ~9,5 среднего видеобитрейта / 6 Мбит/с пропускной способности = устойчивое голодание загрузки; ожидаются rebuffer’ы в течение 30 секунд после опустошения буфера при 30-секундном буфере плеера.
• Задержка обнаружения переключения: 60 секунд (окно агрегации CMCD).
• Распространение steering: до 60 секунд (TTL steering-манифеста).
• Полная задержка реакции: ≤ 120 секунд.
• Буфер плеера: 30 секунд для live (LL-HLS) или 30 секунд для стандартного HLS при типичных конфигурациях.

Гонка некомфортная. При развёртывании со статическим CDN все 60 000 зрителей столкнулись бы с rebuffer. В случае использования DNS-steering и TTL в 60 секунд на рекурсивном резолвере (наилучший сценарий) новые сессии переключились бы на CDN-B, но существующие сессии, использующие кэшированные DNS-ответы, всё равно получили бы rebuffer. При развёртывании с content steering сервер управления трафиком может изменить приоритет каждой активной сессии в пределах TTL манифеста – и полная задержка реакции в 120 секунд едва успевает опередить 60-секундный буфер плеера для тех зрителей, которые ещё не начали его проедать к моменту распространения переключения.

Пример приведён намеренно сжатым; в реальных развёртываниях TTL steering-манифеста устанавливается с учётом длины буфера плеера, окна агрегации CMCD и типичного режима отказа CDN. TTL в 30 секунд обеспечивает больший запас, но нагрузка на steering-сервер при этом возрастает вдвое. Компромиссы накапливаются.

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

Покрытие плееров и CDN – кто реально это поставляет в 2026 году

Покрытие спецификацией и покрытие в поставке – разные вещи. Вот картина 2026 года, составленная на основе релизных заметок, документации вендоров и материалов рабочей группы SVTA Architectures-for-Multi-CDN-Switching.

Плееры, поставляющие content steering для HLS, DASH или обоих. Нативный Apple AVPlayer поддерживает HLS Content Steering с iOS 15 / tvOS 15 / macOS Monterey (2021) и стал первой реализацией в составе поставляемого ПО. Референсный плеер DASH-IF dash.js добавил поддержку content steering в pull request #4031 в 2023 году и достиг полной поддержки версии 1 в dash.js 4.5. Shaka Player (Google) поддерживает content steering v1 как для DASH, так и для HLS – это была первая кросс-протокольная реализация. hls.js внедрил content steering в версии 1.3+ в апреле 2023 года, с последующими исправлениями в 1.5.х и 1.6.х (1.6.15 исправил обработку хоста в URI-REPLACEMENT; в 1.6.х также был исправлен порядок PARAMS для клонов pathway). Video.js v10 со Streaming Processor Framework обеспечивает content steering через свой движок videojs/http-streaming; статус реализации описан на странице документации в репозитории videojs/http-streaming. Android Media3 / ExoPlayer поддерживает content steering начиная с линейки релизов Media3 1.4. Нативные плееры smart-TV – Tizen, webOS, Vidaa – поставляют движки, совместимые с content steering, в прошивках последних моделей; старые прошивки в install-базе не всегда обновляются, и к 2026 году реальное покрытие на smart-TV составляет около 60–80% install-базы.

CDN, поддерживающие модель pathway. Все крупные коммерческие CDN – Akamai, Cloudflare, Fastly, AWS CloudFront, Google Media CDN, Edgio (бывший Limelight + EdgeCast) – работают с content steering, поскольку эта технология не требует изменений со стороны CDN. CDN просто отдают сегменты по тем URL, которые запрашивает плеер; вся логика pathway реализуется между плеером и steering-сервером. Некоторые CDN (например, Akamai и Cloudflare) предлагают готовые решения в виде steering-серверов как часть своих multi-CDN-платформ; другие (такие как Fastly и AWS) оставляют реализацию steering-сервера на стороне клиента или третьей стороны.

Вендоры steering-серверов. Рынок 2026 года включает Cedexis / Citrix Intelligent Traffic Management, NS1 (ныне часть IBM), CDNetworks, MediaMelon (CDN-X), Touchstream Brewer, einbliq.io, THEO Technologies (HLS/DASH-руление контентом как часть THEOplayer) и Broadpeak. Несколько клиентов используют собственные steering-серверы – спецификация настолько проста, что компетентная backend-команда может за пару недель реализовать рабочую версию. При этом основная сложность лежит не в формате JSON, а в агрегации телеметрии.

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

Типовые ошибки

Multi-CDN-развёртывания падают по схожим сценариям, а развёртывания с content-steering наследуют большинство этих сценариев отказа, добавляя к ним небольшое число уникальных для данной спецификации.

Ошибка 1 – steering-сервер становится единой точкой отказа. Вся архитектура зависит от доступности steering-сервера. Если steering-эндпоинт выходит из строя – из-за сбоя DNS, истечения сертификата, обновления деплоя или любой другой причины – плееры не могут обновиться и либо остаются на последнем выбранном pathway, либо откатываются на предыдущий вариант из multivariant-плейлиста. Спецификации предусматривают такое поведение (плеер продолжает воспроизведение на текущем pathway), но преимущество использования multi-CDN теряется, как только steering-сервер становится недоступным. Митигация: размещать steering-эндпоинт минимум в двух регионах с health-чеками и размещать его на инфраструктуре, устойчивой к сбоям CDN, которая сама не зависит ни от одного из CDN, между которыми осуществляется steering.

Ошибка 2 – TTL выставлен слишком длинным для профиля отказа. 300-секундный TTL подходит для балансировки нагрузки при стабильной работе, но он слишком велик для сбоя на уровне CDN во время важного прямого эфира. Оптимальный TTL зависит от буфера плеера (≤ 30 секунд для live), окна агрегации CMCD (около 60 секунд в большинстве реализаций) и издержек на частые запросы к steering-серверу. Повторяющийся вывод из post-mortem-анализа: TTL следует выбирать исходя из худшего сценария, который нужно пережить, а не из среднего случая, который хочется оптимизировать.

Ошибка 3 – несогласованный дизайн URL между CDN блокирует PATHWAY-CLONES. Если варианты CDN-A размещены по https://cdn-a.example.com/streams/{contentid}/1080p_8.m3u8, а CDN-B – по https://cdn-b.example.com/v1/{contentid}/master/1080p.m3u8, steering-сервер не может объявить новый CDN клоном – структуры URL различаются. Решение – стандартизировать структуру URL между CDN на этапе упаковки на origin. Цена позднего исправления – пересборка манифеста и сброс сессии плеера.

Ошибка 4 – идентификаторы CMCD утекают в ключи кэша. Режим CMCD с query-параметрами добавляет CMCD=... к каждому URL сегмента. Если ключ кэша CDN формируется на основе полного URL, включая query string (что является значением по умолчанию для большинства CDN), кэш фрагментируется по каждой сессии: каждый зритель получает уникальный URL, и показатель hit ratio кэша резко падает. Решение хорошо известно и подробно задокументировано (настроить CDN на удаление CMCD-параметров из query string перед вычислением ключа кэша или использовать режим CMCD через HTTP-заголовки вместо query-параметров), однако это – самая распространённая ошибка, с которой сталкиваются команды при первой настройке CMCD на стороне сервера.

Ошибка 5 – install-base smart-TV не совпадает со спецификацией. Устройства Tizen, webOS и Vidaa последних моделей оснащены нативными плеерами, совместимыми с content-steering. У старых устройств такой совместимости нет. Multi-CDN-стратегия, основанная на предположении, что 100% аудитории можно направить через steering, не будет работать на сегментах со старыми прошивками. Митигация: отслеживать долю live-аудитории, способной к steering, по строке user-agent, и поддерживать DNS- или статический failover для остальных.

Ошибка 6 – отношение к steering-серверу как к маркетинговой поверхности. Решения, принимаемые steering-сервером, критически важны для доставки контента; это не место для алгоритмов рекомендаций. Логика работы steering-сервера должна быть максимально узкой (производительность, стоимость, отказоустойчивость). Всё остальное – в манифесте, плеере или отдельном сервисе.

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

В OTT- и live-стриминговых продуктах, которые мы поставляли – включая платформы видеоконференций с WebRTC-резервированием на HLS, e-learning-системы, транслирующие как записанные лекции, так и живые занятия, телемедицинские решения, требующие устойчивости сессий между регионами, – multi-CDN стал необходимым не из-за экономии, а ради отказоустойчивости. Стандарты HLS / DASH Content Steering изменили подход к доставке контента. Там, где раньше мы использовали плеер-специфичные SDK для failover и DNS-управляемые конфигурации, работавшие по-разному на iOS, Android, в вебе и на smart TV, теперь мы предоставляем единый эндпоинт steering-манифеста, единый кросс-платформенный JSON-контракт и одну трубу телеметрии через CMCD. Важна операционная дисциплина на самом сервере steering: его uptime, TTL, наблюдаемость и логика принятия решений. Следующая статья в треке Learn – о токен-аутентификации и подписанных URL – объясняет, как избежать сбоев на уровне per-CDN-аутентификации, которые могут повлиять на слой steering.

Одностраничный чек-лист готовности

Чек-лист на следующей странице – тот самый, который мы используем при оценке развёртывания content-steering для клиента. PDF-файл содержит версию, готовую к печати.

В сжатой форме:

1. Дизайн URL origin – URL-сегменты (путь, имя файла, query-параметры) структурно идентичны на всех кандидатных CDN; отличается только хост. PATHWAY-CLONES зависит от этой структуры.
2. Двойные pathway в манифесте – каждый вариант публикуется дважды, по одному на каждом CDN, с PATHWAY-ID (HLS) или serviceLocation (DASH), указывающим, какой CDN используется.
3. Эндпоинт steering-сервера – размещается на надёжной инфраструктуре, независимой от CDN, между которыми происходит переключение; health-чеки должны выполняться минимум из двух регионов.
4. TTL steering-манифеста – устанавливается как функция от времени буферизации плеера и окна агрегации CMCD; рабочий диапазон – 60–300 секунд.
5. CMCD upstream – плееры настроены на передачу CMCD через заголовок (предпочтительно) или query string (с исключением из ключа кэширования на каждом CDN).
6. Проверка покрытия плееров – задокументированы минимальные поддерживаемые версии: hls.js ≥ 1.4, dash.js ≥ 4.5, Shaka Player ≥ 4.5, Video.js v10 с VHS, AVPlayer iOS 15+, Android Media3 1.4+.
7. Fallback для smart-TV – реализован DNS- или статический failover для старых прошивок smart-TV, не поддерживающих steering-совместимые плееры.
8. Наблюдаемость steering-сервера – дашборды с частотой запросов, историей содержимого JSON, счётчиками зрителей по pathway и метриками агрегации CMCD.
9. Режимы отказа – заранее продумано поведение системы в случае недоступности steering-эндпоинта, сбоя одного CDN или одновременного «пожелтения» всех CDN.
10. План A/B-теста – внедрение steering начинается с части аудитории, измеряются rebuffer ratio, время старта и трафик с origin по сравнению с контрольной группой без steering, после чего происходит полный переход на 100%.

Скачать чек-лист готовности к Content Steering (PDF)

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

• Content Steering – это стандарт IETF, Apple, DASH-IF и ETSI, заменяющий вендор-специфичную сигнализацию для работы с несколькими CDN.
• Механизм: плеер периодически запрашивает небольшой JSON-файл с учётом TTL; в этом файле перечислены идентификаторы CDN в порядке приоритета.
• HLS использует PATHWAY-ID; DASH использует serviceLocation; один и тот же сервер управления маршрутизацией может обслуживать оба протокола.
• PATHWAY-CLONES позволяет серверу управления маршрутизацией объявлять новый CDN в ходе сессии без пересборки манифеста.
• Восходящая телеметрия CMCD превращает content steering в замкнутый контур управления, ориентированный на качество.
• Сервер управления маршрутизацией становится компонентом на критическом пути – проектируйте его с тем же уровнем доступности, что и origin.

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

• Multi-CDN: архитектура, экономика и режимы отказа – архитектура, описанная в статье.
• Токен-аутентификация и подписанные URL – как избежать сбоев в работе слоя маршрутизации из-за аутентификации.
• QoE-метрики: что должен показывать каждый дашборд – ключевые показатели, подтверждающие эффективность развёртывания системы маршрутизации.