Videokomunikado estas la ĉefa maniero de komunikado inter instruisto kaj studento sur la Vimbox-platformo. Ni rezignis pri Skajpo antaŭ longa tempo, provis plurajn triajn solvojn kaj finfine decidiĝis pri la kombinaĵo WebRTC - Janus-pordejo. Dum kelka tempo ni estis feliĉaj pri ĉio, sed ankoraŭ kelkaj negativaj aspektoj daŭre aperis. Kiel rezulto, aparta videodirekto estis kreita.
Mi petis Kirill Rogovoy, la estro de la nova direkto, paroli pri la evoluo de videokomunikado ĉe Skyeng, la problemoj malkovritaj, solvoj kaj lambastonoj kiujn ni finfine uzis. Ni esperas, ke la artikolo estos utila por kompanioj, kiuj ankaŭ kreas filmetojn memstare per TTT-aplikaĵo.
Iom da historio
En la somero de 2017, la estro de Skyeng-disvolviĝo, Sergey Safonov, parolis ĉe Backend Conf kun rakonto pri kiel ni "forlasis Skype kaj efektivigis WebRTC." Interesitoj povas spekti la registradon de la parolado ĉe (~45 min), kaj ĉi tie mi mallonge skizos ĝian esencon.
Por Skyeng School, videokomunikado ĉiam estis prioritata maniero de instruisto-lernanto. Komence oni uzis Skajpon, sed ĝi kategorie ne estis kontentiga pro kelkaj kialoj, ĉefe pro la manko de protokoloj kaj la malebleco de integriĝo rekte en la TTT-aplikaĵon. Tial ni faris ĉiajn eksperimentojn.
Efektive, niaj postuloj por videokomunikado estis proksimume la sekvaj:
— stabileco;
— malalta prezo por leciono;
— registri lecionojn;
— spuri kiu parolas kiom multe (gravas por ni, ke lernantoj parolu pli ol la instruisto dum lecionoj);
— lineara skalo;
- kapablo uzi kaj UDP kaj TCP.
La unua provi estis efektivigi Tokbox en 2013. Ĉio estis bona, sed ĝi montriĝis tre multekosta - 113 rubloj por leciono - kaj manĝis la profiton.
Tiam en 2015, Voximplant estis integrita. Jen la funkcio, kiun ni bezonis por spuri, kiu parolis kiom multe, kaj samtempe la solvo estis multe pli malmultekosta: se nur audio estis registrita, ĝi kostis 20 rublojn por leciono. Tamen ĝi funkciis nur per UDP kaj ne povis ŝanĝi al TCP. Tamen, ĉirkaŭ 40% de studentoj finis uzi ĝin.
Jaron poste, ni komencis havi kompaniajn klientojn kun siaj propraj specifaj postuloj. Ekzemple, ĉio devus funkcii per retumilo; la kompanio nur malfermas http kaj https; t.e. neniu Skajpo aŭ UDP. Korporaciaj klientoj = mono, do ili revenis al Tokbox, sed la problemo de prezo ne malaperis.
Solvo - WebRTC kaj Janus
Decidis uzi . Ĝi respondecas pri establado de konekto, kodado kaj malkodado de riveretoj, sinkronigado de trakoj kaj kvalito-kontrolo kun pritraktado de retaj problemoj. Niaflanke, ni devas certigi legadon de fluoj de la fotilo kaj mikrofono, desegni videon, administri la konekton, establi WebRTC-konekton kaj transdoni fluojn al ĝi, kaj ankaŭ transdoni signalajn mesaĝojn inter klientoj por establi konekton (WebRTC mem priskribas nur la datumformato, sed ne ĝiaj mekanismo-translokigoj). Se klientoj estas malantaŭ NAT, WebRTC ligas STUN-servilojn; se tio ne helpas, TURN-serviloj.
Regula p2p-konekto ne sufiĉas por ni, ĉar ni volas registri lecionojn por plia analizo en kazo de plendoj. Tial ni sendas WebRTC-fluojn per relajso . Kiel rezulto, klientoj ne konas reciproke la adresojn, vidante nur la Janus-serviladreson; ĝi ankaŭ plenumas la funkciojn de signalservilo. Janus havas multajn el la funkcioj kiujn ni bezonas: aŭtomate ŝanĝas al TCP se la kliento havas UDP blokita; povas registri kaj UDP kaj TCP-riveretojn; skalebla; Estas eĉ enkonstruita kromaĵo por eĥaj provoj. Se necese, STUN kaj TURN-serviloj de Twilio estas aŭtomate konektitaj.
En la somero de 2017, ni funkciis du servilojn de Janus, plus plian servilon por prilabori registritajn krudajn sondosierojn kaj video-dosierojn, por ne okupi la procesorojn de la ĉefaj. Dum konekto, Janus-serviloj estis elektitaj sur nepara-para bazo (konektnumero). Tiutempe, ĉi tio sufiĉis, laŭ niaj sentoj, ĝi donis proksimume kvaroblan sekurecan marĝenon, la efektiviga procento estis ĉirkaŭ 80. Samtempe, la prezo estis reduktita al ~2 rubloj por leciono, plus disvolviĝo kaj subteno.
Revenante al la temo de videokomunikado
Ni konstante kontrolas komentojn de studentoj kaj instruistoj por identigi kaj korekti problemojn ĝustatempe. Antaŭ la somero de 2018, voka kvalito estis firme en la unua loko inter plendoj. Unuflanke, tio signifis, ke ni sukcese venkis aliajn mankojn. Aliflanke, estis necese fari ion urĝe: se la leciono estas interrompita, ni riskas perdi ĝian valoron, foje kune kun la kosto de aĉeto de la sekva pako, kaj se la enkonduka leciono estas interrompita, ni riskas perdi potencialan klienton. entute.
Tiutempe, nia videokomunikado ankoraŭ estis en MVP-reĝimo. Simple dirite, ili lanĉis ĝin, ĝi funkciis, ili grimpis ĝin unufoje, ili komprenis kiel fari ĝin - nu, bonege. Se ĝi funkcias, ne riparu ĝin. Neniu intence traktis la temon de komunika kvalito. Antaŭ aŭgusto, evidentiĝis, ke ĉi tio ne povas daŭri, kaj ni lanĉis apartan direkton por ekscii, kio misas kun WebRTC kaj Janus.
Ĉe la enigo, ĉi tiu direkto ricevis: MVP-solvon, neniujn metrikojn, neniujn celojn, neniujn procezojn por plibonigo, dum 7% de instruistoj plendas pri la kvalito de komunikado (ankaŭ ne estis datumoj pri studentoj).
Nova direkto estas survoje
La komando aspektas kiel ĉi tio:
- La estro de la fako, kiu ankaŭ estas la ĉefa programisto.
- QA helpas testi ŝanĝojn, serĉas novajn manierojn krei malstabilajn komunikajn kondiĉojn kaj raportas problemojn de la unua linio.
- La analizisto konstante serĉas diversajn korelaciojn en teknikaj datumoj, plibonigas la analizon de uzantreagoj kaj kontrolas la rezultojn de eksperimentoj.
- La produktmanaĝero helpas kun la ĝenerala direkto kaj asigno de rimedoj por eksperimentoj.
- Dua programisto ofte helpas pri programado kaj rilataj taskoj.
Komence, ni starigis relative fidindan metrikon, kiu spuris ŝanĝojn en komunikaj kvalittaksoj (averaĝe dum tagoj, semajnoj, monatoj). En tiu tempo, tiuj estis karakteroj de instruistoj; pli postaj karakteroj de studentoj estis aldonitaj al ili. Tiam ili komencis konstrui hipotezojn pri kio malbone funkciis, korekti ĝin kaj rigardi ŝanĝojn en dinamiko. Ni iris por la malaltaj fruktoj: ekzemple, ni anstataŭigis la vp8-kodekon per vp9, la rendimento pliboniĝis. Ni provis ludi kun la agordoj de Janus kaj fari aliajn eksperimentojn - plejofte ili ne kondukis al io ajn.
En la dua etapo, hipotezo aperis: WebRTC estas samulo-al-kunula solvo, kaj ni uzas servilon en la mezo. Eble la problemo kuŝas ĉi tie? Ni komencis fosi kaj trovis la plej signifan plibonigon ĝis nun.
En tiu momento, servilo el la naĝejo estis elektita per iom stulta algoritmo: ĉiu havis sian propran "pezon", depende de la kanalo kaj potenco, kaj ni provis sendi la uzanton al tiu kun la plej granda "pezo", sen atentante kie la uzanto situis geografie. Rezulte, instruisto el Peterburgo povis komuniki kun studento el Siberio tra Moskvo, kaj ne per nia Janus-servilo en Peterburgo.
La algoritmo estis refarita: nun, kiam uzanto malfermas nian platformon, ni kolektas pingojn de li al ĉiuj serviloj uzante Ajax. Kiam oni establas konekton, ni elektas paron da pingoj (instruisto-servilo kaj studento-servilo) kun la plej malgranda kvanto. Malpli ping signifas malpli retan distancon al la servilo; pli mallonga distanco signifas pli malaltan probablecon perdi pakaĵetojn; Paka perdo estas la plej granda negativa faktoro en videokomunikado. La parto de negativeco malpliiĝis je duono en tri monatoj (por esti juste, aliaj eksperimentoj estis faritaj ĉi-momente, sed ĉi tiu preskaŭ certe havis la plej grandan efikon).
Ni lastatempe malkovris alian neevidentan, sed ŝajne gravan aferon: anstataŭ unu potenca Janus-servilo sur dika kanalo, estas pli bone havi du pli simplajn kun pli maldika bendolarĝo. Ĉi tio evidentiĝis post kiam ni aĉetis potencajn maŝinojn kun la espero enŝlosi en ilin samtempe tiom da ĉambroj (komunikaj kunsidoj). Serviloj havas limon de larĝa de bando, kiun ni povas precize traduki en la nombron da ĉambroj - ni scias kiom multaj povas esti malfermitaj, ekzemple, je 300 Mbit/s. Tuj kiam estas tro da ĉambroj malfermitaj sur servilo, ni ĉesas elekti ĝin por novaj agadoj ĝis la ŝarĝo malpliiĝos. La ideo estis, ke, aĉetinte potencan maŝinon, ni ŝarĝus la kanalon al ĝi al la maksimumo, tiel ke finfine ĝi limiĝos per la procesoro kaj memoro, kaj ne per larĝa de bando. Sed montriĝis, ke post certa nombro da malfermitaj ĉambroj (420), malgraŭ la fakto, ke la ŝarĝo sur la procesoro, memoro kaj disko estas ankoraŭ tre malproksime de la limoj, negativeco komencas alveni al teknika subteno. Ŝajne, io plimalboniĝas ene de Janus, eble ankaŭ tie estas iuj limigoj. Ni komencis eksperimenti, malaltigis la bendolarĝan limon de 300 ĝis 200 Mbit/s, kaj la problemoj foriris. Nun ni aĉetis tri novajn servilojn samtempe kun malaltaj limoj kaj karakterizaĵoj, ni pensas, ke ĉi tio kondukos al stabila plibonigo de la kvalito de komunikado. Kompreneble, ni ne provis eltrovi kio okazas tie; niaj lambastonoj estas ĉio. En nia defendo, ni diru, ke en tiu momento necesis solvi la preman problemon kiel eble plej rapide, kaj ne fari ĝin bele; krome Janus por ni estas nigra skatolo skribita per C, estas tre multekoste tuŝi ĝin.
Nu, en la procezo ni:
- ĝisdatigis ĉiujn dependecojn, kiuj povus esti ĝisdatigitaj, kaj sur la servilo kaj sur la kliento (ĉi tiuj ankaŭ estis eksperimentoj, ni monitoris la rezultojn);
- riparis ĉiujn identigitajn cimojn rilatajn al specifaj kazoj, ekzemple, kiam la konekto falis kaj ne estis restarigita aŭtomate;
- Ni okazigis multajn renkontiĝojn kun kompanioj laborantaj en la kampo de videokomunikadoj kaj konataj kun niaj problemoj: streaming ludoj, organizado de retseminarioj; ni provis ĉion, kio ŝajnis al ni utila;
- Faris teknikan revizion de la aparataro kaj komunika kvalito de instruistoj, de kiuj venis la plej multaj plendoj.
La eksperimentoj kaj postaj ŝanĝoj ebligis redukti malkontenton pri komunikado inter instruistoj de 7,1% en januaro 2018 al 2,5% en januaro 2019.
Kio sekvas
Stabiligi nian Vimbox-platformon estas unu el la ĉefaj projektoj de la kompanio por 2019. Ni havas grandajn esperojn, ke ni povos konservi la impeton kaj ne plu vidi videokomunikadon en la ĉefaj plendoj. Ni komprenas, ke grava parto de ĉi tiuj plendoj rilatas al malfruoj en komputiloj kaj Interreto de uzantoj, sed ni devas determini ĉi tiun parton kaj solvi la reston. Ĉio alia estas teknika problemo, ŝajnas, ke ni devus povi trakti ĝin.
La ĉefa malfacilaĵo estas, ke ni ne scias ĝis kiu nivelo efektive eblas plibonigi kvaliton. Eltrovi ĉi tiun plafonon estas la ĉefa tasko. Tial, du eksperimentoj estis planitaj:
- komparu videon per Janus kun regula p2p en batalkondiĉoj. Ĉi tiu eksperimento jam estis farita, neniu statistike signifa diferenco estis trovita inter nia solvo kaj p2p;
- Ni liveru (multekostajn) servojn de kompanioj, kiuj gajnas monon ekskluzive per videokomunikadaj solvoj, kaj komparu la kvanton da negativeco de ili kun la ekzistanta.
Ĉi tiuj du eksperimentoj permesos al ni identigi atingeblan celon kaj koncentriĝi pri ĝi.
Krome, ekzistas kelkaj taskoj, kiuj povas esti solvitaj rutine:
- Ni kreas teknikan metrikon de komunika kvalito anstataŭ subjektivaj recenzoj;
- Ni faras pli detalajn sesiajn protokolojn por pli precize analizi la malsukcesojn, kiuj okazas, kompreni kiam kaj kie ĝuste ili okazis, kaj kiaj ŝajne senrilataj eventoj okazis en tiu momento;
- Ni preparas aŭtomatan konektan kvalitan teston antaŭ la leciono, kaj ankaŭ donas al la kliento la ŝancon mane testi la konekton por redukti la kvanton da negativeco kaŭzita de lia aparataro kaj kanalo;
- ni disvolviĝos kaj faros pli da videokomunikadaj ŝarĝtestoj en malbonaj kondiĉoj, kun ŝanĝiĝema paka perdo, ktp.;
- ni ŝanĝas la konduton de serviloj en kazo de problemoj por pliigi misfunkciadon;
- Ni avertos la uzanton, se entute estas io malbona en lia konekto, kiel Skajpo faras, por ke li komprenu, ke la problemo estas liaflanke.
Ekde aprilo, la videokomunikaddirekto fariĝis plentaŭga aparta projekto ene de Skyeng, traktante sian propran produkton, ne nur parton de Vimbox. Ĉi tio signifas, ke ni komencas serĉi homojn . Nu, kiel ĉiam .
Kaj, kompreneble, ni daŭre aktive komunikas kun homoj kaj kompanioj laborantaj kun videokomunikadoj. Se vi volas interŝanĝi sperton kun ni, ni ĝojos! Komentu, kontaktu - ni respondos al ĉiuj.
fonto: www.habr.com