1. من يحتاج WebRTC من جانب الخادم؟
كما نعلم جميعًا ، WebRTC هي تقنية نظير إلى نظير تقوم بتنفيذ قناة اتصال بين مستعرضين لنقل الصوت والفيديو وأي بيانات أخرى بزمن انتقال منخفض. هذه التقنية مجانية تمامًا ، وإذا احتاج تطبيقك إلى إنشاء اتصال في المتصفحات لمشاركين عن بُعد ، فيمكنك إضافة كود جافا سكريبت المناسب إلى صفحات الويب ويتم حل المشكلة. ستتواصل المتصفحات مباشرة ، ولا يلزم وجود خادم.
يدخل WebRTC من جانب الخادم المشهد عندما يكون من الضروري وجود أكثر من مشاركين ، ويتم نقل البيانات من أحد المشاركين إلى عدة مشاركين آخرين في وقت واحد.
في هذه الحالة ، يمكن أن يكون الخادم هو أحد المشاركين ، والذي سيؤسس اتصالًا فرديًا مع المشارك الأول ، ويستقبل البيانات منه ، ثم ينشئ اتصالًا ، وأيضًا في وضع
واحد لواحد مع المشاركين الآخرين ويرسل لهم هذه البيانات. أولئك. يحتفظ الخادم بالعديد من قنوات الاتصال من نظير إلى نظير ويقوم ببساطة بنسخ البيانات إلى جميع هذه القنوات. في مصطلحات WebRTC ، يعمل هذا الخادم كوحدة إعادة توجيه انتقائية (SFU).
ومع ذلك ، فإن التواصل الجماعي ليس ممكنًا فقط مع SFU. قد تسأل لماذا لا يستطيع الجميع إرسال البيانات إلى الجميع ، بدون أي خادم ، وستكون على حق تمامًا. وهذا ما يسمى شبكة الاتصالات.
هناك نقطتان رئيسيتان هنا:
- في مخطط MESH ، يرسل كل مشارك ويستقبل تدفقات بيانات N-1 ، حيث N هو حجم المجموعة. أولئك. تزداد متطلبات سرعة التحميل لكل مشارك في مخطط MESH مع نمو المجموعة. بينما في مخطط SFU ، يرسل كل مشارك دائمًا دفقًا واحدًا فقط. لا يمتلك كل مشارك سرعة اتصال بالشبكة يمكنها التعامل مع إرسال تدفقات N-1.
- , MESH - . , , - . MESH , , VP8/VP9/H264 4 . WebRTC – , . , (PeerConnection). , 720p 30% , . .
بسبب هاتين النقطتين الرئيسيتين ، يصبح تنفيذ مخطط MESH ضعيفًا مع زيادة عدد المشاركين ويجب استخدام مخطط SFU.
لذلك ، مع وجود عدد كبير من المشاركين في الاتصال ، يلزم وجود خادم (SFU).
دعنا نعطي أمثلة على مثل هذه التطبيقات التي تتطلب خادمًا:
- مؤتمرات الفيديو مع العديد من المشاركين (يستخدم Zoom المحبوب للجميع خادم WebRTC ، مثل جميع الخدمات المماثلة).
- المراقبة الحية بالفيديو ، عندما يتم إرسال الفيديو من كاميرا واحدة إلى عدة مشاهدين وأجهزة تسجيل. أنظمة الأمن والمراقبة.
- الأنظمة التفاعلية مثل المزادات عبر الإنترنت والبرامج التعليمية وتطبيقات الويب الأخرى التي تتطلب زمن انتقال صوتي / فيديو منخفض.
2. إذا كنت لا تزال بحاجة إلى WebRTC من جانب الخادم ، فما الذي يمكنك استخدامه في عام 2020؟
خدمة السحابة أو لوحدك؟
هنا ، في البداية ، الحجج المعتادة لتكنولوجيا المعلومات لصالح أحدهما أو الآخر: ستوفر السحابة تكاليف تكنولوجيا المعلومات وتوفرها للخوادم والتكوين وقابلية التوسع. ولكن لوحدك ، إذا نجح كل شيء (لا يوجد ضمان) ، فسيكون أرخص بكثير. بعد كل شيء ، تحتاج إلى الدفع شهريًا مقابل الخدمة السحابية.
الآن للاطلاع على الحجج الخاصة بالتطبيقات الموضحة أعلاه. إذا كان لديك جمهور عالمي ضخم ، في بلدان ومناطق مختلفة ، فسيكون من الصعب عليك بمفردك تجميع كل شيء معًا. على سبيل المثال ، تعد الخدمة السحابية مناسبة لمزاد Sotheby. ولكن إذا كان لديك 2-3 فروع للشركة في مدن مختلفة ، 200-500 مستخدم ، وتحتاج إلى تنظيم ندوة عبر الإنترنت / مؤتمر / تدريب ، وما إلى ذلك بالنسبة لهم ، فيمكنك استئجار عدة خوادم بنفسك على AWS أو منصات استضافة مماثلة ، قم بالتثبيت هناك برنامج خادم WebRTC ، وسيعمل كل شيء. يمكن أن تكون الخوادم في شركتك ، إذا كانت سرعة الاتصال بالإنترنت تسمح بذلك. حسنًا ، بالنسبة لجميع الحلول على نطاق أصغر ، يمكن عمل كل شيء بنفسك.
في الوقت الحالي ، هناك خدمتان من خدمات WebRTC السحابية معروفة ومُختبرة: Millicast و Phenix... كلاهما له تغطية عالمية ، واتصال جيد بين الخوادم في قارات مختلفة (هل تحتاجه؟) وبالفعل زمن انتقال الفيديو (زمن الوصول) في نصف ثانية أو أقل.
الآن دعنا نتحدث عن "بمفردنا".
ستحتاج إلى برنامج خادم WebRTC هنا. هناك 3 طرق للحصول على مثل هذا الخادم.
- اجعلها بنفسك باستخدام واجهة برمجة تطبيقات مفتوحة. وأشهرها هو Google c ++ WebRTC API . يمكنك أيضًا استخدام واجهة برمجة تطبيقات GStreamer . تطبيق مثير للاهتمام في Go: Pion WebRTC . سوف تحتاج إلى مبرمجي ++ C المهرة والكثير من الصبر والوقت لتصحيح الأخطاء. لقد كتبت بالتفصيل عن صعوبات هذا النهج في مقالتي السابقة .
- . Ant Media Server, Kurento, Janus, Jitsi. , , , . github , . , , , . , c++ . . , .
- . , , . Red5 Pro, Flashphoner Unreal Media Server.
WebRTC .
هذا هو الموضوع الأكثر إشكالية. افترض أن شركتك تصدر منتجًا برمجيًا تحتاج فيه إلى تنفيذ خادم WebRTC. فليكن نظام تسجيل ومراقبة بالفيديو لمحطات المطارات ومحطات القطار ومراكز النقل. أو المعدات الطبية مع البرامج المصاحبة الموجودة لبث وتسجيل الفيديو من المناظير الداخلية ، والتي يجب توسيعها قبل بث هذا الفيديو إلى متصفح. أو نظام محاكاة طيران ، حيث يكون من الضروري تنفيذ إمكانية التصور في متصفح و / أو التفاعل مع مستخدم بعيد. نحن نواجه باستمرار متطلبات مماثلة. نظامك الحالي له العديد من القيود. قد لا يكون الوصول إلى الإنترنت متاحًا. لا غيوم. لا يمكنك فتح المنافذ على الخادم. Windows فقط أو Linux فقط. في بعض الأحيان ، حتى إصدار معين فقط من Windows ، لأنه يتم شحذ المنتج الحالي له. خادم WebRTC ،ما يضاف إلى مثل هذا النظام يجب تعديله لكل هذه القيود.
هنا ، قد لا يكون لديك خيار سوى استخدام خادم مفتوح المصدر مثل Ant Media Server أو Janus وتغييره. هذا هو الوضع على لينكس. بالنسبة لنظام التشغيل Windows ، يعد Unreal Media Server مناسبًا - وهذا برنامج مكتوب ومحسّن فقط لنظام التشغيل Windows.
خادم WebRTC كثيف الاستخدام للموارد
ضع ذلك في الاعتبار عند تخطيط مواردك. لقد وصفتُ أسباب كثافة الموارد هذه في مقال سابق ، لكن الاستنتاج هو أن قابلية التوسع تتحقق من خلال معالج قوي جدًا أو عن طريق إضافة خوادم فعلية.
فيما يلي رسم تخطيطي للاختبارات التي تم إجراؤها باستخدام Unreal Media Server v13.0 على مثيل AWS EC2 m4.2xlarge: Intel Xeon 8 cores CPU E5-2686 v4 @ 2.30 GHz ، 32 Gb RAM ، Windows Server 2016.
كما ترى من الرسم التخطيطي ، مع 1000 مشغل ويب متزامن بالنسبة لكاميرا IP هذه ، يكون حمل المعالج 5٪ مع بروتوكول RTMP ، و 75٪ مع بروتوكول WebRTC ، أي يعد WebRTC أكثر كثافة للموارد بأكثر من 10 مرات من RTMP.