Сколько мегабит нужно на одного зрителя стрима: считаем предел канала по аудитории

MAATRIX

Стрим набирает зрителей, а сервер вдруг начинает «тупить» — картинка рассыпается на кубики, кто-то отваливается, кто-то жалуется на буферизацию. Первая мысль — не хватает CPU или диска, но чаще всего дело в куда более скучной вещи: закончился исходящий канал. Каждый зритель — это отдельный поток данных с вашего сервера, и его количество упирается не в мощность процессора, а в арифметику: сколько мегабит в секунду вы можете отдать наружу и сколько мегабит потребляет один просмотр.

Базовая формула: полоса делить на битрейт

Расчёт максимальной аудитории для одного качества стрима — это одна простая формула:

Максимум зрителей = Доступная исходящая полоса (Мбит/с) / Битрейт одного зрителя (Мбит/с)

Пример: у вас выделенный сервер с портом 1 Гбит/с, вы отдаёте стрим в одном качестве с битрейтом 6 Мбит/с (условное 1080p60 с запасом на скачки сложных сцен). Формально:

1000 Мбит/с / 6 Мбит/с ≈ 166 зрителей

Но это теоретический потолок при 100% использовании канала, а реально к нему приближаться нельзя — ни один провайдер и ни одна сетевая карта не отдают заявленную полосу «под ноль» стабильно. На практике закладывайте запас минимум 20-30% на накладные расходы протоколов, скачки битрейта на сложных сценах (переходы, огонь, быстрое движение — encoder временно поднимает битрейт даже при постоянном целевом значении) и на то, чтобы не работать на грани, где любая аномалия валит сервис. С запасом 30% формула из примера даёт уже не 166, а ближе к 115-120 зрителей одновременно — и это по-прежнему верхняя оценка, не гарантия.

Второй фактор, который часто забывают — это разница между «канал до 1 Гбит/с» и «гарантированный канал 1 Гбит/с». Первое — это лимит порта на общем аплинке, который де-факто делится с соседями по стойке в моменты их пиков. Для стрима с предсказуемой аудиторией это не критично, но если вы рассчитываете именно на гарантированную полосу под нагрузкой — уточняйте это явно при выборе тарифа, а не полагайтесь на цифру в описании порта. Подробнее о разнице между заявленной и фактически доступной полосой — в статье про канал 1G против 10G на выделенном сервере.

Множественные битрейты: adaptive bitrate streaming

Реальные стриминговые сервисы почти никогда не раздают всем зрителям один и тот же поток. Вместо этого используется adaptive bitrate streaming (ABR) — технология, знакомая по HLS (HTTP Live Streaming) и подобным протоколам: один и тот же контент кодируется сразу в несколько «рендишенов» (renditions) разного качества и битрейта, а плеер зрителя сам переключается между ними в зависимости от скорости своего интернета и размера окна.

Типичная лестница качеств для живого стрима выглядит примерно так (это ориентировочные диапазоны, которые встречаются в практике стриминговых платформ и энкодеров — конкретные цифры зависят от кодека (H.264/H.265/AV1), контента и настроек кодирования, у вас они могут отличаться):

Ключевое следствие для расчёта канала: аудитория делится между рендишенами непредсказуемо, но канал нужно планировать на худший случай — на сценарий, когда непропорционально большая доля зрителей выбирает самое тяжёлое качество (например, во время анонса или пикового момента стрима, когда все одновременно открывают трансляцию на десктопе с хорошим интернетом). Формула усложняется:

Нужная полоса = Σ (число зрителей рендишена × битрейт рендишена) по всем рендишенам

Если ожидаете 500 одновременных зрителей и закладываете консервативное распределение «30% смотрят 1080p60, 30% — 1080p30, 25% — 720p, 15% — 480p и ниже», расчёт по средним значениям диапазонов даёт что-то вроде: 150×7,5 + 150×5 + 125×4 + 75×1,5 ≈ 1125+750+500+112 ≈ 2,5 Гбит/с. Это уже не про VPS с гигабитным портом — это уровень выделенного сервера с 10G-портом или явное указание на то, что раздачу нужно выносить на CDN. Важно: это иллюстрация методики расчёта, а не универсальное распределение аудитории — у вашего проекта пропорции между качествами будут своими, их стоит снимать из реальной статистики плеера, а не угадывать.

