Собственный live-стриминг для Азии: origin на SRS в Гонконге, Токио или Сингапуре с CDN

Чтобы запустить собственную платформу live-трансляций для зрителей в Азии, разместите origin на SRS (или nginx-rtmp) на выделенном сервере в Гонконге, Токио или Сингапуре, принимайте поток по RTMP или SRT, отдавайте HLS и WebRTC, а раздачу зрителям доверьте CDN. У IMIDC есть всё необходимое: выделенные серверы в Гонконге от $139/мес с маршрутом CN2 GIA в материковый Китай, выделенные серверы в Японии, серверы в Сингапуре по запросу, аплинки 10 Гбит/с, защита от DDoS и CDN IMIDC.

Из чего состоит собственная система live-стриминга

Платформа трансляций состоит из четырёх этапов: приём, origin/упаковка, распространение и воспроизведение.

1. Приём: OBS, vMix или аппаратный энкодер ведущего отправляет RTMP или SRT на origin.
2. Origin: SRS принимает поток, при необходимости транскодирует в несколько битрейтов, нарезает HLS-сегменты, отдаёт WebRTC и пишет запись на диск.
3. Распространение: CDN забирает HLS с origin и кэширует сегменты рядом со зрителями.
4. Воспроизведение: hls.js, Video.js или нативные плееры для HLS; WebRTC-плеер для интерактива с задержкой меньше секунды.

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

Выбор протоколов приёма и воспроизведения

На вход — RTMP или SRT, для масштаба — HLS, а WebRTC — только там, где важна интерактивность.

SRS обрабатывает RTMP, SRT, HLS, HTTP-FLV и WebRTC в одном процессе. Если вам нужен именно LL-HLS с частичными сегментами, сначала убедитесь, что его поддерживают и упаковщик, и CDN, и только потом обещайте зрителям низкую задержку.

Развёртывание SRS в Docker на выделенном сервере

SRS отлично работает в Docker; важно правильно задать порты, публичный IP-кандидат для WebRTC и постоянные каталоги.

mkdir -p /opt/srs/conf /opt/srs/html /opt/srs/record
# put srs.conf (below) into /opt/srs/conf/srs.conf, then:
docker run -d --name srs --restart unless-stopped \
  -p 1935:1935 -p 1985:1985 -p 8080:8080 \
  -p 8000:8000/udp -p 10080:10080/udp \
  -e CANDIDATE=203.0.113.20 \
  -v /opt/srs/conf/srs.conf:/usr/local/srs/conf/srs.conf \
  -v /opt/srs/html:/usr/local/srs/objs/nginx/html \
  -v /opt/srs/record:/usr/local/srs/objs/record \
  ossrs/srs:5 ./objs/srs -c conf/srs.conf

docker logs -f srs          # watch publish / play events
ufw allow 1935/tcp; ufw allow 8000/udp; ufw allow 10080/udp

Готовый к продакшну srs.conf с HLS, HTTP-FLV, WebRTC, SRT, записью и хуком публикации:

listen              1935;
max_connections     3000;
daemon              off;
srs_log_tank        console;

http_api    { enabled on; listen 1985; }
http_server { enabled on; listen 8080; dir ./objs/nginx/html; }
rtc_server  { enabled on; listen 8000; candidate $CANDIDATE; }
srt_server  { enabled on; listen 10080; }

vhost __defaultVhost__ {
    hls {
        enabled         on;
        hls_fragment    2;
        hls_window      12;
        hls_path        ./objs/nginx/html;
        hls_m3u8_file   [app]/[stream].m3u8;
        hls_ts_file     [app]/[stream]-[seq].ts;
        hls_cleanup     on;
    }
    http_remux { enabled on; mount [vhost]/[app]/[stream].flv; }
    rtc        { enabled on; rtmp_to_rtc on; rtc_to_rtmp on; }
    srt        { enabled on; srt_to_rtmp on; }
    dvr {
        enabled     on;
        dvr_plan    session;
        dvr_path    ./objs/record/[app]/[stream]/[2006]-[01]-[02]_[15][04][05].mp4;
    }
    http_hooks {
        enabled     on;
        on_publish  http://127.0.0.1:8085/api/streams/on_publish;
    }
    play { gop_cache on; }
}

