От Skype до WebRTC: как организирахме видео комуникация чрез мрежата

Видео комуникацията е основният начин за комуникация между учител и ученик в платформата Vimbox. Отказахме се от Skype преди много време, опитахме няколко решения на трети страни и в крайна сметка се спряхме на комбинацията WebRTC - Janus-gateway. Известно време бяхме доволни от всичко, но все пак някои негативни аспекти продължаваха да се появяват. В резултат на това беше създадена отделна видео посока.

Помолих Кирил Роговой, ръководител на новото направление, да говори за еволюцията на видео комуникацията в Skyeng, откритите проблеми, решенията и патериците, които в крайна сметка използвахме. Надяваме се, че статията ще бъде полезна за компании, които също създават видео сами чрез уеб приложение.

Малко история

През лятото на 2017 г. ръководителят на разработката на Skyeng, Сергей Сафонов, говори на Backend Conf с история за това как ние „изоставихме Skype и внедрихме WebRTC“. Желаещите могат да гледат записа на изказването на връзка (~45 мин), като тук накратко ще очертая същността му.

За Skyeng School видео комуникацията винаги е била приоритетен начин за комуникация учител-ученик. Първоначално беше използван Skype, но той категорично не беше задоволителен по редица причини, главно поради липсата на логове и невъзможността за интегриране директно в уеб приложението. Затова проведохме всякакви експерименти.

Всъщност нашите изисквания за видео комуникация бяха приблизително следните:
— стабилност;
— ниска цена на урок;
— запис на уроци;
— проследяване кой колко говори (за нас е важно учениците да говорят повече от учителя по време на уроците);
— линейно мащабиране;
- възможност за използване на UDP и TCP.

Първият опит беше внедряването на Tokbox през 2013 г. Всичко беше добре, но се оказа много скъпо - 113 рубли на урок - и изяде печалбата.

След това през 2015 г. Voximplant беше интегриран. Тук беше функцията, от която се нуждаехме, за да проследим кой колко говори и в същото време решението беше много по-евтино: ако се записваше само аудио, струваше 20 рубли на урок. Той обаче работеше само чрез UDP и не можеше да превключи към TCP. Въпреки това около 40% от учениците в крайна сметка го използват.

Година по-късно започнахме да имаме корпоративни клиенти със свои специфични изисквания. Например, всичко трябва да работи през браузър, компанията отваря само http и https; т.е. без Skype или UDP. Корпоративни клиенти = пари, така че те се върнаха към Tokbox, но проблемът с цената не изчезна.

Решение - WebRTC и Janus

Реших да използвам браузърна платформа за peer-to-peer видео комуникация WebRTC. Той отговаря за установяване на връзка, кодиране и декодиране на потоци, синхронизиране на песни и контрол на качеството с обработка на мрежови проблеми. От наша страна трябва да осигурим четене на потоци от камерата и микрофона, рисуване на видео, управление на връзката, установяване на WebRTC връзка и предаване на потоци към нея, както и предаване на сигнални съобщения между клиенти за установяване на връзка (самият WebRTC описва само формат на данните, но не и неговия механизъм за прехвърляне). Ако клиентите са зад NAT, WebRTC свързва STUN сървъри; ако това не помогне, TURN сървъри.

Редовната p2p връзка не е достатъчна за нас, защото искаме да записваме уроци за допълнителен анализ в случай на оплаквания. Затова изпращаме WebRTC потоци чрез реле Janus Gateway от Meetecho. В резултат на това клиентите не знаят адресите на другия, виждайки само адреса на сървъра на Janus; изпълнява и функциите на сигнален сървър. Janus има много от функциите, от които се нуждаем: автоматично превключва към TCP, ако клиентът има блокиран UDP; може да записва както UDP, така и TCP потоци; мащабируем; Има дори вграден плъгин за ехо тестове. Ако е необходимо, сървърите STUN и TURN от Twilio се свързват автоматично.

Лятото на 2017 г. имахме работещи два Janus сървъра, плюс допълнителен сървър за обработка на записани raw аудио и видео файлове, за да не заемат процесорите на основните. При свързване сървърите на Janus бяха избрани на база четно-нечетно (номер на връзката). По това време това беше достатъчно, според нашите чувства, това даде приблизително четирикратен запас на безопасност, процентът на внедряване беше около 80. В същото време цената беше намалена до ~2 рубли на урок, плюс развитие и поддръжка.

