🥇От Skype до WebRTC: как организирахме видео връзката през уеб

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

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

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

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

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

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

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

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

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

Решението — WebRTC и Janus

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

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

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

Връщане към темата за видеовръзка

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

По това време видеовръзката ни все още беше в режим MVP. По-просто казано, пуснахме я, тя заработи, еднократно я мащабирахме, разбрахме какво трябва да правим – и това беше прекрасно. If it works, don’t fix it. Никой не се занимаваше целенасочено с въпроса за качеството на връзката. До август стана ясно, че така не може да продължава и ние стартирахме отделно направление, за да разберем какво не е наред с WebRTC и Janus.

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

Новото направление започва работа

Отборът изглежда така:

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

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

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

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

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

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

И в процеса ние:

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

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

Какво следва

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

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

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

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

Освен това, има редица задачи, които се решават в работен порядък:

създаваме техническа метрика за качеството на връзката вместо субективни отзиви;
правим по-подробни логове на сесиите, за да анализираме по-точно случващите се сривове, да разберем кога и къде точно са се случили, какви на пръв поглед несвързани събития са се състояли в този момент;
подготвяме автоматичен тест за качеството на връзката преди урока, а също така ще дадем възможност на клиента ръчно да тества връзката, за да намалим количеството негативно, произтичащо от неговия хардуер и канал;
разработим и ще правим повече тестове с натоварване на видеовръзката в лоши условия, с променлива загуба на пакети и т.н.;
променяме поведението на сървърите в случай на проблеми, за да увеличим отказоустойчивостта;
ще предупреждаваме потребителя, ако има нещо нередно с връзката, както прави и самият 'Скайп', за да разбере, че проблемът е от негова страна.

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

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

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