A cumunicazione video hè u modu principale di cumunicazione trà maestru è studiente nantu à a piattaforma Vimbox. Avemu rinunciatu à Skype assai tempu fà, pruvatu parechje suluzioni di terzu è, eventualmente, stallate nantu à a combinazione WebRTC - Janus-gateway. Per qualchì tempu eravamu cuntenti di tuttu, ma ancu parechji aspetti negativi cuntinuavanu à emerge. In u risultatu, una direzzione video separata hè stata creata.
Aghju dumandatu à Kirill Rogovoy, u capu di a nova direzzione, per parlà di l'evoluzione di a cumunicazione video in Skyeng, i prublemi scuperti, suluzioni è crutches chì avemu ultimamente utilizatu. Speremu chì l'articulu serà utile per l'imprese chì creanu ancu video per sè stessu attraversu una applicazione web.
Un pocu di storia
In l'estiu di u 2017, u capu di u sviluppu di Skyeng, Sergey Safonov, hà parlatu in Backend Conf cun una storia nantu à cumu avemu "abbandonatu Skype è implementatu WebRTC". Quelli chì sò interessati ponu vede a registrazione di u discorsu à (~ 45 min), è quì descriveraghju brevemente a so essenza.
Per Skyeng School, a cumunicazione video hè sempre stata un modu prioritariu di cumunicazione maestru-studiente. À u principiu, Skype hè stata utilizata, ma era categuricamente micca satisfacente per una quantità di ragioni, principalmente per a mancanza di logs è l'impossibilità di integrazione direttamente in l'applicazione web. Dunque, avemu realizatu ogni tipu di esperimenti.
In realtà, i nostri bisogni per a cumunicazione video eranu circa i seguenti:
- stabilità;
- prezzu bassu per lezzione;
- arregistramentu di lezioni;
— traccia di quale parla quantu (hè impurtante per noi chì i studienti parranu più di u maestru durante e lezioni);
- scala lineale;
- capacità di utilizà tramindui UDP è TCP.
U primu à pruvà era di implementà Tokbox in 2013. Tuttu era bonu, ma hè statu assai caru - 113 rubles per lezzione - è manghjatu u prufittu.
Allora in 2015, Voximplant hè stata integrata. Eccu a funzione chì avemu bisognu di seguità quale hà parlatu quantu, è à u stessu tempu a suluzione era assai più prezzu: se solu l'audio era arregistratu, costava 20 rubles per lezione. Tuttavia, hà travagliatu solu via UDP è ùn pudia micca cambià à TCP. Tuttavia, circa 40% di i studienti anu finitu per aduprà.
Un annu dopu, avemu cuminciatu à avè clienti corporativi cù i so bisogni specifichi. Per esempiu, tuttu deve travaglià attraversu un navigatore, a cumpagnia apre solu http è https; vale à dì senza Skype o UDP. Clienti di l'imprese = soldi, cusì tornanu à Tokbox, ma u prublema di u prezzu ùn hè micca andatu.
Soluzione - WebRTC è Janus
Decisi à aduprà . Hè rispunsevuli di stabilisce una cunnessione, di codificazione è di decodificazione di flussi, di sincronizazione di piste è di cuntrollu di qualità cù a gestione di glitches di rete. Per a nostra parte, avemu da assicurà a lettura di flussi da a camera è u microfonu, disegnu video, gestione di a cunnessione, stabilisce una cunnessione WebRTC è trasmette flussi à questu, è ancu trasmette missaghji di signalazione trà i clienti per stabilisce una cunnessione (WebRTC stessu descrive solu u formatu di dati, ma micca u so trasferimentu di mecanismu). Se i clienti sò daretu à NAT, WebRTC cunnetta i servitori STUN; se questu ùn aiuta micca, i servitori TURN.
Una cunnessione p2p regulare ùn hè micca abbastanza per noi, perchè vulemu registrà lezioni per più analisi in casu di lagnanza. Dunque mandemu flussi WebRTC attraversu un relay . In u risultatu, i clienti ùn cunnosci micca l'indirizzi di l'altri, videndu solu l'indirizzu di u servitore Janus; svolge ancu e funzioni di un servitore di signali. Janus hà parechje di e funziunalità chì avemu bisognu: automaticamente cambia à TCP se u cliente hà UDP bluccatu; pò arregistrà i flussi UDP è TCP; scalabile; Ci hè ancu un plugin integratu per e teste di eco. Se necessariu, i servitori STUN è TURN da Twilio sò cunnessi automaticamente.
In l'estiu di u 2017, avemu avutu dui servitori Janus in esecuzione, più un servitore supplementu per processà i fugliali audio è video prima registrati, per ùn occupà i prucessori di i principali. Quandu si cunnetta, i servitori Janus sò stati scelti nantu à una basa imparu (numeru di cunnessione). À quellu tempu, questu era abbastanza, secondu i nostri sentimenti, hà datu circa un quadru di marghjini di salvezza, u percentualità di implementazione era di circa 80. À u stessu tempu, u prezzu hè stata ridutta à ~ 2 rubles per lezzione, più u sviluppu è u sustegnu.
Riturnà à u tema di a cumunicazione video
Monitoremu constantemente i feedback da i studienti è i prufessori per identificà è curregge i prublemi in modu puntuale. À l'estiu di 2018, a qualità di a chjama era fermamente in u primu locu trà e lagnanza. Da una banda, questu significava chì avemu avutu successu à superà altre carenze. Per d 'altra banda, era necessariu di fà qualcosa d'urgenza: se a lezziò hè disturbata, risichemu di perde u so valore, qualchì volta cù u costu di l'acquistu di u prossimu pacchettu, è se a lezione introduttiva hè disturbata, risichemu di perde un cliente potenziale. in tuttu.
À quellu tempu, a nostra cumunicazione video era sempre in modu MVP. Bastamente, l'anu lanciatu, hà travagliatu, anu scalatu una volta, anu capitu cumu fà - bè, grande. S'ellu funziona, ùn risolve micca. Nimu hà trattatu deliberatamente u prublema di a qualità di a cumunicazione. À Aostu, hè diventatu chjaru chì questu ùn puderia micca cuntinuà, è avemu lanciatu una direzzione separata per capisce ciò chì era sbagliatu cù WebRTC è Janus.
À l'input, sta direzzione hà ricivutu: una suluzione MVP, senza metrica, senza scopi, senza prucessi per migliurà, mentre chì 7% di i prufessori si lamentanu di a qualità di a cumunicazione (ùn ci era ancu micca dati nantu à i studienti).
Una nova direzzione hè in corso
U cumandimu s'assumiglia à questu:
- U capu di u dipartimentu, chì hè ancu u sviluppatore principale.
- QA aiuta à pruvà i cambiamenti, cerca novi modi per creà cundizioni di cumunicazione instabili, è raporta prublemi da a prima linea.
- L'analista cerca constantemente diverse correlazioni in dati tecnichi, migliurà l'analisi di feedback di l'utilizatori, è cuntrolla i risultati di l'esperimenti.
- U capu di produttu aiuta cù a direzzione generale è l'attribuzione di risorse per l'esperimenti.
- Un secondu sviluppatore spessu aiuta cù a prugrammazione è i travaglii cunnessi.
Per principià, avemu stabilitu una metrica relativamente affidabile chì tracciava i cambiamenti in e valutazioni di qualità di a cumunicazione (media annantu à ghjorni, settimane, mesi). À quellu tempu, questi sò stati qualificazioni da i prufessori; i gradi più tardi da i studienti sò stati aghjuntu à elli. Allora cuminciaru à custruisce ipotesi nantu à ciò chì travagliava male, curreghja, è fighjate i cambiamenti in a dinamica. Andemu per u fruttu bassu: per esempiu, avemu rimpiazzatu u codec vp8 cù vp9, u rendiment hà migliuratu. Avemu pruvatu à ghjucà cù i paràmetri di Janus è fà altre esperimenti - in a maiò parte di i casi ùn anu purtatu à nunda.
À a seconda tappa, una ipotesi emerse: WebRTC hè una suluzione peer-to-peer, è usemu un servitore à mezu. Forse u prublema hè quì? Avemu cuminciatu à scavà è truvamu a migliione più significativa finu à avà.
À quellu mumentu, un servitore da a piscina hè statu sceltu cù un algoritmu piuttostu stupidu: ognunu avia u so propiu "pesu", secondu u canali è u putere, è avemu pruvatu à mandà l'utilizatore à quellu cù u "pesu" più grande, senza. fendu attenzione à induve l'utilizatore era situatu geograficamente. In u risultatu, un maestru di San Petruburgu puderia cumunicà cù un studiente da Siberia attraversu Mosca, è micca per mezu di u nostru servitore Janus in San Pietroburgo.
L'algoritmu hè statu rifattu: avà, quandu un utilizatore apre a nostra piattaforma, cullemu pings da ellu à tutti i servitori chì utilizanu Ajax. Quandu stabilisce una cunnessione, selezziunate un paru di pings (professore-servitore è studiente-servitore) cù a quantità più chjuca. Meno ping significa menu distanza di rete à u servitore; distanza più corta significa una probabilità più bassa di perde i pacchetti; A perdita di pacchetti hè u più grande fattore negativu in a cumunicazione video. A parte di negatività hè cascata da a mità in trè mesi (per esse ghjustu, altri esperimenti sò stati realizati à questu tempu, ma questu quasi certamenti hà avutu u più impattu).
Avemu scupertu pocu pocu un altru cosa micca ovvi, ma apparentemente impurtante: invece di un servitore Janus putente nantu à un canale grossu, hè megliu avè dui più simplici cù una larghezza di banda più fina. Questu hè diventatu chjaru dopu avè compru macchine putenti in a speranza di cramming quant'è stanze (sessioni di cumunicazione) in elli à u stessu tempu. I servitori anu un limitu di larghezza di banda, chì pudemu traduce cù precisione in u numeru di stanze - sapemu quantu ponu esse apertu, per esempiu, à 300 Mbit/s. Appena ci sò troppu stanze aperte nantu à un servitore, cessemu di sceglie per novi attività finu à chì a carica diminuisce. L'idea era chì, dopu avè compru una macchina putente, avemu carricà u canali à u massimu, perchè à a fine serà limitatu da u processatore è a memoria, è micca da a larghezza di banda. Ma si girò chì dopu à un certu nùmeru di stanze aperte (420), malgradu u fattu chì a carica nantu à u processatore, a memoria è u discu hè sempre assai luntanu da i limiti, a negatività cumencia à ghjunghje à u supportu tecnicu. Apparentemente, qualcosa s'aggrava in Janus, forse ci sò ancu alcune restrizioni. Avemu cuminciatu à sperimentà, hà abbassatu u limitu di larghezza di banda da 300 à 200 Mbit/s, è i prublemi sò andati. Avà avemu compru trè servitori novi à una volta cù limiti bassi è caratteristiche, pensemu chì questu hà da purtà à una mellura stabile in a qualità di cumunicazione. Di sicuru, ùn avemu micca pruvatu à capisce ciò chì passava quì; i nostri crutches sò tuttu. In a nostra difesa, dicemu chì in quellu mumentu era necessariu di risolve u prublema pressante u più prestu pussibule, è micca di fà bè; in più, Janus per noi hè una scatula negra scritta in C, hè assai caru per tinker cun ella.
Ebbè, in u prucessu avemu:
- aghjurnatu tutte e dependenzii chì puderanu esse aghjurnati, in u servitore è in u cliente (questi eranu ancu esperimenti, avemu monitoratu i risultati);
- riparatu tutti i bugs identificati ligati à casi specifichi, per esempiu, quandu a cunnessione hè cascata è ùn hè micca restaurata automaticamente;
- Avemu fattu assai scontri cù cumpagnie chì travaglianu in u campu di a cumunicazione video è familiarizati cù i nostri prublemi: streaming games, urganizazione di webinars; avemu pruvatu tuttu ciò chì ci paria utile;
- Cunduce una rivista tecnica di u hardware è a qualità di cumunicazione di i prufessori, da quale venenu a maiò parte di lagnanza.
L'esperimenti è i cambiamenti successivi anu permessu di riduce l'insatisfazione cù a cumunicazione trà i prufessori da 7,1% in ghjennaghju 2018 à 2,5% in ghjennaghju 2019.
Chì vene
Stabilizà a nostra piattaforma Vimbox hè unu di i prughjetti principali di a cumpagnia per 2019. Avemu grandi speranze chì puderemu mantene l'impulsu è ùn vede più a cumunicazione video in i primi lagnanze. Avemu capitu chì una parte significativa di sti lagnanza sò ligati à i lags in l'urdinatori di l'utilizatori è in Internet, ma duvemu determinà sta parte è risolve u restu. Tuttu u restu hè un prublema tecnicu, pare chì duvemu esse capace di affruntà.
A difficultà principale hè chì ùn sapemu à quale livellu hè veramente pussibule di migliurà a qualità. Truvà stu tettu hè u compitu principale. Dunque, dui esperimenti sò stati pianificati:
- paragunate video via Janus cù p2p regulare in cundizioni di cummattimentu. Stu esperimentu hè digià statu realizatu, nisuna differenza statisticamente significativa hè stata truvata trà a nostra suluzione è p2p;
- Fornisciamu servizii (caru) da cumpagnie chì guadagnanu soldi solu solu in suluzioni di cumunicazione video, è paragunate a quantità di negatività da elli cù l'esistente.
Sti dui esperimenti ci permetteranu di identificà un scopu realisable è di fucalizza nantu à questu.
Inoltre, ci sò parechje attività chì ponu esse risolte in rutina:
- Creemu una metrica tecnica di qualità di cumunicazione invece di recensioni subjective;
- Facemu logs di sessione più detallati per analizà più accuratamente i fallimenti chì si verificanu, capiscenu quandu è induve esattamente sò accaduti, è ciò chì l'avvenimenti apparentemente senza relazione sò accaduti in quellu mumentu;
- Preparemu una prova di qualità di cunnessione automatica prima di a lezzione, è dà ancu à u cliente l'uppurtunità di pruvà manualmente a cunnessione per riduce a quantità di negatività causata da u so hardware è u canali;
- avemu da sviluppà è cunducerà più teste di carica di cumunicazione video in cundizioni poveri, cù perdita di pacchettu variabile, etc.;
- cambiamu u cumpurtamentu di i servitori in casu di prublemi per aumentà a toleranza di difetti;
- Avvertiremu l'utilizatore s'ellu ci hè qualcosa di sbagliatu cù a so cunnessione in tuttu, cum'è Skype, perchè ellu capisce chì u prublema hè da u so latu.
Dapoi aprile, a direzzione di cumunicazione video hè diventata un prughjettu separatu cumpletu in Skyeng, chì tratta di u so propiu pruduttu, micca solu una parte di Vimbox. Questu significa chì avemu principiatu à circà e persone . Ebbè, cum'è sempre .
E, sicuru, cuntinuemu à cumunicà attivamente cù e persone è l'imprese chì travaglianu cù cumunicazioni video. Sè vo vulete scambià spirienza cun noi, seremu felici! Cumentu, cuntattate - risponderemu à tutti.
Source: www.habr.com