Streamszerver beállítása: egy feltöltés akárhány nézőhöz

Aki saját szerver nélkül streamel, minden nézőnek külön elküldi a képet. Tíz néző tízszer ugyanazt az adatot jelenti, száz néző százszor. Az otthoni vagy irodai feltöltés így néhány néző után bedugul, a kép pedig akadozni kezd, miközben a gép unatkozik.

A streamszerver megfordítja ezt: pontosan egy streamet küld a szervernek, és a szerver szolgálja ki vele az összes nézőt. A saját vonalán ezért mindig csak egyetlen feltöltés fut, teljesen mindegy, hogy tíz vagy tízezer ember nézi. Ez a cikk bemutatja, miért működik ez ilyen jól, hogyan állít fel egy ilyen szervert, melyik protokoll mennyi késleltetésbe kerül, és mennyi forgalom jön össze valójában.

A gond: a feltöltés a szűk keresztmetszet

A videó folyamatos adatfolyam. Egy 1080p-s, másodpercenként 60 képes stream tartalomtól függően 4,5 és 8 Mbit/s között igényel, a 720p 3 és 5 Mbit/s között van. Ez a bitsebesség nézőnként folyik, végig, szünet nélkül.

Egy átlagos németországi lakossági előfizetés feltöltésben 10 és 50 Mbit/s között teljesít, és még sok optikai csatlakozás is 50 és 100 Mbit/s között van feltöltésben. A számítás ezért hamar véget ér:

Jön ehhez egy második, gyakran figyelmen kívül hagyott gond: a csatlakozása ezt a vonalat megosztja mindennel, ami a lakásban vagy az irodában történik. Amint valaki egy nagy fájlt tölt fel, vagy elindul egy mentés, a stream beszakad. Egy adatközponti szervernek nincs ilyen gondja, ott a kapcsolat kizárólag az Öné.

Az elv: egyszer fel, sokszor le

A felépítés három részből áll:

• Az adó, vagyis az OBS, az ffmpeg vagy egy hardveres egység, elküld egy streamet a szervernek. Ezt nevezik ingestnek.
• A szerver átveszi ezt az egy streamet, átalakítja a kívánt kiszolgálási formátumra, és készenlétben tartja.
• A nézők a szerverről veszik le a streamet. Ezt nevezik egressnek, és ez az a rész, amely a nézőszámmal együtt nő.

A döntő az aszimmetria: az Öntől a szerverig vezető utat egyszer járja be a kép, a szervertől a nézőkig vezetőt ezerszer. Ezért a saját csatlakozásának csak annyi feltöltés kell, amennyi egyetlen stream, míg a szervernek olyan kapcsolat kell, amely lépést tart a közönséggel.

Mennyi forgalom jön össze valójában

A sávszélesség csak a számítás fele. Érdekesebb a mennyiség, mert sok szolgáltató ez alapján számláz. A formula egyszerű:

Mennyiség GB-ban = bitsebesség Mbit/s-ban × másodperc × nézők ÷ 8000

Néhány valósághű példa:

Az utolsó oszlop számai az okai annak, hogy a streamelés és a mennyiség alapú számlázás nehezen fér össze. Egyetlen jól sikerült közvetítés el tudja használni egy egész hónap benne lévő mennyiségét, és onnantól minden további terabájtot külön számláznak. Korlátlan forgalmú csomagnál ez a számítás teljesen elmarad: a havi díj fix, mindegy, hogy 200 GB vagy 50 TB megy át a vonalon.

Melyik szoftver illik Önhöz

Kezdésnek az nginx az RTMP-modullal a legkézenfekvőbb választás: mindenhol elérhető, jól dokumentált, és ugyanazt a szervert később átalakítás nélkül használhatja webszerverként a nézői oldalhoz.

Streamszerver felállítása nginxszel és RTMP-vel

Telepítés

Debianon és Ubuntun a libnginx-mod-rtmp csomag magával hozza a modult, semmit sem kell saját kézzel lefordítania:

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

AlmaLinuxon és Rocky Linuxon a modul az EPEL-tárolóból érkezik:

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

Beállítás

Az RTMP-rész az nginx.conf fájlban a http blokkon kívül áll, ez a leggyakoribb kezdő hiba. Egy karcsú, működő változat így néz ki:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS a normál nézőknek
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # adni csak a saját címről lehet
            allow publish 203.0.113.10;
            deny publish all;

            # nézni bárki nézhet
            allow play all;
        }
    }
}

A HLS-fájlokat ezután a normál webszerver szolgálja ki. Ehhez elég egy kis blokk a http részben:

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 *;
    }
}

Könyvtár létrehozása, a beállítás ellenőrzése, újraindítás:

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

Portok megnyitása

Az RTMP az 1935-es porton fut, a kiszolgálás a 80-as és a 443-as porton. nftables vagy ufw segítségével:

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

Figyeljen az első sorra: az adóport csak a saját címe felé van nyitva. Egy a világ felé nyitott RTMP-portot néhány napon belül megtalálnak, mert teljes címtartományokat vizsgálnak át automatikusan, és onnantól valaki más ad az Ön vonalán.

Adás az OBS-ből

Az OBS-ben a Beállítások, Stream alatt a szolgáltatásnál válassza az „Egyéni” lehetőséget:

A Kimenet alatt állítja be a bitsebességet. Irányadó értékek: 1080p60 esetén 6000 kbit/s, 1080p30 esetén 4500 kbit/s, 720p30 esetén 3000 kbit/s. A kulcsképkockák távolságát állítsa 2 másodpercre, különben a HLS-nél egyenetlen szegmensek keletkeznek, és a lejátszó akadozik váltáskor.

