Videosuhtlus on peamine suhtlusviis õpetaja ja õpilase vahel Vimboxi platvormil. Loobusime Skype’ist juba ammu, proovisime mitmeid kolmandate osapoolte lahendusi ja otsustasime lõpuks WebRTC – Januse-lüüsi kombinatsiooni kasuks. Mõnda aega olime kõigega rahul, kuid siiski tekkisid mõned negatiivsed aspektid. Selle tulemusena loodi eraldi videosuund.
Palusin uue suuna juhil Kirill Rogovoyl rääkida videokommunikatsiooni arengust Skyengis, avastatud probleemidest, lahendustest ja karkudest, mida lõpuks kasutasime. Loodame, et artikkel on kasulik ettevõtetele, kes loovad ka ise videoid veebirakenduse kaudu.
Veidi ajalugu
2017. aasta suvel rääkis Skyengi arendusjuht Sergey Safonov Backend Confis looga sellest, kuidas me "jätsime Skype'i ja rakendasime WebRTC". Huvilised saavad kõne salvestust vaadata kl (~45 min) ja siin kirjeldan lühidalt selle olemust.
Skyengi kooli jaoks on videosuhtlus alati olnud õpetaja ja õpilase suhtluse prioriteetne viis. Alguses kasutati Skype'i, kuid see ei olnud kategooriliselt rahuldav mitmel põhjusel, eelkõige logide puudumise ja otse veebirakendusse integreerimise võimatuse tõttu. Seetõttu tegime kõikvõimalikke katseid.
Tegelikult olid meie nõuded videosuhtlusele umbes järgmised:
— stabiilsus;
- madal hind tunni kohta;
— tundide salvestamine;
— jälgimine, kes kui palju räägib (meie jaoks on oluline, et õpilased räägiksid tundides rohkem kui õpetaja);
— lineaarne skaleerimine;
- võimalus kasutada nii UDP-d kui ka TCP-d.
Esimesena proovis Tokboxi juurutada 2013. aastal. Kõik oli hea, kuid see osutus väga kalliks - 113 rubla õppetund - ja sõi kasumi ära.
Seejärel 2015. aastal integreeriti Voximplant. Siin oli funktsioon, mida vajasime, et jälgida, kes kui palju rääkis, ja samas oli lahendus palju odavam: kui salvestati ainult heli, maksis see 20 rubla õppetund. Kuid see töötas ainult UDP kaudu ja ei saanud TCP-le lülituda. Siiski kasutas seda umbes 40% õpilastest.
Aasta hiljem hakkasid meil olema ärikliendid, kellel on oma spetsiifilised nõudmised. Näiteks peaks kõik toimima läbi brauseri, ettevõte avab ainult http ja https; st pole Skype'i ega UDP-d. Ärikliendid = raha, seega naasid nad Tokboxi, kuid hinnaprobleem ei kadunud kuhugi.
Lahendus – WebRTC ja Janus
Otsustati kasutada . See vastutab ühenduse loomise, voogude kodeerimise ja dekodeerimise, radade sünkroonimise ja kvaliteedikontrolli eest koos võrgutõrgetega. Peame omalt poolt tagama voogude lugemise kaamerast ja mikrofonist, video joonistamise, ühenduse haldamise, WebRTC ühenduse loomise ja sellele voogude edastamise, samuti signaalisõnumite edastamise klientide vahel ühenduse loomiseks (WebRTC ise kirjeldab ainult andmevorming, kuid mitte selle edastusmehhanism). Kui kliendid on NAT-i taga, ühendab WebRTC STUN-serverid; kui see ei aita, siis TURN-serverid.
Tavalisest p2p ühendusest meile ei piisa, sest soovime kaebuste korral tunde edasiseks analüüsiks salvestada. Seetõttu saadame WebRTC vooge relee kaudu . Selle tulemusena ei tea kliendid üksteise aadresse, näevad ainult Januse serveri aadressi; see täidab ka signaaliserveri funktsioone. Janusel on palju vajalikke funktsioone: lülitub automaatselt üle TCP-le, kui kliendil on UDP blokeeritud; suudab salvestada nii UDP- kui ka TCP-vooge; skaleeritav; Kajatestide jaoks on isegi sisseehitatud pistikprogramm. Vajadusel ühendatakse automaatselt Twilio serverid STUN ja TURN.
2017. aasta suvel töötas meil kaks Januse serverit ning lisaks veel üks server salvestatud toorheli- ja videofailide töötlemiseks, et mitte hõivata põhiliste protsessoreid. Ühenduse loomisel valiti Januse serverid paaritu-paaris põhimõttel (ühenduse number). Tookord sellest piisas, meie tunnete järgi andis see ligikaudu neljakordse turvavaru, teostusprotsent oli ca 80. Samal ajal langes hind ~2 rublale tunni kohta pluss arendus ja tugi.
Tulles tagasi videokommunikatsiooni teema juurde
Jälgime pidevalt õpilaste ja õpetajate tagasisidet, et probleemid õigel ajal tuvastada ja parandada. 2018. aasta suveks oli kõnekvaliteet kaebuste hulgas kindlalt esikohal. Ühest küljest tähendas see, et saime edukalt üle ka muudest puudujääkidest. Teisest küljest oli vaja midagi kiiremas korras ette võtta: kui õppetund jääb katki, siis riskime kaotada selle väärtus, mõnikord koos järgmise paketi ostmise kuluga, ja kui sissejuhatav tund on häiritud, siis riskime potentsiaalse kliendi kaotamisega. üldse.
Sel ajal oli meie videosuhtlus veel MVP režiimis. Lihtsamalt öeldes käivitasid nad selle, see töötas, nad suurendasid seda üks kord, nad said aru, kuidas seda teha – hästi, suurepärane. Kui see töötab, ärge seda parandage. Keegi ei käsitlenud teadlikult suhtluskvaliteedi küsimust. Augustiks sai selgeks, et nii edasi minna ei saa ning käivitasime eraldi suuna, et välja selgitada, mis WebRTC-l ja Janusel viga on.
Sisendil sai see suund: MVP lahendus, ei mõõdikuid, eesmärke, parendusprotsesse pole, samas kui 7% õpetajatest kurdab suhtluskvaliteedi üle (andmed ka õpilaste kohta puudusid).
Uus suund on käimas
Käsk näeb välja umbes selline:
- Osakonnajuhataja, kes on ühtlasi ka põhiarendaja.
- QA aitab muudatusi testida, otsib uusi viise ebastabiilsete sidetingimuste loomiseks ja teavitab probleemidest eesliinil.
- Analüütik otsib pidevalt tehnilistes andmetes erinevaid seoseid, täiustab kasutajate tagasiside analüüsi, kontrollib katsete tulemusi.
- Tootejuht aitab katsete üldise suuna ja ressursside eraldamisega.
- Teine arendaja aitab sageli programmeerimise ja sellega seotud ülesannete täitmisel.
Alustuseks seadsime paika suhteliselt usaldusväärse mõõdiku, mis jälgis kommunikatsioonikvaliteedi hinnangute muutusi (päevade, nädalate, kuude keskmine). Tol ajal olid need õpetajate hinded, hiljem lisati neile õpilaste hinded. Seejärel hakkasid nad püstitama hüpoteese selle kohta, mis valesti töötas, seda parandama ja dünaamika muutusi vaatama. Läksime madalalt rippuva puuvilja poole: näiteks asendasime vp8 koodeki vp9 vastu, jõudlus paranes. Proovisime mängida Januse seadetega ja teha muid katseid – enamasti ei viinud need millegini.
Teises etapis tekkis hüpotees: WebRTC on peer-to-peer lahendus ja selle keskel kasutame serverit. Võib-olla peitub probleem siin? Alustasime kaevamist ja leidsime seni kõige olulisema paranduse.
Sel hetkel valiti basseinist server üsna rumala algoritmi abil: igaühel oli oma "kaal", olenevalt kanalist ja võimsusest ning proovisime saata kasutaja suurima "kaaluga" ilma. pöörates tähelepanu kasutaja geograafilisele asukohale . Tänu sellele sai Peterburist pärit õpetaja Siberist pärit õpilasega suhelda Moskva kaudu, mitte meie Peterburi Januse serveri kaudu.
Algoritm on ümber tehtud: nüüd, kui kasutaja meie platvormi avab, kogume temalt pingid kõikidesse Ajaxi kasutavatesse serveritesse. Ühenduse loomisel valime väikseima summaga pingipaari (õpetaja-server ja õpilane-server). Vähem ping tähendab väiksemat võrgu kaugust serverist; lühem vahemaa tähendab väiksemat tõenäosust pakettide kaotamiseks; Pakettide kadu on videokommunikatsiooni suurim negatiivne tegur. Negatiivsuse osakaal langes kolme kuuga poole võrra (ausalt öeldes tehti sel ajal ka teisi katseid, kuid sellel oli peaaegu kindlasti kõige suurem mõju).
Hiljuti avastasime veel ühe mitteilmse, kuid pealtnäha olulise asja: ühe võimsa Januse serveri asemel paksul kanalil on parem kaks lihtsamat, väiksema ribalaiusega. See sai selgeks pärast seda, kui ostsime võimsad masinad lootuses neisse korraga nii palju ruume (kommunikatsiooniseansse) toppida. Serveritel on ribalaiuse limiit, mille saame täpselt ümber tõlkida ruumide arvuks – me teame, kui palju saab avada näiteks kiirusel 300 Mbit/s. Niipea kui serveris on liiga palju ruume avatud, lõpetame selle valimise uuteks tegevusteks kuni koormuse vähenemiseni. Idee seisnes selles, et olles ostnud võimsa masina, laadime kanali sinna maksimaalselt, nii et lõpuks piiraks seda protsessor ja mälu, mitte ribalaius. Kuid selgus, et pärast teatud arvu avatud ruume (420), vaatamata sellele, et protsessori, mälu ja ketta koormus on endiselt piiridest väga kaugel, hakkab tehnilise toe poole jõudma negatiivsus. Ilmselt läheb Januse sees midagi hullemaks, ehk on sealgi mingid piirangud. Hakkasime katsetama, alandasime ribalaiuse piirangut 300-lt 200 Mbit/s peale ja probleemid kadusid. Nüüd ostsime kolm uut serverit korraga, madalate limiitide ja omadustega, arvame, et see toob kaasa sidekvaliteedi stabiilse paranemise. Muidugi ei püüdnud me aru saada, mis seal toimub; meie kargud on kõik. Ütleme oma kaitseks, et tol hetkel oli vaja pakiline probleem võimalikult kiiresti lahendada, mitte ilusti teha; pealegi on Janus meie jaoks must kast C-ga kirjutatud, sellega on väga kallis nokitseda.
Noh, selle käigus me:
- uuendatud kõik sõltuvused, mida sai uuendada, nii serveris kui ka kliendis (need olid ka katsetused, jälgisime tulemusi);
- parandas kõik tuvastatud vead, mis on seotud konkreetsete juhtumitega, näiteks kui ühendus katkes ja seda ei taastatud automaatselt;
- Pidasime palju kohtumisi videokommunikatsiooni valdkonnas tegutsevate ja meie probleemidega kursis olevate ettevõtetega: mängude striimimine, veebiseminaride korraldamine; proovisime kõike, mis meile kasulik tundus;
- Viis läbi õpetajate riistvara ja suhtluskvaliteedi tehnilise ülevaatuse, kellelt tuli enim kaebusi.
Katsed ja hilisemad muudatused võimaldasid vähendada rahulolematust õpetajate suhtlemisega 7,1. aasta jaanuari 2018%-lt 2,5. aasta jaanuaris 2019%-le.
mis edasi
Meie Vimboxi platvormi stabiliseerimine on üks ettevõtte 2019. aasta põhiprojekte. Meil on suured lootused, et suudame hoogu hoida ja videosuhtlust enam tippkaebustes ei näe. Mõistame, et märkimisväärne osa neist kaebustest on seotud kasutajate arvutite ja Interneti viivitusega, kuid me peame selle osa kindlaks määrama ja ülejäänud lahendama. Kõik muu on tehniline probleem, tundub, et peaksime sellega toime tulema.
Peamine raskus seisneb selles, et me ei tea, millisele tasemele on tegelikult võimalik kvaliteeti parandada. Selle ülemmäära väljaselgitamine on peamine ülesanne. Seetõttu kavandati kaks katset:
- võrrelda videot Januse kaudu tavalise p2p-ga lahingutingimustes. See katse on juba läbi viidud, meie lahenduse ja p2p vahel statistiliselt olulist erinevust ei leitud;
- Pakkugem (kalleid) teenuseid ettevõtetelt, kes teenivad raha ainult videosidelahenduste pealt, ja võrdleme nende negatiivsuse hulka olemasolevaga.
Need kaks katset võimaldavad meil tuvastada saavutatava eesmärgi ja sellele keskenduda.
Lisaks on mitmeid ülesandeid, mida saab rutiinselt lahendada:
- Loome subjektiivsete arvustuste asemel suhtluskvaliteedi tehnilise mõõdiku;
- Teeme täpsemaid sessiooniloge, et täpsemalt analüüsida esinevaid tõrkeid, aru saada, millal ja kus need täpselt tekkisid ning millised pealtnäha mitteseotud sündmused sel hetkel toimusid;
- Valmistame enne õppetundi ette automaatse ühenduse kvaliteedi testi, samuti anname kliendile võimaluse ühendust käsitsi testida, et vähendada tema riistvarast ja kanalist põhjustatud negatiivsust;
- töötame välja ja viime läbi rohkem videoside koormusteste kehvades tingimustes, muutuva pakettkaoga jne;
- muudame probleemide korral serverite käitumist, et tõsta tõrketaluvust;
- Hoiatame kasutajat, kui tema ühendusega on üldse midagi valesti, nagu teeb Skype, et ta mõistaks, et probleem on tema poolel.
Alates aprillist on videosuhtlussuunast saanud Skyengis täieõiguslik eraldiseisev projekt, mis tegeleb oma tootega, mitte ainult Vimboxi osaga. See tähendab, et hakkame inimesi otsima . No nagu alati .
Ja loomulikult jätkame aktiivset suhtlemist videokommunikatsiooniga tegelevate inimeste ja ettevõtetega. Kui soovid meiega kogemusi vahetada, siis oleme rõõmsad! Kommenteerige, võtke ühendust – vastame kõigile.
Allikas: www.habr.com