Почему лайв-контент требует мощных серверов и CDN

1) В чём «тяжесть» лайва по сравнению с VOD

Фан-аут в реальном времени. Один входящий поток → тысячи исходящих. Любая просадка CPU/сети мгновенно бьёт по всем зрителям.

Жёсткие SLA по задержке. В лайве важна не только «картинка», но и «сегодняшний воздух»: 0,5–2 с для WebRTC и 2–5 с для LL-HLS.

Постоянный энкодинг/транскодинг. Нужно держать несколько битрейт-лестниц (ABR) и профилей под разные экраны/сети.

Нестабильная сеть зрителя. Требуются адаптивные битрейты, перекадровки, пересборка GOP и агрессивные буферы при пиках.

Невозможность «починить потом». В VOD можно перерендерить. В лайве ошибка кадра — потерянный момент навсегда.

2) Серверы для энкодинга и транскодинга: CPU, GPU, пресеты

Кодеки: H.264/AVC — золотой стандарт совместимости; HEVC/AV1 — экономят трафик, но тяжелее для кодирования и декодирования на слабых устройствах.

Железо:

CPU x264 (veryfast–faster) — стабильность, предсказуемость, но дорогой по ядрам.
GPU NVENC/AMF/Quick Sync — дешёвый на поток, полезен для лестниц ABR.
Настройки низкой задержки: короткий GOP (1–2 сек), ограниченные B-frames, CBR/консервативный VBR, регулярные ключевые кадры для быстрых переключений профилей.
Почему «мощные»: пара десятков одновременных 1080p60 профилей уже упирает сервер в CPU/GPU и память, особенно при многолестничном ABR.

3) WebRTC, SFU и TURN: где нужна «реальная» мощность

SFU (Selective Forwarding Unit). Не микширует, а маршрутизирует потоки → экономит CPU, но требует широкого egress и грамотного фан-аута.

TURN/ICE/STUN. При NAT/фаерволах трафик идёт через TURN — это полный relay, удваивающий нагрузку на uplink.

Backpressure и приоритизация. При перегрузе SFU должен понижать качество/частоту кадров, иначе разорвёт сессию.

Почему CDN недостаточно. WebRTC плохо кэшируется традиционным CDN — нагрузка ложится на медиасерверный слой (SFU-кластеры).

4) LL-HLS/DASH и CDN: как масштабировать зрителей

Кэшируемость сегментов. В отличие от WebRTC, сегменты HLS/DASH кэшируются на edge → резко снижается нагрузка на origin.

Origin-shield и многоуровневый CDN. Edge → региональные кеш-узлы → origin. Высокий cache hit ratio критичен для экономии egress/CPU.

ABR-лестницы. 240p–1080p (иногда 1440p/2160p). Чем больше профилей — тем выше нагрузка на транскодер и хранилище.

Мульти-CDN. Anycast/DNS-steering, real-user measurements (RUM) и автоматический фейловер по метрикам времени загрузки/ошибок.

5) Согласованность времени и событий

Для интерактивных лайв-сценариев (ставки, квизы, лайв-казино):

Жёсткая синхронизация времени (NTP/chrony), отметки `video_ts` в событиях и серверный «источник истины».
Последовательность сообщений (seq, ACK, ретрансмит, идемпотентность).
Реплеи и запись (WORM-хранилище) для разборов спорных моментов.

6) Пример расчёта ёмкости (консервативно)

Поток 1080p с битрейтом ≈ 4 Мбит/с.

Онлайна одновременно: 20 000 зрителей.

Суммарный egress: 4 × 20 000 = 80 000 Мбит/с = 80 Гбит/с.

При 80% cache-hit на edge трафик с origin ≈ 20%: 16 Гбит/с.

Для WebRTC (некэшируемо) если один SFU-узел стабильно держит ~8 Гбит/с egress, нужно ≈ 10 SFU-нод + 2–3 в резерве.

💡 Вывод: даже «умеренный» лайв быстро упирается в сетевой egress и горизонтальное масштабирование медиасерверов.

7) Хранение записей и таймшифт

5 Мбит/с → 0,625 МБ/с → ≈ 2,2 ГБ на час на один профиль.

Для 6 профилей ABR и 10 столов/каналов: 2,2 × 6 × 10 = ≈ 132 ГБ/час.

