Настройка стриминг-сервера: одна отдача на любое число зрителей

Кто стримит без собственного сервера, отправляет картинку каждому зрителю по отдельности. Десять зрителей означают десять раз одни и те же данные, сто зрителей сто раз. Исходящий канал дома или в офисе упирается в потолок уже после нескольких зрителей, и картинка начинает подвисать, хотя компьютер при этом почти не загружен.

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

Проблема: узкое место в вашем исходящем канале

Видео идёт непрерывным потоком. Поток в 1080p с 60 кадрами в секунду требует от 4,5 до 8 Мбит/с в зависимости от содержимого, для 720p это от 3 до 5 Мбит/с. Этот битрейт уходит на каждого зрителя, всё время, без перерыва.

Средний домашний канал в Германии отдаёт от 10 до 50 Мбит/с, даже у многих оптических подключений исходящая скорость лежит в пределах от 50 до 100 Мбит/с. Поэтому арифметика заканчивается быстро:

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

Принцип: один раз наверх, много раз вниз

Схема состоит из трёх частей:

• Источник, то есть OBS, ffmpeg или аппаратный энкодер, отправляет поток на сервер. Это называется ingest.
• Сервер принимает этот один поток, перекладывает его в нужный формат выдачи и держит наготове.
• Зрители забирают поток с сервера. Это называется egress, и именно эта часть растёт вместе с числом зрителей.

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

Сколько трафика реально набегает

Полоса это только половина расчёта. Интереснее объём, потому что у многих провайдеров счёт выставляют именно по нему. Формула простая:

Объём в ГБ = битрейт в Мбит/с × секунды × зрители ÷ 8000

Несколько реалистичных примеров:

Числа в последнем столбце и есть причина, по которой стриминг плохо сочетается с оплатой по объёму. Одна удачная трансляция способна израсходовать включённый объём за целый месяц, и каждый следующий терабайт тогда считают отдельно. В тарифе с безлимитным трафиком этот расчёт исчезает полностью: цена за месяц зафиксирована, независимо от того, прошло через канал 200 ГБ или 50 ТБ.

Какая программа вам подойдёт

Для начала nginx с модулем RTMP самый очевидный выбор: он доступен везде, хорошо документирован, и этот же сервер потом можно без переделок использовать как веб-сервер для страницы со зрителями.

Поднимаем стриминг-сервер на nginx и RTMP

Установка

В Debian и Ubuntu модуль приходит с пакетом libnginx-mod-rtmp, собирать ничего вручную не нужно:

apt update
apt install -y nginx libnginx-mod-rtmp ffmpeg

В AlmaLinux и Rocky Linux модуль берётся из репозитория EPEL:

dnf install -y epel-release
dnf install -y nginx nginx-mod-rtmp ffmpeg

Настройка

Раздел RTMP стоит в nginx.conf вне блока http, это самая частая ошибка новичков. Компактный рабочий вариант выглядит так:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS для обычных зрителей
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # отправлять разрешено только с вашего собственного адреса
            allow publish 203.0.113.10;
            deny publish all;

            # смотреть разрешено всем
            allow play all;
        }
    }
}

Сами файлы HLS отдаёт потом обычный веб-сервер. Для этого хватает небольшого блока в разделе http:

server {
    listen 80;
    server_name stream.example.com;

    location /hls {
        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }
        root /var/www/stream;
        add_header Cache-Control no-cache;
        add_header Access-Control-Allow-Origin *;
    }
}

Создаём каталог, проверяем конфигурацию, перезапускаем:

mkdir -p /var/www/stream/hls
chown -R www-data:www-data /var/www/stream
nginx -t && systemctl reload nginx

Открываем порты

RTMP работает на порту 1935, выдача идёт через 80 и 443. С nftables или ufw:

ufw allow from 203.0.113.10 to any port 1935 proto tcp
ufw allow 80/tcp
ufw allow 443/tcp

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

Отправка из OBS

В OBS в настройках, в разделе «Трансляция», выберите сервис «Особый»:

Битрейт задаётся в разделе «Вывод». Как ориентир: 1080p60 при 6000 кбит/с, 1080p30 при 4500 кбит/с, 720p30 при 3000 кбит/с. Поставьте интервал ключевых кадров в 2 секунды, иначе в HLS получаются неровные сегменты и плеер запинается при переключении.

Просмотр

После этого поток лежит по адресу https://stream.example.com/hls/kanal1.m3u8 и открывается в любом плеере с поддержкой HLS, в браузере, например, через hls.js или Video.js. Для быстрой проверки достаточно VLC и пункта «Открыть URL».

Отправка на несколько платформ одновременно

Это второе большое преимущество собственного сервера. Вместо того чтобы разрывать свой канал тремя параллельными отдачами, вы отправляете один раз на сервер, а он раздаёт дальше. Для этого в блоке application добавляется по строке на каждую цель:

application live {
    live on;
    record off;

    push rtmp://live.plattform-a.example/app/STREAM_KEY;
    push rtmp://live.plattform-b.example/app/STREAM_KEY;
}

Ваша отдача при этом остаётся на уровне одного единственного потока. Размножением занимается сервер, а полоса там именно то, для чего он и существует.

Задержка: какой протокол для чего

Задержка возникает почти полностью при выдаче, а не при отправке. Это важно понимать, потому что многие ищут не в том месте:

Чем ниже задержка, тем дороже обходится отдельный зритель. HLS самый дешёвый, потому что состоит из обычных файлов, которые отдаст любой веб-сервер и любой кеш. WebRTC, напротив, держит для каждого зрителя отдельное соединение и требует заметно больше вычислительной мощности. Берите низкую задержку только там, где она вам действительно нужна.

Транскодирование: когда оно оправдано

Пока сервер просто пересылает поток дальше, вычислительная мощность ему почти не нужна. Одно современное ядро обслуживает так несколько сотен зрителей, узким местом остаётся только канал.

Как только вы захотите предложить несколько уровней качества, чтобы смотреть могли и зрители со слабым соединением, картина меняется. Каждый дополнительный уровень нужно вычислить:

ffmpeg -i rtmp://127.0.0.1/live/kanal1 \
  -c:v libx264 -preset veryfast -b:v 3000k -s 1280x720 -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_720 \
  -c:v libx264 -preset veryfast -b:v 1200k -s 854x480  -c:a copy -f flv rtmp://127.0.0.1/live/kanal1_480

Считайте от двух до четырёх ядер на каждый уровень. Три уровня занимают таким образом уже от восьми до двенадцати ядер постоянно. Поэтому хорошо подумайте, нужны ли они вам: для публики, которая в основном сидит за компьютером или в Wi-Fi, часто достаточно одного удачно выбранного уровня.

Защита: кому разрешено отправлять

Стриминг-сервер виден снаружи, и его находят. Для повседневной работы хватает трёх мер:

• Файрвол на порт отправки. На 1935 пускаем только ваш собственный адрес. Если ваш адрес меняется, пользуйтесь вместо этого доступом к серверу через VPN.
• Проверка ключа потока. С помощью on_publish nginx при каждой попытке отправки вызывает небольшой скрипт, который сверяет ключ со списком и при несовпадении отказывает.
• Базовая защита от перегрузки. Стриминг-сервер это заманчивая цель, потому что сбой виден сразу. У KernelHost на каждом сервере лежит защита от флуда с запасом 3,2 Тбит/с, и настраивать для этого ничего не нужно. Подробнее на странице о защите от DDoS.

Выбор площадки и несколько серверов

Сервер нужен не рядом с вами, а рядом с вашими зрителями. Ваше собственное соединение с сервером устанавливается один раз и потом работает стабильно, даже через полконтинента. А вот соединение со зрителями определяет время загрузки и долю тех, кто уходит.

Если ваша публика в основном в Европе, площадка в Германии стоит правильно. Если она распределена по нескольким континентам, оправдан второй сервер и распределение через DNS, чтобы каждый зритель попадал на ближайший. KernelHost предлагает для этого площадки в Германии, на западном побережье США, на восточном побережье США, а также в Сингапуре и Южной Корее, обзор вы найдёте на странице Локации серверов.

Если вы раздаёте файлы, а не живую картинку, то есть обновления, изображения или видеоархивы, правильный инструмент не стриминг-сервер, а кеш перед ним. Как это работает, описано в статье Строим свой CDN-сервер.

Какой сервер подойдёт

Для стриминг-сервера важен другой порядок приоритетов, чем для веб-сервера:

1. Канал и трафик. Это узкое место, причём всегда. Настоящий гигабитный канал без ограничения скорости несёт около 160 зрителей при 6 Мбит/с.
2. Безлимитный трафик. Тарифы с оплатой по объёму для стриминга почти не поддаются расчёту, потому что один удачный вечер расходует месячный объём.
3. Процессор. Второстепенен, пока вы не транскодируете. При транскодировании он становится вторым узким местом.
4. Оперативная память и диск. Самое некритичное. Место на диске становится темой только тогда, когда вы храните записи.

Ровно на этот случай рассчитаны наши серверы с безлимитным трафиком: настоящий канал 2 × 1 Гбит/с на каждый сервер, неограниченный объём без ограничения скорости, фиксированная цена за месяц независимо от переданного количества и защита от флуда на 3,2 Тбит/с с завода. Сервер выдаётся меньше чем за 30 секунд, с полным доступом root, с IPv4 и сетью IPv6 /64. Оплата идёт по предоплате, отказаться можно ежемесячно, так что вы можете начать с небольшого тарифа и расти вместе с публикой.