Configurare un server di streaming: un solo upload per un numero qualsiasi di spettatori

Chi trasmette senza un server proprio invia il proprio video a ogni spettatore separatamente. Dieci spettatori significano dieci volte gli stessi dati, cento spettatori cento volte. L'upload di casa o dell'ufficio è così saturo già dopo pochi spettatori, e il video inizia a scattare anche se il computer non ha quasi nulla da fare.

Un server di streaming ribalta la situazione: tu invii al server esattamente un flusso, e il server serve con quello tutti gli spettatori. La tua linea trasporta quindi sempre un solo upload, sia che guardino dieci persone sia che ne guardino diecimila. Questo articolo mostra perché funziona così bene, come si configura un server di questo tipo, quanto ritardo costa ciascun protocollo e quanto traffico si accumula davvero.

Il problema: il collo di bottiglia è il tuo upload

Il video è un flusso continuo. Un flusso in 1080p con 60 immagini al secondo richiede, a seconda del contenuto, da 4,5 a 8 Mbit/s, il 720p sta tra 3 e 5 Mbit/s. Questo bitrate scorre per ogni spettatore, tutto il tempo, senza pause.

Una linea domestica media in Germania raggiunge in upload tra 10 e 50 Mbit/s, e anche molti collegamenti in fibra arrivano in upload a 50 o 100 Mbit/s. Il conto finisce quindi presto:

A questo si aggiunge un secondo problema, spesso trascurato: la tua linea è condivisa con tutto il resto della casa o dell'ufficio. Appena qualcuno carica un file grande o parte un backup, il flusso crolla. Un server in data center non ha questo problema, perché lì la connettività è a tua disposizione in esclusiva.

Il principio: un solo upload, tanti download

L'architettura è composta da tre parti:

• L'emittente, cioè OBS, ffmpeg o un encoder hardware, invia un flusso al server. Questa parte si chiama ingest.
• Il server riceve questo unico flusso, lo converte nel formato di distribuzione desiderato e lo tiene pronto.
• Gli spettatori prelevano il flusso dal server. Questa parte si chiama egress ed è quella che cresce con il numero di spettatori.

Decisiva è l'asimmetria: il percorso da te al server viene fatto una volta sola, il percorso dal server agli spettatori mille volte. Per questo la tua linea ha bisogno soltanto dell'upload di un singolo flusso, mentre il server ha bisogno di una connettività che stia al passo con il pubblico.

Quanto traffico si accumula davvero

La banda è solo metà del conto. Più interessante è il volume, perché è su quello che molti provider fatturano. La formula è semplice:

Volume in GB = bitrate in Mbit/s × secondi × spettatori ÷ 8000

Qualche esempio realistico:

I numeri dell'ultima colonna sono il motivo per cui streaming e fatturazione a volume vanno poco d'accordo. Una sola diretta ben seguita può consumare il volume incluso di un mese intero, e ogni terabyte successivo viene poi conteggiato a parte. Con una tariffa a traffico illimitato questo conto non esiste: il prezzo mensile è fisso, che passino 200 GB o 50 TB sulla linea.

Quale software fa per te

Per iniziare, nginx con il modulo RTMP è la scelta più ovvia: è disponibile ovunque, ben documentato, e lo stesso server lo puoi usare più tardi, senza modifiche, come webserver per la pagina degli spettatori.

Configurare un server di streaming con nginx e RTMP

Installazione

Su Debian e Ubuntu il pacchetto libnginx-mod-rtmp porta con sé il modulo, non devi compilare nulla:

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

Su AlmaLinux e Rocky Linux il modulo arriva dal repository EPEL:

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

Configurazione

La parte RTMP va messa nel file nginx.conf fuori dal blocco http, ed è l'errore più frequente di chi inizia. Una versione minima e funzionante è questa:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS per gli spettatori normali
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # pubblicazione consentita solo dal proprio indirizzo
            allow publish 203.0.113.10;
            deny publish all;

            # la visione resta libera per tutti
            allow play all;
        }
    }
}

I file HLS vengono poi consegnati dal normale webserver. Per questo basta un piccolo blocco nella parte 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 *;
    }
}

Crea la directory, verifica la configurazione, riavvia:

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

Aprire le porte

RTMP gira sulla porta 1935, la distribuzione passa dalla 80 e dalla 443. Con nftables o ufw:

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

Fai attenzione alla prima riga: la porta di pubblicazione è aperta solo per il tuo indirizzo. Una porta RTMP aperta a tutto il mondo viene trovata in pochi giorni, perché interi intervalli di indirizzi vengono scansionati automaticamente, e a quel punto trasmette qualcun altro sulla tua linea.

Trasmettere con OBS

In OBS, sotto Impostazioni, Streaming, imposta il servizio «Personalizzato»:

Sotto Uscita imposti il bitrate. Come riferimento: 1080p60 con 6000 kbit/s, 1080p30 con 4500 kbit/s, 720p30 con 3000 kbit/s. Imposta la distanza tra i keyframe a 2 secondi, altrimenti con HLS si creano segmenti irregolari e il player scatta al cambio di qualità.

