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