OpenVPN يوزّع البث الجماعي على كل عميل لا على المشتركين

«يدعم البث الجماعي» يجيب عن سؤال بروتوكول ويترك سؤال السعة دون مساس. ما يهم تشغيليًا هو عدد النسخ التي يرسلها الخادم لحزمة مجموعة واحدة وأي الأنفاق تحملها. تطبيق واحد مشترك يتلقى البث لا يثبت إلا أن التسليم يعمل في مكان ما. ولا يثبت أن العملاء غير المهتمين قد وُفّروا في النطاق الترددي.

ثلاثة أسئلة داخل ادعاء ميزة واحد

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

أبقِها منفصلة عند تقدير حجم رابط. السؤال الثالث وحده هو الذي يحدد ميزانية الصادر على جانب الخادم.

ما يفعله خادم فضاء المستخدم بحزمة مجموعة

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

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

اعمل ميزانية للنسخ قبل أن تقيس أي شيء

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

ip -s link show tun0

اقرأ عدّاد بايتات الإرسال قبل فترة ثابتة وبعدها مع مرسل واحد معروف نشط. اقسم على الفترة وقارن بمعدل الحمولة مضروبًا في عدد العملاء. رقم قريب من معدل البث الواحد يعني أن النسخ محدود النطاق؛ ورقم قريب من المعدل المضروب يعني أن كل عميل يتلقى نسخة.

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

اختبار بعميلين يحسم مسألة النطاق

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

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

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

اختيار تصميم محدود النطاق بدلًا من إزالة الحدود

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

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

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