Отправьте поток из OBS или ffmpeg и проверьте воспроизведение:

# OBS (RTMP):  Server  rtmp://203.0.113.20/live   Stream key  event1?secret=YOUR_KEY
# SRT push from ffmpeg (OBS can also output SRT):
ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 4000k -g 60 \
  -c:a aac -b:a 128k -f mpegts \
  "srt://203.0.113.20:10080?streamid=#!::r=live/event1,m=publish"

# Playback URLs
# HLS       http://203.0.113.20:8080/live/event1.m3u8
# HTTP-FLV  http://203.0.113.20:8080/live/event1.flv
# WebRTC    http://203.0.113.20:1985/rtc/v1/whep/?app=live&stream=event1   (WHEP)

• Интервал ключевых кадров в энкодере — 2 секунды, в соответствии с hls_fragment 2.
• CANDIDATE должен быть публичным IP сервера, иначе WebRTC-плееры не подключатся.
• Хук on_publish позволяет приложению проверять ключ потока: ответ HTTP 200 с телом 0 разрешает публикацию, любой другой — отклоняет.

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

# simple ABR ladder: pull the source from SRS and publish 720p + 480p renditions
ffmpeg -i rtmp://127.0.0.1/live/event1 \
  -map 0:v -map 0:a -c:v libx264 -preset veryfast -s 1280x720 -b:v 2500k -g 60 \
     -c:a aac -b:a 128k -f flv rtmp://127.0.0.1/live/event1_720 \
  -map 0:v -map 0:a -c:v libx264 -preset veryfast -s 854x480 -b:v 1000k -g 60 \
     -c:a aac -b:a 96k  -f flv rtmp://127.0.0.1/live/event1_480

Предпочитаете nginx-rtmp? Он лёгкий и покрывает связку RTMP → HLS, но не умеет SRT и WebRTC «из коробки»:

# nginx-rtmp alternative (nginx.conf, top level)
rtmp {
    server {
        listen 1935;
        application live {
            live on;
            hls on;
            hls_path /var/www/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;
            on_publish http://127.0.0.1:8085/api/streams/on_publish;
        }
    }
}

Расчёт полосы: зрители × битрейт

Пиковый исходящий трафик равен числу одновременных зрителей, умноженному на средний битрейт, плюс около 10% накладных расходов протокола.

Формула: ГБ в час = Мбит/с × 3600 / 8 / 1000. Один origin с аплинком 10 Гбит/с с запасом обслужит напрямую несколько сотен зрителей; дальше зрителей нужно переводить на CDN, а origin будет питать только кэш CDN. Входящий поток по сравнению с этим мал: 4–6 Мбит/с на один 1080p-поток ведущего.

Связка origin и CDN IMIDC

Пусть CDN забирает HLS с origin по HTTPS, долго кэширует сегменты и около секунды — плейлисты.

# Nginx in front of SRS as the HTTPS origin for the CDN
server {
    listen 443 ssl;
    http2 on;
    server_name origin-live.example.com;
    ssl_certificate     /etc/nginx/ssl/origin-live.crt;
    ssl_certificate_key /etc/nginx/ssl/origin-live.key;

    location ~ \.m3u8$ {
        proxy_pass http://127.0.0.1:8080;
        add_header Cache-Control "max-age=1" always;
        add_header Access-Control-Allow-Origin "*" always;
    }
    location ~ \.(ts|m4s)$ {
        proxy_pass http://127.0.0.1:8080;
        add_header Cache-Control "max-age=86400" always;
        add_header Access-Control-Allow-Origin "*" always;
    }
}

