ویډیو اړیکه د ویمبوکس پلیټ فارم کې د ښوونکي او زده کونکي ترمینځ د اړیکو اصلي لاره ده. موږ ډیر وخت دمخه سکایپ پریښود ، د دریمې ډلې ډیری حلونو هڅه وکړه او په نهایت کې د WebRTC - Janus-gateway ترکیب کې میشت شو. د څه مودې لپاره موږ په هر څه خوشحاله وو، مګر بیا هم ځینې منفي اړخونه راڅرګندېدل. د پایلې په توګه، یو جلا ویډیو لارښود جوړ شو.
ما د نوي سمت مشر کیریل روګووی څخه وغوښتل چې په سکاینګ کې د ویډیو مخابراتو د تکامل په اړه وغږیږي، هغه ستونزې چې موندل شوي، حلونه او کرچونه چې موږ یې په پای کې کاروو. موږ امید لرو چې مقاله به د شرکتونو لپاره ګټوره وي چې د ویب غوښتنلیک له لارې پخپله ویډیو هم رامینځته کوي.
یو څه تاریخ
د 2017 په دوبي کې، د سکاینګ پراختیا مشر، سرګي سفونوف، په Backend Conf کې د یوې کیسې سره خبرې وکړې چې څنګه موږ "سکایپ پریښود او WebRTC پلي کړو." علاقمندان کولی شي د وینا ریکارډ په دې لینک کې وګوري (~ 45 دقیقې)، او دلته به زه په لنډه توګه د هغې جوهر بیان کړم.
د سکاینګ ښوونځي لپاره، ویډیو اړیکه تل د ښوونکي او زده کونکي اړیکو لومړیتوب لاره وه. په لومړي سر کې، سکایپ کارول کیده، مګر دا د یو شمیر دلایلو لپاره په کلکه توګه د قناعت وړ نه و، په عمده توګه د لاګونو نشتوالي او په مستقیم ډول په ویب اپلیکیشن کې د ادغام ناممکنیت له امله. له همدې امله، موږ هر ډول تجربې ترسره کړې.
په حقیقت کې، د ویډیو اړیکو لپاره زموږ اړتیاوې نږدې لاندې وې:
- ثبات؛
- په هر درس کې ټیټه بیه؛
- درسونه ثبتول؛
- دا معلومول چې څوک څومره خبرې کوي (دا زموږ لپاره مهمه ده چې زده کونکي د درسونو په جریان کې د ښوونکي په پرتله ډیرې خبرې وکړي)؛
- خطي اندازه کول؛
- د UDP او TCP دواړو کارولو وړتیا.
لومړی یې هڅه وکړه چې په 2013 کې د توک باکس پلي کړي. هرڅه ښه وو، مګر دا خورا ګران و - په هر درس کې 113 روبله - او ګټه یې وخوړه.
بیا په 2015 کې، Voximplant مدغم شو. دلته هغه فنکشن و چې موږ یې د تعقیبولو لپاره اړتیا درلوده چې څوک څومره خبرې کوي، او په ورته وخت کې حل خورا ارزانه و: که یوازې آډیو ثبت شي، دا په هر درس کې 20 روبله لګښت لري. په هرصورت، دا یوازې د UDP له لارې کار کوي او نشي کولی TCP ته لاړ شي. په هرصورت، شاوخوا 40٪ زده کونکي یې کارول پای ته ورساوه.
یو کال وروسته، موږ د خپلو ځانګړو اړتیاو سره د کارپوریټ پیرودونکي درلودل پیل کړل. د مثال په توګه، هرڅه باید د براوزر له لارې کار وکړي؛ شرکت یوازې http او https پرانیزي؛ د بیلګې په توګه هیڅ سکایپ یا UDP نشته. د کارپوریټ پیرودونکي = پیسې، نو دوی توک باکس ته راستانه شول، مګر د نرخ ستونزه له منځه لاړه.
حل - WebRTC او جانس
د کارولو پریکړه وکړه . دا د اړیکې رامینځته کولو ، کوډ کولو او کوډ کولو جریانونو ، د ټریکونو همغږي کولو او د شبکې خرابیو اداره کولو سره د کیفیت کنټرول مسؤلیت لري. زموږ د برخې لپاره، موږ باید ډاډ ترلاسه کړو چې د کیمرې او مایکروفون څخه د جریانونو لوستل، ویډیو رسمول، د پیوستون اداره کول، د WebRTC اتصال رامینځته کول او هغې ته د جریانونو لیږدول، او همدارنګه د اړیکو رامینځته کولو لپاره د پیرودونکو ترمنځ د سیګنال پیغامونو لیږدول (WebRTC پخپله یوازې تشریح کوي. د معلوماتو بڼه، مګر د لیږد میکانیزم نه). که پیرودونکي د NAT شاته وي، WebRTC د STUN سرورونو سره نښلوي؛ که دا مرسته ونه کړي، سرورونه بدل کړئ.
د p2p منظم اړیکه زموږ لپاره کافي نه ده، ځکه چې موږ غواړو د شکایتونو په صورت کې د نورو تحلیلونو لپاره درسونه ثبت کړو. له همدې امله موږ د ریل له لارې د WebRTC جریان لیږو . د پایلې په توګه، پیرودونکي د یو بل پته نه پیژني، یوازې د جانوس سرور پته ګوري؛ دا د سیګنال سرور دندې هم ترسره کوي. جانس ډیری ځانګړتیاوې لري چې موږ ورته اړتیا لرو: په اتوماتيک ډول TCP ته ځي که چیرې پیرودونکي UDP بند کړي وي؛ کولی شي دواړه UDP او TCP جریان ثبت کړي؛ د توزیع وړ د اکو ازموینو لپاره حتی یو جوړ شوی پلگ ان شتون لري. که اړتیا وي، د Twilio څخه STUN او TURN سرورونه په اوتومات ډول وصل شوي.
د 2017 په دوبي کې، موږ د جانوس دوه سرورونه روان وو، په بیله بیا د ثبت شوي خام آډیو او ویډیو فایلونو پروسس کولو لپاره اضافي سرور، ترڅو د اصلي پروسیسرونو قبضه ونه کړي. کله چې وصل شي ، د جانوس سرورونه د عجیب - حتی اساس (د پیوستون شمیره) غوره شوي. په هغه وخت کې، دا کافي وه، زموږ د احساساتو سره سم، دا نږدې څلور چنده د خوندیتوب حاشیه ورکړه، د پلي کولو سلنه شاوخوا 80 وه. په ورته وخت کې، قیمت په هر درس کې ~ 2 روبلو ته راټیټ شوی، او همدارنګه پراختیا او ملاتړ.
بیرته د ویډیو اړیکو موضوع ته
موږ په دوامداره توګه د زده کونکو او ښوونکو نظرونه څارو ترڅو په وخت سره ستونزې وپیژنو او سمې کړو. د 2018 په دوبي کې ، د تلیفون کیفیت په کلکه د شکایتونو په مینځ کې په لومړي ځای کې و. له یوې خوا، دا پدې مانا وه چې موږ په بریالیتوب سره په نورو نیمګړتیاوو بریالي شوي یو. له بلې خوا، دا اړینه وه چې یو څه سمدستي ترسره شي: که درس ګډوډ شي، موږ د خپل ارزښت له لاسه ورکولو خطر لرو، ځینې وختونه د راتلونکي کڅوړې پیرود لګښت سره، او که ابتدايي درس ګډوډ شي، موږ د احتمالي پیرودونکي له لاسه ورکولو خطر لرو. په ټولیز ډول
په هغه وخت کې، زموږ ویډیو اړیکه لاهم د MVP حالت کې وه. په ساده ډول، دوی دا پیل کړل، دا کار وکړ، دوی یې یو ځل اندازه کړل، دوی پوهیدل چې دا څنګه وکړي - ښه، عالي. که دا کار وکړي، دا مه حل کړئ. هیچا په قصدي ډول د مخابراتو کیفیت مسله په ګوته نه کړه. د اګست په میاشت کې، دا څرګنده شوه چې دا دوام نشي کولی، او موږ یو جلا لار پیل کړه ترڅو معلومه کړو چې د WebRTC او Janus سره څه غلط وو.
په داخل کې، دا لارښوونه ترلاسه شوه: د MVP حل، هیڅ میټریک، هیڅ هدف، د پرمختګ لپاره هیڅ پروسې نشته، پداسې حال کې چې 7٪ ښوونکي د اړیکو کیفیت څخه شکایت کوي (د زده کونکو په اړه هیڅ معلومات شتون نلري).
یو نوی لوری روان دی
امر یو څه داسې ښکاري:
- د څانګې مشر، چې اصلي پراختیا کونکی هم دی.
- QA د بدلونونو ازموینې کې مرسته کوي، د بې ثباته اړیکو شرایطو رامینځته کولو لپاره نوې لارې لټوي، او د لومړۍ کرښې څخه ستونزې راپوروي.
- شنونکی په دوامداره توګه په تخنیکي معلوماتو کې مختلف ارتباطات لټوي، د کاروونکو نظرونو تحلیل ته وده ورکوي، او د تجربو پایلې ګوري.
- د محصول مدیر د تجربو لپاره د سرچینو عمومي لارښود او تخصیص کې مرسته کوي.
- دوهم پرمخ وړونکی اکثرا د برنامه کولو او اړوندو دندو سره مرسته کوي.
د پیل کولو لپاره، موږ یو نسبتا معتبر میټریک جوړ کړ چې د مخابراتو کیفیت ارزونو کې بدلونونه تعقیب کړي (په اوسط ډول د ورځو، اونیو، میاشتو په اوږدو کې). په هغه وخت کې، دا د ښوونکو ټولګي وو؛ وروسته د زده کونکو ټولګي دوی ته اضافه شوي. بیا دوی د هغه څه په اړه فرضیې رامینځته کول پیل کړل چې غلط کار کوي ، سم یې کړي ، او په متحرکاتو کې بدلونونه وګوري. موږ د ټیټ ځړولو میوو لپاره لاړو: د مثال په توګه ، موږ د vp8 کوډیک د vp9 سره بدل کړ ، فعالیت ښه شو. موږ هڅه وکړه چې د جانس ترتیباتو سره لوبې وکړو او نورې تجربې ترسره کړو - په ډیری قضیو کې دوی هیڅ شی ته لار نه وهي.
په دویمه مرحله کې، یوه فرضیه راڅرګنده شوه: WebRTC یو ملګری حل دی، او موږ په مینځ کې یو سرور کاروو. شاید ستونزه دلته ده؟ موږ کیندل پیل کړل او تر دې دمه ترټولو مهم پرمختګ مو وموندل.
په دې شیبه کې، د حوض څخه یو سرور د یو ډیر احمق الګوریتم په کارولو سره غوره شوی و: هر یو خپل "وزن" درلود، د چینل او ځواک پورې اړه لري، او موږ هڅه وکړه چې کاروونکي هغه ته واستوو چې لوی "وزن" لري، پرته له دې. دې ته پام کول چې کاروونکي په جغرافیه کې موقعیت لري. د پایلې په توګه، د سینټ پیټرزبورګ یو ښوونکی کولی شي د سایبریا له زده کونکي سره د مسکو له لارې اړیکه ونیسي، نه په سینټ پیټرزبورګ کې زموږ د جانوس سرور له لارې.
الګوریتم بیا جوړ شوی: اوس، کله چې یو کاروونکي زموږ پلیټ فارم پرانیزي، موږ د ایجیکس په کارولو سره ټولو سرورونو ته پینګونه راټولوو. کله چې اړیکه جوړه کړئ، موږ د پینګونو یوه جوړه غوره کوو (ښوونکی-سرور او زده کونکي-سرور) د لږ مقدار سره. لږ پینګ پدې معنی دی چې سرور ته د شبکې فاصله کمه ده؛ لنډ واټن پدې معنی دی چې د کڅوړو له لاسه ورکولو کم احتمال؛ د پاکټ ضایع د ویډیو اړیکو ترټولو لوی منفي فکتور دی. د منفي ونډه په دریو میاشتو کې نیمایي ته راښکته شوه (د عادلانه وي، په دې وخت کې نورې تجربې ترسره شوې، مګر دا تقریبا یقینا خورا اغیز درلود).
موږ پدې وروستیو کې یو بل غیر څرګند ، مګر په ښکاره ډول مهم شی وموندل: په یو موټی چینل کې د یو ځواکمن جانوس سرور پرځای ، دا غوره ده چې دوه ساده د پتلي بینډ ویت سره ولرئ. دا وروسته له هغه روښانه شوه چې موږ په ورته وخت کې د ډیری خونو (د مخابراتو ناستې) د مینځلو په امید کې ځواکمن ماشینونه وپیرو. سرورونه د بینډ ویت حد لري، کوم چې موږ کولی شو د خونو شمیر په سمه توګه وژباړو - موږ پوهیږو چې څومره خلاص کیدی شي، د بیلګې په توګه، په 300 Mbit/s کې. هرڅومره ژر چې په سرور کې ډیری خونې خلاصې وي ، موږ د نوي فعالیتونو لپاره غوره کول بندوو تر هغه چې بار کم شي. نظر دا و چې ، د یو ځواکمن ماشین پیرودلو سره ، موږ به چینل تر اعظمي حد پورې پورته کړو ، ترڅو په پای کې دا د پروسیسر او حافظې لخوا محدود وي ، نه د بنډ ویت لخوا. مګر دا معلومه شوه چې د یو مشخص شمیر خلاص خونو (420) وروسته، د دې حقیقت سره سره چې د پروسیسر، حافظې او ډیسک بار لا تر اوسه د حد څخه ډیر دی، منفي تخنیکي مالتړ ته رسیدل پیل کوي. په ښکاره ډول ، د جانوس دننه یو څه خرابیږي ، شاید هلته هم ځینې محدودیتونه شتون ولري. موږ تجربه پیل کړه، د بینډ ویت حد له 300 څخه 200 Mbit/s ته راټیټ کړ، او ستونزې لرې شوې. اوس موږ د ټیټ محدودیتونو او ځانګړتیاو سره په یوځل کې درې نوي سرورونه اخیستي، موږ فکر کوو چې دا به د اړیکو کیفیت کې د ثابت پرمختګ لامل شي. البته، موږ هڅه نه ده کړې چې معلومه کړو چې هلته څه روان دي؛ زموږ بیسارې هرڅه دي. زموږ په دفاع کې، راځئ چې ووایو چې په هغه وخت کې دا اړینه وه چې ژر تر ژره د فشار ستونزه حل کړي، او دا په ښکلي ډول ترسره نه کړي؛ برسېره پردې، زموږ لپاره جانوس یو تور بکس دی چې په C کې لیکل شوی، دا خورا ګران دی چې ورسره ټیکر وکړئ.
ښه، په پروسه کې موږ:
- ټول انحصارونه تازه کړل چې تازه کیدی شي، دواړه په سرور او پیرودونکي کې (دا هم تجربې وې، موږ پایلې څارلې)؛
- د ځانګړو قضیو پورې اړوند ټول پیژندل شوي بګونه حل کړي، د بیلګې په توګه، کله چې پیوستون راټیټ شو او په اوتومات ډول بحال نه شو؛
- موږ د هغو شرکتونو سره ډیری ناستې ترسره کړې چې د ویډیو مخابراتو په برخه کې کار کوي او زموږ له ستونزو سره آشنا دي: د لوبو سټینګ کول، د ویبینارونو تنظیم کول؛ موږ هر هغه څه هڅه وکړه چې زموږ لپاره ګټور ښکاري؛
- د ښوونکو د هارډویر او مخابراتو کیفیت تخنیکي بیاکتنه ترسره کړه، له کومو څخه چې ډیری شکایتونه راغلي.
تجربو او وروسته بدلونونو دا ممکنه کړه چې د ښوونکو ترمنځ د اړیکو په اړه نا رضایتي د 7,1 په جنوري کې 2018٪ څخه په جنوري 2,5 کې 2019٪ ته راټیټ کړي.
نور څه شی دی
زموږ د Vimbox پلیټ فارم ثبات د 2019 لپاره د شرکت له اصلي پروژو څخه دی. موږ لوړې هیلې لرو چې موږ به وکولی شو حرکت وساتو او نور به په لوړ شکایتونو کې ویډیو اړیکه ونه ګورو. موږ پوهیږو چې د دې شکایتونو یوه د پام وړ برخه د کاروونکو کمپیوټرونو او انټرنیټ کې ځنډ سره تړاو لري، مګر موږ باید دا برخه وټاکو او پاتې یې حل کړو. نور هر څه تخنیکي ستونزه ده، داسې ښکاري چې موږ باید د هغې سره مقابله وکړو.
اصلي ستونزه دا ده چې موږ نه پوهیږو چې د کیفیت ښه کول واقعیا کومې کچې ته رسیدلي دي. د دې چت معلومول اصلي دنده ده. له همدې امله، دوه تجربې پالن شوي:
- په جنګي شرایطو کې د منظم p2p سره د جانوس له لارې ویډیو پرتله کړئ. دا تجربه لا دمخه ترسره شوې، زموږ د حل او p2p ترمنځ د احصایې له پلوه د پام وړ توپیر ندی موندل شوی؛
- راځئ چې د هغو شرکتونو څخه (ګران) خدمات عرضه کړو چې په ځانګړې توګه د ویډیو مخابراتو حلونو څخه پیسې ګټي، او د دوی څخه د منفي اندازه د موجوده سره پرتله کړئ.
دا دوه تجربې به موږ ته اجازه راکړي چې د لاسته راوړلو وړ هدف وپیژنو او په هغې تمرکز وکړو.
سربیره پردې، یو شمیر دندې شتون لري چې په منظمه توګه حل کیدی شي:
- موږ د موضوعي بیاکتنې پرځای د مخابراتو کیفیت تخنیکي میټریک رامینځته کوو؛
- موږ د سیشن نور تفصيلي لاګونه جوړوو ترڅو هغه ناکامي په سمه توګه تحلیل کړو چې واقع کیږي، پوهیږو چې کله او چیرته واقع شوي، او هغه څه چې په هغه وخت کې داسې ښکاري چې غیر اړونده پیښې واقع شوي؛
- موږ د لوست څخه دمخه د اتوماتیک پیوستون کیفیت ازموینه چمتو کوو ، او پیرودونکي ته دا فرصت هم ورکوو چې په لاسي ډول د پیوستون ازموینه وکړي ترڅو د هغه د هارډویر او چینل له امله رامینځته شوي منفي مقدار کم کړي؛
- موږ به په ضعیف شرایطو کې د ویدیو مخابراتو بار ازموینې رامینځته او ترسره کړو ، د متغیر پاکټ ضایع کیدو سره ، او داسې نور؛
- موږ د ستونزو په صورت کې د سرورونو چلند بدلوو ترڅو د غلطۍ زغم زیات کړي؛
- موږ به کارونکي ته خبرداری ورکړو که چیرې د هغه په اړیکه کې کوم څه غلط وي ، لکه څنګه چې سکایپ کوي ، ترڅو هغه پوه شي چې ستونزه د هغه په غاړه ده.
د اپریل راهیسې ، د ویډیو مخابراتو لارښود په سکاینګ کې په بشپړ ډول جلا پروژه ګرځیدلې ، د خپل محصول سره معامله کوي ، نه یوازې د ویمبوکس برخه. دا پدې مانا ده چې موږ د خلکو په لټه کې یو . ښه، د تل په څیر .
او البته، موږ په فعاله توګه د خلکو او شرکتونو سره د ویډیو مخابراتو سره کار کولو ته ادامه ورکوو. که تاسو غواړئ زموږ سره تجربه تبادله کړئ، موږ به خوښ یو! تبصره وکړئ، اړیکه ونیسئ - موږ به ټولو ته ځواب ووایو.
سرچینه: www.habr.com