Видео харилцаа холбоо нь Vimbox платформ дээр багш, сурагчийн хоорондын харилцааны гол арга зам юм. Бид удаан хугацааны өмнө Skype-аас татгалзаж, гуравдагч талын хэд хэдэн шийдлийг туршиж үзсэн бөгөөд эцэст нь WebRTC - Janus-gateway хослол дээр суурьшсан. Хэсэг хугацаанд бид бүх зүйлд сэтгэл хангалуун байсан ч зарим нэг сөрөг талууд гарч ирсээр байв. Үүний үр дүнд тусдаа видео чиглэл бий болсон.
Би шинэ чиглэлийн тэргүүн Кирилл Роговойгоос Skyeng-ийн видео харилцааны хувьсал, олж илрүүлсэн асуудлууд, шийдэл, бидний эцсийн эцэст ашигласан таягны талаар ярихыг хүссэн. Энэхүү нийтлэл нь вэб програмаар дамжуулан бие даан видео бүтээдэг компаниудад хэрэг болно гэж найдаж байна.
Түүх бага
2017 оны зун Skyeng хөгжүүлэлтийн дарга Сергей Сафонов Backend Conf дээр бид "Skype-г орхиж, WebRTC-г хэрхэн хэрэгжүүлсэн" тухай түүхийг ярьжээ. Сонирхсон хүмүүс ярианы бичлэгийг эндээс үзэх боломжтой (~45 мин), энд би түүний мөн чанарыг товч тайлбарлах болно.
Skyeng сургуулийн хувьд видео харилцаа холбоо нь багш, сурагчдын харилцааны тэргүүлэх арга зам байсаар ирсэн. Эхлээд Skype-г ашигладаг байсан боловч хэд хэдэн шалтгааны улмаас энэ нь үндсэндээ бүртгэлгүй, вэб програмд шууд нэгтгэх боломжгүй байсантай холбоотой байв. Тиймээс бид бүх төрлийн туршилтуудыг хийсэн.
Үнэндээ бидний видео харилцаанд тавигдах шаардлагууд нь ойролцоогоор дараах байдалтай байв.
- тогтвортой байдал;
- нэг хичээлийн үнэ бага;
- хичээл бичих;
— хэн хэр их ярьж байгааг хянах (хичээлийн үеэр сурагчид багшаас илүү ярих нь бидний хувьд чухал);
- шугаман масштаб;
- UDP болон TCP хоёуланг нь ашиглах чадвар.
Анх 2013 онд Токбоксыг хэрэгжүүлэх гэж оролдсон. Бүх зүйл сайхан байсан, гэхдээ энэ нь маш үнэтэй болж, нэг хичээлд 113 рубль зарцуулж, ашгийг нь идэв.
Дараа нь 2015 онд Voximplant нэгдсэн. Хэн хэр их ярьж байгааг хянах функц энд байсан бөгөөд үүний зэрэгцээ шийдэл нь хамаагүй хямд байсан: хэрэв зөвхөн аудио бичлэг хийсэн бол нэг хичээлийн үнэ 20 рубль болно. Гэсэн хэдий ч, энэ нь зөвхөн UDP-ээр ажилладаг байсан бөгөөд TCP руу шилжиж чадаагүй. Гэсэн хэдий ч оюутнуудын 40 орчим хувь нь үүнийг ашигласан байна.
Жилийн дараа бид өөрсдийн шаардлага бүхий корпорацийн үйлчлүүлэгчидтэй болж эхэлсэн. Жишээлбэл, бүх зүйл хөтчөөр ажиллах ёстой; компани зөвхөн http болон https-ийг нээдэг; өөрөөр хэлбэл Skype эсвэл UDP байхгүй. Байгууллагын үйлчлүүлэгчид = мөнгө гэж тэд Tokbox руу буцаж ирсэн боловч үнийн асуудал арилаагүй.
Шийдэл - WebRTC болон Janus
Ашиглахаар шийдсэн . Энэ нь холболт үүсгэх, урсгалыг кодлох, тайлах, замуудыг синхрончлох, сүлжээний доголдлыг зохицуулах чанарын хяналтыг хариуцдаг. Бидний хувьд бид камер, микрофоноос урсгал унших, видео зурах, холболтыг удирдах, WebRTC холболтыг бий болгох, түүн рүү урсгал дамжуулах, түүнчлэн холболт үүсгэхийн тулд үйлчлүүлэгчдийн хооронд дохионы мессежийг дамжуулахыг хангах ёстой (WebRTC өөрөө зөвхөн өгөгдлийн формат, гэхдээ түүний механизмыг шилжүүлэхгүй). Хэрэв үйлчлүүлэгчид NAT-ийн ард байгаа бол WebRTC STUN серверүүдийг холбодог, хэрэв энэ нь тус болохгүй бол серверүүдийг TURN.
Бидний хувьд ердийн p2p холболт хангалтгүй, учир нь бид гомдол гарсан тохиолдолд цаашдын дүн шинжилгээ хийх хичээлүүдийг бүртгэхийг хүсч байна. Тиймээс бид WebRTC дамжуулалтыг релейгээр дамжуулдаг . Үүний үр дүнд үйлчлүүлэгчид бие биенийхээ хаягийг мэдэхгүй, зөвхөн Janus серверийн хаягийг хардаг; мөн дохионы серверийн үүргийг гүйцэтгэдэг. Janus бидэнд хэрэгтэй олон боломжуудтай: хэрэв үйлчлүүлэгч UDP-г хаасан бол автоматаар TCP руу шилжинэ; UDP болон TCP урсгалыг хоёуланг нь бичиж болно; өргөтгөх боломжтой; Цуурай тест хийх зориулалттай залгаас хүртэл байдаг. Шаардлагатай бол Twilio-ийн STUN болон TURN серверүүд автоматаар холбогддог.
2017 оны зун бид хоёр Janus серверийг ажиллуулж, үндсэн серверүүдийн процессорыг эзлэхгүйн тулд бичигдсэн түүхий аудио болон видео файлуудыг боловсруулах нэмэлт сервертэй болсон. Холбох үед Janus серверүүдийг тэгш сондгойгоор сонгосон (холболтын дугаар). Тэр үед энэ нь хангалттай байсан, бидний мэдрэмжийн дагуу, энэ нь ойролцоогоор дөрөв дахин аюулгүй байдлын маржин өгсөн, хэрэгжилтийн хувь нь 80 орчим байсан. Үүний зэрэгцээ, үнэ нь хичээл тутамд ~ 2 рубль, дээр нь хөгжүүлэлт, дэмжлэг буурсан байна.
Видео харилцааны сэдэв рүү буцах
Асуудлыг цаг тухайд нь илрүүлж, засч залруулахын тулд оюутан, багш нарын санал хүсэлтийг байнга хянаж байдаг. 2018 оны зун гэхэд дуудлагын чанар гомдлын дунд нэгдүгээр байрт оржээ. Энэ нь нэг талаараа бусад дутагдлаа амжилттай даван туулсан гэсэн үг. Нөгөөтэйгүүр, яаралтай ямар нэг зүйл хийх шаардлагатай байв: хэрэв хичээл тасалдвал бид үнэ цэнээ алдах эрсдэлтэй, заримдаа дараагийн багцыг худалдаж авах зардалтай хамт, хэрэв танилцуулах хичээл тасалдвал бид боломжит үйлчлүүлэгчээ алдах эрсдэлтэй. бүхэлдээ.
Тэр үед бидний видео холбоо MVP горимд хэвээр байсан. Энгийнээр хэлбэл, тэд үүнийг эхлүүлсэн, ажилласан, тэд үүнийг нэг удаа томруулсан, яаж хийхийг ойлгосон - сайн, гайхалтай. Хэрэв энэ нь ажиллаж байгаа бол үүнийг засах хэрэггүй. Харилцаа холбооны чанарын асуудалд хэн ч санаатайгаар хандаагүй. XNUMX-р сар гэхэд үүнийг үргэлжлүүлэх боломжгүй нь тодорхой болсон бөгөөд бид WebRTC болон Janus-д юу буруу байгааг олж мэдэхийн тулд тусдаа чиглэлийг эхлүүлсэн.
Оролтын үед энэ чиглэлийг хүлээн авсан: MVP шийдэл, ямар ч хэмжүүр, зорилго байхгүй, сайжруулах үйл явц байхгүй, харин багш нарын 7% нь харилцааны чанарын талаар гомдоллодог (оюутнуудын талаархи мэдээлэл ч байхгүй).
Шинэ чиглэл хийгдэж байна
Тушаал нь иймэрхүү харагдаж байна:
- Мөн гол хөгжүүлэгч нь болох хэлтсийн дарга.
- QA нь өөрчлөлтийг турших, харилцааны тогтворгүй нөхцөлийг бий болгох шинэ арга замыг эрэлхийлж, асуудлыг урд талын шугамаас мэдээлэхэд тусалдаг.
- Шинжээч нь техникийн өгөгдөлд янз бүрийн хамаарлыг байнга хайж, хэрэглэгчийн санал хүсэлтийн дүн шинжилгээг сайжруулж, туршилтын үр дүнг шалгадаг.
- Бүтээгдэхүүний менежер нь туршилтын нөөцийг ерөнхийд нь чиглүүлэх, хуваарилахад тусалдаг.
- Хоёрдахь хөгжүүлэгч нь ихэвчлэн програмчлал болон холбогдох ажлуудад тусалдаг.
Эхлэхийн тулд бид харилцааны чанарын үнэлгээний өөрчлөлтийг (өдөр, долоо хоног, сарын дундаж) хянадаг харьцангуй найдвартай хэмжигдэхүүнийг бий болгосон. Тухайн үед энэ нь багш нарын үнэлгээ байсан бөгөөд дараа нь оюутнуудын дүн нэмдэг байв. Дараа нь тэд юу буруу ажиллаж байгаа талаар таамаглал дэвшүүлж, засч залруулж, динамикийн өөрчлөлтийг харж эхлэв. Бид бага унжсан жимс авахаар явсан: жишээлбэл, vp8 кодлогчийг vp9-ээр сольсон, гүйцэтгэл сайжирсан. Бид Janus-ийн тохиргоотой тоглож, бусад туршилтуудыг хийхийг оролдсон - ихэнх тохиолдолд тэд юу ч хүргэсэнгүй.
Хоёрдахь шатанд нэг таамаглал гарч ирэв: WebRTC бол үе тэнгийнхэн хоорондын шийдэл бөгөөд бид дунд нь сервер ашигладаг. Магадгүй асуудал энд байгаа юм болов уу? Бид ухаж эхэлсэн бөгөөд өнөөг хүртэл хамгийн чухал сайжруулалтыг олсон.
Тэр үед усан сангаас серверийг нэлээд тэнэг алгоритм ашиглан сонгосон: суваг, хүчнээс хамааран тус бүр өөрийн гэсэн "жинтэй" байсан бөгөөд бид хэрэглэгчийг хамгийн том "жин" рүү илгээхийг оролдсон. хэрэглэгчийн газарзүйн байршилд анхаарлаа хандуулах. Үүний үр дүнд Санкт-Петербургийн багш манай Санкт-Петербург дахь Janus серверээр биш Москвагаар дамжин Сибирийн оюутантай харилцах боломжтой болсон.
Алгоритм дахин хийгдсэн: одоо хэрэглэгч манай платформыг нээхэд бид түүнээс Ajax ашиглан бүх сервер рүү пинг цуглуулдаг. Холболт хийхдээ бид хамгийн бага хэмжээтэй хос пинг (багш-сервер, оюутан-сервер)-ийг сонгоно. Пинг бага байна гэдэг нь сервер хүртэлх сүлжээний зай бага гэсэн үг; богино зай нь пакетуудыг алдах магадлал бага гэсэн үг; Пакет алдагдах нь видео харилцааны хамгийн том сөрөг хүчин зүйл юм. Сөрөг байдлын эзлэх хувь гурван сарын дотор хоёр дахин буурсан (шударга байхын тулд энэ үед бусад туршилтууд хийгдсэн боловч энэ нь бараг л хамгийн их нөлөө үзүүлсэн).
Бид саяхан өөр нэг тодорхой бус, гэхдээ маш чухал зүйлийг олж мэдэв: зузаан суваг дээрх нэг хүчирхэг Janus серверийн оронд илүү нимгэн зурвасын өргөнтэй хоёр энгийн сервертэй байх нь дээр. Бид нэгэн зэрэг олон өрөө (харилцаа холбооны сесс) багтаах найдлагатайгаар хүчирхэг машин худалдаж авсны дараа энэ нь тодорхой болсон. Серверүүд нь зурвасын өргөний хязгаартай байдаг бөгөөд үүнийг бид өрөөний тоонд яг таг орчуулж чаддаг - жишээлбэл, 300 Мбит / сек хурдтайгаар хичнээн нээх боломжтойг бид мэднэ. Сервер дээр хэт олон өрөө нээгдмэгц ачаалал буурах хүртэл бид үүнийг шинэ үйл ажиллагаанд сонгохоо зогсооно. Хүчирхэг машин худалдаж авсны дараа бид сувгийг дээд зэргээр ачаалж, эцэст нь зурвасын өргөнөөр бус процессор, санах ойгоор хязгаарлагдах болно гэсэн санаа байв. Гэхдээ тодорхой тооны нээлттэй өрөөнүүдийн дараа (420) процессор, санах ой, дискний ачаалал хязгаараас хол байгаа хэдий ч техникийн дэмжлэг үзүүлэхэд сөрөг нөлөө үзүүлж эхэлдэг. Янусын дотор ямар нэг зүйл улам дордож байгаа бололтой, магадгүй тэнд бас зарим хязгаарлалтууд байдаг. Бид туршилт хийж, зурвасын өргөний хязгаарыг 300-аас 200 Мбит/с болгон бууруулж, асуудал арилсан. Одоо бид бага хязгаарлалттай, шинж чанартай гурван шинэ серверийг нэг дор худалдаж авсан бөгөөд энэ нь харилцааны чанарыг тогтвортой сайжруулахад хүргэнэ гэж бид бодож байна. Мэдээжийн хэрэг, бид тэнд юу болж байгааг ойлгохыг оролдоогүй; бидний суга таяг бол бүх зүйл юм. Бидний өмгөөллийн хувьд, тэр үед тулгамдсан асуудлыг аль болох хурдан шийдвэрлэх шаардлагатай байсан бөгөөд үүнийг сайхан хийх шаардлагагүй гэж хэлье; Түүнээс гадна Janus бол бидний хувьд C хэл дээр бичигдсэн хар хайрцаг бөгөөд үүнийг хийх нь маш үнэтэй юм.
За, энэ явцад бид:
- сервер болон үйлчлүүлэгчийн аль алинд нь шинэчлэгдэж болох бүх хамаарлыг шинэчилсэн (эдгээр нь бас туршилт байсан, бид үр дүнг хянаж байсан);
- тодорхой тохиолдлуудтай холбоотой бүх тодорхойлсон алдааг зассан, жишээлбэл, холболт тасарч автоматаар сэргээгдэхгүй байх;
- Бид видео харилцааны чиглэлээр ажилладаг компаниудтай олон уулзалт хийсэн бөгөөд бидний асуудалтай танилцсан: стриминг тоглоом, вебинар зохион байгуулах; бидэнд хэрэгтэй санагдсан бүх зүйлийг бид туршиж үзсэн;
- Хамгийн их гомдол ирсэн багш нарын техник хангамж, харилцааны чанарт техникийн үзлэг хийсэн.
Туршилтууд болон дараагийн өөрчлөлтүүд нь багш нарын харилцааны талаархи сэтгэл ханамжгүй байдлыг 7,1 оны 2018-р сард 2,5% байсан бол 2019 оны XNUMX-р сард XNUMX% хүртэл бууруулах боломжтой болсон.
Дараа нь юу юм
Манай Vimbox платформыг тогтворжуулах нь компанийн 2019 оны гол төслүүдийн нэг юм. Бид эрчмээ хадгалж, дээд зэргийн гомдлуудад видео харилцаа холбоог цаашид харахгүй болно гэдэгт их найдаж байна. Эдгээр гомдлын нэлээд хэсэг нь хэрэглэгчдийн компьютер, интернетийн хоцрогдолтой холбоотой гэдгийг бид ойлгож байгаа ч энэ хэсгийг нь тодорхойлж, үлдсэн хэсгийг нь шийдвэрлэх ёстой. Бусад бүх зүйл бол техникийн асуудал, бид үүнийг даван туулах ёстой юм шиг байна.
Хамгийн гол хүндрэл нь бид чанарыг ямар түвшинд сайжруулах боломжтойг мэдэхгүй байгаа явдал юм. Энэ таазыг олж мэдэх нь гол ажил юм. Тиймээс хоёр туршилт хийхээр төлөвлөж байна:
- Janus-аар дамжуулан видеог байлдааны нөхцөлд ердийн p2p-тэй харьцуулах. Энэ туршилтыг аль хэдийн хийсэн бөгөөд бидний шийдэл болон p2p хооронд статистикийн хувьд мэдэгдэхүйц ялгаа олдсонгүй;
- Зөвхөн видео холбооны шийдлээр мөнгө олдог компаниудын үйлчилгээг (үнэтэй) нийлүүлж, тэдгээрийн сөрөг байдлын хэмжээг одоо байгаатай харьцуулцгаая.
Эдгээр хоёр туршилт нь бидэнд хүрч болох зорилгыг тодорхойлж, түүнд анхаарлаа төвлөрүүлэх боломжийг олгоно.
Үүнээс гадна тогтмол шийдэж болох хэд хэдэн ажил байдаг:
- Бид субъектив шүүмжийн оронд харилцааны чанарын техникийн хэмжүүрийг бий болгодог;
- Бид гарсан алдааг илүү нарийвчлалтай шинжлэх, яг хэзээ, хаана үүссэн, тухайн үед ямар холбоогүй мэт санагдсан үйл явдлуудыг ойлгохын тулд илүү нарийвчилсан сессийн бүртгэл хийдэг;
- Хичээл эхлэхээс өмнө бид холболтын чанарын шалгалтыг автоматаар бэлдэж, үйлчлүүлэгчид өөрийн техник хангамж, сувгаас үүдэлтэй сөрөг нөлөөллийн хэмжээг багасгахын тулд холболтыг гараар шалгах боломжийг олгодог;
- Бид хувьсах багцын алдагдал гэх мэт муу нөхцөлд видео холбооны ачааллын туршилтыг боловсруулж, хийх болно;
- алдааг тэсвэрлэх чадварыг нэмэгдүүлэхийн тулд асуудал гарсан тохиолдолд серверийн үйл ажиллагааг өөрчлөх;
- Skype шиг холболтод ямар нэг зүйл буруу байвал бид хэрэглэгчдэд анхааруулах бөгөөд ингэснээр асуудал түүний талд байгааг ойлгох болно.
Дөрөвдүгээр сараас хойш видео харилцааны чиглэл нь зөвхөн Vimbox-ийн нэг хэсэг биш харин өөрийн бүтээгдэхүүнтэй холбоотой Skyeng-ийн бүрэн бие даасан төсөл болсон. Энэ нь бид хүмүүсийг хайж эхэлж байна гэсэн үг юм . За, урьдын адил .
Мэдээжийн хэрэг, бид видео харилцаа холбооны чиглэлээр ажилладаг хүмүүс, компаниудтай идэвхтэй харилцаж байна. Хэрэв та бидэнтэй туршлага солилцохыг хүсвэл бид баяртай байх болно! Сэтгэгдэл бичих, холбоо бариарай - бид бүгдэд нь хариулах болно.
Эх сурвалж: www.habr.com