يعد الاتصال بالفيديو هو الوسيلة الرئيسية للتواصل بين المعلم والطالب على منصة Vimbox. لقد تخلينا عن Skype منذ وقت طويل، وقمنا بتجربة العديد من حلول الجهات الخارجية واستقرينا في النهاية على مجموعة WebRTC - بوابة Janus. لبعض الوقت كنا سعداء بكل شيء، ولكن استمرت بعض الجوانب السلبية في الظهور. ونتيجة لذلك، تم إنشاء اتجاه فيديو منفصل.
لقد طلبت من كيريل روجوفوي، رئيس الاتجاه الجديد، أن يتحدث عن تطور اتصالات الفيديو في Skyeng، والمشكلات المكتشفة، والحلول والعكازات التي استخدمناها في النهاية. نأمل أن تكون المقالة مفيدة للشركات التي تقوم أيضًا بإنشاء مقاطع فيديو بنفسها من خلال تطبيق ويب.
القليل من التاريخ
في صيف عام 2017، تحدث سيرجي سافونوف، رئيس تطوير Skyeng، في Backend Conf بقصة حول كيفية "التخلي عن Skype وتنفيذ WebRTC". ويمكن للمهتمين مشاهدة تسجيل الخطاب على (~45 دقيقة)، وهنا سألخص جوهرها بإيجاز.
بالنسبة لمدرسة Skyeng، كان الاتصال بالفيديو دائمًا وسيلة ذات أولوية للتواصل بين المعلم والطالب. في البداية، تم استخدام Skype، لكنه لم يكن مرضيًا بشكل قاطع لعدد من الأسباب، ويرجع ذلك أساسًا إلى عدم وجود سجلات واستحالة التكامل مباشرة في تطبيق الويب. ولذلك، قمنا بإجراء جميع أنواع التجارب.
في الواقع، كانت متطلباتنا للاتصال عبر الفيديو تقريبًا كما يلي:
- استقرار؛
- سعر منخفض لكل درس؛
— تسجيل الدروس.
- تتبع من يتحدث كم (من المهم بالنسبة لنا أن يتحدث الطلاب أكثر من المعلم أثناء الدروس)؛
- القياس الخطي؛
- القدرة على استخدام كل من UDP وTCP.
أول من حاول تنفيذ Tokbox في عام 2013. كان كل شيء على ما يرام، ولكن اتضح أنه مكلف للغاية - 113 روبل لكل درس - وأكل الربح.
ثم في عام 2015، تم دمج Voximplant. كانت هذه هي الوظيفة التي نحتاجها لتتبع من تحدث وكم كان الحل أرخص بكثير: إذا تم تسجيل الصوت فقط، فسيكلف 20 روبل لكل درس. ومع ذلك، فهو يعمل فقط عبر UDP ولا يمكنه التبديل إلى TCP. ومع ذلك، انتهى الأمر بحوالي 40٪ من الطلاب باستخدامه.
وبعد مرور عام، بدأنا في الحصول على عملاء من الشركات بمتطلباتهم الخاصة. على سبيل المثال، يجب أن يعمل كل شيء من خلال المتصفح، فالشركة تفتح فقط http وhttps؛ أي لا يوجد Skype أو UDP. عملاء الشركات = المال، فعادوا إلى Tokbox، لكن مشكلة السعر لم تنتهِ.
الحل - WebRTC وجانوس
قررت استخدام . وهي مسؤولة عن إنشاء اتصال وترميز وفك تشفير التدفقات ومزامنة المسارات ومراقبة الجودة مع معالجة مواطن الخلل في الشبكة. من جانبنا، يجب علينا التأكد من قراءة التدفقات من الكاميرا والميكروفون، ورسم الفيديو، وإدارة الاتصال، وإنشاء اتصال WebRTC وإرسال التدفقات إليه، بالإضافة إلى نقل رسائل الإشارة بين العملاء لإنشاء اتصال (WebRTC نفسه يصف فقط تنسيق البيانات، ولكن ليس عمليات نقل الآلية الخاصة بها). إذا كان العملاء وراء NAT، فإن WebRTC يتصل بخوادم STUN، وإذا لم يساعد ذلك، فخوادم TURN.
إن اتصال p2p العادي لا يكفي بالنسبة لنا، لأننا نريد تسجيل الدروس لمزيد من التحليل في حالة وجود شكاوى. ولذلك نرسل تدفقات WebRTC من خلال التتابع . ونتيجة لذلك، لا يعرف العملاء عناوين بعضهم البعض، ولا يرون سوى عنوان خادم Janus؛ كما أنه يؤدي وظائف خادم الإشارة. يتمتع Janus بالعديد من الميزات التي نحتاجها: يتحول تلقائيًا إلى TCP إذا تم حظر UDP على العميل؛ يمكنه تسجيل تدفقات UDP وTCP؛ القابلة للتطوير؛ يوجد أيضًا مكون إضافي مدمج لاختبارات الصدى. إذا لزم الأمر، يتم توصيل خوادم STUN وTURN من Twilio تلقائيًا.
في صيف عام 2017، كان لدينا خادمان من نوع Janus قيد التشغيل، بالإضافة إلى خادم إضافي لمعالجة ملفات الصوت والفيديو الخام المسجلة، حتى لا تشغل معالجات المعالجات الرئيسية. عند الاتصال، تم اختيار خوادم Janus على أساس فردي وزوجي (رقم الاتصال). في ذلك الوقت كان هذا كافيا، حسب مشاعرنا، أعطى هامش أمان أربعة أضعاف تقريبا، وكانت نسبة التنفيذ حوالي 80. وفي الوقت نفسه، تم تخفيض السعر إلى ~ 2 روبل لكل درس، بالإضافة إلى التطوير والدعم.
العودة إلى موضوع الاتصالات الفيديو
نحن نراقب باستمرار تعليقات الطلاب والمدرسين من أجل تحديد المشكلات وتصحيحها في الوقت المناسب. بحلول صيف عام 2018، كانت جودة المكالمات في المرتبة الأولى بين الشكاوى. فمن ناحية، كان هذا يعني أننا نجحنا في التغلب على أوجه القصور الأخرى. من ناحية أخرى، كان من الضروري القيام بشيء ما على وجه السرعة: إذا تم تعطيل الدرس، فإننا نجازف بفقدان قيمته، وأحيانًا إلى جانب تكلفة شراء الحزمة التالية، وإذا تم تعطيل الدرس التمهيدي، فإننا نخاطر بفقدان عميل محتمل كليا.
في ذلك الوقت، كانت اتصالات الفيديو الخاصة بنا لا تزال في وضع MVP. ببساطة، لقد أطلقوه، ونجح، وقاموا بتوسيع نطاقه مرة واحدة، وفهموا كيفية القيام بذلك - حسنًا، عظيم. إذا كان يعمل، لا إصلاحه. لم يتطرق أحد عمدا إلى مسألة جودة الاتصالات. بحلول شهر أغسطس، أصبح من الواضح أن هذا لا يمكن أن يستمر، وأطلقنا اتجاهًا منفصلاً لمعرفة الخطأ في WebRTC وJanus.
عند الإدخال، تلقى هذا الاتجاه: حل MVP، ولا توجد مقاييس، ولا أهداف، ولا عمليات للتحسين، بينما يشتكي 7٪ من المعلمين من جودة التواصل (لم تكن هناك بيانات عن الطلاب أيضًا).
هناك اتجاه جديد قيد التنفيذ
يبدو الأمر كالتالي:
- رئيس القسم وهو المطور الرئيسي أيضًا.
- يساعد ضمان الجودة في اختبار التغييرات والبحث عن طرق جديدة لخلق ظروف اتصال غير مستقرة والإبلاغ عن المشكلات من الخط الأمامي.
- يبحث المحلل باستمرار عن الارتباطات المختلفة في البيانات الفنية، ويحسن تحليل تعليقات المستخدمين، ويتحقق من نتائج التجارب.
- يساعد مدير المنتج في التوجيه العام وتخصيص الموارد للتجارب.
- غالبًا ما يساعد المطور الثاني في البرمجة والمهام ذات الصلة.
في البداية، قمنا بإعداد مقياس موثوق نسبيًا لتتبع التغييرات في تقييمات جودة الاتصالات (المتوسط على مدار أيام أو أسابيع أو أشهر). وكانت هذه في ذلك الوقت عبارة عن درجات من المعلمين، ثم أضيفت إليها فيما بعد درجات الطلاب. ثم بدأوا في بناء فرضيات حول الأخطاء التي حدثت، وتصحيحها، والنظر في التغيرات في الديناميكيات. لقد اخترنا الثمرة السهلة: على سبيل المثال، استبدلنا برنامج الترميز vp8 ببرنامج vp9، مما أدى إلى تحسن الأداء. لقد حاولنا اللعب بإعدادات يانوس وإجراء تجارب أخرى - وفي معظم الحالات لم تؤدي إلى أي شيء.
في المرحلة الثانية، ظهرت فرضية: WebRTC هو حل نظير إلى نظير، ونحن نستخدم خادمًا في المنتصف. ربما المشكلة تكمن هنا؟ بدأنا الحفر ووجدنا التحسن الأكثر أهمية حتى الآن.
في تلك اللحظة، تم اختيار خادم من التجمع باستخدام خوارزمية غبية إلى حد ما: كان لكل خادم "وزنه" الخاص، اعتمادًا على القناة والقوة، وحاولنا إرسال المستخدم إلى الخادم الذي لديه "وزن" أكبر، دون مع الانتباه إلى مكان تواجد المستخدم جغرافيًا. نتيجة لذلك، يمكن للمعلم من سانت بطرسبرغ التواصل مع طالب من سيبيريا عبر موسكو، وليس من خلال خادم يانوس لدينا في سانت بطرسبرغ.
تمت إعادة تصميم الخوارزمية: الآن، عندما يفتح المستخدم منصتنا، نقوم بجمع الأصوات منه إلى جميع الخوادم التي تستخدم Ajax. عند إنشاء اتصال، نختار زوجًا من الأصوات (خادم المعلم وخادم الطالب) بأقل كمية. يعني اختبار ping الأقل مسافة أقل بين الشبكة والخادم؛ المسافة الأقصر تعني احتمالية أقل لفقدان الحزم؛ يعد فقدان الحزمة أكبر عامل سلبي في اتصالات الفيديو. انخفضت حصة السلبية بمقدار النصف في ثلاثة أشهر (ولكي نكون منصفين، تم إجراء تجارب أخرى في ذلك الوقت، ولكن من المؤكد أن هذه التجربة كان لها التأثير الأكبر).
لقد اكتشفنا مؤخرًا شيئًا آخر غير واضح، ولكنه مهم على ما يبدو: بدلاً من خادم Janus القوي على قناة سميكة، من الأفضل أن يكون لديك خادمان أبسط بنطاق ترددي أقل. لقد أصبح هذا واضحًا بعد أن اشترينا آلات قوية على أمل حشر أكبر عدد ممكن من الغرف (جلسات الاتصال) فيها في نفس الوقت. تحتوي الخوادم على حد لعرض النطاق الترددي، والذي يمكننا ترجمته بدقة إلى عدد الغرف - فنحن نعرف عدد الغرف التي يمكن فتحها، على سبيل المثال، بسرعة 300 ميجابت/ثانية. بمجرد وجود عدد كبير جدًا من الغرف المفتوحة على الخادم، نتوقف عن اختياره للأنشطة الجديدة حتى ينخفض الحمل. كانت الفكرة أنه بعد شراء جهاز قوي، سنقوم بتحميل القناة إليه إلى الحد الأقصى، بحيث تكون في النهاية محدودة بالمعالج والذاكرة، وليس بعرض النطاق الترددي. ولكن اتضح أنه بعد عدد معين من الغرف المفتوحة (420)، على الرغم من أن الحمل على المعالج والذاكرة والقرص لا يزال بعيدًا جدًا عن الحدود، تبدأ السلبية في الوصول إلى الدعم الفني. على ما يبدو، هناك شيء يزداد سوءا داخل يانوس، ربما هناك بعض القيود هناك أيضا. بدأنا بالتجربة، وخفضنا حد النطاق الترددي من 300 إلى 200 ميجابت/ثانية، وانتهت المشكلة. قمنا الآن بشراء ثلاثة خوادم جديدة دفعة واحدة بحدود وخصائص منخفضة، ونعتقد أن هذا سيؤدي إلى تحسن ثابت في جودة الاتصال. بالطبع، لم نحاول معرفة ما يحدث هناك، فعكازاتنا هي كل شيء. دفاعًا عن أنفسنا، لنفترض أنه في تلك اللحظة كان من الضروري حل المشكلة الملحة في أسرع وقت ممكن، وليس القيام بذلك بشكل جميل؛ بالإضافة إلى ذلك، يانوس بالنسبة لنا هو صندوق أسود مكتوب بلغة C، والعبث به مكلف للغاية.
حسنًا، في هذه العملية قمنا بما يلي:
- تحديث جميع التبعيات التي يمكن تحديثها، سواء على الخادم أو على العميل (كانت هذه أيضًا تجارب، وقمنا بمراقبة النتائج)؛
- تم إصلاح جميع الأخطاء التي تم تحديدها والمتعلقة بحالات محددة، على سبيل المثال، عند انقطاع الاتصال وعدم استعادته تلقائيًا؛
- لقد عقدنا الكثير من الاجتماعات مع الشركات العاملة في مجال اتصالات الفيديو وعلى دراية بمشاكلنا: بث الألعاب، وتنظيم الندوات عبر الإنترنت؛ لقد جربنا كل ما بدا لنا مفيدًا؛
- إجراء مراجعة فنية لجودة الأجهزة والاتصالات الخاصة بالمعلمين، الذين جاءت منهم معظم الشكاوى.
أتاحت التجارب والتغييرات اللاحقة تقليل عدم الرضا عن التواصل بين المعلمين من 7,1% في يناير 2018 إلى 2,5% في يناير 2019.
ما هي الخطوة التالية
يعد تثبيت منصة Vimbox الخاصة بنا أحد المشاريع الرئيسية للشركة لعام 2019. لدينا آمال كبيرة في أن نتمكن من الحفاظ على الزخم وعدم رؤية اتصالات الفيديو في أهم الشكاوى. نحن ندرك أن جزءًا كبيرًا من هذه الشكاوى يتعلق بالتأخير في أجهزة الكمبيوتر والإنترنت الخاصة بالمستخدمين، ولكن يجب علينا تحديد هذا الجزء وحل الباقي. كل شيء آخر يمثل مشكلة فنية، ويبدو أننا يجب أن نكون قادرين على التعامل معها.
تكمن الصعوبة الرئيسية في أننا لا نعرف إلى أي مستوى يمكن فعليًا تحسين الجودة. اكتشاف هذا السقف هو المهمة الرئيسية. ولذلك، تم التخطيط لتجربتين:
- قارن الفيديو عبر Janus مع p2p العادي في ظروف القتال. تم إجراء هذه التجربة بالفعل، ولم يتم العثور على فرق ذي دلالة إحصائية بين الحل الذي قدمناه وp2p؛
- دعونا نقدم خدمات (باهظة الثمن) من الشركات التي تجني الأموال حصريًا من حلول اتصالات الفيديو، ونقارن مقدار السلبية منها مع تلك الموجودة.
ستسمح لنا هاتان التجربتان بتحديد هدف يمكن تحقيقه والتركيز عليه.
بالإضافة إلى ذلك، هناك عدد من المهام التي يمكن حلها بشكل روتيني:
- نقوم بإنشاء مقياس فني لجودة الاتصال بدلاً من المراجعات الذاتية؛
- نقوم بإنشاء سجلات جلسة أكثر تفصيلاً من أجل تحليل حالات الفشل التي تحدث بشكل أكثر دقة، وفهم متى وأين حدثت بالضبط، وما هي الأحداث التي تبدو غير ذات صلة والتي حدثت في تلك اللحظة؛
- نقوم بإعداد اختبار جودة الاتصال التلقائي قبل الدرس، كما نمنح العميل فرصة اختبار الاتصال يدويًا لتقليل كمية السلبية التي تسببها أجهزته وقناته؛
- سنقوم بتطوير وإجراء المزيد من اختبارات تحميل اتصالات الفيديو في الظروف السيئة، مع فقدان الحزمة المتغير، وما إلى ذلك؛
- نقوم بتغيير سلوك الخوادم في حالة حدوث مشكلات لزيادة القدرة على تحمل الخطأ؛
- وسوف نقوم بتحذير المستخدم إذا كان هناك خطأ ما في اتصاله على الإطلاق، كما يفعل Skype، حتى يفهم أن المشكلة في جانبه.
منذ أبريل، أصبح اتجاه اتصالات الفيديو مشروعًا منفصلاً كاملاً داخل Skyeng، يتعامل مع منتجه الخاص، وليس مجرد جزء من Vimbox. هذا يعني أننا بدأنا في البحث عن الأشخاص . حسنا، كما هو الحال دائما .
وبالطبع، نواصل التواصل بنشاط مع الأشخاص والشركات التي تعمل في مجال اتصالات الفيديو. إذا كنت ترغب في تبادل الخبرات معنا، سنكون سعداء! التعليق، تواصل معنا - سنجيب على الجميع.
المصدر: www.habr.com