Нужны «холодные» слои хранения + жизненные циклы (tiering/TTL).

8) Типовые узкие места

CPU/GPU транскодеров. Пики подключений → рост «решейпов» и пересборки GOP.

Сеть SFU и TURN. SNI-блокировки, NAT-симметрик → полный relay и внезапный шпиль нагрузки.

Дисковая подсистема origin. Высокая QPS по мелким сегментам, особенно при LL-HLS.

Память и сокеты. Тысячи WebSocket/DTLS-сессий на ядро требуют тюнинга ядра/epoll и лимитов FD.

GC/RT паузы. На JVM/Node медиашлюзах — настройка GC и изоляция «горячих» путей.

9) Безопасность и защита контента

TLS-терминация на edge, HSTS, современный набор шифров.

Подписанные URL/токены, короткий TTL, гео/реф-ограничения.

DRM/LL-token для защищённых лент.

Анти-скрейпинг/анти-рестрим. Водяные знаки, поведенческие сигналы, непубличные манифесты.

10) Наблюдаемость и SLO

Видеометрии: e2e-задержка, фриз-рейт, пропуски кадров, процент понижения профиля ABR, отказы декодера.

Сеть: throughput по точкам присутствия, переподключения WebRTC, ошибки ICE/TURN, RTT/джиттер.

Сервер: загрузка CPU/GPU, температура, ulimit, количество открытых сокетов, p95/p99 по API.

Продукт: коннект-рейт, удержание, средняя длительность сессии, complaint-rate.

SLO-примеры: 99,5% сегментов доставляются < 1,5 с; 95-й перцентиль задержки WebRTC ≤ 2,5 с; drop-frame < 1%.

11) Оптимизация стоимости без потери качества

Гибрид кодирования: базовые профили на GPU, «красивые» профили для премиум — на x264 CPU.

Content-aware encoding. Динамические битрейты по сценам (статичные/динамичные эпизоды).

Мульти-CDN с ценовым роутингом. Переключение по совокупной метрике качества/стоимости.

Уменьшение числа профилей. Если аудитория — мобильная, 720p часто «держит удар».

Edge-origin-shield. Повышаем cache-hit, снижаем исходящий трафик с origin.

12) Чек-лист для запуска лайва «на мощностях»

Инфраструктура

Кластер транскодеров (CPU+GPU) с автоскейлом и горячим резервом.
SFU-кластер для WebRTC + TURN-пул с белыми IP и мониторингом relay-доли.
Origin-shield и как минимум 2 независимых CDN.
Хранилище с политиками TTL/архивом (WORM) для записей/реплеев.

Низкая задержка

GOP ≤ 2 c, ключевые кадры по расписанию, CBR/low-latency пресеты.
ABR-лестница оптимизирована под мобильный сегмент.
Реал-тайм синхронизация времени, отметки `video_ts` в событиях.

Надёжность

Мультизонность, фейловер потоков, автоматический дегрейд качества вместо дропа.
Тесты на 1,5× плановой нагрузки и «шторм» переподключений.
Полная наблюдаемость: метрики, логи, трассировки, алерты.

Безопасность

Подписанные URL, короткий TTL, гео-ограничения, DRM при необходимости.
TLS на edge, ротация сертификатов, защита от хотлинка/рестримов.
Минимизация PII, сегрегация сетей, аудит доступа.

13) Рецепт архитектуры по роли контента

Интерактив (ставки/викторины/лайв-казино): WebRTC + SFU, ультра-низкая задержка, параллельный LL-HLS как «зрительный» фид.

Трансляции масс-аудитории: LL-HLS/DASH + агрессивный CDN, ABR-оптимизация, запись и таймшифт.

Гибрид: первичка в WebRTC, зеркалирование в LL-HLS для реплеев и отложенного просмотра.

Лайв-контент — это не просто «видео в интернете». Это управляемая в реальном времени фабрика потоков, где медиасерверы, энкодеры, SFU, CDN и хранилища работают синхронно и под пиковыми нагрузками. Мощные серверы нужны, чтобы держать энкодинг и фан-аут без потери кадров; CDN — чтобы доставить миллионам сегменты быстро и дёшево. В связке они дают то, чего ждут зрители и интерактивные сценарии: стабильную картинку, низкую задержку и масштаб, а бизнес — предсказуемую себестоимость и SLA.