Stream sunucusu kurma: dilediğiniz kadar izleyici için tek yükleme

Kendi sunucusu olmadan yayın yapan kişi, görüntüsünü her izleyiciye ayrı ayrı gönderir. On izleyici, aynı verinin on kez gitmesi anlamına gelir; yüz izleyici yüz kez. Evdeki ya da ofisteki yükleme hattı böylece birkaç izleyiciden sonra tıkanır ve bilgisayar hiç zorlanmadığı hâlde görüntü takılmaya başlar.

Stream sunucusu bunu tersine çevirir: Sunucuya tam olarak bir stream gönderirsiniz ve sunucu bütün izleyicileri bununla besler. Böylece kendi hattınız her zaman yalnızca tek bir yükleme taşır; on kişi de izlese, on bin kişi de izlese hiç fark etmez. Bu yazı, bunun neden bu kadar iyi işlediğini, böyle bir sunucuyu nasıl kuracağınızı, hangi protokolün ne kadar gecikmeye yol açtığını ve bu sırada gerçekte ne kadar trafik birikeceğini gösteriyor.

Sorun: darboğaz sizin yükleme hattınız

Video kesintisiz bir akıştır. Saniyede 60 kare ile 1080p bir stream, içeriğe göre 4,5 ile 8 Mbit/s arası ister; 720p ise 3 ile 5 Mbit/s arasındadır. Bu bit hızı izleyici başına akar, hem de baştan sona, hiç ara vermeden.

Almanya'daki ortalama bir ev bağlantısı yüklemede 10 ile 50 Mbit/s arasını kaldırır; birçok fiber bağlantı bile yüklemede 50 ile 100 Mbit/s arasındadır. Hesap bu yüzden çabucak bitiyor:

Buna, sık sık gözden kaçan ikinci bir sorun eklenir: Bağlantınız bu hattı evdeki ya da ofisteki her şeyle paylaşır. Biri büyük bir dosya yüklemeye başladığı ya da bir yedekleme işi devreye girdiği anda yayın çöker. Veri merkezindeki bir sunucuda bu sorun yoktur, orada bağlantı yalnızca size ayrılmıştır.

İlke: bir kez yukarı, çok kez aşağı

Kurulum üç parçadan oluşur:

• Gönderici, yani OBS, ffmpeg ya da bir donanım kutusu, sunucuya bir stream gönderir. Buna ingest denir.
• Sunucu bu tek stream'i alır, istenen yayın biçimine çevirir ve hazır tutar.
• İzleyiciler stream'i sunucudan çeker. Buna egress denir ve izleyici sayısıyla büyüyen kısım budur.

Belirleyici olan asimetridir: Sizden sunucuya giden yol bir kez yürünür, sunucudan izleyicilere giden yol binlerce kez. Bu yüzden bağlantınıza yalnızca tek bir stream kadar yükleme gerekir, sunucuya ise izleyici kitlesine yetişebilen bir bağlantı.

Gerçekte ne kadar trafik birikiyor

Bant genişliği hesabın yalnızca yarısıdır. Daha ilginç olanı hacimdir, çünkü birçok sağlayıcı buna göre faturalandırır. Formül basit:

GB cinsinden hacim = Mbit/s cinsinden bit hızı × saniye × izleyici ÷ 8000

Birkaç gerçekçi örnek:

Son sütundaki sayılar, yayıncılık ile hacme dayalı faturalandırmanın neden birbirine hiç uymadığını gösteriyor. İyi izlenen tek bir yayın, koca bir ayın dahil hacmini bitirebilir ve bundan sonraki her terabayt ayrı ayrı hesaplanır. Sınırsız trafikli bir tarifede bu hesap tamamen ortadan kalkar: Hattan 200 GB da geçse 50 TB da geçse aylık fiyat sabittir.

Hangi yazılım size uygun

Başlangıç için en akla yatkın seçim, RTMP modüllü nginx: Her yerde bulunur, iyi belgelenmiştir ve aynı sunucuyu sonradan hiç değişiklik yapmadan izleyici sayfası için web sunucusu olarak da kullanabilirsiniz.