Връщайки се към темата за видео комуникацията

Ние непрекъснато следим обратната връзка от ученици и преподаватели, за да идентифицираме и коригираме проблемите своевременно. До лятото на 2018 г. качеството на разговорите беше твърдо на първо място сред оплакванията. От една страна, това означаваше, че успешно сме преодолели други недостатъци. От друга страна, беше необходимо да се направи нещо спешно: ако урокът бъде прекъснат, рискуваме да загубим стойността му, понякога заедно с разходите за закупуване на следващия пакет, а ако уводният урок бъде прекъснат, рискуваме да загубим потенциален клиент като цяло.

По това време нашата видео комуникация все още беше в режим MVP. Казано по-просто, стартираха го, проработи, мащабираха го веднъж, разбраха как да го направят - добре, страхотно. Ако работи, не го поправяйте. Никой съзнателно не се зае с въпроса за качеството на комуникацията. До август стана ясно, че това не може да продължи и стартирахме отделна посока, за да разберем какво не е наред с WebRTC и Janus.

На входа тази посока получи: MVP решение, без показатели, без цели, без процеси за подобрение, докато 7% от учителите се оплакват от качеството на комуникацията (нямаше данни и за учениците).

В ход е ново направление

Командата изглежда по следния начин:

• Ръководителят на отдела, който е и главен разработчик.
• QA помага при тестване на промените, търси нови начини за създаване на нестабилни комуникационни условия и съобщава за проблеми от първа линия.
• Анализаторът непрекъснато търси различни корелации в техническите данни, подобрява анализа на обратната връзка с потребителите и проверява резултатите от експериментите.
• Продуктовият мениджър помага с цялостното насочване и разпределението на ресурсите за експерименти.
• Втори разработчик често помага с програмирането и свързаните с него задачи.

Като начало създадохме сравнително надежден показател, който проследява промените в оценките на качеството на комуникацията (средно за дни, седмици, месеци). Тогава това бяха оценки от учители, по-късно към тях бяха добавени оценки от ученици. След това започнаха да изграждат хипотези за това какво работи погрешно, коригираха го и наблюдаваха промените в динамиката. Отидохме за ниско висящия плод: например заменихме кодека vp8 с vp9, производителността се подобри. Опитахме се да играем с настройките на Janus и да проведем други експерименти - в повечето случаи те не доведоха до нищо.

На втория етап се появи хипотеза: WebRTC е peer-to-peer решение, а ние използваме сървър в средата. Може би проблемът е тук? Започнахме да копаем и открихме най-значимото подобрение досега.

В този момент сървър от пула беше избран с помощта на доста глупав алгоритъм: всеки имаше собствено „тегло“, в зависимост от канала и мощността, и ние се опитахме да изпратим потребителя към този с най-голямо „тегло“, без обръщайки внимание на географското местоположение на потребителя. В резултат на това учител от Санкт Петербург може да комуникира с ученик от Сибир през Москва, а не чрез нашия сървър Janus в Санкт Петербург.

Алгоритъмът е преработен: сега, когато потребител отвори нашата платформа, ние събираме ping от него до всички сървъри, използващи Ajax. Когато установяваме връзка, избираме двойка пингове (учител-сървър и ученик-сървър) с най-малък размер. По-малко ping означава по-малко мрежово разстояние до сървъра; по-късото разстояние означава по-малка вероятност от загуба на пакети; Загубата на пакети е най-големият негативен фактор във видео комуникацията. Делът на негативизма е намалял наполовина за три месеца (за да бъдем честни, по това време са проведени други експерименти, но този почти със сигурност е имал най-голямо въздействие).

