ຈາກ Skype ໄປ WebRTC: ພວກເຮົາຈັດການສື່ສານວິດີໂອຜ່ານເວັບແນວໃດ

ການສື່ສານວິດີໂອແມ່ນວິທີການຕົ້ນຕໍຂອງການສື່ສານລະຫວ່າງຄູແລະນັກຮຽນໃນເວທີ Vimbox. ພວກເຮົາໄດ້ປະຖິ້ມ Skype ເປັນເວລາດົນນານກ່ອນຫນ້ານີ້, ພະຍາຍາມແກ້ໄຂບັນຫາຂອງພາກສ່ວນທີສາມຫຼາຍຄັ້ງແລະໃນທີ່ສຸດກໍໄດ້ຕົກລົງໃນ WebRTC - Janus-gateway ປະສົມປະສານ. ສໍາລັບບາງຄັ້ງພວກເຮົາມີຄວາມສຸກກັບທຸກສິ່ງທຸກຢ່າງ, ແຕ່ຍັງມີບາງດ້ານລົບຍັງສືບຕໍ່ອອກມາ. ດັ່ງນັ້ນ, ທິດທາງວິດີໂອແຍກຕ່າງຫາກໄດ້ຖືກສ້າງຂື້ນ.

ຂ້າພະເຈົ້າໄດ້ຂໍໃຫ້ Kirill Rogovoy, ຫົວຫນ້າທິດທາງໃຫມ່, ເວົ້າກ່ຽວກັບວິວັດທະນາຂອງການສື່ສານວິດີໂອຢູ່ Skyeng, ບັນຫາທີ່ຄົ້ນພົບ, ວິທີແກ້ໄຂແລະໄມ້ຄ້ອນເທົ້າທີ່ພວກເຮົາໃຊ້ໃນທີ່ສຸດ. ພວກເຮົາຫວັງວ່າບົດຄວາມຈະເປັນປະໂຫຍດສໍາລັບບໍລິສັດທີ່ຍັງສ້າງວິດີໂອດ້ວຍຕົນເອງໂດຍຜ່ານຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌.

ບາງປະຫວັດສາດ

ໃນຊ່ວງລຶະເບິ່ງຮ້ອນຂອງ 2017, ຫົວຫນ້າການພັດທະນາ Skyeng, Sergey Safonov, ໄດ້ໂອ້ລົມກັບ Backend Conf ດ້ວຍເລື່ອງກ່ຽວກັບວິທີທີ່ພວກເຮົາ "ປະຖິ້ມ Skype ແລະປະຕິບັດ WebRTC." ຜູ້ທີ່ສົນໃຈສາມາດເຂົ້າໄປເບິ່ງບັນທຶກສຽງກ່າວໄດ້ທີ່ ການເຊື່ອມຕໍ່ (~45 ນາ​ທີ) ແລະ​ໃນ​ທີ່​ນີ້​ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ອະ​ທິ​ບາຍ​ໂດຍ​ຫຍໍ້​ໂດຍ​ເນື້ອ​ແທ້​ຂອງ​ມັນ​.

ສໍາລັບໂຮງຮຽນ Skyeng, ການສື່ສານທາງວິດີໂອແມ່ນສະເຫມີໄປເປັນວິທີການບູລິມະສິດຂອງການສື່ສານຄູອາຈານແລະນັກສຶກສາ. ໃນຕອນທໍາອິດ, Skype ຖືກນໍາໃຊ້, ແຕ່ວ່າມັນເປັນປະເພດທີ່ບໍ່ຫນ້າພໍໃຈສໍາລັບເຫດຜົນຈໍານວນຫນຶ່ງ, ຕົ້ນຕໍແມ່ນຍ້ອນການຂາດບັນທຶກແລະຄວາມບໍ່ເປັນໄປໄດ້ຂອງການເຊື່ອມໂຍງໂດຍກົງເຂົ້າໃນຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌. ເພາະສະນັ້ນ, ພວກເຮົາດໍາເນີນການທົດລອງທຸກປະເພດ.

ໃນຄວາມເປັນຈິງ, ຄວາມຕ້ອງການຂອງພວກເຮົາສໍາລັບການສື່ສານວິດີໂອແມ່ນປະມານດັ່ງຕໍ່ໄປນີ້:
- ຄວາມ​ຫມັ້ນ​ຄົງ​;
- ລາຄາຕໍ່າຕໍ່ບົດຮຽນ;
- ການ​ບັນ​ທຶກ​ບົດ​ຮຽນ​;
— ການ​ຕິດ​ຕາມ​ຜູ້​ທີ່​ເວົ້າ​ຫຼາຍ​ປານ​ໃດ (ມັນ​ເປັນ​ສິ່ງ​ສໍາ​ຄັນ​ສໍາ​ລັບ​ພວກ​ເຮົາ​ທີ່​ນັກ​ຮຽນ​ເວົ້າ​ຫຼາຍ​ກ​່​ວາ​ຄູ​ອາ​ຈານ​ໃນ​ລະ​ຫວ່າງ​ການ​ຮຽນ​)​;
- ການ​ປັບ​ຂະ​ຫນາດ​ເສັ້ນ​;
- ຄວາມສາມາດໃນການນໍາໃຊ້ທັງ UDP ແລະ TCP.