nginx ve RTMP ile stream sunucusu kurma

Kurulum

Debian ve Ubuntu'da modül libnginx-mod-rtmp paketiyle birlikte gelir, kendiniz derlemeniz gerekmez:

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

AlmaLinux ve Rocky Linux'ta modül EPEL deposundan gelir:

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

Yapılandırma

RTMP bölümü nginx.conf dosyasında dışarıda durur, http bloğunun içinde değil; bu, en sık yapılan başlangıç hatasıdır. Yalın ve çalışan bir sürüm şöyle görünür:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # normal izleyiciler için HLS
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # yayın yalnızca kendi adresinizden yapılabilir
            allow publish 203.0.113.10;
            deny publish all;

            # izlemek herkese açık
            allow play all;
        }
    }
}

HLS dosyalarını daha sonra normal web sunucusu sunar. Bunun için http bölümünde küçük bir blok yeterlidir:

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

Dizini oluşturun, yapılandırmayı sınayın, yeniden başlatın:

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

Portları açma

RTMP 1935 numaralı portta çalışır, yayınlama ise 80 ve 443 üzerinden. nftables ya da ufw ile:

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

İlk satıra dikkat edin: Gönderme portu yalnızca kendi adresinize açıktır. Dünyaya açık bir RTMP portu birkaç gün içinde bulunur, çünkü adres blokları otomatik olarak baştan sona taranır; ardından sizin hattınız üzerinden bir başkası yayın yapar.

OBS ile yayın yapma

OBS'te Ayarlar, Yayın bölümünde hizmet olarak “Özel” seçeneğini girin:

Çıkış bölümünde bit hızını ayarlarsınız. Yol gösterici değerler: 1080p60 için 6000 kbit/s, 1080p30 için 4500 kbit/s, 720p30 için 3000 kbit/s. Anahtar kare aralığını 2 saniyeye alın, aksi hâlde HLS'te düzensiz segmentler oluşur ve oynatıcı geçişlerde takılır.

İzleme

Stream bundan sonra https://stream.example.com/hls/kanal1.m3u8 adresinde durur ve HLS destekleyen her oynatıcıyla açılır; tarayıcıda örneğin hls.js ya da Video.js ile. Hızlı bir denetim için VLC'de “Ağ Akışı Aç” yeterlidir.

Aynı anda birden fazla platforma yayın yapma

Bu, kendinize ait bir sunucunun ikinci büyük avantajıdır. Üç paralel yüklemeyle hattınızı patlatmak yerine sunucuya bir kez gönderirsiniz, dağıtmayı o sürdürür. Bunun için application bloğuna hedef başına bir satır eklersiniz:

application live {
    live on;
    record off;

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

Yüklemeniz bu arada tek bir stream'de kalır. Çoğaltmayı sunucu devralır ve bant genişliği de tam olarak onun var olma sebebidir.

Gecikme: hangi protokol ne için

Gecikme neredeyse tamamen yayınlama tarafında oluşur, gönderme tarafında değil. Bunu anlamak önemli, çünkü pek çok kişi yanlış yerde arıyor:

Gecikme ne kadar düşükse tek bir izleyici o kadar pahalıya gelir. HLS en ucuzudur, çünkü her web sunucusunun ve her önbelleğin sunabileceği basit dosyalardan oluşur. WebRTC ise her izleyici için ayrı bir bağlantıyı açık tutar ve böylece belirgin biçimde daha fazla işlem gücü harcar. Düşük gecikmeyi yalnızca gerçekten ihtiyaç duyduğunuz yerde seçin.

Transcoding: ne zaman değer

Sunucu stream'i yalnızca aktardığı sürece neredeyse hiç işlem gücüne ihtiyaç duymaz. Tek bir modern çekirdek bu şekilde birkaç yüz izleyiciye hizmet eder, darboğaz yalnızca bağlantıdır.

Zayıf bağlantılı izleyicilerin de izleyebilmesi için birden fazla kalite kademesi sunmak istediğiniz anda bu değişir. Her ek kademenin hesaplanması gerekir:

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

Kademe başına iki ile dört çekirdek hesaplayın. Üç kademe böylece sekiz ile on iki çekirdeği sürekli bağlar. Bu yüzden bunlara ihtiyacınız olup olmadığını iyice düşünün: Ağırlıklı olarak bilgisayar başında ya da kablosuz ağda oturan bir izleyici kitlesi için çoğu zaman iyi seçilmiş tek bir kademe yeterlidir.

Güvenlik: kim yayın yapabilir

Stream sunucusu dışarıdan görünür ve mutlaka bulunur. Günlük kullanım için üç önlem yeterlidir:

• Gönderme portunda güvenlik duvarı. 1935 portuna yalnızca kendi adresiniz girebilir. Adresiniz değişiyorsa onun yerine sunucuya bir VPN erişimi kullanın.
• Yayın anahtarını denetleyin. nginx, on_publish ile her yayın denemesinde küçük bir betik çağırır; bu betik anahtarı bir listeye karşı denetler ve uyuşmazlık hâlinde reddeder.
• Aşırı yüke karşı temel koruma. Stream sunucusu kazançlı bir hedeftir, çünkü bir kesinti anında göze çarpar. KernelHost'ta her sunucuda 3,2 Tbps kapasiteli bir flood koruması bulunur, siz hiçbir şey ayarlamak zorunda kalmadan. Ayrıntılar DDoS koruması sayfasında.

Lokasyon seçimi ve birden fazla sunucu

Sunucunun yeri size yakın bir nokta değil, izleyicilerinize yakın bir noktadır. Sizin sunucuya olan bağlantınız bir kez kurulur ve sonra, yarım kıta öteden bile olsa, kararlı biçimde çalışır. İzleyicilere giden bağlantı ise yüklenme süresine ve terk oranına karar verir.

İzleyici kitleniz ağırlıklı olarak Avrupa'daysa Almanya'daki bir lokasyon doğru seçimdir. Kitle birden fazla kıtaya dağılıyorsa ikinci bir sunucu ve DNS üzerinden dağıtım işe yarar; böylece her izleyici kendisine en yakın olanda sonlanır. KernelHost bunun için Almanya'da, ABD Batı Yakası'nda, ABD Doğu Yakası'nda, ayrıca Singapur ve Güney Kore'de lokasyonlar sunuyor; genel bir bakışı sunucu lokasyonları altında bulabilirsiniz.

Canlı görüntü yerine dosya dağıtıyorsanız, yani güncellemeler, görseller ya da video arşivleri, doğru araç stream sunucusu değil, önüne konan bir önbellektir. Bunun nasıl işlediği Kendi CDN sunucunuzu kurma yazısında anlatılıyor.

Hangi sunucu uygun

Stream sunucusunda, web sunucusundakinden farklı bir sıralama geçerlidir:

1. Bağlantı ve trafik. Darboğaz burasıdır, hem de her zaman. Kısıtlama uygulanmayan gerçek bir gigabit bağlantı, 6 Mbit/s ile yaklaşık 160 izleyici taşır.
2. Sınırsız trafik. Hacme dayalı tarifelerin yayıncılıkta hesabı neredeyse hiç tutmaz, çünkü başarılı tek bir akşam ayın hacmini bitirir.
3. CPU. Transcoding yapmadığınız sürece ikinci planda. Transcoding'de ikinci darboğaz hâline gelir.
4. RAM ve disk. En az kritik olanlar. Ancak kayıtları saklamaya başladığınızda disk alanı konu olur.

Tam olarak bu duruma göre tasarlanmış olan Sınırsız Trafik root sunucularımız: sunucu başına gerçek 2 × 1 Gbit/s bağlantı, kısıtlama olmadan sınırsız hacim, aktarılan miktardan bağımsız sabit bir aylık fiyat ve kutudan çıktığı gibi 3,2 Tbps flood koruması. Sunucu 30 saniyenin altında hazır oluyor; tam root erişimi, IPv4 ve bir /64 IPv6 ağıyla. Faturalandırma PrePaid esasına göre yapılır ve aylık olarak iptal edilebilir, yani küçük bir tarifeyle başlayıp izleyici kitleniz büyüdükçe büyüyebilirsiniz.