Configurezi un server de streaming: un upload pentru oricâți spectatori

Cine transmite fără un server propriu își trimite imaginea separat către fiecare spectator. Zece spectatori înseamnă de zece ori aceleași date, o sută de spectatori de o sută de ori. Uploadul de acasă sau din birou este astfel înfundat după câțiva spectatori, iar imaginea începe să se întrerupă, deși calculatorul nu are aproape nimic de făcut.

Un server de streaming întoarce situația: tu trimiți către server exact un flux, iar serverul alimentează cu el toți spectatorii. Linia ta duce astfel mereu un singur upload, complet indiferent dacă privesc zece sau zece mii de oameni. Articolul arată de ce funcționează atât de bine, cum ridici un astfel de server, ce întârziere costă fiecare protocol și cât trafic se adună în realitate.

Problema: uploadul tău este punctul de strangulare

Videoul este un flux continuu. Un flux în 1080p cu 60 de imagini pe secundă are nevoie, în funcție de conținut, de 4,5 până la 8 Mbit/s, 720p stă între 3 și 5 Mbit/s. Acest bitrate curge pentru fiecare spectator, tot timpul, fără pauză.

O conexiune casnică medie în Germania duce la upload între 10 și 50 Mbit/s, iar chiar și multe racorduri de fibră optică stau la upload între 50 și 100 Mbit/s. De aceea socoteala se termină repede:

Mai apare o a doua problemă, trecută deseori cu vederea: racordul tău împarte această linie cu tot restul din casă sau din birou. Din clipa în care cineva încarcă un fișier mare sau pornește un backup, fluxul se prăbușește. Un server din centrul de date nu are problema asta, acolo conectivitatea îți stă la dispoziție exclusiv ție.

Principiul: o dată în sus, de multe ori în jos

Structura are trei părți:

• Emițătorul, adică OBS, ffmpeg sau o cutie hardware, trimite un flux către server. Asta se numește ingest.
• Serverul preia acest singur flux, îl trece în formatul de livrare dorit și îl ține pregătit.
• Spectatorii își iau fluxul de la server. Asta se numește egress și este partea care crește odată cu numărul de spectatori.

Decisivă este asimetria: drumul de la tine la server se face o singură dată, drumul de la server la spectatori de mii de ori. De aceea racordul tău are nevoie doar de atât upload cât cere un singur flux, în timp ce serverul are nevoie de o conectivitate care ține pasul cu publicul.

Cât trafic se adună în realitate

Banda este doar jumătate din socoteală. Mai interesant este volumul, pentru că la mulți furnizori factura se face după el. Formula este simplă:

Volum în GB = bitrate în Mbit/s × secunde × spectatori ÷ 8000

Câteva exemple realiste:

Cifrele din ultima coloană sunt motivul pentru care streamingul și facturarea la volum se potrivesc prost. O singură transmisiune bine vizitată poate consuma volumul inclus al unei luni întregi, iar fiecare terabyte în plus se socotește apoi separat. La un tarif cu trafic nelimitat socoteala asta dispare complet: prețul lunar este fix, fie că trec 200 GB, fie că trec 50 TB pe linie.

Ce software ți se potrivește

Pentru început, nginx cu modulul RTMP este alegerea cea mai la îndemână: este disponibil peste tot, bine documentat, iar același server îl poți folosi mai târziu, fără modificări, ca server web pentru pagina spectatorilor.

Ridici un server de streaming cu nginx și RTMP

Instalare

Pe Debian și Ubuntu, pachetul libnginx-mod-rtmp aduce modulul cu el, nu trebuie să compilezi nimic:

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

Pe AlmaLinux și Rocky Linux, modulul vine din depozitul EPEL:

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

Configurare

Partea RTMP stă în nginx.conf în afara blocului http, asta este cea mai frecventă greșeală de început. O variantă zveltă și funcțională arată așa:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS pentru spectatorii normali
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # se poate publica doar de la propria adresă
            allow publish 203.0.113.10;
            deny publish all;

            # privit are voie oricine
            allow play all;
        }
    }
}

Fișierele HLS le livrează apoi serverul web normal. Pentru asta ajunge un bloc mic în partea 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 *;
    }
}

Creezi directorul, verifici configurația, repornești:

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

Deschizi porturile

RTMP merge pe portul 1935, livrarea trece prin 80 și 443. Cu nftables sau ufw:

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

Fii atent la prima linie: portul de publicare este deschis doar pentru propria adresă. Un port RTMP deschis către toată lumea este găsit în câteva zile, pentru că intervale întregi de adrese sunt scanate automat, iar atunci transmite altcineva pe linia ta.

Transmiți cu OBS

În OBS, la Setări, Transmisiune, treci serviciul „Personalizat”:

La Ieșire setezi bitrate-ul. Ca reper: 1080p60 cu 6000 kbit/s, 1080p30 cu 4500 kbit/s, 720p30 cu 3000 kbit/s. Pune distanța dintre keyframe-uri la 2 secunde, altfel la HLS apar segmente neregulate și playerul se bâlbâie la comutare.

Privești transmisiunea