ສິ່ງທໍາອິດທີ່ພະຍາຍາມແມ່ນການປະຕິບັດ Tokbox ໃນປີ 2013. ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ແຕ່ມັນໄດ້ກາຍເປັນລາຄາແພງຫຼາຍ - 113 rubles ຕໍ່ບົດຮຽນ - ແລະໄດ້ຮັບຜົນກໍາໄລ.

ຫຼັງຈາກນັ້ນ, ໃນປີ 2015, Voximplant ໄດ້ຖືກປະສົມປະສານ. ນີ້ແມ່ນຫນ້າທີ່ທີ່ພວກເຮົາຕ້ອງການເພື່ອຕິດຕາມຜູ້ທີ່ເວົ້າຫຼາຍປານໃດ, ແລະໃນເວລາດຽວກັນການແກ້ໄຂແມ່ນລາຄາຖືກກວ່າຫຼາຍ: ຖ້າພຽງແຕ່ບັນທຶກສຽງ, ມັນມີມູນຄ່າ 20 rubles ຕໍ່ບົດຮຽນ. ຢ່າງໃດກໍ່ຕາມ, ມັນພຽງແຕ່ເຮັດວຽກຜ່ານ UDP ແລະບໍ່ສາມາດປ່ຽນເປັນ TCP. ຢ່າງໃດກໍຕາມ, ປະມານ 40% ຂອງນັກຮຽນໄດ້ສິ້ນສຸດລົງເຖິງການນໍາໃຊ້ມັນ.

ປີຕໍ່ມາ, ພວກເຮົາເລີ່ມມີລູກຄ້າຂອງບໍລິສັດທີ່ມີຄວາມຕ້ອງການສະເພາະຂອງຕົນເອງ. ຕົວຢ່າງ, ທຸກສິ່ງທຸກຢ່າງຄວນເຮັດວຽກຜ່ານຕົວທ່ອງເວັບ, ບໍລິສັດພຽງແຕ່ເປີດ http ແລະ https; i.e. ບໍ່ມີ Skype ຫຼື UDP. ລູກຄ້າຂອງບໍລິສັດ = ເງິນ, ດັ່ງນັ້ນພວກເຂົາກັບຄືນໄປຫາ Tokbox, ແຕ່ບັນຫາຂອງລາຄາບໍ່ໄດ້ຫມົດໄປ.

ການແກ້ໄຂ - WebRTC ແລະ Janus

ຕັດສິນໃຈໃຊ້ ແພລະຕະຟອມຂອງຕົວທ່ອງເວັບສໍາລັບການສື່ສານວິດີໂອແບບ peer-to-peer WebRTC. ມັນ​ເປັນ​ຜູ້​ຮັບ​ຜິດ​ຊອບ​ສໍາ​ລັບ​ການ​ສ້າງ​ຕັ້ງ​ການ​ເຊື່ອມ​ຕໍ່​, ການ​ເຂົ້າ​ລະ​ຫັດ​ແລະ​ການ​ຖອດ​ລະ​ຫັດ​ສາຍ​, synchronizing ຕິດ​ຕາມ​ແລະ​ການ​ຄວບ​ຄຸມ​ຄຸນ​ນະ​ພາບ​ທີ່​ມີ​ການ​ຈັດ​ການ glitches ເຄືອ​ຂ່າຍ​. ສໍາລັບພາກສ່ວນຂອງພວກເຮົາ, ພວກເຮົາຕ້ອງຮັບປະກັນການອ່ານນ້ໍາຈາກກ້ອງຖ່າຍຮູບແລະໄມໂຄໂຟນ, ແຕ້ມວິດີໂອ, ການຄຸ້ມຄອງການເຊື່ອມຕໍ່, ສ້າງຕັ້ງການເຊື່ອມຕໍ່ WebRTC ແລະການຖ່າຍທອດນ້ໍາກັບມັນ, ເຊັ່ນດຽວກັນກັບການສົ່ງຂໍ້ຄວາມສັນຍານລະຫວ່າງລູກຄ້າເພື່ອສ້າງການເຊື່ອມຕໍ່ (WebRTC ຕົວຂອງມັນເອງອະທິບາຍພຽງແຕ່. ຮູບແບບຂໍ້ມູນ, ແຕ່ບໍ່ແມ່ນກົນໄກການໂອນຂອງມັນ). ຖ້າລູກຄ້າຢູ່ເບື້ອງຫຼັງ NAT, WebRTC ເຊື່ອມຕໍ່ເຊີບເວີ STUN; ຖ້າອັນນີ້ບໍ່ຊ່ວຍ, ລ້ຽວເຊີບເວີ.

