
بعد تحليل قدرة التكوينات القياسية للخوادم في المحيط الرقمي مسبقًا من حيث تدفق WebRTC ، لاحظنا أن خادمًا واحدًا يمكنه تغطية ما يصل إلى 2000 مشاهد. في الحياة الواقعية ، الحالات التي يكون فيها خادم واحد غير كافٍ ليست شائعة.
افترض أن هواة المقامرة في ألمانيا يشاهدون سباقات الخيول في الوقت الفعلي في أستراليا. نظرًا لأن سباقات الخيل ليست لعبة رياضية فحسب ، بل تنطوي أيضًا على مكاسب كبيرة بشرط إجراء رهانات ميدانية في الوقت المناسب ، يجب تسليم الفيديو بأقل زمن انتقال ممكن.
مثال آخر: تقوم شركة عالمية ، أحد رواد FCMG في السوق ولديها فروع في أوروبا وروسيا وجنوب شرق آسيا ، بتنظيم ندوات تدريبية لمديري المبيعات مع البث المباشر من المقر الرئيسي في البحر المتوسط. يجب أن يكون المشاهدون قادرين على رؤية مقدم العرض وسماعه في الوقت الفعلي.
تقدم هذه الأمثلة نفس المتطلبات: تقديم تدفقات وسائط منخفضة الكمون لعدد كبير من المشاهدين. سيتطلب ذلك نشر شبكة تسليم محتوى - CDN.
تجدر الإشارة إلى أن تقنية توصيل التيار التقليدية باستخدام HLS ليست مناسبة تمامًا حيث يمكنها إضافة ما يصل إلى 30 ثانية من التأخيرات ، والتي تعد مهمة للغاية بالنسبة للعرض في الوقت الفعلي. تخيل أن الخيول قد انتهت بالفعل ، وقد تم نشر النتائج على الموقع ، في حين أن الجماهير لا تزال تشاهد نهاية السباق. تقنية WebRTC خالية من هذا العيب ويمكن أن تضمن أقل من ثانية واحدة من التأخير ، وهو أمر ممكن حتى عبر القارات بفضل قنوات الاتصال الحديثة.
بادئ ذي بدء ، سوف نرى كيفية نشر أبسط CDN لتقديم تدفقات WebRTC وكيفية توسيع نطاقه بعد ذلك.
مبادئ التنمية المستدامة
يمكن أن يلعب خادم في CDN أحد الأدوار التالية:
- الأصل هو الخادم المصمم لنشر تدفقات الوسائط. يشارك التدفقات إلى خوادم أخرى وكذلك المستخدمين.
- Transcoder هو الخادم المخصص لتدفقات الترميز. يسحب التدفقات من خادم Origin ويمرر التدفقات المحولة إلى Edge. سوف ننظر في هذا الدور في الجزء التالي.
- Edge هو الخادم المصمم لمشاركة التدفقات مع المستخدمين. يسحب التدفقات من خوادم Origin أو Transcoder ولا يمررها إلى خوادم CDN الأخرى.
يسمح خادم Origin بنشر تدفقات WebRTC و RTMP أو التقاط التدفقات من مصادر أخرى عبر RTMP أو RTSP أو الطرق الأخرى المتاحة.
يمكن للمستخدمين تشغيل التدفقات من خوادم Edge عبر WebRTC و RTMP و RTSP و HLS.
من أجل تقليل زمن الوصول إلى الحد الأدنى ، من المستحسن نقل التدفقات بين خوادم CDN باستخدام WebRTC.
يتم وصف CDN الثابت تمامًا في مرحلة التكوين. في الواقع ، يشبه إعداد CDN ثابت إعداد موازن التحميل: يتم سرد كافة أجهزة الاستقبال في إعدادات خادم مصدر الدفق.
على سبيل المثال ، لدينا خادم أصل واحد في فرانكفورت وواحد في نيويورك وواحد في سنغافورة