Если ваш сервер сам транскодирует входящий поток в несколько рендишенов (например, через ffmpeg или встроенный транскодер медиасервера), закладывайте отдельно нагрузку на CPU/GPU за транскодирование и отдельно — исходящий канал на раздачу уже готовых рендишенов. Это две разные статьи расходов ресурсов, и одно не компенсирует нехватку другого.

Реальный запас: overhead, всплески, инфраструктура

Голая арифметика «битрейт × зрители» занижает реальную потребность в канале по нескольким причинам, которые стоит закладывать заранее:

• Протокольные накладные расходы. TCP/IP-заголовки, TLS-рукопожатия и повторные передачи пакетов при малейшей потере съедают часть полосы сверх «полезного» видеобитрейта. На стабильном канале это единицы процентов, на нестабильном — может доходить до 15-20%.
• Переменный битрейт (VBR). Даже при целевом битрейте 6 Мбит/с encoder кратковременно поднимает его на сложных сценах (быстрое движение, много деталей, смена сцены). Пиковый битрейт может превышать средний на 30-50% на короткие интервалы — и именно пиковые значения определяют, забьётся канал или нет в конкретную секунду.
• Служебный трафик сервера. Чат, API-запросы плеера, метрики, health-checks, возможно — параллельная запись архива на диск или отправка копии на резервный сервер. Это не про зрителей напрямую, но откусывает от общей полосы канала.
• Асимметрия входящего/исходящего. Если сервер сам принимает исходный поток по RTMP от стримера (обычно скромный битрейт, единицы мегабит) и параллельно раздаёт его сотням зрителей, входящий поток почти не влияет на расчёт — узкое место практически всегда исходящий канал, но стоит убедиться, что порт не шейпится симметрично в обе стороны.
• Соседи по инфраструктуре. На «негарантированном» канале (см. выше про «до 1 Гбит/с») чужой пик может временно урезать вашу реальную полосу именно в тот момент, когда она нужна вам самим.

Практический вывод: берите расчётную потребность в канале и умножайте на коэффициент запаса 1,3-1,5. Это не магическое число — это здравый буфер, чтобы всплеск на сложной сцене или временная деградация канала не обрушивали трансляцию для всех зрителей разом. Держать канал заполненным на 95-100% от номинала — верный способ получить массовую буферизацию в самый неподходящий момент, например на пике зрительского интереса.

Когда собственная раздача перестаёт масштабироваться

Собственный сервер отлично работает, пока аудитория укладывается в разумный запас от канала, и пока зрители географически близки к дата-центру, где стоит сервер. У этой модели есть естественный потолок, и полезно заранее понимать, где он проходит:

1. Полоса физически исчерпана. Формула из первого раздела дала предел в 150-300 одновременных зрителей на гигабитном порту (в зависимости от битрейта и запаса) — и вы этот предел достигли или приближаетесь к нему. Следующий шаг — либо более широкий канал (10G и выше), либо распределение нагрузки.
2. Аудитория географически размазана. Один сервер в одной точке мира — это одна и та же задержка и одинаковый маршрут для зрителя из соседнего города и зрителя с другого континента. Зрителям далеко от дата-центра будет хуже независимо от запаса канала — здесь помогает не увеличение полосы, а географическое распределение точек раздачи.
3. Стоимость исходящего трафика растёт быстрее выручки. Если монетизация стрима не покрывает растущий счёт за egress-трафик, дальнейший рост аудитории на своей инфраструктуре становится экономически невыгодным даже при технической возможности его выдержать.
4. Нужна отказоустойчивость, а не только полоса. Один сервер — одна точка отказа. Для критичного по надёжности стрима одного канала с запасом недостаточно — нужно резервирование самого узла раздачи, а не только полосы.