ການເຊື່ອມຕໍ່ p2p ປົກກະຕິແມ່ນບໍ່ພຽງພໍສໍາລັບພວກເຮົາ, ເພາະວ່າພວກເຮົາຕ້ອງການບັນທຶກບົດຮຽນສໍາລັບການວິເຄາະຕື່ມອີກໃນກໍລະນີຂອງການຮ້ອງທຸກ. ດັ່ງນັ້ນພວກເຮົາສົ່ງ WebRTC streams ຜ່ານ relay Janus Gateway ໂດຍ Metecho. ດັ່ງນັ້ນ, ລູກຄ້າບໍ່ຮູ້ທີ່ຢູ່ຂອງແຕ່ລະຄົນ, ເຫັນພຽງແຕ່ທີ່ຢູ່ຂອງເຄື່ອງແມ່ຂ່າຍຂອງ Janus; ມັນຍັງປະຕິບັດຫນ້າທີ່ຂອງເຄື່ອງແມ່ຂ່າຍສັນຍານ. Janus ມີຫຼາຍລັກສະນະທີ່ພວກເຮົາຕ້ອງການ: ອັດຕະໂນມັດປ່ຽນເປັນ TCP ຖ້າລູກຄ້າຖືກບລັອກ UDP; ສາມາດບັນທຶກທັງ UDP ແລະ TCP streams; ຂະຫຍາຍໄດ້; ມີແມ້ກະທັ້ງ plugin ກໍ່ສ້າງໃນການທົດສອບ echo. ຖ້າຈໍາເປັນ, ເຊີບເວີ STUN ແລະ TURN ຈາກ Twilio ແມ່ນເຊື່ອມຕໍ່ໂດຍອັດຕະໂນມັດ.

ໃນຊ່ວງລຶະເບິ່ງຮ້ອນຂອງ 2017, ພວກເຮົາມີສອງເຊີບເວີ Janus ແລ່ນ, ບວກກັບເຄື່ອງແມ່ຂ່າຍເພີ່ມເຕີມສໍາລັບການປະມວນຜົນໄຟລ໌ສຽງແລະວິດີໂອດິບທີ່ບັນທຶກໄວ້, ເພື່ອບໍ່ໃຫ້ຄອບຄອງໂປເຊດເຊີຂອງຕົ້ນຕໍ. ເມື່ອເຊື່ອມຕໍ່, ເຊີບເວີ Janus ຖືກເລືອກບົນພື້ນຖານຄີກ-ຄູ່ (ໝາຍເລກເຊື່ອມຕໍ່). ໃນເວລານັ້ນ, ນີ້ແມ່ນພຽງພໍ, ອີງຕາມຄວາມຮູ້ສຶກຂອງພວກເຮົາ, ມັນໃຫ້ອັດຕາຄວາມປອດໄພປະມານສີ່ເທົ່າ, ອັດຕາສ່ວນການປະຕິບັດແມ່ນປະມານ 80. ໃນຂະນະດຽວກັນ, ລາຄາໄດ້ຖືກຫຼຸດລົງເປັນ ~ 2 rubles ຕໍ່ບົດຮຽນ, ບວກກັບການພັດທະນາແລະການສະຫນັບສະຫນູນ.

ກັບຄືນໄປຫາຫົວຂໍ້ຂອງການສື່ສານວິດີໂອ

ພວກ​ເຮົາ​ຕິດ​ຕາມ​ກວດ​ກາ​ຄໍາ​ຄຶດ​ຄໍາ​ເຫັນ​ຂອງ​ນັກ​ຮຽນ​ແລະ​ຄູ​ອາ​ຈານ​ຢູ່​ສະ​ເຫມີ​ເພື່ອ​ກໍາ​ນົດ​ແລະ​ແກ້​ໄຂ​ບັນ​ຫາ​ໄດ້​ທັນ​ເວ​ລາ​. ໃນຊ່ວງລຶະເບິ່ງຮ້ອນຂອງປີ 2018, ຄຸນນະພາບການໂທແມ່ນຢືນຢູ່ໃນອັນດັບທໍາອິດໃນບັນດາຄໍາຮ້ອງທຸກ. ໃນອີກດ້ານຫນຶ່ງ, ນີ້ຫມາຍຄວາມວ່າພວກເຮົາໄດ້ເອົາຊະນະຂໍ້ບົກຜ່ອງອື່ນໆຢ່າງສໍາເລັດຜົນ. ໃນທາງກົງກັນຂ້າມ, ມັນຈໍາເປັນຕ້ອງເຮັດອັນຮີບດ່ວນ: ຖ້າບົດຮຽນຖືກຂັດຂວາງ, ພວກເຮົາມີຄວາມສ່ຽງຕໍ່ການສູນເສຍມູນຄ່າຂອງມັນ, ບາງຄັ້ງພ້ອມກັບຄ່າໃຊ້ຈ່າຍໃນການຊື້ຊຸດຕໍ່ໄປ, ແລະຖ້າບົດຮຽນເບື້ອງຕົ້ນຖືກລົບກວນ, ພວກເຮົາມີຄວາມສ່ຽງຕໍ່ການສູນເສຍລູກຄ້າທີ່ເປັນໄປໄດ້. ທັງໝົດ.