Наскоро открихме друго неочевидно, но очевидно важно нещо: вместо един мощен Janus сървър на дебел канал, по-добре е да имате два по-прости с по-тънка честотна лента. Това стана ясно, след като купихме мощни машини с надеждата да натъпчем колкото се може повече стаи (комуникационни сесии) в тях едновременно. Сървърите имат ограничение на честотната лента, което можем точно да преведем в броя на стаите - знаем колко могат да бъдат отворени, например при 300 Mbit/s. Веднага щом има твърде много отворени стаи на сървъра, спираме да го избираме за нови дейности, докато натоварването намалее. Идеята беше, като си купим мощна машина, да натоварим максимално канала към нея, така че в крайна сметка да е ограничен от процесора и паметта, а не от честотната лента. Но се оказа, че след известен брой отворени стаи (420), въпреки факта, че натоварването на процесора, паметта и диска все още е много далеч от границите, негативността започва да пристига в техническата поддръжка. Очевидно нещо се влошава вътре в Янус, може би там също има някои ограничения. Започнахме да експериментираме, намалихме лимита на честотната лента от 300 на 200 Mbit/s и проблемите изчезнаха. Сега купихме три нови сървъра наведнъж с ниски лимити и характеристики, смятаме, че това ще доведе до стабилно подобряване на качеството на комуникацията. Разбира се, не се опитахме да разберем какво се случва там; нашите патерици са всичко. В наша защита, нека кажем, че в този момент беше необходимо да се реши належащият проблем възможно най-бързо, а не да се направи красиво; освен това Janus за нас е черна кутия, написана на C, много е скъпо да се занимавате с нея.

Е, в процеса ние:

• актуализира всички зависимости, които могат да бъдат актуализирани, както на сървъра, така и на клиента (това също бяха експерименти, наблюдавахме резултатите);
• поправени са всички идентифицирани грешки, свързани с конкретни случаи, например, когато връзката е прекъсната и не е възстановена автоматично;
• Проведохме много срещи с компании, работещи в областта на видео комуникациите и запознати с нашите проблеми: стрийминг на игри, организиране на уебинари; опитахме всичко, което ни се стори полезно;
• Направи технически преглед на качеството на хардуера и комуникацията на учителите, от които идват най-много оплаквания.

Експериментите и последвалите промени позволиха да се намали недоволството от комуникацията сред учителите от 7,1% през януари 2018 г. на 2,5% през януари 2019 г.

Какво следва?

Стабилизирането на нашата платформа Vimbox е един от основните проекти на компанията за 2019 г. Имаме големи надежди, че ще успеем да запазим инерцията и повече да не виждаме видео комуникация в най-големите оплаквания. Ние разбираме, че значителна част от тези оплаквания са свързани със закъснения в компютрите на потребителите и интернет, но трябва да определим тази част и да разрешим останалите. Всичко останало е технически проблем, изглежда би трябвало да можем да се справим с него.

Основната трудност е, че не знаем до какво ниво всъщност е възможно да се подобри качеството. Намирането на този таван е основната задача. Затова бяха планирани два експеримента:

1. сравнете видео чрез Janus с обикновен p2p в бойни условия. Този експеримент вече е проведен, не е открита статистически значима разлика между нашето решение и p2p;
2. Нека предоставим (скъпи) услуги от компании, които печелят пари изключително от решения за видео комуникация, и сравнете количеството негативизъм от тях със съществуващото.

Тези два експеримента ще ни позволят да идентифицираме постижима цел и да се съсредоточим върху нея.

Освен това има редица задачи, които могат да се решават рутинно:

• Създаваме техническа метрика за качество на комуникацията вместо субективни прегледи;
• Правим по-подробни регистрационни файлове на сесиите, за да анализираме по-точно възникналите грешки, да разберем кога и къде точно са се случили и какви привидно несвързани събития са се случили в този момент;
• Изготвяме автоматичен тест за качество на връзката преди урока и също така даваме възможност на клиента да тества ръчно връзката, за да намали количеството негативизъм, причинен от неговия хардуер и канал;
• ще разработим и проведем повече тестове за натоварване на видео комуникациите при лоши условия, с променлива загуба на пакети и т.н.;
• променяме поведението на сървърите в случай на проблеми, за да увеличим толерантността към грешки;
• Ние ще предупредим потребителя, ако изобщо има нещо нередно с връзката му, както прави Skype, за да разбере, че проблемът е на негова страна.

От април направлението за видеокомуникации се превърна в пълноценен отделен проект в Skyeng, занимаващ се със собствен продукт, а не просто част от Vimbox. Това означава, че започваме да търсим хора на работа с видео на пълен работен ден. Е, както винаги Търсим много добри хора.

И, разбира се, продължаваме да общуваме активно с хора и компании, работещи с видео комуникации. Ако искате да обмените опит с нас, ще се радваме! Коментирайте, свържете се - ще отговорим на всеки.

Източник: www.habr.com