از Skype تا WebRTC: نحوه سازماندهی ارتباط ویدیویی از طریق وب

ارتباط تصویری راه اصلی ارتباط معلم و دانش آموز در پلتفرم Vimbox است. ما مدتها پیش اسکایپ را رها کردیم، چندین راه حل شخص ثالث را امتحان کردیم و در نهایت در ترکیب WebRTC - Janus-gateway مستقر شدیم. برای مدتی از همه چیز راضی بودیم، اما هنوز برخی از جنبه های منفی همچنان ظاهر می شد. در نتیجه یک جهت ویدیویی جداگانه ایجاد شد.

من از کریل روگووی، رئیس بخش جدید خواستم تا در مورد تکامل ارتباطات ویدیویی در Skyeng، مشکلات کشف شده، راه حل ها و عصاهایی که در نهایت استفاده کردیم صحبت کند. امیدواریم این مقاله برای شرکت هایی که به تنهایی از طریق یک برنامه وب نیز ویدیو ایجاد می کنند مفید باشد.

کمی از تاریخ

در تابستان 2017، سرگئی سافونوف، رئیس توسعه Skyeng، در Backend Conf با داستانی در مورد اینکه چگونه اسکایپ را رها کردیم و WebRTC را پیاده‌سازی کردیم، صحبت کرد. علاقه مندان می توانند ضبط این سخنرانی را به نشانی پیوند (~45 دقیقه)، و در اینجا به طور خلاصه ماهیت آن را بیان می کنم.

برای مدرسه Skyeng، ارتباط ویدیویی همیشه یکی از راه‌های اولویت‌دار ارتباط معلم و دانش‌آموز بوده است. در ابتدا از اسکایپ استفاده می شد، اما به دلایل متعدد، در درجه اول به دلیل عدم وجود گزارش و عدم امکان ادغام مستقیم در برنامه وب، به طور قطعی رضایت بخش نبود. بنابراین، ما انواع آزمایش ها را انجام دادیم.

در واقع، الزامات ما برای ارتباط تصویری تقریباً موارد زیر بود:
- ثبات؛
- قیمت پایین برای هر درس؛
- ضبط دروس؛
- پیگیری اینکه چه کسی چقدر صحبت می کند (برای ما مهم است که دانش آموزان در طول درس بیشتر از معلم صحبت کنند).
- مقیاس بندی خطی؛
- امکان استفاده از UDP و TCP.

اولین تلاش برای پیاده سازی Tokbox در سال 2013 بود. همه چیز خوب بود، اما معلوم شد که بسیار گران است - 113 روبل در هر درس - و سود را خورد.

سپس در سال 2015، Voximplant یکپارچه شد. این تابعی بود که ما برای ردیابی اینکه چه کسی چقدر صحبت می کند نیاز داشتیم، و در عین حال راه حل بسیار ارزان تر بود: اگر فقط صدا ضبط می شد، هزینه آن برای هر درس 20 روبل بود. با این حال، فقط از طریق UDP کار می کرد و نمی توانست به TCP سوئیچ کند. با این حال، حدود 40٪ از دانش آموزان در نهایت از آن استفاده کردند.

یک سال بعد، ما شروع به داشتن مشتریان شرکتی با نیازهای خاص خود کردیم. به عنوان مثال، همه چیز باید از طریق یک مرورگر کار کند؛ شرکت فقط http و https را باز می کند. یعنی بدون اسکایپ یا UDP. مشتریان شرکتی = پول، بنابراین به توک باکس بازگشتند، اما مشکل قیمت برطرف نشد.

راه حل - WebRTC و Janus

تصمیم به استفاده گرفت پلت فرم مرورگر برای ارتباط ویدیویی نظیر به نظیر WebRTC. این مسئول ایجاد یک اتصال، رمزگذاری و رمزگشایی جریان ها، همگام سازی مسیرها و کنترل کیفیت با رسیدگی به اشکالات شبکه است. به نوبه خود، ما باید از خواندن جریان‌ها از دوربین و میکروفون، ترسیم ویدیو، مدیریت اتصال، ایجاد اتصال WebRTC و انتقال جریان‌ها به آن، و همچنین ارسال پیام‌های سیگنالینگ بین مشتریان برای برقراری ارتباط اطمینان حاصل کنیم (خود WebRTC فقط فرمت داده، اما نه انتقال مکانیسم آن). اگر کلاینت‌ها پشت NAT هستند، WebRTC سرورهای STUN را متصل می‌کند؛ اگر کمکی نکرد، سرورها را تغییر دهید.