ໃນເວລານັ້ນ, ການສື່ສານວິດີໂອຂອງພວກເຮົາຍັງຢູ່ໃນໂຫມດ MVP. ເວົ້າງ່າຍໆ, ພວກເຂົາເປີດຕົວມັນ, ມັນເຮັດວຽກ, ພວກເຂົາຂະຫຍາຍມັນຄັ້ງດຽວ, ພວກເຂົາເຂົ້າໃຈວິທີການເຮັດມັນ - ດີ, ດີຫຼາຍ. ຖ້າມັນເຮັດວຽກ, ຢ່າແກ້ໄຂມັນ. ບໍ່ມີໃຜຕັ້ງໃຈແກ້ໄຂບັນຫາຄຸນນະພາບການສື່ສານ. ມາຮອດເດືອນສິງຫາ, ມັນໄດ້ກາຍເປັນທີ່ຊັດເຈນວ່າອັນນີ້ບໍ່ສາມາດສືບຕໍ່ໄດ້, ແລະພວກເຮົາໄດ້ເປີດຕົວທິດທາງແຍກຕ່າງຫາກເພື່ອຄົ້ນຫາສິ່ງທີ່ຜິດພາດກັບ WebRTC ແລະ Janus.

ໃນການປ້ອນຂໍ້ມູນ, ທິດທາງນີ້ໄດ້ຮັບ: ການແກ້ໄຂ MVP, ບໍ່ມີ metrics, ບໍ່ມີເປົ້າຫມາຍ, ບໍ່ມີຂະບວນການປັບປຸງ, ໃນຂະນະທີ່ 7% ຂອງຄູສອນຈົ່ມກ່ຽວກັບຄຸນນະພາບຂອງການສື່ສານ (ບໍ່ມີຂໍ້ມູນກ່ຽວກັບນັກຮຽນ).

ທິດທາງໃໝ່ກຳລັງດຳເນີນຢູ່

ຄໍາສັ່ງມີລັກສະນະຄ້າຍຄືນີ້:

• ຫົວຫນ້າພະແນກ, ຜູ້ທີ່ຍັງເປັນຜູ້ພັດທະນາຕົ້ນຕໍ.
• QA ຊ່ວຍທົດສອບການປ່ຽນແປງ, ຊອກຫາວິທີໃຫມ່ເພື່ອສ້າງເງື່ອນໄຂການສື່ສານທີ່ບໍ່ຫມັ້ນຄົງ, ແລະລາຍງານບັນຫາຈາກແຖວຫນ້າ.
• ນັກວິເຄາະຊອກຫາຄວາມກ່ຽວຂ້ອງກັນຢ່າງຕໍ່ເນື່ອງໃນຂໍ້ມູນດ້ານວິຊາການ, ປັບປຸງການວິເຄາະຄວາມຄິດເຫັນຂອງຜູ້ໃຊ້, ແລະກວດເບິ່ງຜົນຂອງການທົດລອງ.
• ຜູ້ຈັດການຜະລິດຕະພັນຊ່ວຍໃນທິດທາງລວມແລະການຈັດສັນຊັບພະຍາກອນສໍາລັບການທົດລອງ.
• ຜູ້ພັດທະນາທີສອງມັກຈະຊ່ວຍໃນການຂຽນໂປລແກລມແລະວຽກງານທີ່ກ່ຽວຂ້ອງ.

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ພວກເຮົາຕັ້ງຄ່າ metric ທີ່ເຊື່ອຖືໄດ້ທີ່ຕິດຕາມການປ່ຽນແປງການປະເມີນຄຸນນະພາບການສື່ສານ (ສະເລ່ຍໃນມື້, ອາທິດ, ເດືອນ). ໃນ​ເວ​ລາ​ນັ້ນ​, ເຫຼົ່າ​ນີ້​ແມ່ນ​ຊັ້ນ​ຮຽນ​ຈາກ​ຄູ​ອາ​ຈານ​, ຫຼັງ​ຈາກ​ນັ້ນ​ຊັ້ນ​ຮຽນ​ຈາກ​ນັກ​ຮຽນ​ໄດ້​ຖືກ​ເພີ່ມ​ໃຫ້​ເຂົາ​ເຈົ້າ​. ຫຼັງຈາກນັ້ນ, ພວກເຂົາເຈົ້າໄດ້ເລີ່ມຕົ້ນທີ່ຈະສ້າງສົມມຸດຕິຖານກ່ຽວກັບສິ່ງທີ່ເຮັດວຽກຜິດພາດ, ແກ້ໄຂມັນ, ແລະເບິ່ງການປ່ຽນແປງໃນນະໂຍບາຍດ້ານ. ພວກເຮົາໄດ້ໄປຫາຫມາກໄມ້ທີ່ຫ້ອຍຕ່ໍາ: ຕົວຢ່າງ, ພວກເຮົາໄດ້ປ່ຽນຕົວແປງສັນຍານ vp8 ດ້ວຍ vp9, ການປະຕິບັດການປັບປຸງ. ພວກເຮົາໄດ້ພະຍາຍາມຫຼິ້ນກັບການຕັ້ງຄ່າ Janus ແລະດໍາເນີນການທົດລອງອື່ນໆ - ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ພວກເຂົາບໍ່ໄດ້ນໍາໄປສູ່ສິ່ງໃດ.

