في الآونة الأخيرة ، ركض العديد من الأصدقاء الذين يقومون بمشاريع اجتماعية لطرح نفس السؤال عليّ: هل تستخدم شبكة CDN عالية الدفاع لدعم WebRTC في النهاية آه؟ لقد تعرضت لـ DDoS كل يوم خدر فروة الرأس، ولا أجرؤ على تعريض محطة المصدر مباشرة، وبطاقة الصوت والفيديو في الوقت الحقيقي في PPT تكاد تكون ملعونة حتى الموت من قبل المستخدم.
لأكون صادقًا، في المرة الأولى التي سمعت فيها هذا السؤال كدت أن أرش قهوتي على الشاشة، WebRTC هو في الأساس اتصال مباشر بين طرفين P2P، وتسريع ذاكرة التخزين المؤقت التقليدية لشبكة CDN ليس بنفس الطريقة. ولكن بعد أن سألني المزيد من الأشخاص، أدركت أن الأمور ليست بهذه البساطة - الآن القليل من حجم المنصة الاجتماعية، من الذي لا يزال يجرؤ على وضع تدفقات الصوت والفيديو عارية مباشرة على الشبكة العامة؟
كنت في الطرف المتلقي لهذا الأمر العام الماضي. في ذلك الوقت، كان المشروع في عجلة من أمره لبدء العمل على الإنترنت، وألقى مباشرةً بخادم TURN على السحابة العامة، والذي تم اختراقه في غضون ثلاثة أيام من افتتاحه. قام المهاجم بتحديد عنوان IP لخادم الوسائط الخاص بنا، وأدت حركة المرور التي بلغت 300 جيجا في الثانية إلى سقوط غرفة الخادم مباشرةً في ثقب أسود. كان المشهد كما لو أن مركز البيانات بأكمله قد غُمر رقميًا.
جوهر المشكلة هو هذا: تم تصميم WebRTC في الأصل للاتصال المباشر من نظير إلى نظير، لكن واقع بيئة الشبكة معقد للغاية لدرجة أنه يجعل رأسك يؤلمك!إن معدل فشل اجتياز NAT أكثر من 30%، وجدران الحماية الخاصة بالشركات هي القاتل الأول لبث الصوت والفيديو. هذا الوقت للاعتماد على خادم TURN للقيام بالعبور - وهذا الشيء هو مجرد نقطة تعرض لبروتوكول الإنترنت.
ما هو أكثر إثارة للاشمئزاز هو أن WebRTC لديه عيب قاتل عند إنشاء اتصال: عملية جمع عناوين ICE المرشحة تكشف كلاً من IP الخاص بالإنترانت و IP العام. لقد التقطت حزمة وشاهدتها مرة واحدة، وأثناء عملية التفاوض STUN تم نقل IP الخاص بالخادم عبر الشبكة كما لو كان عارياً. لا يحتاج المهاجمون حتى إلى عناء المسح الضوئي، يمكنهم فقط انتقاء عنوان IP الخاص بخادم الوسائط مباشرةً من إشارات المصافحة.
هذا هو الوقت المناسب لشبكات CDN عالية الدفاع لتلعب دورها. لكن بائعي شبكات CDN التقليدية مثل CDN07، يتم تحسين عقدهم بشكل أساسي لـ HTTP/HTTPS، ودعم بروتوكولات UDP هو ببساطة لمس. لقد اختبرت العقد الخاصة بهم، وتضاعفت حركة مرور WebRTC بعد التأخير مباشرة، ومعدل فقدان الحزمة أكثر من 15% أمر شائع الحدوث.
بدلاً من ذلك، فوجئت بسرور بشبكة CDN5، المتخصصة في الاتصالات في الوقت الحقيقي. تدعم جميع العقد الطرفية الخاصة بهم بروتوكولات SRT و WebRTC، والأهم من ذلك أنهم نشروا مجموعات وكلاء TURN مخصصة حول العالم. إليك رسم تخطيطي لهيكلها:
لاحظ أن سياسة iceTransportPolicy مضبوطة على الترحيل - وهذا هو مفتاح إنقاذ الأرواح. يؤدي إجبار كل حركة المرور على المرور عبر مرحل TURN إلى زيادة وقت الاستجابة قليلاً، ولكنه يخفي عنوان IP المصدر تمامًا، ويبلغ متوسط زيادة وقت الاستجابة في حدود 40 مللي ثانية، وهو ما يقع ضمن النطاق المقبول.
حل 08Host أكثر إثارة للاهتمام. لديهم نظام توجيه ذكي يمكنه التبديل ديناميكيًا بين UDP و TCP وفقًا لظروف الشبكة في الوقت الفعلي. تنتقل الاتصالات إلى TCP، وتنتقل Unicom إلى UDP، وتستخدم شبكة الهاتف المحمول حتى بروتوكول QUIC. لقد اختبرت عمدًا في ذروة المساء، ويتم التحكم في معدل فقدان الحزمة دائمًا بأقل من 3%:
صُمم هذا الـ IP_ip_pool_ip المزيف بذكاء - تستخدم العقد الطرفية عناوين IP افتراضية للتواصل مع المصدر، ولا يتم كشف عناوين IP الحقيقية أبدًا. تدوير مقاطع IP كل 5 دقائق يعادل وضع بدلة تمويه على الخادم.
إن تأثير الحماية من DDoS مبالغ فيه بشكل أكبر. في الشهر الماضي، واجهنا هجومًا مستهدفًا ضد بوابة WebRTC، 800,000 حزمة SYN في الثانية مخصصة لمنفذ TURN. قام مركز التنظيف في CDN5 بتشغيل الحماية الذكية مباشرة، وجدولة حركة المرور تلقائيًا إلى ثلاث عقد تنظيف مختلفة. تُظهر الإحصائيات النهائية أن 0.31 تيرابايت في الثانية فقط من حركة المرور المشروعة قد تأثرت، ولم يكن المستخدمون على علم بذلك تقريبًا.
ومع ذلك، من المهم ملاحظة أن شبكات CDN عالية الدفاع لا تدعم جميع شبكات CDN عالية الدفاع WebRTC، فبعض البائعين يقومون ببساطة بإعادة توجيه حركة مرور UDP دون حتى ضمانات جودة الخدمة الأساسية. عند الاختبار، تأكد من إلقاء نظرة على هذه المؤشرات الرئيسية: معدل نجاح اتصال ICE، وتباين التأخير من طرف إلى طرف، ومعدل إعادة إرسال فقدان الحزمة. لقد لخصت مخطط تحقق سريع:
تُظهر بيانات القياس أن شبكة CDN ذات الدفاع العالي الجيدة يمكن أن تجعل التحكم في زمن انتقال WebRTC P99 في غضون 200 مللي ثانية، ومعدل نجاح الاتصال في 5 ثوانٍ بنسبة 99.8% أو أكثر. على وجه الخصوص، يمكن الضغط على التأخير من هونج كونج إلى وادي السيليكون إلى حوالي 150 مللي ثانية، وهو قريب من مستوى البيانات المخصصة.
إذا نظرنا إلى الوراء الآن، فإن الجمع بين WebRTC وشبكة CDN عالية الدفاع يشبه التأمين المزدوج للاتصال في الوقت الحقيقي. فكلاهما يحتفظ بميزة الكمون المنخفض لـ P2P ويكتسب القدرة على حماية السحابة. يمكن للحماية من DDoS وحدها أن توفر مئات الآلاف من تكاليف عرض النطاق الترددي كل عام، خاصةً بالنسبة للمنصات الاجتماعية التي تتعرض لضرر كبير.
أخيرًا، درس في البكاء: لا تبني مجموعة TURN الخاصة بك لتوفير المال. ألقى فريقي ثلاثة أشهر في العام الماضي، استثمرت معدات تنظيف حركة المرور الخفيفة أكثر من مليونين، نتائج تأثير الحماية ليست جيدة مثل بائعي CDN المحترفين. الآن فكر في الأمر حقًا في الدماغ في الماء، يجب إعطاء الأشياء الاحترافية للرجال المحترفين للقيام بها.
إذن، نعود إلى السؤال الأصلي: هل تدعم شبكات CDN الاجتماعية عالية الحماية WebRTC؟ الجواب ليس فقط الدعم، بل يجب أن تدعم. في هذه الأيام، التواصل في الوقت الحقيقي بدون حماية يشبه الركض عاريًا في ساحة المعركة، يمكن لأي فتى نصي فقط أن يمحو المسرح. اختر مزود خدمة CDN المناسب، يمكن لأعمالك الصوتية والفيديو أن ترتاح حقًا.
