Videokommunikasjon er hovedmåten for kommunikasjon mellom lærer og elev på Vimbox-plattformen. Vi ga opp Skype for lenge siden, prøvde flere tredjepartsløsninger og slo oss til slutt på WebRTC - Janus-gateway-kombinasjonen. En stund var vi fornøyde med alt, men fortsatt dukket det opp noen negative sider. Som et resultat ble det opprettet en egen videoretning.
Jeg spurte Kirill Rogovoy, lederen for den nye retningen, om å snakke om utviklingen av videokommunikasjon på Skyeng, problemene som ble oppdaget, løsninger og krykker som vi til slutt brukte. Vi håper artikkelen vil være nyttig for bedrifter som også lager video på egenhånd gjennom en nettapplikasjon.
En bit av historien
Sommeren 2017 snakket sjefen for Skyeng-utvikling, Sergey Safonov, på Backend Conf med en historie om hvordan vi "forlot Skype og implementerte WebRTC." Interesserte kan se opptak av talen kl (~45 min), og her vil jeg kort skissere essensen.
For Skyeng skole har videokommunikasjon alltid vært en prioritert måte for lærer-elev kommunikasjon. Til å begynne med ble Skype brukt, men det var kategorisk ikke tilfredsstillende av en rekke årsaker, først og fremst på grunn av mangelen på logger og umuligheten av integrering direkte i nettapplikasjonen. Derfor utførte vi alle slags eksperimenter.
Faktisk var våre krav til videokommunikasjon omtrent følgende:
— stabilitet;
— lav pris per leksjon;
— ta opp leksjoner;
— sporing av hvem som snakker hvor mye (det er viktig for oss at elevene snakker mer enn læreren i timene);
— lineær skalering;
- evne til å bruke både UDP og TCP.
Den første som prøvde var å implementere Tokbox i 2013. Alt var bra, men det viste seg å være veldig dyrt - 113 rubler per leksjon - og spiste opp overskuddet.
Så i 2015 ble Voximplant integrert. Her var funksjonen vi trengte for å spore hvem som snakket hvor mye, og samtidig var løsningen mye billigere: Hvis bare lyd ble tatt opp, kostet det 20 rubler per leksjon. Den fungerte imidlertid bare via UDP og kunne ikke bytte til TCP. Imidlertid endte rundt 40 % av studentene opp med å bruke det.
Et år senere begynte vi å ha bedriftskunder med sine egne spesifikke krav. For eksempel skal alt fungere gjennom en nettleser, selskapet åpner kun http og https; dvs. ingen Skype eller UDP. Bedriftskunder = penger, så de returnerte til Tokbox, men problemet med pris forsvant ikke.
Løsning - WebRTC og Janus
Besluttet å bruke . Det er ansvarlig for å etablere en tilkobling, kode og dekode strømmer, synkronisere spor og kvalitetskontroll med håndtering av nettverksfeil. For vår del må vi sørge for å lese strømmer fra kamera og mikrofon, tegne video, administrere forbindelsen, etablere en WebRTC-forbindelse og overføre strømmer til den, samt sende signalmeldinger mellom klienter for å etablere en forbindelse (WebRTC selv beskriver kun dataformat, men ikke dets mekanismeoverføringer). Hvis klienter er bak NAT, kobler WebRTC til STUN-servere; hvis dette ikke hjelper, TURN-servere.
En vanlig p2p-tilkobling er ikke nok for oss, fordi vi ønsker å ta opp leksjoner for videre analyse i tilfelle klager. Derfor sender vi WebRTC-strømmer gjennom et relé . Som et resultat kjenner ikke klienter hverandres adresser, og ser bare Janus-serveradressen; den utfører også funksjonene til en signalserver. Janus har mange av funksjonene vi trenger: bytter automatisk til TCP hvis klienten har UDP blokkert; kan ta opp både UDP- og TCP-strømmer; skalerbar; Det er til og med en innebygd plugin for ekkotester. Ved behov kobles STUN- og TURN-servere fra Twilio automatisk til.
Sommeren 2017 hadde vi to Janus-servere i gang, pluss en ekstra server for å behandle innspilte rå lyd- og videofiler, for ikke å okkupere prosessorene til de viktigste. Ved tilkobling ble Janus-servere valgt på oddetallsbasis (tilkoblingsnummer). På den tiden var dette nok, ifølge våre følelser ga det omtrent en firedobbel sikkerhetsmargin, implementeringsprosenten var omtrent 80. Samtidig ble prisen redusert til ~2 rubler per leksjon, pluss utvikling og støtte.
Tilbake til temaet videokommunikasjon
Vi overvåker kontinuerlig tilbakemeldinger fra elever og lærere for å identifisere og rette opp problemer i tide. Sommeren 2018 var samtalekvaliteten solid på førsteplass blant klager. På den ene siden betydde dette at vi hadde overvunnet andre mangler. På den annen side var det nødvendig å gjøre noe raskt: hvis leksjonen blir forstyrret, risikerer vi å miste verdien, noen ganger sammen med kostnadene ved å kjøpe den neste pakken, og hvis introduksjonsleksjonen blir forstyrret, risikerer vi å miste en potensiell kunde totalt.
På den tiden var videokommunikasjonen vår fortsatt i MVP-modus. Enkelt sagt, de lanserte det, det fungerte, de skalerte det en gang, de forsto hvordan de skulle gjøre det - vel, flott. Hvis det fungerer, ikke fiks det. Ingen tok bevisst opp spørsmålet om kommunikasjonskvalitet. I august ble det klart at dette ikke kunne fortsette, og vi lanserte en egen retning for å finne ut hva som var galt med WebRTC og Janus.
Ved innspillet fikk denne retningen: en MVP-løsning, ingen beregninger, ingen mål, ingen forbedringsprosesser, mens 7 % av lærerne klager på kvaliteten på kommunikasjonen (det var heller ingen data på elevene).
En ny retning er på vei
Kommandoen ser omtrent slik ut:
- Avdelingslederen, som også er hovedutvikler.
- QA hjelper med å teste endringer, ser etter nye måter å skape ustabile kommunikasjonsforhold på og rapporterer problemer fra frontlinjen.
- Analytikeren ser hele tiden etter ulike sammenhenger i tekniske data, forbedrer analysen av brukertilbakemeldinger og sjekker resultatene av eksperimenter.
- Produktsjefen hjelper til med den overordnede retningen og allokeringen av ressurser til eksperimenter.
- En annen utvikler hjelper ofte med programmering og relaterte oppgaver.
Til å begynne med satte vi opp en relativt pålitelig beregning som sporet endringer i kommunikasjonskvalitetsvurderinger (gjennomsnitt over dager, uker, måneder). På den tiden var dette karakterer fra lærere, senere ble karakterer fra elever lagt til dem. Så begynte de å bygge hypoteser om hva som fungerte galt, korrigere det og se på endringer i dynamikk. Vi gikk for den lavthengende frukten: for eksempel byttet vi ut vp8-kodeken med vp9, ytelsen ble forbedret. Vi prøvde å leke med Janus-innstillingene og gjennomføre andre eksperimenter - i de fleste tilfeller førte de ikke til noe.
På det andre trinnet dukket det opp en hypotese: WebRTC er en peer-to-peer-løsning, og vi bruker en server i midten. Kanskje ligger problemet her? Vi begynte å grave og fant den viktigste forbedringen så langt.
I det øyeblikket ble en server fra bassenget valgt ved hjelp av en ganske dum algoritme: hver hadde sin egen "vekt", avhengig av kanalen og kraften, og vi prøvde å sende brukeren til den med størst "vekt", uten ta hensyn til hvor brukeren var geografisk plassert. Som et resultat kunne en lærer fra St. Petersburg kommunisere med en elev fra Sibir gjennom Moskva, og ikke gjennom vår Janus-server i St. Petersburg.
Algoritmen har blitt gjort om: nå, når en bruker åpner plattformen vår, samler vi inn ping fra ham til alle servere som bruker Ajax. Når vi oppretter en forbindelse, velger vi et par pinger (lærer-server og student-server) med det minste beløpet. Mindre ping betyr mindre nettverksavstand til serveren; kortere avstand betyr lavere sannsynlighet for å miste pakker; Pakketap er den største negative faktoren i videokommunikasjon. Andelen negativitet falt med det halve på tre måneder (for å være rettferdig, andre eksperimenter ble utført på dette tidspunktet, men dette hadde nesten helt sikkert størst effekt).
Vi oppdaget nylig en annen ikke-åpenbar, men tilsynelatende viktig ting: i stedet for en kraftig Janus-server på en tykk kanal, er det bedre å ha to enklere med tynnere båndbredde. Dette ble klart etter at vi kjøpte kraftige maskiner i håp om å stappe så mange rom (kommunikasjonsøkter) inn i dem samtidig. Servere har en båndbreddegrense, som vi nøyaktig kan oversette til antall rom – vi vet hvor mange som kan åpnes, for eksempel ved 300 Mbit/s. Så snart det er for mange rom åpne på en server, slutter vi å velge den for nye aktiviteter inntil belastningen avtar. Tanken var at etter å ha kjøpt en kraftig maskin, ville vi laste kanalen til den maksimalt, slik at den til slutt ville bli begrenset av prosessoren og minnet, og ikke av båndbredden. Men det viste seg at etter et visst antall åpne rom (420), til tross for at belastningen på prosessoren, minnet og disken fortsatt er veldig langt fra grensene, begynner negativiteten å komme til teknisk støtte. Tilsynelatende er det noe som blir verre inni Janus, kanskje er det noen restriksjoner der også. Vi begynte å eksperimentere, senket båndbreddegrensen fra 300 til 200 Mbit/s, og problemene forsvant. Nå har vi kjøpt tre nye servere på en gang med lave grenser og egenskaper, vi tror at dette vil føre til en stabil forbedring av kvaliteten på kommunikasjonen. Selvfølgelig prøvde vi ikke å finne ut hva som foregikk der; krykkene våre er alt. Til vårt forsvar, la oss si at det i det øyeblikket var nødvendig å løse det presserende problemet så raskt som mulig, og ikke å gjøre det vakkert; dessuten er Janus for oss en svart boks skrevet i C, det er veldig dyrt å fikle med den.
Vel, i prosessen:
- oppdaterte alle avhengigheter som kunne oppdateres, både på serveren og på klienten (dette var også eksperimenter, vi overvåket resultatene);
- fikset alle identifiserte feil relatert til spesifikke tilfeller, for eksempel når forbindelsen falt og ikke ble gjenopprettet automatisk;
- Vi holdt mange møter med selskaper som jobber innen videokommunikasjon og kjente med problemene våre: streaming av spill, organisering av webinarer; vi prøvde alt som virket nyttig for oss;
- Gjennomførte en teknisk gjennomgang av maskinvare- og kommunikasjonskvaliteten til lærerne, som det kom flest klager fra.
Forsøkene og påfølgende endringer gjorde det mulig å redusere misnøyen med kommunikasjon blant lærere fra 7,1 % i januar 2018 til 2,5 % i januar 2019.
Hva er neste
Stabilisering av Vimbox-plattformen vår er et av selskapets hovedprosjekter for 2019. Vi har store forhåpninger om at vi skal klare å opprettholde momentumet og ikke lenger se videokommunikasjon i toppklagene. Vi forstår at en betydelig del av disse klagene er relatert til etterslep i brukernes datamaskiner og Internett, men vi må bestemme denne delen og løse resten. Alt annet er et teknisk problem, det ser ut til at vi burde være i stand til å takle det.
Den største vanskeligheten er at vi ikke vet til hvilket nivå det faktisk er mulig å forbedre kvaliteten. Å finne ut dette taket er hovedoppgaven. Derfor ble det planlagt to eksperimenter:
- sammenligne video via Janus med vanlig p2p i kampforhold. Dette eksperimentet er allerede utført, ingen statistisk signifikant forskjell ble funnet mellom vår løsning og p2p;
- La oss levere (dyre) tjenester fra selskaper som utelukkende tjener penger på videokommunikasjonsløsninger, og sammenligne mengden negativitet fra dem med den eksisterende.
Disse to eksperimentene vil tillate oss å identifisere et oppnåelig mål og fokusere på det.
I tillegg er det en rekke oppgaver som kan løses rutinemessig:
- Vi lager en teknisk målestokk for kommunikasjonskvalitet i stedet for subjektive anmeldelser;
- Vi lager mer detaljerte sesjonslogger for mer nøyaktig å analysere feilene som oppstår, forstå når og nøyaktig hvor de oppstod, og hvilke tilsynelatende urelaterte hendelser som fant sted i det øyeblikket;
- Vi forbereder en automatisk tilkoblingskvalitetstest før leksjonen, og gir også klienten muligheten til å manuelt teste tilkoblingen for å redusere mengden negativitet forårsaket av maskinvaren og kanalen hans;
- vi vil utvikle og gjennomføre flere videokommunikasjonsbelastningstester under dårlige forhold, med variabelt pakketap osv.;
- vi endrer oppførselen til servere i tilfelle problemer for å øke feiltoleransen;
- Vi vil advare brukeren hvis det i det hele tatt er noe galt med forbindelsen hans, slik Skype gjør, slik at han forstår at problemet er på hans side.
Siden april har videokommunikasjonsretningen blitt et fullverdig eget prosjekt innen Skyeng, som omhandler sitt eget produkt, ikke bare en del av Vimbox. Det betyr at vi begynner å lete etter folk på . Vel, som alltid .
Og selvfølgelig fortsetter vi aktivt å kommunisere med mennesker og selskaper som jobber med videokommunikasjon. Ønsker du å utveksle erfaringer med oss, blir vi glade! Kommenter, ta kontakt - vi svarer alle.
Kilde: www.habr.com