ໃນຂັ້ນຕອນທີສອງ, ການສົມມຸດຕິຖານໄດ້ເກີດຂື້ນ: WebRTC ແມ່ນການແກ້ໄຂ peer-to-peer, ແລະພວກເຮົາໃຊ້ເຄື່ອງແມ່ຂ່າຍກາງ. ບາງທີບັນຫາແມ່ນຢູ່ທີ່ນີ້? ພວກເຮົາໄດ້ເລີ່ມຂຸດຄົ້ນແລະພົບເຫັນການປັບປຸງທີ່ສໍາຄັນທີ່ສຸດມາເຖິງຕອນນັ້ນ.

ໃນເວລານີ້, ເຄື່ອງແມ່ຂ່າຍຈາກສະນຸກເກີໄດ້ຖືກເລືອກໂດຍໃຊ້ສູດການຄິດໄລ່ທີ່ໂງ່ຫຼາຍ: ແຕ່ລະຄົນມີ "ນ້ໍາຫນັກ", ຂຶ້ນກັບຊ່ອງທາງແລະພະລັງງານ, ແລະພວກເຮົາໄດ້ພະຍາຍາມສົ່ງຜູ້ໃຊ້ໄປຫາຜູ້ທີ່ມີ "ນ້ໍາຫນັກ" ທີ່ໃຫຍ່ທີ່ສຸດ, ໂດຍບໍ່ມີການ ເອົາໃຈໃສ່ກັບບ່ອນທີ່ຜູ້ໃຊ້ຕັ້ງພູມສັນຖານ. ດັ່ງນັ້ນ, ຄູສອນຈາກເຊນປີເຕີສະເບີກສາມາດສື່ສານກັບນັກຮຽນຈາກ Siberia ຜ່ານ Moscow, ແລະບໍ່ແມ່ນຜ່ານເຄື່ອງແມ່ຂ່າຍ Janus ຂອງພວກເຮົາໃນ St.

ສູດການຄິດໄລ່ໄດ້ຖືກເຮັດຄືນໃຫມ່: ໃນປັດຈຸບັນ, ເມື່ອຜູ້ໃຊ້ເປີດເວທີຂອງພວກເຮົາ, ພວກເຮົາເກັບກໍາຂໍ້ມູນ pings ຈາກລາວໄປຫາເຄື່ອງແມ່ຂ່າຍທັງຫມົດໂດຍໃຊ້ Ajax. ເມື່ອສ້າງການເຊື່ອມຕໍ່, ພວກເຮົາເລືອກຄູ່ pings (ຄູ - ເຊີຟເວີແລະນັກຮຽນ - ເຄື່ອງແມ່ຂ່າຍ) ທີ່ມີຈໍານວນນ້ອຍທີ່ສຸດ. ping ຫນ້ອຍຫມາຍຄວາມວ່າໄລຍະເຄືອຂ່າຍຫນ້ອຍລົງກັບເຄື່ອງແມ່ຂ່າຍ; ໄລຍະຫ່າງທີ່ສັ້ນກວ່າຫມາຍເຖິງຄວາມເປັນໄປໄດ້ທີ່ຕໍ່າກວ່າຂອງການສູນເສຍແພັກເກັດ; ການສູນເສຍແພັກເກັດແມ່ນປັດໃຈລົບທີ່ໃຫຍ່ທີ່ສຸດໃນການສື່ສານວິດີໂອ. ສ່ວນແບ່ງທາງລົບຫຼຸດລົງເຄິ່ງຫນຶ່ງໃນສາມເດືອນ (ເພື່ອຄວາມຍຸຕິທໍາ, ການທົດລອງອື່ນໆໄດ້ຖືກປະຕິບັດໃນເວລານີ້, ແຕ່ນີ້ເກືອບແນ່ນອນວ່າມີຜົນກະທົບຫຼາຍທີ່ສຸດ).

