إعداد Stream Server: بثّ صاعد واحد لأي عدد من المشاهدين

من يبثّ من دون خادم خاص، يرسل صورته إلى كل مشاهد على حدة. فعشرة مشاهدين يعنون عشر مرات من البيانات نفسها، ومئة مشاهد يعنون مئة مرة. وبذلك يمتلئ الرفع في المنزل أو في المكتب بعد عدد قليل من المشاهدين، فتبدأ الصورة بالتقطّع رغم أن الجهاز لا يفعل شيئاً تقريباً.

أما Stream Server فيعكس ذلك: ترسلون بثّاً واحداً بالضبط إلى الخادم، والخادم يغذّي منه كل المشاهدين. وبذلك لا يحمل خطّكم أبداً أكثر من بثّ صاعد واحد، سواء كان المتابعون عشرة أو عشرة آلاف. يبيّن هذا المقال لماذا تعمل هذه الطريقة بهذه الجودة، وكيف تُعِدّون خادماً كهذا، وأي بروتوكول يكلّفكم أي تأخير، وكم يبلغ حجم الترافيك فعلياً.

المشكلة: الرفع عندكم هو عنق الزجاجة

الفيديو تدفّق مستمر. فالبثّ بدقة 1080p وبمعدل 60 صورة في الثانية يحتاج، تبعاً للمحتوى، من 4.5 إلى ⁦8 Mbit/s⁩، أما 720p فيتراوح بين 3 و⁦5 Mbit/s⁩. ويسيل معدل البتات هذا لكل مشاهد، طوال الوقت، بلا توقف.

ويبلغ خط المنزل المتوسط في ألمانيا في الرفع ما بين 10 و⁦50 Mbit/s⁩، وحتى كثير من خطوط الألياف الضوئية تتراوح في الرفع بين 50 و⁦100 Mbit/s⁩. ولهذا ينتهي الحساب سريعاً:

وتُضاف إلى ذلك مشكلة ثانية كثيراً ما تُغفَل: خطّكم يتقاسم هذه الوصلة مع كل شيء آخر في المنزل أو في المكتب. فبمجرد أن يرفع أحدهم ملفاً كبيراً أو ينطلق نسخ احتياطي، ينهار البثّ. أما الخادم في مركز البيانات فلا يعاني هذه المشكلة، إذ تكون الوصلة هناك في خدمتكم وحدكم.

المبدأ: رفعٌ واحد، تنزيلٌ متكرّر

تتكوّن البنية من ثلاثة أجزاء:

• المُرسِل، أي OBS أو ffmpeg أو صندوق عتاد، يرسل بثّاً إلى الخادم. وهذا ما يسمّى Ingest.
• الخادم يستقبل هذا البثّ الواحد، ويحوّله إلى صيغة العرض المطلوبة، ويحتفظ به جاهزاً.
• المشاهدون يجلبون البثّ من الخادم. وهذا ما يسمّى Egress، وهو الجزء الذي ينمو مع عدد المشاهدين.

والحاسم هنا هو عدم التناظر: فالطريق منكم إلى الخادم يُسلَك مرة واحدة، والطريق من الخادم إلى المشاهدين يُسلَك ألف مرة. ولذلك لا يحتاج خطّكم من الرفع إلا بمقدار بثّ واحد، في حين يحتاج الخادم وصلة تواكب حجم الجمهور.

كم يبلغ حجم الترافيك فعلياً

النطاق الترددي نصف الحساب فقط. والأهمّ منه هو الحجم، لأن كثيراً من المزوّدين يحاسبون عليه. والصيغة بسيطة:

الحجم بالـ GB = معدل البتات بالـ Mbit/s × الثواني × المشاهدون ÷ 8000

وبعض الأمثلة الواقعية:

الأرقام في العمود الأخير هي السبب في أن البثّ والمحاسبة على الحجم لا يتوافقان. فنقل واحد حسن الحضور قد يستهلك الحجم المتضمَّن لشهر كامل، ثم يُحاسَب كل تيرابايت إضافي على حدة. أما في خطة بـ حركة مرور غير محدودة فيسقط هذا الحساب تماماً: السعر الشهري ثابت، سواء مرّ عبر الخط ⁦200 GB⁩ أو ⁦50 TB⁩.

أي برمجية تناسبكم

وفي البداية يكون nginx مع وحدة RTMP الخيار الأقرب: فهو متاح في كل مكان، وموثّق جيداً، ويمكنكم لاحقاً استخدام الخادم نفسه بلا تعديل كخادم ويب لصفحة المشاهدين.