• Направьте имя вроде origin-live.example.com на origin и укажите его как источник в CDN IMIDC; зрители используют имя CDN.
• Плейлисты (.m3u8) меняются с каждым сегментом, поэтому кэшируйте их на 1–2 секунды; сегменты неизменны — кэшируйте надолго.
• Для платных и закрытых мероприятий используйте подписанные URL или токен-аутентификацию на CDN.
• WebRTC-сессии держите на origin (или на нескольких региональных SRS-edge), поскольку HTTP CDN не кэширует WebRTC.

Запись и архивирование

Записывайте каждую трансляцию на origin, а готовые файлы переносите в объектное хранилище для повторов и просмотра по запросу.

# move finished recordings to S3-compatible object storage every 10 minutes (cron)
*/10 * * * * rclone move /opt/srs/record s3store:live-archive --min-age 10m --delete-empty-src-dirs

Каталог записи в конфигурации выше находится вне публичной веб-директории, поэтому исходные записи нельзя скачать, угадав URL. Для долгосрочного архива используйте отдельный сервер хранения или бакет объектного хранилища, а опубликованные повторы транскодируйте в HLS-лестницу.

Где разместить origin и как защититься от DDoS

Размещайте origin ближе к ведущим и основной аудитории и защищайте публичные точки входа.

• Подключите защиту от DDoS IMIDC для origin — особенно игровые и киберспортивные трансляции привлекают атаки.
• Открывайте только нужное: 1935/10080 для приёма (лучше по белому списку IP ведущих), 443 для CDN и порты WebRTC.
• Меняйте ключи потоков для каждого мероприятия и проверяйте их в хуке публикации.
• Трансляции для зрителей из материкового Китая должны содержать законный контент, а live-видеосервисы там могут подпадать под отдельные требования лицензирования; это не юридическая консультация.

Какая конфигурация IMIDC вам подходит

Размер origin определяется числом ведущих, нагрузкой транскодирования и тем, сколько трафика берёт на себя CDN.

• Внутренние вебинары и занятия до нескольких сотен зрителей: один выделенный сервер в Гонконге или в Японии, отдающий HLS напрямую.
• Публичные события и игровые трансляции на тысячи зрителей: выделенный origin с защитой от DDoS плюс CDN IMIDC.
• Мультирегиональная платформа: origin в Гонконге и Токио, Сингапур по запросу через продажи, а при наличии своей ASN — BGP и Anycast для приёма.
• GPU или многоядерные узлы транскодирования, большие диски для архива: запросите индивидуальную конфигурацию у отдела продаж IMIDC.

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

Где лучше разместить сервер для собственных live-трансляций для зрителей в Азии?

Если много зрителей в материковом Китае, обычно выбирают Гонконг, так как серверы IMIDC там используют China Telecom CN2 GIA. Токио подходит для Японии и Кореи, Сингапур — для Юго-Восточной Азии; для смешанной аудитории используйте один origin плюс CDN.

Сколько полосы нужно на 1 000 зрителей?

При 3 Мбит/с на зрителя нужно около 3 Гбит/с пикового исходящего трафика и примерно 1,35 ТБ в час. Поэтому аудиторию такого размера стоит обслуживать через CDN, а не напрямую с origin.

Что выбрать: SRS или nginx-rtmp?

SRS поддерживает RTMP, SRT, HLS, HTTP-FLV и WebRTC в одном сервере и имеет HTTP API, поэтому это более полное решение. nginx-rtmp легче и подходит для простых сценариев RTMP → HLS.

Можно ли получить задержку меньше секунды для тысяч зрителей?

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

Предоставляет ли IMIDC защиту от DDoS для стриминговых origin?

Да. IMIDC предлагает защиту от DDoS, которую можно подключить к серверам, работающим как origin. Сообщите отделу продаж ожидаемый масштаб мероприятий, чтобы защита и порты соответствовали трафику.

Планируете собственную стриминговую платформу? Начните с выделенного сервера в Гонконге или в Токио и CDN IMIDC, либо откройте тикет — команда IMIDC поможет подобрать origin.