Videokommunikation er hovedformen for kommunikation mellem lærer og elev på Vimbox platformen. Vi opgav Skype for længe siden, prøvede adskillige tredjepartsløsninger og slog os til sidst fast på kombinationen WebRTC - Janus-gateway. I nogen tid var vi tilfredse med alting, men stadig nogle negative aspekter fortsatte med at dukke op. Som et resultat blev der oprettet en separat videoretning.
Jeg bad Kirill Rogovoy, lederen af den nye retning, om at tale om udviklingen af videokommunikation hos Skyeng, de opdagede problemer, løsninger og krykker, som vi i sidste ende brugte. Vi håber, at artiklen vil være nyttig for virksomheder, der også laver video på egen hånd gennem en webapplikation.
Lidt historie
I sommeren 2017 talte lederen af Skyeng-udvikling, Sergey Safonov, på Backend Conf med en historie om, hvordan vi "opgav Skype og implementerede WebRTC." Interesserede kan se optagelsen af talen kl (~45 min), og her vil jeg kort skitsere dens essens.
For Skyeng School har videokommunikation altid været en prioriteret måde for lærer-elev kommunikation. I starten blev Skype brugt, men det var kategorisk ikke tilfredsstillende af en række årsager, primært på grund af manglen på logfiler og umuligheden af integration direkte i webapplikationen. Derfor udførte vi alle mulige eksperimenter.
Faktisk var vores krav til videokommunikation omtrent følgende:
— stabilitet;
— lav pris pr. lektion;
— optagelse af lektioner;
— sporing af, hvem der taler hvor meget (det er vigtigt for os, at eleverne taler mere end læreren i undervisningen);
— lineær skalering;
- evne til at bruge både UDP og TCP.
Den første til at prøve var at implementere Tokbox i 2013. Alt var godt, men det viste sig at være meget dyrt - 113 rubler pr. lektion - og spiste overskuddet.
Så i 2015 blev Voximplant integreret. Her var den funktion, vi skulle bruge for at spore, hvem der talte, hvor meget, og samtidig var løsningen meget billigere: Hvis der kun blev optaget lyd, kostede det 20 rubler pr. lektion. Det fungerede dog kun via UDP og kunne ikke skifte til TCP. Men omkring 40 % af eleverne endte med at bruge det.
Et år senere begyndte vi at have erhvervskunder med deres egne specifikke krav. For eksempel skal alt fungere gennem en browser, virksomheden åbner kun http og https; dvs. ingen Skype eller UDP. Virksomhedskunder = penge, så de vendte tilbage til Tokbox, men problemet med prisen forsvandt ikke.
Løsning - WebRTC og Janus
Besluttet at bruge . Det er ansvarligt for at etablere en forbindelse, indkode og afkode streams, synkronisere spor og kvalitetskontrol med håndtering af netværksfejl. For vores vedkommende skal vi sørge for at læse streams fra kameraet og mikrofonen, tegne video, administrere forbindelsen, etablere en WebRTC-forbindelse og sende streams til den, samt sende signalbeskeder mellem klienter for at etablere en forbindelse (WebRTC selv beskriver kun dataformat, men ikke dets mekanismeoverførsler). Hvis klienter er bag NAT, forbinder WebRTC STUN-servere; hvis dette ikke hjælper, TURN-servere.
En almindelig p2p-forbindelse er ikke nok for os, fordi vi ønsker at optage lektioner til yderligere analyse i tilfælde af klager. Derfor sender vi WebRTC-streams gennem et relæ . Som følge heraf kender klienterne ikke hinandens adresser, idet de kun ser Janus-serveradressen; den udfører også en signalservers funktioner. Janus har mange af de funktioner, vi har brug for: skifter automatisk til TCP, hvis klienten har blokeret UDP; kan optage både UDP- og TCP-streams; skalerbar; Der er endda et indbygget plugin til ekkotest. Om nødvendigt tilsluttes STUN- og TURN-servere fra Twilio automatisk.
I sommeren 2017 havde vi to Janus-servere kørende, plus en ekstra server til behandling af optagede rå lyd- og videofiler, for ikke at optage processorerne på de vigtigste. Ved tilslutning blev Janus-servere valgt på ulige-lige basis (forbindelsesnummer). På det tidspunkt var dette nok, ifølge vores følelser gav det cirka en firedobbelt sikkerhedsmargin, implementeringsprocenten var omkring 80. Samtidig blev prisen reduceret til ~2 rubler per lektion plus udvikling og support.
Vender tilbage til emnet videokommunikation
Vi overvåger konstant feedback fra elever og lærere for at identificere og rette problemer rettidigt. I sommeren 2018 lå opkaldskvaliteten på førstepladsen blandt klager. På den ene side betød det, at vi med succes havde håndteret andre mangler. På den anden side var det nødvendigt at gøre noget akut: hvis lektionen bliver forstyrret, risikerer vi at miste dens værdi, nogle gange sammen med omkostningerne ved at købe den næste pakke, og hvis den indledende lektion bliver forstyrret, risikerer vi at miste en potentiel kunde i det hele taget.
På det tidspunkt var vores videokommunikation stadig i MVP-tilstand. Kort sagt, de lancerede det, det virkede, de skalerede det én gang, de forstod, hvordan man gjorde det - ja, fantastisk. Hvis det virker, skal du ikke rette det. Ingen behandlede bevidst spørgsmålet om kommunikationskvalitet. I august stod det klart, at dette ikke kunne fortsætte, og vi lancerede en separat retning for at finde ud af, hvad der var galt med WebRTC og Janus.
Ved inputtet modtog denne retning: en MVP-løsning, ingen målinger, ingen mål, ingen processer til forbedring, mens 7 % af lærerne klager over kvaliteten af kommunikationen (der var heller ingen data om elever).
En ny retning er på vej
Kommandoen ser nogenlunde sådan ud:
- Afdelingslederen, som også er hovedudvikler.
- QA hjælper med at teste ændringer, leder efter nye måder at skabe ustabile kommunikationsforhold på og rapporterer problemer fra frontlinjen.
- Analytikeren leder konstant efter forskellige sammenhænge i tekniske data, forbedrer analysen af brugerfeedback og kontrollerer resultaterne af eksperimenter.
- Produktchefen hjælper med den overordnede retning og allokering af ressourcer til eksperimenter.
- En anden udvikler hjælper ofte med programmering og relaterede opgaver.
Til at begynde med opsatte vi en relativt pålidelig metrik, der sporede ændringer i kommunikationskvalitetsvurderinger (gennemsnit over dage, uger, måneder). På det tidspunkt var disse karakterer fra lærere, senere blev karakterer fra elever tilføjet dem. Derefter begyndte de at opbygge hypoteser om, hvad der virkede forkert, rette det og se på ændringer i dynamikken. Vi gik efter den lavthængende frugt: for eksempel erstattede vi vp8 codec med vp9, ydeevnen blev forbedret. Vi forsøgte at lege med Janus-indstillingerne og lave andre eksperimenter - i de fleste tilfælde førte de ikke til noget.
På anden fase dukkede en hypotese op: WebRTC er en peer-to-peer løsning, og vi bruger en server i midten. Måske ligger problemet her? Vi begyndte at grave og fandt den hidtil mest markante forbedring.
I det øjeblik blev en server fra poolen valgt ved hjælp af en ret dum algoritme: hver havde sin egen "vægt", afhængigt af kanalen og effekt, og vi forsøgte at sende brugeren til den med den største "vægt", uden være opmærksom på, hvor brugeren var geografisk placeret. Som et resultat kunne en lærer fra Skt. Petersborg kommunikere med en elev fra Sibirien gennem Moskva, og ikke gennem vores Janus-server i Skt. Petersborg.
Algoritmen er blevet lavet om: Nu, når en bruger åbner vores platform, indsamler vi ping fra ham til alle servere, der bruger Ajax. Når vi etablerer en forbindelse, vælger vi et par pings (lærer-server og elev-server) med det mindste beløb. Mindre ping betyder mindre netværksafstand til serveren; kortere afstand betyder lavere sandsynlighed for at miste pakker; Pakketab er den største negative faktor i videokommunikation. Andelen af negativitet faldt til det halve på tre måneder (for at være retfærdig blev der udført andre eksperimenter på dette tidspunkt, men dette havde næsten helt sikkert den største effekt).
Vi har for nylig opdaget en anden ikke-indlysende, men tilsyneladende vigtig ting: i stedet for en kraftfuld Janus-server på en tyk kanal, er det bedre at have to enklere med tyndere båndbredde. Dette blev klart, efter at vi købte kraftfulde maskiner i håbet om at proppe så mange rum (kommunikationssessioner) ind i dem på samme tid. Servere har en båndbreddegrænse, som vi præcist kan oversætte til antallet af rum – vi ved hvor mange der kan åbnes, for eksempel ved 300 Mbit/s. Så snart der er for mange rum åbne på en server, stopper vi med at vælge den til nye aktiviteter, indtil belastningen aftager. Tanken var, at vi, efter at have købt en kraftig maskine, ville indlæse kanalen til den maksimalt, så den i sidste ende ville blive begrænset af processoren og hukommelsen og ikke af båndbredden. Men det viste sig, at efter et vist antal åbne rum (420), på trods af at belastningen på processoren, hukommelsen og disken stadig er meget langt fra grænserne, begynder negativiteten at komme til teknisk support. Tilsyneladende bliver noget værre indeni Janus, måske er der også nogle begrænsninger der. Vi begyndte at eksperimentere, sænkede båndbreddegrænsen fra 300 til 200 Mbit/s, og problemerne forsvandt. Nu har vi købt tre nye servere på én gang med lave grænser og egenskaber, vi tror, at dette vil føre til en stabil forbedring af kvaliteten af kommunikationen. Selvfølgelig forsøgte vi ikke at finde ud af, hvad der foregik der; vores krykker er alt. Til vores forsvar, lad os sige, at det i det øjeblik var nødvendigt at løse det presserende problem så hurtigt som muligt, og ikke at gøre det smukt; desuden er Janus for os en sort boks skrevet i C, det er meget dyrt at pille ved den.
Nå, i processen:
- opdateret alle afhængigheder, der kunne opdateres, både på serveren og på klienten (dette var også eksperimenter, vi overvågede resultaterne);
- rettet alle identificerede fejl relateret til specifikke tilfælde, for eksempel når forbindelsen faldt og ikke blev gendannet automatisk;
- Vi holdt mange møder med virksomheder, der arbejder inden for videokommunikation og var fortrolige med vores problemer: streaming af spil, organisering af webinarer; vi prøvede alt, hvad der syntes nyttigt for os;
- Foretog en teknisk gennemgang af hardware- og kommunikationskvaliteten hos lærere, fra hvem de fleste klager kom.
Forsøgene og de efterfølgende ændringer gjorde det muligt at reducere utilfredsheden med kommunikation blandt lærerne fra 7,1 % i januar 2018 til 2,5 % i januar 2019.
Hvad er næste
Stabilisering af vores Vimbox-platform er et af virksomhedens hovedprojekter for 2019. Vi har store forhåbninger om, at vi vil være i stand til at fastholde momentum og ikke længere se videokommunikation i topklagerne. Vi forstår, at en væsentlig del af disse klager er relateret til forsinkelser i brugernes computere og internet, men vi skal bestemme denne del og løse resten. Alt andet er et teknisk problem, det ser ud til, at vi burde kunne klare det.
Den største vanskelighed er, at vi ikke ved, til hvilket niveau det faktisk er muligt at forbedre kvaliteten. At finde ud af dette loft er hovedopgaven. Derfor var der planlagt to forsøg:
- sammenligne video via Janus med almindelig p2p under kampforhold. Dette eksperiment er allerede blevet udført, ingen statistisk signifikant forskel blev fundet mellem vores løsning og p2p;
- Lad os levere (dyre) tjenester fra virksomheder, der udelukkende tjener penge på videokommunikationsløsninger, og sammenligne mængden af negativitet fra dem med den eksisterende.
Disse to eksperimenter vil give os mulighed for at identificere et opnåeligt mål og fokusere på det.
Derudover er der en række opgaver, der kan løses rutinemæssigt:
- Vi skaber en teknisk målestok for kommunikationskvalitet i stedet for subjektive anmeldelser;
- Vi laver mere detaljerede sessionslogfiler for mere præcist at kunne analysere de fejl, der opstår, forstå, hvornår og præcis hvor de opstod, og hvilke tilsyneladende urelaterede hændelser, der fandt sted i det øjeblik;
- Vi forbereder en automatisk forbindelseskvalitetstest før lektionen, og giver også klienten mulighed for manuelt at teste forbindelsen for at reducere mængden af negativitet forårsaget af hans hardware og kanal;
- vi vil udvikle og udføre flere videokommunikationsbelastningstests under dårlige forhold, med variabelt pakketab osv.;
- vi ændrer servernes adfærd i tilfælde af problemer for at øge fejltolerancen;
- Vi vil advare brugeren, hvis der overhovedet er noget galt med hans forbindelse, som Skype gør, så han forstår, at problemet er på hans side.
Siden april er videokommunikationsretningen blevet et fuldgyldigt separat projekt inden for Skyeng, der beskæftiger sig med sit eget produkt, ikke kun en del af Vimbox. Det betyder, at vi begynder at lede efter folk på . Nå, som altid .
Og selvfølgelig fortsætter vi med at kommunikere aktivt med mennesker og virksomheder, der arbejder med videokommunikation. Hvis du vil udveksle erfaringer med os, vil vi blive glade! Kommenter, tag kontakt - vi svarer alle.
Kilde: www.habr.com