ພວກເຮົາບໍ່ດົນມານີ້ໄດ້ຄົ້ນພົບສິ່ງອື່ນທີ່ບໍ່ຊັດເຈນ, ແຕ່ເຫັນໄດ້ຊັດເຈນວ່າມີຄວາມສໍາຄັນ: ແທນທີ່ຈະເປັນເຄື່ອງແມ່ຂ່າຍ Janus ທີ່ມີປະສິດທິພາບຫນຶ່ງຢູ່ໃນຊ່ອງທາງຫນາ, ມັນດີກວ່າທີ່ຈະມີສອງອັນທີ່ງ່າຍດາຍກວ່າທີ່ມີແບນວິດບາງກວ່າ. ນີ້ໄດ້ກາຍເປັນທີ່ຊັດເຈນຫຼັງຈາກທີ່ພວກເຮົາຊື້ເຄື່ອງຈັກທີ່ມີປະສິດທິພາບໃນຄວາມຫວັງທີ່ຈະບີບອັດຫ້ອງຫຼາຍ (ກອງປະຊຸມການສື່ສານ) ເຂົ້າໄປໃນພວກມັນໃນເວລາດຽວກັນ. ເຄື່ອງແມ່ຂ່າຍມີຂອບເຂດຈໍາກັດແບນວິດ, ເຊິ່ງພວກເຮົາສາມາດແປໄດ້ຢ່າງຖືກຕ້ອງກ່ຽວກັບຈໍານວນຫ້ອງ - ພວກເຮົາຮູ້ວ່າສາມາດເປີດໄດ້ຫຼາຍປານໃດ, ຕົວຢ່າງ, ຢູ່ທີ່ 300 Mbit / s. ທັນທີທີ່ມີຫ້ອງຫຼາຍເກີນໄປເປີດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ, ພວກເຮົາຢຸດເຊົາເລືອກມັນສໍາລັບກິດຈະກໍາໃຫມ່ຈົນກ່ວາການໂຫຼດຫຼຸດລົງ. ຄວາມຄິດແມ່ນວ່າ, ໄດ້ຊື້ເຄື່ອງຈັກທີ່ມີປະສິດທິພາບ, ພວກເຮົາຈະໂຫລດຊ່ອງທາງໃຫ້ມັນສູງສຸດ, ດັ່ງນັ້ນໃນທີ່ສຸດມັນຈະຖືກຈໍາກັດໂດຍໂປເຊດເຊີແລະຫນ່ວຍຄວາມຈໍາ, ແລະບໍ່ແມ່ນແບນວິດ. ແຕ່ມັນໄດ້ຫັນອອກວ່າຫຼັງຈາກຈໍານວນທີ່ແນ່ນອນຂອງຫ້ອງເປີດ (420), ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າການໂຫຼດຢູ່ໃນໂປເຊດເຊີ, ຫນ່ວຍຄວາມຈໍາແລະແຜ່ນແມ່ນຍັງຢູ່ໄກຈາກຂອບເຂດຈໍາກັດ, ຄວາມບໍ່ພໍໃຈເລີ່ມຕົ້ນມາຮອດການສະຫນັບສະຫນູນດ້ານວິຊາການ. ປາກົດຂື້ນ, ບາງສິ່ງບາງຢ່າງຮ້າຍແຮງຂຶ້ນພາຍໃນ Janus, ບາງທີອາດມີຂໍ້ຈໍາກັດບາງຢ່າງຢູ່ທີ່ນັ້ນ. ພວກເຮົາເລີ່ມທົດລອງ, ຫຼຸດຂີດຈຳກັດແບນວິດຈາກ 300 ຫາ 200 Mbit/s, ແລະບັນຫາຕ່າງໆກໍ່ຫາຍໄປ. ໃນປັດຈຸບັນພວກເຮົາໄດ້ຊື້ສາມເຄື່ອງແມ່ຂ່າຍໃຫມ່ໃນເວລາດຽວກັນທີ່ມີຂໍ້ຈໍາກັດຕ່ໍາແລະຄຸນລັກສະນະ, ພວກເຮົາຄິດວ່ານີ້ຈະນໍາໄປສູ່ການປັບປຸງທີ່ຫມັ້ນຄົງໃນຄຸນນະພາບຂອງການສື່ສານ. ແນ່ນອນ, ພວກເຮົາບໍ່ໄດ້ພະຍາຍາມຊອກຫາສິ່ງທີ່ເກີດຂຶ້ນຢູ່ທີ່ນັ້ນ; ໄມ້ຄ້ອນເທົ້າຂອງພວກເຮົາແມ່ນທຸກສິ່ງທຸກຢ່າງ. ໃນ​ການ​ປ້ອງ​ກັນ​ປະ​ເທດ​ຂອງ​ພວກ​ເຮົາ, ໃຫ້​ເວົ້າ​ວ່າ​ໃນ​ເວ​ລາ​ນັ້ນ​ມັນ​ຈໍາ​ເປັນ​ເພື່ອ​ແກ້​ໄຂ​ບັນ​ຫາ​ທີ່​ກົດ​ດັນ​ໄວ​ເທົ່າ​ທີ່​ເປັນ​ໄປ​ໄດ້, ແລະ​ບໍ່​ໄດ້​ເຮັດ​ໃຫ້​ມັນ​ງາມ; ນອກຈາກນັ້ນ, Janus ສໍາລັບພວກເຮົາແມ່ນກ່ອງສີດໍາທີ່ຂຽນເປັນ C, ມັນມີລາຄາແພງຫຼາຍທີ່ຈະໃສ່ມັນ.