یک اتصال معمولی p2p برای ما کافی نیست، زیرا ما می خواهیم دروس را برای تجزیه و تحلیل بیشتر در صورت شکایت ضبط کنیم. بنابراین ما جریان های WebRTC را از طریق یک رله ارسال می کنیم Janus Gateway توسط Meetecho. در نتیجه، مشتریان آدرس یکدیگر را نمی دانند و فقط آدرس سرور Janus را می بینند. همچنین عملکردهای یک سرور سیگنال را انجام می دهد. Janus بسیاری از ویژگی های مورد نیاز ما را دارد: اگر سرویس گیرنده UDP مسدود شده باشد، به طور خودکار به TCP سوئیچ می شود. می تواند هر دو جریان UDP و TCP را ضبط کند. مقیاس پذیر؛ حتی یک افزونه داخلی برای آزمایش اکو وجود دارد. در صورت لزوم، سرورهای STUN و TURN از Twilio به طور خودکار متصل می شوند.

در تابستان 2017، ما دو سرور Janus در حال اجرا داشتیم، به علاوه یک سرور اضافی برای پردازش فایل‌های صوتی و تصویری خام ضبط‌شده، تا پردازنده‌های اصلی‌ها را اشغال نکند. هنگام اتصال، سرورهای Janus بر اساس زوج و فرد (شماره اتصال) انتخاب شدند. در آن زمان، این کافی بود، طبق احساسات ما، تقریباً یک حاشیه ایمنی چهار برابری ایجاد کرد، درصد اجرا حدود 80 بود. در همان زمان، قیمت به ~ 2 روبل در هر درس کاهش یافت، به علاوه توسعه و پشتیبانی.

بازگشت به موضوع ارتباط تصویری

ما به طور مداوم بر بازخورد دانش آموزان و معلمان نظارت می کنیم تا مشکلات را به موقع شناسایی و اصلاح کنیم. در تابستان 2018، کیفیت تماس در بین شکایات در جایگاه اول قرار داشت. از یک طرف، این بدان معنا بود که ما با موفقیت بر سایر کاستی ها غلبه کرده بودیم. از طرف دیگر، لازم بود یک کار فوری انجام شود: اگر درس مختل شود، خطر از دست دادن ارزش آن را داریم، گاهی اوقات همراه با هزینه خرید بسته بعدی، و اگر در درس مقدماتی اختلال ایجاد شود، خطر از دست دادن مشتری بالقوه را داریم. در مجموع

در آن زمان ارتباط تصویری ما هنوز در حالت MVP بود. به عبارت ساده، آنها آن را راه اندازی کردند، کار کرد، آنها آن را یک بار مقیاس کردند، آنها فهمیدند که چگونه این کار را انجام دهند - خوب، عالی است. اگر کار می کند، آن را تعمیر نکنید. هیچ کس عمداً به موضوع کیفیت ارتباطات نپرداخته است. در ماه آگوست، مشخص شد که این نمی تواند ادامه یابد، و ما مسیر جداگانه ای را راه اندازی کردیم تا بفهمیم چه مشکلی در WebRTC و Janus وجود دارد.

در ورودی، این جهت دریافت کرد: یک راه حل MVP، بدون معیار، بدون هدف، هیچ فرآیندی برای بهبود، در حالی که 7٪ از معلمان از کیفیت ارتباطات شکایت دارند (هیچ اطلاعاتی در مورد دانش آموزان وجود نداشت).

جهت جدیدی در حال انجام است

دستور چیزی شبیه به این است:

• رئیس بخش، که توسعه دهنده اصلی نیز می باشد.
• QA به آزمایش تغییرات کمک می کند، به دنبال راه های جدیدی برای ایجاد شرایط ارتباطی ناپایدار می گردد و مشکلات را از خط مقدم گزارش می دهد.
• تحلیلگر دائماً به دنبال همبستگی های مختلف در داده های فنی است، تجزیه و تحلیل بازخورد کاربران را بهبود می بخشد و نتایج آزمایش ها را بررسی می کند.
• مدیر محصول در جهت گیری کلی و تخصیص منابع برای آزمایش ها کمک می کند.
• یک توسعه دهنده دوم اغلب در برنامه نویسی و کارهای مرتبط کمک می کند.

برای شروع، ما یک معیار نسبتا قابل اعتماد تنظیم کردیم که تغییرات در ارزیابی‌های کیفیت ارتباطات (میانگین در طول روز، هفته، ماه) را ردیابی می‌کرد. در آن زمان اینها نمرات معلمان بود؛ بعدها نمرات دانش آموزان به آنها اضافه شد. سپس آنها شروع به ساختن فرضیه هایی در مورد اینکه چه چیزی اشتباه کار می کند، آن را تصحیح کردند و به تغییرات در پویایی نگاه کردند. ما به سراغ میوه کم آویزان رفتیم: به عنوان مثال، کدک vp8 را با vp9 جایگزین کردیم، عملکرد بهبود یافت. ما سعی کردیم با تنظیمات Janus بازی کنیم و آزمایش های دیگری را انجام دهیم - در بیشتر موارد آنها به چیزی منجر نشدند.