في هذه الحالة ، سيتم إعداد Origin أكثر أو أقل مثل هذا:
<loadbalancer mode="roundrobin" stream_distribution="webrtc"> <node id="1"> <ip>edge1.thestaticcdn.com</ip> <wss>443</wss> </node> <node id="2"> <ip>edge2.thestaticcdn.com</ip> <wss>443</wss> </node> </loadbalancer>
فيما يلي المشكلة الأولى في CDN الثابتة: لكي يتم تضمين هذا النوع من CDN خادم Edge جديد أو استثناء خادم من CDN ، يجب تعديل الإعدادات وإعادة تشغيل جميع خوادم Origin.
يتم بث التدفقات المنشورة على Origin إلى جميع خوادم Edge المدرجة في الإعدادات. يتم أيضًا اتخاذ القرار بشأن خادم Edge الذي سيقوم المستخدم بالاتصال به على خادم Origin. إليكم المشكلة الثانية: إذا كان هناك عدد قليل من المشاهدين أو لا يوجد - على سبيل المثال ، في سنغافورة في وقت مبكر من المساء بينما في نيويورك في منتصف الليل - سيتم بث البث إلى Edge 1 على أي حال. يتم هدر حركة المرور دون أي غرض ، وأنها ليست مجانية.
يمكن حل هاتين المسألتين باستخدام CDN الديناميكي.
الآن ، نريد إعداد CDN دون إعادة تشغيل جميع خوادم Origin ولا نريد نقل التدفقات إلى خوادم Edge بدون اتصال المستخدمين. في هذه الحالة ، ليست هناك حاجة للاحتفاظ بالقائمة الكاملة لخوادم CDN في مكان ما من الإعدادات. يجب على كل خادم إنشاء مثل هذه القائمة بشكل مستقل. للقيام بذلك ، يجب أن تعرف الحالة الحالية للخوادم الأخرى في أي وقت محدد.
من الناحية المثالية ، يجب أن يكون تحديد نقطة الدخول - الخادم الذي يبدأ تشغيل CDN - في الإعدادات كافياً. أثناء بدء التشغيل ، يجب على كل خادم إرسال طلب إلى نقطة الدخول هذه والاستجابة لقائمة عقد CDN والتدفقات المنشورة. إذا تعذر الوصول إلى نقطة الدخول ، فيجب على الخادم انتظار الرسائل من خوادم أخرى.
يجب على الخادم توصيل أي تغييرات في حالته إلى خوادم أخرى في CDN.
أبسط CDN: في وسط أوروبا
سنحاول الآن إعداد CDN ديناميكي وبدء تشغيله. لنفترض أولاً أننا بحاجة إلى تقديم تدفقات الوسائط للمشاهدين في أوروبا التي تغطي ما يصل إلى 5000 مستخدم. لنفترض أن مصدر الدفق موجود أيضًا في أوروبا

سنقوم بنشر ثلاثة خوادم في مركز بيانات في أوروبا. سنستخدم مثيلات Flashphoner WebCallServer (خادم فيديو دفق WebRTC) كمكونات تجميع CDN

إعداد:
cdn_enabled=true cdn_ip=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
- الحافة 1 الاتحاد الأوروبي
cdn_enabled=true cdn_ip=e-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
- الحافة 2 الاتحاد الأوروبي
cdn_enabled=true cdn_ip=e-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
يتم تنفيذ تبادل الرسائل بين عقد CDN الديناميكي عبر Websocket ، وبالتأكيد يتم دعم Secure Websocket.
يتم بث التدفقات داخل CDN عبر WebRTC. عادةً ما يتم استخدام UDP كوسيلة نقل ، ولكن إذا كان ذلك ضروريًا لضمان جودة تدفق جيدة مع عدم وجود قناة جيدة بين الخوادم ، فمن الممكن التبديل إلى TCP. لسوء الحظ ، في هذه الحالة ، يزيد الكمون.
أعد تشغيل الخوادم ، وافتح مثال o-eu1
خادم o-eu1
، o-eu1
دوري 10 دقائق إلى 0 مؤقت مؤقت للعد التنازلي

افتح مثال "المشغل" على خادم e-eu1
، قم بتشغيل الدفق

وتفعل الشيء نفسه على e-eu2

يعمل CDN! كما ترون على لقطات الشاشة ، يتزامن توقيت الفيديو مع الثانية على جزء النشر وجزء العرض بفضل WebRTC والقنوات الجيدة.
وما وراء ذلك نذهب: ربط أمريكا
نحن الآن بصدد تقديم تيارات للمشاهدين في القارة الأمريكية مع مراعاة النشر

سنقوم بنشر ثلاثة خوادم في مركز بيانات أمريكي دون إغلاق الجزء الأوروبي من شبكة CDN

إعداد:
cdn_enabled=true cdn_ip=o-us1.flashponer.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
أعد تشغيل الخوادم الأمريكية ، تحقق من النشر

والتشغيل

لاحظ أن الجزء الأوروبي يواصل العمل. سنقوم بالتحقق مما إذا كان المستخدمون الأمريكيون سيتمكنون من مشاهدة البث المنشور من أوروبا. نشر دفق test_eu
على خادم o-eu1

e-us1
على e-us1

وهذا يعمل أيضا! بالنسبة إلى زمن الانتقال ، تُظهر لقطات الشاشة مرة أخرى تزامن الموقت في الفيديو على جزء النشر وعلى جزء المشاهدة إلى الثانية.
لاحظ أنه لا يمكن تشغيل التدفقات المنشورة على خادم Origin آخر على خادم Origin افتراضيًا ، ولكن إذا لزم الأمر ، يمكن إعداد ذلك وفقًا لذلك.
cdn_origin_to_origin_route_propagation=true
أن تستمر
باختصار ، لقد قمنا بنشر CDN بسيط ثم قمنا بعد ذلك بتحجيمه بنجاح إلى قارتين لنشر تدفقات WebRTC منخفضة الكمون ولعبها. لهذا الغرض ، لم نقوم بتعديل معلمات الدفق عند التشغيل ، والتي غالبًا ما تكون مطلوبة في الحياة الواقعية: جميع المشاهدين لديهم قنوات مختلفة ، ومن أجل الحفاظ على جودة البث المطلوبة ، على سبيل المثال ، لتقليل الدقة أو معدل البت. سنتعامل مع هذا في الجزء التالي ...
Flashphoner WebCallServer image في DigitalOcean Marketplace - صورة Web Call Server في DigitalOcean.
CDN لتدفق WebRTC كامن منخفض - شبكة توصيل المحتوى المستندة إلى Web Call Server.