Fluxul stă apoi la https://stream.example.com/hls/kanal1.m3u8 și se deschide cu orice player care știe HLS, în browser de exemplu cu hls.js sau Video.js. Pentru o verificare rapidă ajunge VLC, prin „Deschide flux de rețea”.

Transmiți simultan către mai multe platforme

Acesta este al doilea mare avantaj al unui server propriu. În loc să îți arunci linia în aer cu trei uploaduri paralele, trimiți o dată către server, iar el distribuie mai departe. Pentru asta completezi în blocul application o linie pentru fiecare destinație:

application live {
    live on;
    record off;

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

Uploadul tău rămâne la un singur flux. Multiplicarea o preia serverul, iar acolo banda este exact lucrul pentru care există.

Întârzierea: ce protocol pentru ce

Întârzierea apare aproape integral la livrare, nu la transmitere. Este important de înțeles, pentru că mulți caută în locul greșit:

Cu cât întârzierea este mai mică, cu atât devine mai scump fiecare spectator. HLS este cel mai ieftin, pentru că este făcut din fișiere simple, pe care orice server web și orice cache le pot livra. WebRTC ține în schimb o conexiune proprie deschisă pentru fiecare spectator și costă astfel mult mai multă putere de calcul. Ia întârzierea mică numai acolo unde ai nevoie de ea cu adevărat.

Transcodarea: când merită

Cât timp serverul doar retransmite fluxul, nu are nevoie aproape de nicio putere de calcul. Un singur nucleu modern servește în felul acesta câteva sute de spectatori, singura strangulare este conectivitatea.

Din clipa în care vrei să oferi mai multe niveluri de calitate, ca să poată privi și spectatorii cu conexiune slabă, lucrurile se schimbă. Fiecare nivel suplimentar trebuie calculat:

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

Socotește două până la patru nuclee pe nivel. Trei niveluri leagă astfel permanent între opt și douăsprezece nuclee. De aceea gândește-te bine dacă ai nevoie de ele: pentru un public care stă în majoritate la calculator sau în WLAN ajunge deseori un singur nivel, bine ales.

Securizare: cine are voie să transmită

Un server de streaming este vizibil din afară și va fi găsit. Trei măsuri ajung pentru uzul zilnic:

• Firewall pe portul de publicare. Doar propria adresă are voie pe 1935. Dacă adresa ta se schimbă, folosește în locul ei un acces VPN către server.
• Verifică cheia de stream. Cu on_publish, nginx apelează la fiecare încercare de publicare un script mic, care compară cheia cu o listă și refuză orice nepotrivire.
• Protecție de bază împotriva supraîncărcării. Un server de streaming este o țintă atractivă, pentru că o cădere se vede imediat. La KernelHost, o protecție antiflood cu 3,2 Tbps capacitate stă în fața fiecărui server, fără să fie nevoie să configurezi ceva. Mai multe pe pagina despre protecția DDoS.

Alegerea locației și mai multe servere

Serverul nu stă în apropierea ta, ci în apropierea spectatorilor tăi. Propria ta conexiune către server se stabilește o singură dată și apoi merge stabil, chiar și peste jumătate de continent. Conexiunea către spectatori decide în schimb timpul de încărcare și rata de abandon.

Dacă publicul tău stă în majoritate în Europa, o locație în Germania este cea potrivită. Dacă se întinde peste mai multe continente, merită un al doilea server și o distribuție prin DNS, astfel încât fiecare spectator să ajungă la cel mai apropiat. KernelHost oferă pentru asta locații în Germania, pe Coasta de Vest a SUA, pe Coasta de Est a SUA, precum și în Singapore și Coreea de Sud, iar o privire de ansamblu găsești la locațiile serverelor.

Dacă distribui fișiere în loc de imagini live, adică actualizări, imagini sau arhive video, unealta potrivită nu este un server de streaming, ci un cache în fața originii. Cum funcționează asta stă în articolul Construiește-ți propriul server CDN.

Ce server se potrivește

Pentru un server de streaming contează o altă ordine decât la un server web:

1. Conectivitate și trafic. Aici este strangularea, și anume mereu. O conectivitate gigabit reală, fără limitare, duce în jur de 160 de spectatori la 6 Mbit/s.
2. Trafic nelimitat. Tarifele bazate pe volum sunt greu de calculat la streaming, pentru că o singură seară reușită consumă volumul lunar.
3. Procesorul. Secundar, cât timp nu transcodezi. La transcodare devine a doua strangulare.
4. RAM și disc. Cel mai puțin critice. Spațiul pe disc devine o temă abia când păstrezi înregistrări.

Exact pe acest caz sunt croite serverele root cu trafic nelimitat de la noi: conectivitate reală de 2 × 1 Gbit/s pe server, volum nelimitat fără limitare de viteză, un preț lunar fix independent de cantitatea transferată și 3,2 Tbps protecție antiflood din fabrică. Serverul este livrat în mai puțin de 30 de secunde, cu acces root complet, IPv4 și o rețea IPv6 /64. Facturarea se face pe bază PrePaid și se poate anula lunar, deci poți începe cu un tarif mic și crește atunci când publicul tău crește.