Guardare lo stream

Lo stream si trova poi su https://stream.example.com/hls/kanal1.m3u8 e si apre con qualsiasi player compatibile con HLS, nel browser per esempio con hls.js o Video.js. Per una prova rapida basta VLC con «Apri flusso di rete».

Trasmettere a più piattaforme contemporaneamente

È il secondo grande vantaggio di un server proprio. Invece di far saltare la tua linea con tre upload in parallelo, trasmetti una volta al server, che poi distribuisce. Per farlo aggiungi nel blocco application una riga per ogni destinazione:

application live {
    live on;
    record off;

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

Il tuo upload resta comunque un solo flusso. La moltiplicazione la fa il server, e lì la banda è esattamente ciò per cui esiste.

Ritardo: quale protocollo per quale scopo

Il ritardo nasce quasi per intero nella distribuzione, non nell'invio. È importante capirlo, perché molti cercano nel posto sbagliato:

Più basso è il ritardo, più costa il singolo spettatore. HLS è il più economico, perché è composto da semplici file che qualsiasi webserver e qualsiasi cache possono consegnare. WebRTC invece tiene aperta una connessione per ogni spettatore e richiede quindi molta più potenza di calcolo. Scegli il ritardo basso solo dove ti serve davvero.

Transcoding: quando conviene

Finché il server si limita a inoltrare il flusso, la potenza di calcolo richiesta è minima. Un singolo core moderno serve così diverse centinaia di spettatori, e il collo di bottiglia è soltanto la connettività.

La cosa cambia appena vuoi offrire più livelli di qualità, perché possano guardare anche gli spettatori con una connessione debole. Ogni livello aggiuntivo va calcolato:

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

Conta da due a quattro core per livello. Tre livelli occupano quindi in modo permanente da otto a dodici core. Valuta perciò con attenzione se ti servono: per un pubblico che sta in prevalenza al computer o in WLAN, spesso basta un solo livello scelto bene.

Mettere in sicurezza: chi può trasmettere

Un server di streaming è visibile dall'esterno e viene trovato. Per l'uso quotidiano bastano tre misure:

• Firewall sulla porta di pubblicazione. Solo il tuo indirizzo può arrivare alla 1935. Se il tuo indirizzo cambia, usa invece un accesso VPN al server.
• Verifica della chiave di streaming. Con on_publish nginx richiama a ogni tentativo di pubblicazione un piccolo script, che confronta la chiave con un elenco e rifiuta se non corrisponde.
• Protezione di base contro il sovraccarico. Un server di streaming è un bersaglio interessante, perché un'interruzione si vede subito. Su ogni server KernelHost è attiva una protezione antiflood con 3,2 Tbps di capacità, senza che tu debba configurare nulla. Maggiori dettagli nella pagina sulla protezione DDoS.

Scelta della sede e più server

Il server non va vicino a te, ma vicino ai tuoi spettatori. La tua connessione verso il server viene stabilita una volta e poi resta stabile, anche attraverso mezzo continente. La connessione verso gli spettatori, invece, decide tempi di caricamento e percentuale di abbandono.

Se il tuo pubblico è in prevalenza in Europa, una sede in Germania è la scelta giusta. Se si distribuisce su più continenti, conviene un secondo server e una distribuzione tramite DNS, così ogni spettatore finisce su quello più vicino. KernelHost offre a questo scopo sedi in Germania, sulla costa ovest degli Stati Uniti, sulla costa est degli Stati Uniti e inoltre a Singapore e in Corea del Sud; una panoramica la trovi alla pagina Sedi dei server.

Se distribuisci file invece di immagini dal vivo, cioè aggiornamenti, immagini o archivi video, lo strumento giusto non è un server di streaming, ma una cache davanti all'origine. Come funziona lo spiega l'articolo Costruire un proprio server CDN.

Quale server serve

Per un server di streaming conta un ordine di priorità diverso rispetto a un webserver:

1. Connettività e traffico. È il collo di bottiglia, sempre. Una connettività gigabit reale senza limitazioni regge circa 160 spettatori a 6 Mbit/s.
2. Traffico illimitato. Le tariffe a volume sono difficilmente calcolabili per lo streaming, perché una sola serata di successo consuma il volume del mese.
3. CPU. Secondaria, finché non fai transcoding. Con il transcoding diventa il secondo collo di bottiglia.
4. RAM e disco. I meno critici. Lo spazio su disco diventa un tema solo quando conservi le registrazioni.

I nostri server root a traffico illimitato sono tagliati esattamente su questo caso: connettività reale di 2 × 1 Gbit/s per server, volume illimitato senza limitazioni, un prezzo mensile fisso indipendente dalla quantità trasferita e 3,2 Tbps di protezione antiflood di serie. Il server è pronto in meno di 30 secondi, con accesso root completo, IPv4 e una rete IPv6 /64. La fatturazione è PrePaid e disdicibile ogni mese, quindi puoi iniziare con una tariffa piccola e crescere quando cresce il tuo pubblico.