ແລ້ວ, ໃນຂະບວນການພວກເຮົາ:

• ປັບປຸງການເພິ່ງພາອາໄສທັງຫມົດທີ່ສາມາດໄດ້ຮັບການປັບປຸງ, ທັງຢູ່ໃນເຄື່ອງແມ່ຂ່າຍແລະລູກຄ້າ (ເຫຼົ່ານີ້ຍັງເປັນການທົດລອງ, ພວກເຮົາຕິດຕາມຜົນໄດ້ຮັບ);
• ແກ້ໄຂຂໍ້ບົກພ່ອງທີ່ຖືກກໍານົດທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບກໍລະນີສະເພາະ, ສໍາລັບຕົວຢ່າງ, ເມື່ອການເຊື່ອມຕໍ່ຫຼຸດລົງແລະບໍ່ໄດ້ຮັບການຟື້ນຟູໂດຍອັດຕະໂນມັດ;
• ພວກເຮົາໄດ້ຈັດກອງປະຊຸມຫຼາຍກັບບໍລິສັດທີ່ເຮັດວຽກໃນພາກສະຫນາມຂອງການສື່ສານວິດີໂອແລະຄຸ້ນເຄີຍກັບບັນຫາຂອງພວກເຮົາ: streaming ເກມ, ການຈັດ webinars; ພວກເຮົາໄດ້ພະຍາຍາມທຸກສິ່ງທຸກຢ່າງທີ່ເບິ່ງຄືວ່າເປັນປະໂຫຍດສໍາລັບພວກເຮົາ;
• ໄດ້ດໍາເນີນການກວດກາດ້ານວິຊາການກ່ຽວກັບຄຸນນະພາບຂອງຮາດແວແລະການສື່ສານຂອງຄູອາຈານ, ຈາກຜູ້ທີ່ຄໍາຮ້ອງທຸກຫຼາຍທີ່ສຸດແມ່ນມາຈາກ.

ການທົດລອງແລະການປ່ຽນແປງຕໍ່ມາເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຫຼຸດຜ່ອນຄວາມບໍ່ພໍໃຈໃນການສື່ສານລະຫວ່າງຄູອາຈານຈາກ 7,1% ໃນເດືອນມັງກອນ 2018 ເປັນ 2,5% ໃນເດືອນມັງກອນ 2019.

ມີຫຍັງຕໍ່ໄປ

ການສ້າງສະຖຽນລະພາບຂອງເວທີ Vimbox ຂອງພວກເຮົາແມ່ນຫນຶ່ງໃນໂຄງການຕົ້ນຕໍຂອງບໍລິສັດສໍາລັບ 2019. ພວກເຮົາມີຄວາມຫວັງສູງວ່າພວກເຮົາຈະສາມາດຮັກສາຈັງຫວະແລະບໍ່ເຫັນການສື່ສານທາງວິດີໂອໃນຄໍາຮ້ອງທຸກດ້ານເທິງ. ພວກເຮົາເຂົ້າໃຈວ່າສ່ວນທີ່ສໍາຄັນຂອງການຮ້ອງທຸກເຫຼົ່ານີ້ແມ່ນກ່ຽວຂ້ອງກັບຄວາມຊັກຊ້າໃນຄອມພິວເຕີຂອງຜູ້ໃຊ້ແລະອິນເຕີເນັດ, ແຕ່ພວກເຮົາຕ້ອງກໍານົດສ່ວນນີ້ແລະແກ້ໄຂສ່ວນທີ່ເຫຼືອ. ທຸກສິ່ງທຸກຢ່າງອື່ນແມ່ນບັນຫາດ້ານວິຊາການ, ມັນເບິ່ງຄືວ່າພວກເຮົາຄວນຈະສາມາດຮັບມືກັບມັນໄດ້.

ຄວາມຫຍຸ້ງຍາກຕົ້ນຕໍແມ່ນພວກເຮົາບໍ່ຮູ້ວ່າມັນເປັນໄປໄດ້ໃນລະດັບໃດທີ່ຈະປັບປຸງຄຸນນະພາບ. ຊອກຫາເພດານນີ້ແມ່ນວຽກງານຕົ້ນຕໍ. ດັ່ງນັ້ນ, ສອງການທົດລອງໄດ້ຖືກວາງແຜນ:

1. ປຽບທຽບວິດີໂອຜ່ານ Janus ກັບ p2p ປົກກະຕິໃນສະພາບການຕໍ່ສູ້. ການທົດລອງນີ້ໄດ້ຖືກປະຕິບັດແລ້ວ, ບໍ່ມີຄວາມແຕກຕ່າງທີ່ສໍາຄັນທາງສະຖິຕິລະຫວ່າງການແກ້ໄຂຂອງພວກເຮົາແລະ p2p;
2. ໃຫ້ສະຫນອງການບໍລິການ (ລາຄາແພງ) ຈາກບໍລິສັດທີ່ສ້າງລາຍໄດ້ສະເພາະໃນການແກ້ໄຂການສື່ສານທາງວິດີໂອ, ແລະປຽບທຽບຈໍານວນ negativity ຈາກພວກເຂົາກັບອັນທີ່ມີຢູ່ແລ້ວ.