إعداد Stream Server باستخدام nginx وRTMP

التثبيت

على Debian وUbuntu تأتي الوحدة مع الحزمة libnginx-mod-rtmp، فلا تحتاجون إلى ترجمة أي شيء بأنفسكم:

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

وعلى AlmaLinux وRocky Linux تأتي الوحدة من مستودع EPEL:

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

الضبط

يوضَع جزء RTMP في nginx.conf خارج كتلة http، وهذا أكثر خطأ يقع فيه المبتدئون. وفيما يلي صيغة خفيفة وعاملة:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;

            # HLS للمشاهدين العاديين
            hls on;
            hls_path /var/www/stream/hls;
            hls_fragment 2s;
            hls_playlist_length 12s;

            # الإرسال مسموح من العنوان الخاص وحده
            allow publish 203.0.113.10;
            deny publish all;

            # المشاهدة مسموحة للجميع
            allow play all;
        }
    }
}

وبعد ذلك يسلّم خادم الويب العادي ملفات HLS. ويكفي لذلك كتلة صغيرة في جزء 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 *;
    }
}

إنشاء المجلد، وفحص الضبط، وإعادة التشغيل:

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

فتح المنافذ

يعمل RTMP على المنفذ 1935، ويجري التسليم عبر 80 و443. وباستخدام nftables أو ufw:

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

انتبهوا إلى السطر الأول: منفذ الإرسال مفتوح فقط لعنوانكم الخاص. فمنفذ RTMP المفتوح للعالم كله يُكتشَف في غضون أيام قليلة، لأن نطاقات عناوين كاملة تُفحَص آلياً، وبعدها يرسل شخص آخر عبر خطّكم.

الإرسال باستخدام OBS

في OBS ضمن الإعدادات، ثم البثّ، أدخِلوا الخدمة «مخصّص»:

وتحت «الإخراج» تضبطون معدل البتات. وكقيمة استرشادية: 1080p60 بمعدل ⁦6000 kbit/s⁩، و1080p30 بمعدل ⁦4500 kbit/s⁩، و720p30 بمعدل ⁦3000 kbit/s⁩. واضبطوا مسافة الإطار المفتاحي على ثانيتين، وإلا نشأت في HLS مقاطع غير منتظمة وتقطّع المشغّل عند التبديل.

المشاهدة

يصبح البثّ بعد ذلك متاحاً على https://stream.example.com/hls/kanal1.m3u8 ويمكن فتحه بأي مشغّل يدعم HLS، وفي المتصفح مثلاً عبر hls.js أو Video.js. وللفحص السريع يكفي VLC عبر «فتح دفق شبكة».

الإرسال إلى عدة منصّات في الوقت نفسه

هذه هي الميزة الكبيرة الثانية لخادم خاص. فبدل تفجير خطّكم بثلاث عمليات رفع متوازية، ترسلون مرة واحدة إلى الخادم، وهو يوزّع. ولذلك تضيفون في كتلة application سطراً لكل هدف:

application live {
    live on;
    record off;

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

ويبقى رفعكم عند بثّ واحد. والمضاعفة يتولاها الخادم، وهناك يكون النطاق الترددي هو بالضبط ما وُجد من أجله.

التأخير: أي بروتوكول لأي غرض

ينشأ التأخير كله تقريباً عند العرض، لا عند الإرسال. ومن المهم فهم ذلك، لأن كثيرين يبحثون في المكان الخطأ:

وكلما انخفض التأخير، ارتفعت كلفة المشاهد الواحد. فـ HLS هو الأرخص، لأنه يتكوّن من ملفات بسيطة يستطيع أي خادم ويب وأي ذاكرة مؤقتة تسليمها. أما WebRTC فيبقي لكل مشاهد اتصالاً خاصاً مفتوحاً، ويكلّف بذلك قدرة حسابية أكبر بكثير. فلا تأخذوا بالتأخير المنخفض إلا حيث تحتاجونه فعلاً.

Transcoding: متى يستحق الأمر

ما دام الخادم يمرّر البثّ فقط، فهو لا يحتاج قدرة حسابية تقريباً. فنواة حديثة واحدة تخدم بهذه الطريقة عدة مئات من المشاهدين، والعنق الزجاجي هو الوصلة وحدها.

لكن الأمر يتغيّر بمجرد أن تريدوا تقديم عدة مستويات جودة، لكي يستطيع المشاهدون ذوو الاتصال الضعيف المتابعة أيضاً. فكل مستوى إضافي يجب حسابه:

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

احسبوا نواتين إلى أربع نوى لكل مستوى. فثلاثة مستويات تشغل بذلك ثماني إلى اثنتي عشرة نواة بشكل دائم. ولذلك فكّروا جيداً فيما إذا كنتم تحتاجونها: فلجمهور يجلس في معظمه أمام الحاسب أو على شبكة لاسلكية، يكفي غالباً مستوى واحد مختار بعناية.

التأمين: من يحقّ له الإرسال

Stream Server مرئي من الخارج وسيُكتشَف. وثلاثة إجراءات تكفي للاستخدام اليومي:

• جدار حماية على منفذ الإرسال. عنوانكم وحده يحقّ له الوصول إلى 1935. وإذا تغيّر عنوانكم، فاستخدموا بدلاً من ذلك وصولاً عبر VPN إلى الخادم.
• فحص مفتاح البثّ. عبر on_publish ينادي nginx عند كل محاولة إرسال سكربتاً صغيراً يفحص المفتاح مقابل قائمة ويرفض عند عدم التطابق.
• حماية أساسية من الإغراق. Stream Server هدف مُغرٍ، لأن انقطاعه يظهر فوراً. وفي KernelHost توجد حماية من الإغراق بسعة ⁦3.2 Tbps⁩ على كل خادم، من دون أن تُعِدّوا أي شيء. والمزيد عن ذلك في صفحة حماية DDoS.

اختيار الموقع وعدة خوادم

الخادم لا ينتمي إلى جواركم، بل إلى جوار مشاهديكم. فاتصالكم بالخادم يُنشَأ مرة واحدة ثم يعمل بثبات، حتى عبر نصف قارة. أما الاتصال بالمشاهدين فهو الذي يحدّد زمن التحميل ونسبة الانصراف.

فإذا كان جمهوركم في أوروبا في معظمه، فموقع في ألمانيا هو الصحيح. وإذا توزّع على عدة قارات، فيستحق الأمر خادماً ثانياً وتوزيعاً عبر DNS، حتى يصل كل مشاهد إلى الأقرب إليه. وتوفّر KernelHost لهذا الغرض مواقع في ألمانيا، وعلى الساحل الغربي للولايات المتحدة، وعلى الساحل الشرقي للولايات المتحدة، وكذلك في سنغافورة وكوريا الجنوبية، وتجدون نظرة عامة في مواقع الخوادم.

وإذا كنتم توزّعون ملفات بدلاً من صور حيّة، أي تحديثات أو صوراً أو أرشيفات فيديو، فالأداة الصحيحة ليست Stream Server بل ذاكرة مؤقتة أمامه. وكيف يعمل ذلك مشروح في مقال بناء CDN Server خاص بكم.

أي خادم يناسب

في Stream Server يختلف ترتيب الأهمية عمّا هو في خادم ويب:

1. الوصلة والترافيك. هنا يكون العنق الزجاجي، دائماً. فوصلة جيجابت حقيقية بلا خفض للسرعة تحمل نحو 160 مشاهداً بمعدل ⁦6 Mbit/s⁩.
2. حركة مرور غير محدودة. الخطط المحاسَبة على الحجم لا تكاد تُحسَب في البثّ، لأن أمسية ناجحة واحدة تستهلك الحجم الشهري.
3. المعالج. في الدرجة الثانية، ما لم تقوموا بـ Transcoding. وعند Transcoding يصبح العنق الزجاجي الثاني.
4. الذاكرة والقرص. الأقل أهمية. ولا تصبح مساحة القرص موضوعاً إلا إذا احتفظتم بالتسجيلات.

وعلى هذه الحالة بالضبط صُمّمت الخوادم الجذرية بحركة مرور غير محدودة عندنا: وصلة حقيقية بسعة ⁦2 × 1 Gbit/s⁩ لكل خادم، وحجم غير محدود بلا خفض للسرعة، وسعر شهري ثابت مستقل عن الكمية المنقولة، وحماية من الإغراق بسعة ⁦3.2 Tbps⁩ من المصنع. ويُجهَّز الخادم في أقل من 30 ثانية، مع وصول Root كامل، وIPv4، وشبكة IPv6 بحجم ⁦/64⁩. وتجري المحاسبة على أساس الدفع المسبق مع إمكان الإلغاء شهرياً، فيمكنكم البدء بخطة صغيرة والنمو مع نمو جمهوركم.