در مرحله دوم، یک فرضیه ظاهر شد: WebRTC یک راه حل همتا به همتا است و ما از یک سرور در وسط استفاده می کنیم. شاید مشکل اینجاست؟ ما شروع به حفاری کردیم و مهمترین پیشرفت را تا کنون پیدا کردیم.

در آن لحظه، سروری از استخر با استفاده از یک الگوریتم نسبتاً احمقانه انتخاب شد: هر کدام بسته به کانال و قدرت، "وزن" خود را داشتند، و ما سعی کردیم کاربر را به یکی با بزرگترین "وزن" ارسال کنیم، بدون اینکه توجه به موقعیت جغرافیایی کاربر در نتیجه، معلمی از سن پترزبورگ می توانست با دانش آموزی از سیبری از طریق مسکو ارتباط برقرار کند، نه از طریق سرور Janus ما در سن پترزبورگ.

الگوریتم دوباره انجام شده است: اکنون، وقتی کاربر پلتفرم ما را باز می کند، پینگ ها را از او به همه سرورها با استفاده از Ajax جمع آوری می کنیم. هنگام برقراری ارتباط، یک جفت پینگ (معلم-سرور و دانشجو-سرور) با کمترین مقدار انتخاب می کنیم. پینگ کمتر به معنای فاصله کمتر شبکه تا سرور است. فاصله کوتاهتر به معنای احتمال کمتر از دست دادن بسته ها است. از دست دادن بسته بزرگترین عامل منفی در ارتباطات ویدیویی است. سهم منفی در سه ماه به نصف کاهش یافت (منصفانه، آزمایش‌های دیگری در این زمان انجام شد، اما این آزمایش تقریباً مطمئناً بیشترین تأثیر را داشت).

ما اخیراً یک چیز غیر بدیهی، اما ظاهراً مهم دیگر را کشف کردیم: به جای یک سرور قدرتمند Janus در یک کانال ضخیم، بهتر است دو سرور ساده تر با پهنای باند کمتر داشته باشیم. این موضوع پس از خرید ماشین‌های قدرتمند به امید اینکه بتوانیم همزمان تعداد زیادی اتاق (جلسات ارتباطی) را در آن‌ها جمع کنیم، مشخص شد. سرورها دارای محدودیت پهنای باند هستند که می‌توانیم آن را با دقت به تعداد اتاق‌ها ترجمه کنیم - می‌دانیم که چه تعداد اتاق‌ها را می‌توان باز کرد، مثلاً با سرعت 300 مگابیت بر ثانیه. به محض اینکه تعداد زیادی اتاق روی سرور باز شود، انتخاب آن را برای فعالیت های جدید متوقف می کنیم تا بارگذاری کاهش یابد. ایده این بود که با خرید یک دستگاه قدرتمند، کانال را به حداکثر بارگذاری کنیم تا در نهایت توسط پردازنده و حافظه محدود شود و نه با پهنای باند. اما معلوم شد که پس از تعداد معینی اتاق باز (420)، با وجود این واقعیت که بار روی پردازنده، حافظه و دیسک هنوز از محدودیت ها فاصله دارد، منفی شروع به رسیدن به پشتیبانی فنی می کند. ظاهراً چیزی در ژانوس بدتر می شود، شاید در آنجا نیز محدودیت هایی وجود داشته باشد. ما شروع به آزمایش کردیم، محدودیت پهنای باند را از 300 به 200 مگابیت بر ثانیه کاهش دادیم و مشکلات برطرف شد. اکنون سه سرور جدید را به طور همزمان با محدودیت ها و ویژگی های کم خریداری کردیم، فکر می کنیم که این منجر به بهبود پایدار در کیفیت ارتباطات می شود. البته، ما سعی نکردیم بفهمیم آنجا چه خبر است؛ عصای زیر بغل ما همه چیز است. در دفاع از خود، بیایید بگوییم که در آن لحظه لازم بود که مشکل فشار را در اسرع وقت حل کنیم، نه اینکه آن را به زیبایی انجام دهیم. علاوه بر این، Janus برای ما یک جعبه سیاه است که با C نوشته شده است، سرهم کردن با آن بسیار گران است.

خوب، در این فرآیند ما:

• تمام وابستگی هایی را که می توان به روز کرد، هم در سرور و هم روی مشتری به روز کرد (اینها نیز آزمایشاتی بودند، ما نتایج را زیر نظر گرفتیم).
• رفع تمام اشکالات شناسایی شده مربوط به موارد خاص، به عنوان مثال، زمانی که اتصال قطع شد و به طور خودکار بازیابی نشد.
• ما جلسات زیادی با شرکت های فعال در زمینه ارتباطات ویدیویی برگزار کردیم و با مشکلات خود آشنا شدیم: پخش بازی ها، سازماندهی وبینارها. ما هر چیزی را که برایمان مفید بود امتحان کردیم.
• بررسی فنی سخت افزار و کیفیت ارتباط معلمان را انجام داد که بیشترین شکایات از آنها بود.

آزمایش‌ها و تغییرات بعدی این امکان را به وجود آورد که نارضایتی از ارتباط بین معلمان از 7,1 درصد در ژانویه 2018 به 2,5 درصد در ژانویه 2019 کاهش یابد.

بعدی چیست؟

تثبیت پلت فرم Vimbox ما یکی از پروژه های اصلی این شرکت برای سال 2019 است. ما امیدواریم که بتوانیم شتاب را حفظ کنیم و دیگر شاهد ارتباطات ویدیویی در شکایات برتر نباشیم. ما می دانیم که بخش قابل توجهی از این شکایات مربوط به تاخیر در رایانه و اینترنت کاربران است، اما باید این بخش را تعیین کنیم و بقیه را حل کنیم. همه چیز دیگر یک مشکل فنی است، به نظر می رسد ما باید بتوانیم با آن کنار بیاییم.

مشکل اصلی این است که ما نمی دانیم واقعاً تا چه سطحی می توان کیفیت را بهبود بخشید. پیدا کردن این سقف وظیفه اصلی است. بنابراین، دو آزمایش برنامه ریزی شد:

1. مقایسه ویدیو از طریق Janus با p2p معمولی در شرایط جنگی. این آزمایش قبلا انجام شده است، هیچ تفاوت آماری معنی داری بین محلول ما و p2p یافت نشد.
2. بیایید خدمات (گران قیمت) را از شرکت‌هایی که منحصراً از راه‌حل‌های ارتباط ویدیویی کسب درآمد می‌کنند ارائه کنیم و میزان منفی بودن آن‌ها را با موارد موجود مقایسه کنیم.

این دو آزمایش به ما این امکان را می دهند که یک هدف قابل دستیابی را شناسایی کرده و روی آن تمرکز کنیم.

علاوه بر این، تعدادی کار وجود دارد که می توان به طور معمول آنها را حل کرد:

• ما یک معیار فنی از کیفیت ارتباطات به جای بررسی های ذهنی ایجاد می کنیم.
• برای تجزیه و تحلیل دقیق‌تر شکست‌هایی که رخ می‌دهند، متوجه می‌شویم که دقیقاً چه زمانی و کجا رخ داده‌اند، و چه رویدادهایی به ظاهر نامرتبط در آن لحظه رخ داده‌اند، گزارش‌های جزئیات بیشتری از جلسه ایجاد می‌کنیم.
• ما قبل از درس تست کیفیت اتصال خودکار را آماده می کنیم و همچنین به مشتری این فرصت را می دهیم که به صورت دستی اتصال را آزمایش کند تا میزان منفی ناشی از سخت افزار و کانال خود را کاهش دهد.
• ما تست‌های بار ارتباطی ویدیویی بیشتری را در شرایط بد، با از دست دادن بسته متغیر و غیره توسعه و انجام خواهیم داد.
• ما رفتار سرورها را در صورت بروز مشکل تغییر می دهیم تا تحمل خطا را افزایش دهیم.
• در صورتی که مشکلی در ارتباط با کاربر وجود داشته باشد، همانطور که اسکایپ انجام می دهد، به کاربر هشدار می دهیم تا متوجه شود که مشکل از طرف اوست.

از آوریل، مسیر ارتباط ویدیویی به یک پروژه مجزای کامل در Skyeng تبدیل شده است که با محصول خود سروکار دارد، نه فقط بخشی از Vimbox. این بدان معنی است که ما شروع به جستجوی افراد در آن می کنیم کار با ویدئو در حالت تمام وقت. خب مثل همیشه ما به دنبال افراد خوب زیادی هستیم.

و، البته، ما همچنان به طور فعال با افراد و شرکت هایی که با ارتباطات ویدئویی کار می کنند، ارتباط برقرار می کنیم. اگر مایل به تبادل تجربه با ما هستید، خوشحال خواهیم شد! نظر دهید، تماس بگیرید - ما به همه پاسخ خواهیم داد.

منبع: www.habr.com