A videokommunikáció a tanár és diák közötti kommunikáció fő módja a Vimbox platformon. Nagyon régen feladtuk a Skype-ot, kipróbáltunk számos külső megoldást, és végül a WebRTC – Janus-gateway kombináció mellett döntöttünk. Egy ideig mindennel elégedettek voltunk, de továbbra is felbukkant néhány negatív oldal. Ennek eredményeként egy külön videó rendezés készült.
Megkértem Kirill Rogovoyt, az új irányzat vezetőjét, hogy beszéljen a Skyeng videokommunikációjának alakulásáról, a felfedezett problémákról, megoldásokról és mankókról, amelyeket végül használtunk. Reméljük, hogy a cikk hasznos lesz azoknak a cégeknek, amelyek saját maguk is készítenek videót webes alkalmazáson keresztül.
Egy kis történelem
2017 nyarán a Skyeng fejlesztési részlegének vezetője, Sergey Safonov a Backend Conf-on beszélt arról, hogyan „elhagytuk a Skype-ot és bevezettük a WebRTC-t”. Az érdeklődők a beszéd felvételét a címen tekinthetik meg (~45 perc), és itt röviden felvázolom a lényegét.
A Skyeng School számára a videokommunikáció mindig is a tanár-diák kommunikáció elsődleges módja volt. Eleinte a Skype-ot használták, de ez több okból is kategorikusan nem volt kielégítő, elsősorban a naplók hiánya és a webalkalmazásba való közvetlen integráció lehetetlensége miatt. Ezért mindenféle kísérletet végeztünk.
Valójában a videokommunikációra vonatkozó követelményeink hozzávetőlegesen a következők voltak:
— stabilitás;
– alacsony óradíj;
— órák felvétele;
— annak nyomon követése, hogy ki mennyit beszél (számunkra fontos, hogy a tanulók többet beszéljenek, mint a tanár az órákon);
— lineáris skálázás;
- UDP és TCP használatának képessége.
Az első próbálkozás a Tokbox bevezetése volt 2013-ban. Minden jó volt, de nagyon drágának bizonyult - leckénként 113 rubel -, és megette a profitot.
Aztán 2015-ben a Voximplant integrálásra került. Itt volt az a funkció, amelyre szükségünk volt, hogy nyomon kövessük, ki mennyit beszélt, ugyanakkor a megoldás sokkal olcsóbb volt: ha csak hangot rögzítettek, akkor 20 rubelbe került óránként. Azonban csak UDP-n keresztül működött, és nem tudott TCP-re váltani. A hallgatók körülbelül 40%-a azonban végül használta.
Egy évvel később céges ügyfeleink is voltak saját specifikus igényeikkel. Például mindennek böngészőn keresztül kell működnie, a cég csak a http és a https oldalt nyitja meg; azaz nincs Skype vagy UDP. Céges ügyfelek = pénz, így visszatértek a Tokboxhoz, de az ár probléma nem szűnt meg.
Megoldás - WebRTC és Janus
Úgy döntött, hogy használja . Feladata a kapcsolat létrehozása, a folyamok kódolása és dekódolása, a sávok szinkronizálása és a minőség-ellenőrzés a hálózati hibák kezelésével. A magunk részéről gondoskodnunk kell a kamerából és a mikrofonból érkező streamek leolvasásáról, videó rajzolásáról, kapcsolat kezeléséről, WebRTC kapcsolat létrehozásáról és streamek továbbításáról, valamint a kliensek közötti jelzőüzenetek továbbításáról a kapcsolat létrehozásához (maga a WebRTC csak a adatformátum, de nem annak átviteli mechanizmusa). Ha a kliensek NAT mögött állnak, a WebRTC összekapcsolja a STUN szervereket; ha ez nem segít, akkor a TURN szervereket.
A rendszeres p2p kapcsolat nekünk nem elég, mert szeretnénk leckéket rögzíteni további elemzésekhez, panaszok esetén. Ezért a WebRTC streameket közvetítőn keresztül küldjük . Ennek eredményeként a kliensek nem ismerik egymás címét, csak a Janus szerver címét látják; jelszerver funkcióit is ellátja. A Janus számos funkcióval rendelkezik, amire szükségünk van: automatikusan átvált TCP-re, ha a kliens UDP-t blokkolt; UDP és TCP adatfolyamokat is rögzíthet; méretezhető; Még egy beépített plugin is található a visszhangtesztekhez. Ha szükséges, a Twilio STUN és TURN szerverei automatikusan összekapcsolódnak.
2017 nyarán két Janus szerverünk működött, plusz egy további szerver a rögzített nyers audio és video fájlok feldolgozására, hogy ne foglalják le a fő processzorokat. Csatlakozáskor a Janus szerverek páratlan alapon (kapcsolati szám) lettek kiválasztva. Akkoriban ez bőven elég volt, érzéseink szerint megközelítőleg négyszeres biztonsági ráhagyást adott, a megvalósítási százalék kb. 80. Ezzel párhuzamosan lecsökkent az óra ~2 rubelre, plusz fejlesztés és támogatás.
Visszatérve a videokommunikáció témájához
Folyamatosan figyeljük a diákok és tanárok visszajelzéseit, hogy a problémákat időben felismerjük és kijavítsuk. 2018 nyarára a hívásminőség határozottan az első helyen állt a panaszok között. Ez egyrészt azt jelentette, hogy más hiányosságokat is sikeresen kezeltünk. Másrészt sürgősen tenni kellett valamit: ha az óra megszakad, értékvesztést kockáztatunk, esetenként a következő csomag vásárlási költségével együtt, ha pedig a bevezető óra megszakad, egy potenciális ügyfél elvesztését kockáztatjuk. teljesen.
Ekkor még MVP módban zajlott a videokommunikációnk. Egyszerűen fogalmazva, elindították, működött, egyszer átméretezték, megértették, hogyan kell csinálni - na, nagyszerű. Ha működik, ne javítsd. Senki nem foglalkozott szándékosan a kommunikáció minőségének kérdésével. Augusztusra világossá vált, hogy ez nem mehet tovább, és külön irányt indítottunk, hogy kitaláljuk, mi a baj a WebRTC-vel és a Janusszal.
A bemenetnél ez az irány kapott: MVP megoldást, se mérőszámot, se célt, se fejlesztési folyamatot, miközben a tanárok 7%-a panaszkodik a kommunikáció minőségére (a tanulókról sem volt adat).
Új irány van folyamatban
A parancs valahogy így néz ki:
- Az osztályvezető, aki egyben a fő fejlesztő is.
- A minőségbiztosítás segít tesztelni a változásokat, új utakat keres instabil kommunikációs feltételek megteremtésére, és a problémákat a frontvonalból jelenti.
- Az elemző folyamatosan keresi a különféle összefüggéseket a műszaki adatokban, javítja a felhasználói visszajelzések elemzését, ellenőrzi a kísérletek eredményeit.
- A termékmenedzser segít a kísérletek általános irányításában és az erőforrások elosztásában.
- Egy második fejlesztő gyakran segít a programozásban és a kapcsolódó feladatokban.
Először is beállítottunk egy viszonylag megbízható mérőszámot, amely nyomon követi a kommunikáció minőségi értékelésében bekövetkezett változásokat (napok, hetek, hónapok átlaga). Akkoriban ezek tanári osztályzatok voltak, később a diákok osztályzatait is hozzáadták hozzájuk. Aztán elkezdtek hipotéziseket építeni arról, hogy mi működik rosszul, kijavították, és megvizsgálták a dinamikában bekövetkezett változásokat. Az alacsonyan lógó gyümölcsre mentünk: például a vp8 kodeket vp9-re cseréltük, a teljesítmény javult. Megpróbáltunk játszani a Janus beállításokkal és más kísérleteket is végezni – a legtöbb esetben nem vezettek semmire.
A második szakaszban felmerült egy hipotézis: a WebRTC egy peer-to-peer megoldás, és mi egy szervert használunk a közepén. Talán itt van a probléma? Elkezdtünk ásni, és az eddigi legjelentősebb javulást találtuk.
Abban a pillanatban egy meglehetősen hülye algoritmussal kiválasztottak egy szervert a készletből: mindegyiknek megvolt a maga „súlya”, csatornától és teljesítménytől függően, és megpróbáltuk a felhasználót a legnagyobb „súllyal” rendelkezőhöz küldeni, anélkül, hogy figyelve a felhasználó földrajzi elhelyezkedését . Ennek eredményeként egy szentpétervári tanár Moszkván keresztül tudott kommunikálni egy szibériai diákkal, nem pedig a szentpétervári Janus szerverünkön keresztül.
Az algoritmust átdolgoztuk: most, amikor egy felhasználó megnyitja a platformunkat, pingeket gyűjtünk tőle az összes Ajaxot használó szerverre. A kapcsolat létesítésekor kiválasztunk egy ping-párt (tanár-szerver és diák-szerver), amelynek a legkisebb mennyisége. A kisebb ping kisebb hálózati távolságot jelent a szervertől; a rövidebb távolság a csomagok elvesztésének kisebb valószínűségét jelenti; A videokommunikáció legnagyobb negatív tényezője a csomagvesztés. A negativitás aránya a felére csökkent három hónap alatt (az igazat megvallva, más kísérleteket is végeztek ekkor, de szinte biztosan ez volt a legnagyobb hatással).
Nemrég felfedeztünk egy másik nem nyilvánvaló, de látszólag fontos dolgot: egy vastag csatornán egy erős Janus szerver helyett jobb, ha két egyszerűbb, vékonyabb sávszélességű. Ez azután vált világossá, hogy erős gépeket vásároltunk abban a reményben, hogy egyszerre minél több helyiséget (kommunikációs munkamenetet) zsúfolunk beléjük. A szervereknek van sávszélesség-korlátja, amit pontosan le tudunk fordítani a szobák számára – tudjuk, hogy mennyit lehet megnyitni például 300 Mbit/s-on. Amint túl sok szoba van nyitva egy szerveren, addig nem választjuk új tevékenységekhez, amíg a terhelés csökken. Az ötlet az volt, hogy miután vásároltunk egy erős gépet, maximálisan ráterheljük a csatornát, hogy végül a processzor és a memória korlátozza, és ne a sávszélesség. De kiderült, hogy bizonyos számú nyitott szoba után (420), annak ellenére, hogy a processzor, a memória és a lemez terhelése még mindig nagyon messze van a határoktól, a negativitás kezd megérkezni a technikai támogatáshoz. Januson belül láthatóan romlik valami, talán ott is vannak korlátozások. Elkezdtünk kísérletezni, 300-ról 200 Mbit/s-ra csökkentettük a sávszélesség-korlátot, és a problémák megszűntek. Most három új szervert vásároltunk egyszerre alacsony limitekkel és jellemzőkkel, úgy gondoljuk, hogy ez a kommunikáció minőségének stabil javulását eredményezi. Természetesen nem próbáltuk kitalálni, hogy mi történik ott, a mankóink minden. Védekezésünkre mondjuk azt, hogy abban a pillanatban a sürgető problémát a lehető leggyorsabban kellett megoldani, nem pedig szépen; ráadásul a Janus nekünk egy C-ben írt fekete doboz, nagyon drága bütykölni vele.
Nos, a folyamat során:
- frissítette az összes frissíthető függőséget, mind a szerveren, mind a kliensen (ezek is kísérletek voltak, figyeltük az eredményeket);
- kijavította az összes azonosított hibát, amely bizonyos esetekkel kapcsolatos, például amikor a kapcsolat megszakadt, és nem állt helyre automatikusan;
- Rengeteg találkozót tartottunk videokommunikációs területen dolgozó, problémáinkat ismerő cégekkel: streaming játékok, webináriumok szervezése; mindent kipróbáltunk, ami hasznosnak tűnt számunkra;
- Technikai felülvizsgálatot végzett a tanárok hardver- és kommunikációs minőségéről, akiktől a legtöbb panasz érkezett.
A kísérletek és az azt követő változtatások lehetővé tették a tanárok kommunikációjával kapcsolatos elégedetlenség csökkentését a 7,1. januári 2018%-ról 2,5. januári 2019%-ra.
Mi a következő
A Vimbox platform stabilizálása a cég egyik fő projektje 2019-ben. Nagyon reméljük, hogy sikerül fenntartani a lendületet, és többé nem látni a videokommunikációt a legfőbb panaszok között. Megértjük, hogy ezeknek a panaszoknak egy jelentős része a felhasználók számítógépének és internetének lemaradásaihoz kapcsolódik, de ezt a részt meg kell határoznunk, a többit pedig meg kell oldanunk. Minden más technikai probléma, úgy tűnik, meg kell birkózni vele.
A fő nehézség az, hogy nem tudjuk, hogy valójában milyen szintig lehet minőséget javítani. Ennek a plafonnak a megállapítása a fő feladat. Ezért két kísérletet terveztek:
- Hasonlítsa össze a Januson keresztüli videót a normál p2p-vel harci körülmények között. Ezt a kísérletet már elvégeztük, nem találtunk statisztikailag szignifikáns különbséget a mi megoldásunk és a p2p között;
- Szállítsunk (drága) szolgáltatásokat olyan cégektől, amelyek kizárólag videokommunikációs megoldásokon keresnek pénzt, és hasonlítsuk össze a belőlük származó negativitás mértékét a meglévővel.
Ez a két kísérlet lehetővé teszi számunkra, hogy azonosítsunk egy elérhető célt, és arra összpontosítsunk.
Ezen kívül számos rutinszerűen megoldható feladat van:
- A szubjektív vélemények helyett a kommunikáció minőségének technikai mérőszámát hozzuk létre;
- Részletesebb munkamenet-naplókat készítünk annak érdekében, hogy pontosabban elemezhessük a fellépő hibákat, megértsük, mikor és hol történtek pontosan, és milyen látszólag nem kapcsolódó események történtek abban a pillanatban;
- Az óra előtt automatikus kapcsolatminőségi tesztet készítünk, valamint lehetőséget adunk a kliensnek a kapcsolat manuális tesztelésére, hogy csökkentsük a hardvere és a csatornája által okozott negatívumot;
- több videokommunikációs terhelési tesztet fejlesztünk és végzünk rossz körülmények között, változó csomagveszteséggel stb.;
- probléma esetén megváltoztatjuk a szerverek viselkedését a hibatűrés növelése érdekében;
- A Skype-hoz hasonlóan figyelmeztetjük a felhasználót, ha valami probléma van a kapcsolatával, hogy megértse, hogy a probléma az ő oldalán van.
Április óta a videokommunikációs irány egy teljes értékű külön projektté vált a Skyengen belül, amely saját termékkel foglalkozik, nem csak a Vimbox részével. Ez azt jelenti, hogy elkezdünk embereket keresni . Nos, mint mindig .
És természetesen továbbra is aktívan kommunikálunk a videokommunikációval foglalkozó emberekkel és cégekkel. Ha tapasztalatot szeretne cserélni velünk, örömmel fogadjuk! Kommentelj, vedd fel velünk a kapcsolatot – mindenkinek válaszolunk.
Forrás: will.com