ການທົດລອງທັງສອງອັນນີ້ຈະຊ່ວຍໃຫ້ພວກເຮົາສາມາດກໍານົດເປົ້າຫມາຍທີ່ສາມາດບັນລຸໄດ້ແລະສຸມໃສ່ມັນ.

ນອກຈາກນັ້ນ, ຍັງມີວຽກງານຈໍານວນຫນຶ່ງທີ່ສາມາດແກ້ໄຂໄດ້ເປັນປົກກະຕິ:

• ພວກເຮົາສ້າງ metric ດ້ານວິຊາການຂອງຄຸນນະພາບການສື່ສານແທນທີ່ຈະເປັນການທົບທວນຫົວຂໍ້;
• ພວກເຮົາເຮັດບົດບັນທຶກກອງປະຊຸມຢ່າງລະອຽດຫຼາຍຂຶ້ນເພື່ອວິເຄາະຄວາມລົ້ມເຫຼວທີ່ເກີດຂຶ້ນໄດ້ຢ່າງຖືກຕ້ອງ, ເຂົ້າໃຈວ່າມັນເກີດຂຶ້ນເມື່ອໃດ ແລະຢູ່ໃສ, ແລະເຫດການທີ່ເບິ່ງຄືວ່າບໍ່ກ່ຽວຂ້ອງເກີດຂຶ້ນໃນຂະນະນັ້ນ;
• ພວກເຮົາກະກຽມການທົດສອບຄຸນນະພາບການເຊື່ອມຕໍ່ອັດຕະໂນມັດກ່ອນບົດຮຽນ, ແລະຍັງໃຫ້ລູກຄ້າໂອກາດທີ່ຈະທົດສອບການເຊື່ອມຕໍ່ດ້ວຍຕົນເອງເພື່ອຫຼຸດຜ່ອນຈໍານວນ negativity ທີ່ເກີດຈາກຮາດແວແລະຊ່ອງທາງຂອງລາວ;
• ພວກເຮົາຈະພັດທະນາແລະດໍາເນີນການທົດສອບການໂຫຼດການສື່ສານວິດີໂອຫຼາຍຂຶ້ນໃນສະພາບທີ່ບໍ່ດີ, ມີການສູນເສຍແພັກເກັດທີ່ປ່ຽນແປງ, ແລະອື່ນໆ;
• ພວກເຮົາປ່ຽນແປງພຶດຕິກໍາຂອງເຄື່ອງແມ່ຂ່າຍໃນກໍລະນີທີ່ມີບັນຫາເພື່ອເພີ່ມຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ;
• ພວກເຮົາຈະເຕືອນຜູ້ໃຊ້ຖ້າມີບາງສິ່ງບາງຢ່າງທີ່ຜິດພາດກັບການເຊື່ອມຕໍ່ຂອງລາວທັງຫມົດ, ດັ່ງທີ່ Skype ເຮັດ, ເພື່ອໃຫ້ລາວເຂົ້າໃຈວ່າບັນຫາແມ່ນຢູ່ຂ້າງລາວ.

ນັບຕັ້ງແຕ່ເດືອນເມສາ, ທິດທາງການສື່ສານວິດີໂອໄດ້ກາຍເປັນໂຄງການແຍກຕ່າງຫາກຢ່າງເຕັມທີ່ພາຍໃນ Skyeng, ຈັດການກັບຜະລິດຕະພັນຂອງຕົນເອງ, ບໍ່ພຽງແຕ່ສ່ວນຫນຶ່ງຂອງ Vimbox. ນີ້ຫມາຍຄວາມວ່າພວກເຮົາກໍາລັງເລີ່ມຊອກຫາຄົນ ເຮັດວຽກກັບວິດີໂອໃນຮູບແບບເຕັມເວລາ. ດີ, ເປັນສະເຫມີ ພວກເຮົາກໍາລັງຊອກຫາຫຼາຍຄົນທີ່ດີ.

ແລະ, ແນ່ນອນ, ພວກເຮົາສືບຕໍ່ຕິດຕໍ່ສື່ສານຢ່າງຈິງຈັງກັບປະຊາຊົນແລະບໍລິສັດທີ່ເຮັດວຽກກັບການສື່ສານວິດີໂອ. ຖ້າທ່ານຕ້ອງການແລກປ່ຽນປະສົບການກັບພວກເຮົາ, ພວກເຮົາຈະດີໃຈ! ຄອມເມັ້ນ, ຕິດຕໍ່ໄດ້ - ພວກເຮົາຈະຕອບທຸກຄົນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com