Nézés

A stream ezután a https://stream.example.com/hls/kanal1.m3u8 címen érhető el, és bármelyik HLS-képes lejátszóval megnyitható, böngészőben például a hls.js vagy a Video.js segítségével. Gyors ellenőrzéshez elég a VLC a „Hálózati megnyitás” funkcióval.

Adás több platformra egyszerre

Ez a saját szerver második nagy előnye. Ahelyett, hogy három párhuzamos feltöltéssel szétfeszítené a vonalát, egyszer küld a szervernek, az pedig továbbosztja. Ehhez az application blokkban célonként felvesz egy sort:

application live {
    live on;
    record off;

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

A feltöltése közben egyetlen streamnél marad. A megsokszorozást a szerver végzi, és ott a sávszélesség pontosan az, amiért a szerver van.

Késleltetés: melyik protokoll mire

A késleltetés szinte teljes egészében a kiszolgálásnál keletkezik, nem az adásnál. Ezt fontos megérteni, mert sokan rossz helyen keresik:

Minél kisebb a késleltetés, annál drágább az egyes néző. A HLS a legolcsóbb, mert egyszerű fájlokból áll, amelyeket bármelyik webszerver és bármelyik gyorsítótár ki tud szolgálni. A WebRTC ezzel szemben minden nézőnek külön kapcsolatot tart nyitva, és így jóval több számítási teljesítményt igényel. Az alacsony késleltetést csak ott válassza, ahol valóban szükség van rá.

Átkódolás: mikor érdemes

Amíg a szerver csak továbbadja a streamet, szinte semmi számítási teljesítményre nincs szüksége. Egyetlen modern mag így több száz nézőt kiszolgál, a szűk keresztmetszet egyedül a hálózati kapcsolat.

Amint több minőségi szintet szeretne kínálni, hogy a gyenge kapcsolatú nézők is nézhessék, ez megváltozik. Minden további szintet ki kell számolni:

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

Szintenként két és négy mag között számoljon. Három szint így már nyolc és tizenkét mag között köt le tartósan. Gondolja át ezért jól, hogy valóban szükség van rájuk: olyan közönségnél, amely túlnyomórészt számítógép előtt vagy Wi-Fin ül, gyakran egyetlen jól megválasztott szint is elég.

Védelem: ki adhat

A streamszerver kívülről látható, és meg is találják. Három intézkedés elég a napi üzemhez:

• Tűzfal az adóportra. Csak a saját címe mehet az 1935-esre. Ha a címe változik, használjon helyette VPN-hozzáférést a szerverhez.
• A streamkulcs ellenőrzése. Az on_publish révén az nginx minden adási kísérletnél meghív egy kis szkriptet, amely egy listához méri a kulcsot, és eltérés esetén elutasít.
• Alapvédelem a túlterhelés ellen. A streamszerver hálás célpont, mert a kiesés azonnal látható. A KernelHostnál minden szerveren 3,2 Tbps kapacitású floodvédelem fut, anélkül hogy bármit be kellene állítania. Erről bővebben a DDoS-védelem oldalon.

Helyszínválasztás és több szerver

A szervernek nem az Ön közelében a helye, hanem a nézői közelében. A saját kapcsolata a szerverhez egyszer épül fel, és utána stabilan fut, akár fél kontinensen át is. A nézőkhöz vezető kapcsolat ezzel szemben a betöltési időről és a lemorzsolódásról dönt.

Ha a közönsége túlnyomórészt Európában van, egy németországi helyszín a jó választás. Ha több kontinensen szóródik szét, érdemes egy második szerver és a DNS-en keresztüli szétosztás, hogy minden néző a hozzá legközelebbinél érkezzen meg. A KernelHost ehhez németországi, az Egyesült Államok nyugati partján és keleti partján lévő, valamint szingapúri és dél-koreai helyszíneket kínál, áttekintést a szerverhelyszínek oldalon talál.

Ha élő kép helyett fájlokat oszt szét, vagyis frissítéseket, képeket vagy videóarchívumokat, akkor nem a streamszerver a megfelelő eszköz, hanem egy gyorsítótár elé állítva. Hogy ez hogyan működik, arról a Saját CDN-szerver felépítése című cikk szól.

Melyik szerver a megfelelő

Streamszervernél más sorrend számít, mint egy webszervernél:

1. Hálózati kapcsolat és forgalom. Ez a szűk keresztmetszet, mindig. Egy valódi, nem korlátozott gigabites kapcsolat 6 Mbit/s mellett körülbelül 160 nézőt visz.
2. Korlátlan forgalom. A mennyiség alapú csomagok streameléshez alig kalkulálhatók, mert egyetlen sikeres este elhasználja a havi mennyiséget.
3. Processzor. Másodlagos, amíg nem kódol át. Átkódolásnál ez lesz a második szűk keresztmetszet.
4. Memória és lemez. A legkevésbé kritikus. Csak akkor lesz téma a lemezhely, ha felvételeket is megőriz.

Pontosan erre az esetre vannak méretezve a korlátlan forgalmú root szervereink: valódi 2 × 1 Gbit/s kapcsolat szerverenként, korlátlan mennyiség sávszélesség-korlátozás nélkül, fix havi díj az átvitt mennyiségtől függetlenül, és gyárilag 3,2 Tbps floodvédelem. A szerver 30 másodperc alatt üzembe áll, teljes root hozzáféréssel, IPv4-címmel és egy /64-es IPv6-hálózattal. A számlázás PrePaid alapú és havonta felmondható, így kezdhet egy kis csomaggal, és növekedhet, ahogy a közönsége nő.