Komunikasi video minangka cara utama komunikasi antarane guru lan siswa ing platform Vimbox. Kita nyerah Skype suwene suwe, nyoba sawetara solusi pihak katelu lan pungkasane mapan ing kombinasi WebRTC - Janus-gateway. Kanggo sawetara wektu kita padha seneng karo kabeh, nanging isih sawetara aspèk negatif terus muncul. Akibaté, arah video sing kapisah digawe.
Aku takon Kirill Rogovoy, kepala arah anyar, kanggo ngomong babagan evolusi komunikasi video ing Skyeng, masalah sing ditemokake, solusi lan crutches sing pungkasane digunakake. Muga-muga artikel kasebut migunani kanggo perusahaan sing uga nggawe video dhewe liwat aplikasi web.
Sawetara sejarah
Ing musim panas 2017, kepala pangembangan Skyeng, Sergey Safonov, ngandika ing Backend Conf kanthi crita babagan carane kita "ninggalake Skype lan ngetrapake WebRTC." Sing kasengsem bisa nonton rekaman pidato ing (~ 45 mnt), lan ing kene aku bakal nerangake kanthi ringkes babagan inti.
Kanggo Skyeng School, komunikasi video tansah dadi prioritas komunikasi guru-murid. Ing wiwitan, Skype digunakake, nanging sacara kategorine ora puas amarga sawetara alasan, utamane amarga kekurangan log lan ora bisa integrasi langsung menyang aplikasi web. Mulane, kita nindakake kabeh jinis eksperimen.
Bener, syarat kita kanggo komunikasi video kira-kira ing ngisor iki:
- stabilitas;
- rega murah saben wulangan;
- ngrekam piwulang;
— nelusuri sing ngomong pinten (penting kanggo kita siswa ngomong luwih saka guru sak pawulangan);
- skala linear;
- kemampuan kanggo nggunakake UDP lan TCP.
Sing pisanan nyoba yaiku ngetrapake Tokbox ing taun 2013. Kabeh apik, nanging dadi larang banget - 113 rubel saben pelajaran - lan entuk bathi.
Banjur ing 2015, Voximplant digabungake. Iki minangka fungsi sing dibutuhake kanggo nglacak sapa sing ngomong, lan ing wektu sing padha, solusi kasebut luwih murah: yen mung audio direkam, biaya 20 rubel saben pelajaran. Nanging, mung bisa digunakake liwat UDP lan ora bisa ngalih menyang TCP. Nanging, udakara 40% siswa rampung nggunakake.
Setaun sabanjure, kita wiwit duwe klien perusahaan kanthi syarat khusus dhewe. Contone, kabeh kudu bisa liwat browser, perusahaan mung mbukak http lan https; yaiku ora ana Skype utawa UDP. Klien perusahaan = dhuwit, mula dheweke bali menyang Tokbox, nanging masalah rega ora ilang.
Solusi - WebRTC lan Janus
Mutusake kanggo nggunakake . Tanggung jawab kanggo nggawe sambungan, enkoding lan dekoding stream, nyinkronake trek lan kontrol kualitas kanthi nangani gangguan jaringan. Kanggo bagean kita, kita kudu njamin maca stream saka kamera lan mikropon, nggambar video, ngatur sambungan, nggawe sambungan WebRTC lan ngirim stream menyang, uga ngirim pesen sinyal antarane klien kanggo nggawe sambungan (WebRTC dhewe mung nerangake format data, nanging ora transfer mekanisme). Yen klien ana ing mburi NAT, WebRTC nyambungake server STUN; yen iki ora mbantu, TURN server.
Sambungan p2p biasa ora cukup kanggo kita, amarga kita pengin ngrekam pelajaran kanggo analisis luwih lanjut yen ana keluhan. Mulane kita ngirim stream WebRTC liwat relay . Akibaté, klien ora ngerti alamat saben liyane, ndeleng mung alamat server Janus; iku uga nindakake fungsi saka server sinyal. Janus nduweni akeh fitur sing dibutuhake: kanthi otomatis ngalih menyang TCP yen klien wis diblokir UDP; bisa ngrekam loro UDP lan TCP stream; bisa diukur; Malah ana plugin sing dibangun kanggo tes gema. Yen perlu, server STUN lan TURN saka Twilio disambungake kanthi otomatis.
Ing musim panas 2017, kita duwe loro server Janus sing mlaku, ditambah karo server tambahan kanggo ngolah file audio lan video mentah sing direkam, supaya ora ngenggoni prosesor sing utama. Nalika nyambungake, server Janus dipilih kanthi ganjil-genah (nomer sambungan). Ing wektu kasebut, iki cukup, miturut perasaan kita, menehi kira-kira margin safety kaping papat, persentase implementasine kira-kira 80. Ing wektu sing padha, rega dikurangi dadi ~ 2 rubel saben pelajaran, ditambah pembangunan lan dhukungan.
Bali menyang topik komunikasi video
Kita terus-terusan ngawasi umpan balik saka siswa lan guru supaya bisa ngenali lan mbenerake masalah kanthi pas wektune. Ing musim panas 2018, kualitas telpon dadi paling apik ing antarane keluhan. Ing tangan siji, iki tegese kita wis kasil ngatasi kekurangan liyane. Ing tangan liyane, iku perlu kanggo nindakake soko urgently: yen pawulangan disrupted, kita resiko kelangan regane, kadhangkala bebarengan karo biaya tuku paket sabanjuré, lan yen pawulangan pambuko disrupted, kita resiko kelangan klien potensial. sakabehe.
Ing wektu iku, komunikasi video kita isih ing mode MVP. Cukup, dheweke ngluncurake, kerjane, ukurane sapisan, dheweke ngerti carane nindakake - apik banget. Yen bisa, aja ndandani. Ora ana sing sengaja ngatasi masalah kualitas komunikasi. Ing wulan Agustus, dadi cetha yen iki ora bisa diterusake, lan kita ngluncurake arah sing kapisah kanggo ngerteni apa sing salah karo WebRTC lan Janus.
Ing input, arah iki ditampa: solusi MVP, ora ana metrik, ora ana tujuan, ora ana proses perbaikan, dene 7% guru sambat babagan kualitas komunikasi (ora ana data babagan siswa).
A arah anyar lagi ditindakake
Printah katon kaya iki:
- Kepala departemen, sing uga dadi pangembang utama.
- QA mbantu pangowahan tes, golek cara anyar kanggo nggawe kahanan komunikasi sing ora stabil, lan nglaporake masalah saka garis ngarep.
- Analis terus-terusan nggoleki macem-macem korélasi ing data teknis, nambah analisis umpan balik pangguna, lan mriksa asil eksperimen.
- Manajer produk mbantu arah sakabèhé lan alokasi sumber daya kanggo eksperimen.
- Pangembang kapindho asring mbantu program lan tugas sing gegandhengan.
Kanggo miwiti, kita nyiyapake metrik sing relatif dipercaya sing nglacak owah-owahan ing penilaian kualitas komunikasi (rata-rata liwat dina, minggu, sasi). Ing wektu iku, iki minangka biji saka guru, banjur biji saka siswa ditambahake. Banjur padha wiwit mbangun hipotesis babagan apa sing salah, mbenerake, lan ndeleng owah-owahan ing dinamika. We tindak kanggo woh kurang hanging: contone, kita ngganti codec vp8 karo vp9, kinerja apik. Kita nyoba muter setelan Janus lan nindakake eksperimen liyane - ing kasus-kasus sing paling akeh, dheweke ora nyebabake apa-apa.
Ing tahap kapindho, hipotesis muncul: WebRTC minangka solusi peer-to-peer, lan kita nggunakake server ing tengah. Mbok masalah dumunung kene? Kita miwiti ngeduk lan nemokake asil dandan sing paling penting nganti saiki.
Ing wayahe, server saka blumbang dipilih nggunakake algoritma sing rada bodho: saben duwe "bobot" dhewe, gumantung saka saluran lan daya, lan kita nyoba ngirim pangguna menyang sing paling gedhe "bobot", tanpa mbayar manungsa waé menyang ngendi pangguna dumunung geografis. Akibaté, guru saka St Petersburg bisa komunikasi karo mahasiswa saka Siberia liwat Moscow, lan ora liwat server Janus kita ing St.
Algoritma wis digawe maneh: saiki, nalika pangguna mbukak platform kita, kita ngumpulake ping saka dheweke menyang kabeh server nggunakake Ajax. Nalika nggawe sambungan, kita milih pasangan ping (guru-server lan siswa-server) kanthi jumlah paling cilik. Kurang ping tegese kurang jarak jaringan menyang server; jarak sing luwih cendhek tegese luwih murah kemungkinan ilang paket; Packet loss minangka faktor negatif paling gedhe ing komunikasi video. Pangsa negativitas ambruk setengah ing telung sasi (dadi adil, eksperimen liyane ditindakake ing wektu iki, nanging iki meh mesthi duwe pengaruh paling gedhe).
Kita bubar nemokake liyane sing ora jelas, nanging penting banget: tinimbang siji server Janus sing kuat ing saluran sing kandel, luwih becik duwe loro sing luwih gampang kanthi bandwidth sing luwih tipis. Iki dadi cetha sawise kita tuku mesin kuat ing pangarep-arep cramming minangka akeh kamar (sesi komunikasi) menyang ing wektu sing padha. Server duwe watesan bandwidth, sing bisa diterjemahake kanthi akurat menyang jumlah kamar - kita ngerti carane akeh sing bisa dibukak, contone, ing 300 Mbit / s. Sanalika ana akeh banget kamar mbukak ing server, kita mungkasi milih kanggo aktivitas anyar nganti mbukak sudo. Ing idea ana sing, wis tuku mesin kuat, kita bakal mbukak saluran menyang maksimum, supaya ing pungkasan bakal diwatesi dening prosesor lan memori, lan ora bandwidth. Nanging ternyata sawise sawetara kamar mbukak (420), senadyan kasunyatan sing mbukak ing prosesor, memori lan disk isih adoh banget saka watesan, negativity wiwit teka ing technical support. Ketoke, ana sing saya tambah parah ing Janus, mbok menawa uga ana larangan. Kita miwiti nyobi, sudo watesan bandwidth saka 300 kanggo 200 Mbit / s, lan masalah ilang. Saiki kita tuku telung server anyar bebarengan karo watesan kurang lan ciri, kita mikir sing iki bakal mimpin kanggo dandan stabil ing kualitas komunikasi. Mesthi wae, kita ora nyoba ngerteni apa sing kedadeyan ing kana; kruk kita kabeh. Ing pertahanan kita, ayo ngomong yen ing wektu iku perlu kanggo ngatasi masalah sing paling cepet sabisa, lan ora nindakake kanthi apik; liyane, Janus kanggo kita kothak ireng ditulis ing C, iku larang banget kanggo tinker karo.
Inggih, ing proses kita:
- nganyari kabeh dependensi sing bisa dianyari, ing server lan ing klien (iki uga eksperimen, kita ngawasi asil);
- ndandani kabeh kewan omo sing diidentifikasi sing ana gandhengane karo kasus tartamtu, contone, nalika sambungan mudhun lan ora dibalekake kanthi otomatis;
- Kita nganakake akeh rapat karo perusahaan sing kerja ing bidang komunikasi video lan kenal karo masalah kita: game streaming, ngatur webinar; kita nyoba kabeh sing ketoke migunani kanggo kita;
- Nindakake review teknis babagan hardware lan kualitas komunikasi guru, sing paling akeh keluhan.
Eksperimen lan owah-owahan sabanjure bisa nyuda rasa ora puas karo komunikasi antarane guru saka 7,1% ing Januari 2018 dadi 2,5% ing Januari 2019.
Apa mbesuk
Stabilisasi platform Vimbox minangka salah sawijining proyek utama perusahaan kanggo 2019. Kita duwe pangarep-arep supaya bisa njaga momentum lan ora bisa ndeleng komunikasi video ing keluhan ndhuwur. We ngerti sing bagean pinunjul saka keluhan iki related kanggo lags komputer kedhaftar lan Internet, nanging kita kudu nemtokake bagean iki lan ngatasi liyane. Kabeh liyane masalah teknis, misale jek kita kudu bisa kanggo ngrampungake karo.
Kangelan utama iku kita ora ngerti apa tingkat iku bener bisa kanggo nambah kualitas. Nggoleki langit-langit iki minangka tugas utama. Mulane, rong eksperimen direncanakake:
- mbandhingake video liwat Janus karo p2p biasa ing kahanan pertempuran. Eksperimen iki wis ditindakake, ora ana prabédan sing signifikan sacara statistik ing antarane solusi lan p2p;
- Ayo nyedhiyakake layanan (larang) saka perusahaan sing nggawe dhuwit khusus kanggo solusi komunikasi video, lan mbandhingake jumlah negativitas karo sing wis ana.
Loro eksperimen iki bakal ngidini kita ngenali tujuan sing bisa ditindakake lan fokus.
Kajaba iku, ana sawetara tugas sing bisa dirampungake kanthi rutin:
- Kita nggawe metrik teknis kualitas komunikasi tinimbang review subyektif;
- Kita nggawe log sesi sing luwih rinci supaya luwih akurat nganalisa kegagalan sing kedadeyan, ngerti kapan lan ing ngendi persis kedadeyan kasebut, lan kedadeyan sing ora ana hubungane karo kedadeyan kasebut;
- Kita nyiapake tes kualitas sambungan otomatis sadurunge wulangan, lan uga menehi klien kesempatan kanggo nyoba sambungan kanthi manual supaya bisa nyuda jumlah negativitas sing disebabake dening hardware lan saluran;
- kita bakal ngembangake lan nganakake tes beban komunikasi video liyane ing kahanan sing ora apik, kanthi mundhut paket variabel, lsp;
- kita ngganti prilaku server ing cilik saka masalah kanggo nambah toleransi fault;
- Kita bakal ngelingake pangguna yen ana sing salah karo sambungane, kaya sing ditindakake Skype, supaya dheweke ngerti manawa masalah kasebut ana ing sisihane.
Wiwit April, arah komunikasi video wis dadi proyek kapisah lengkap ing Skyeng, ngurusi produk dhewe, ora mung bagean saka Vimbox. Iki tegese kita miwiti kanggo golek wong ing . Inggih, minangka tansah .
Lan, mesthi, kita terus aktif komunikasi karo wong lan perusahaan sing nggarap komunikasi video. Yen sampeyan pengin ijol-ijolan pengalaman karo kita, kita bakal bungah! Komentar, hubungi - kita bakal mangsuli kabeh wong.
Source: www.habr.com