В этот момент естественным следующим шагом становится CDN (Content Delivery Network) — не потому что «так положено», а потому что он решает конкретно проблемы 1-4: распределяет раздачу по множеству узлов по миру, снимает пиковую нагрузку с origin-сервера и переводит расходы из «своя дорогая исходящая полоса» в тарифицируемый по объёму сервис. У CDN тоже есть своя цена и свои ограничения — он не бесплатен и не обязателен при любом трафике. Методику расчёта, когда переход на CDN действительно окупается, а когда раздача со своего сервера всё ещё дешевле и достаточно хороша, разбирает статья CDN против раздачи со своего сервера: когда он окупается. Для многих небольших и средних стримов ответ — не спешить: пока аудитория помещается в канал с комфортным запасом и сосредоточена в одном регионе, собственная раздача обычно дешевле и проще в администрировании.

Методика планирования канала под ожидаемую аудиторию

Порядок действий, который снимает большую часть сюрпризов при росте аудитории:

1. Зафиксируйте битрейт-лестницу. Определите, сколько рендишенов вы отдаёте и битрейт каждого — это не гипотеза, а конкретные цифры из настроек вашего энкодера или транскодера.

2. Оцените целевую и пиковую аудиторию. Не среднюю, а пиковую одновременную — именно она определяет требуемый канал. Если данных ещё нет (новый проект), заложите оптимистичный сценарий с запасом на будущее — расширять канал заранее почти всегда дешевле, чем экстренно мигрировать под нагрузкой.

3. Оцените распределение по качествам. Если сервис уже работает — возьмите реальную статистику плеера (что показывает большинство зрителей). Если проекта ещё нет — считайте консервативно, ближе к худшему сценарию (больше зрителей на высоком качестве, чем вы ожидаете).

4. Посчитайте требуемую полосу по формуле «сумма зрителей на рендишен × битрейт рендишена», умножьте на коэффициент запаса 1,3-1,5.

5. Сверьте с реальными характеристиками тарифа, а не только с заголовком «канал 1 Гбит/с»: гарантированная это полоса или «до», есть ли ограничение по месячному трафику в дополнение к скорости порта (тогда даже при достаточной полосе можно упереться в квоту раньше конца месяца).

6. Заложите мониторинг канала заранее, а не по факту жалоб зрителей. Простая связка на сервере:

# Разовая проверка текущей загрузки исходящего интерфейса
iftop -i eth0

# Долговременная статистика трафика по интерфейсу
vnstat -i eth0 -l

# Алерт, если исходящая полоса превысила 80% от канала
# (пример логики для скрипта на cron, значение in bytes/sec)
THRESHOLD=93750000  # 750 Мбит/с = 80% от гигабитного порта
CURRENT=$(vnstat -i eth0 --oneline | awk -F';' '{print $11}')

Порог в 80% от номинала — рабочий ориентир для алерта, чтобы успеть отреагировать (добавить сервер, включить резерв, ограничить приём новых зрителей на пиковом качестве) до того, как канал забьётся полностью и начнётся деградация для всех сразу, а не для условного «последнего» зрителя.

7. Спланируйте план Б заранее. Что произойдёт при достижении предела: авто-переключение новых зрителей на более низкий битрейт, очередь/ограничение по числу подключений, подключение резервного сервера или переход раздачи на CDN. Решение, принятое на трезвую голову при планировании, почти всегда лучше решения, принятого в 2 часа ночи во время пикового стрима. Если аудитория уже требует выделенного канала с запасом на рост, стоит сразу смотреть в сторону сервера с широким портом — обзор конфигураций для стриминговой платформы есть в статье выделенный сервер для стриминговой платформы: конфигурация и цена, а если речь о стриминге на одной из популярных площадок вроде Twitch — по требованиям к ресурсам поможет разбор сколько ресурсов нужно VPS для стримера на Twitch и YouTube.

Частые вопросы