การสื่อสารผ่านวิดีโอเป็นวิธีการสื่อสารหลักระหว่างครูและนักเรียนบนแพลตฟอร์ม Vimbox เราเลิกใช้ Skype ไปนานแล้ว ลองใช้โซลูชันของบุคคลที่สามหลายตัว และในที่สุดก็ตัดสินใจใช้ WebRTC - การรวมเกตเวย์ Janus บางครั้งเราก็พอใจกับทุกสิ่ง แต่ก็ยังมีด้านลบอยู่บ้างที่ยังคงปรากฏให้เห็น เป็นผลให้มีการสร้างทิศทางวิดีโอแยกต่างหาก
ฉันขอให้ Kirill Rogovoy หัวหน้าฝ่ายทิศทางใหม่พูดคุยเกี่ยวกับวิวัฒนาการของการสื่อสารผ่านวิดีโอที่ Skyeng ปัญหาที่พบ วิธีแก้ไขและไม้ค้ำยันที่เราใช้ในที่สุด เราหวังว่าบทความนี้จะเป็นประโยชน์สำหรับบริษัทที่สร้างวิดีโอด้วยตนเองผ่านเว็บแอปพลิเคชัน
บิตของประวัติศาสตร์
ในฤดูร้อนปี 2017 Sergey Safonov หัวหน้าฝ่ายพัฒนา Skyeng พูดที่ Backend Conf พร้อมเรื่องราวเกี่ยวกับวิธีที่เรา "ละทิ้ง Skype และนำ WebRTC ไปใช้" ผู้สนใจสามารถรับชมการบันทึกปาฐกถาได้ที่ (ประมาณ 45 นาที) และที่นี่ฉันจะสรุปสาระสำคัญโดยย่อ
สำหรับโรงเรียน Skyeng การสื่อสารผ่านวิดีโอถือเป็นวิธีสื่อสารระหว่างครูและนักเรียนที่มีความสำคัญมาโดยตลอด ในตอนแรก Skype ถูกใช้ แต่ก็ไม่น่าพอใจด้วยเหตุผลหลายประการ สาเหตุหลักมาจากการขาดบันทึกและความเป็นไปไม่ได้ของการรวมเข้ากับเว็บแอปพลิเคชันโดยตรง ดังนั้นเราจึงทำการทดลองทุกประเภท
จริงๆ แล้ว ข้อกำหนดของเราสำหรับการสื่อสารผ่านวิดีโอมีดังต่อไปนี้โดยประมาณ:
— ความมั่นคง;
— ราคาต่อบทเรียนต่ำ
— การบันทึกบทเรียน
— การติดตามว่าใครพูดมากแค่ไหน (เป็นสิ่งสำคัญสำหรับเราที่นักเรียนพูดมากกว่าครูในระหว่างบทเรียน)
— มาตราส่วนเชิงเส้น
- ความสามารถในการใช้ทั้ง UDP และ TCP
สิ่งแรกที่ต้องลองคือการใช้ Tokbox ในปี 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 มีคุณสมบัติมากมายที่เราต้องการ: สลับไปใช้ TCP โดยอัตโนมัติหากไคลเอนต์บล็อก UDP; สามารถบันทึกทั้งสตรีม UDP และ TCP ปรับขนาดได้; มีแม้กระทั่งปลั๊กอินในตัวสำหรับการทดสอบเสียงสะท้อน หากจำเป็น เซิร์ฟเวอร์ STUN และ TURN จาก Twilio จะเชื่อมต่อโดยอัตโนมัติ
ในฤดูร้อนปี 2017 เรามีเซิร์ฟเวอร์ Janus สองเซิร์ฟเวอร์ที่ทำงานอยู่ พร้อมด้วยเซิร์ฟเวอร์เพิ่มเติมสำหรับการประมวลผลไฟล์เสียงและวิดีโอ Raw ที่บันทึกไว้ เพื่อไม่ให้กินพื้นที่โปรเซสเซอร์ของเซิร์ฟเวอร์หลัก เมื่อทำการเชื่อมต่อ เซิร์ฟเวอร์ Janus จะถูกเลือกเป็นเลขคี่-คู่ (หมายเลขการเชื่อมต่อ) ตามความรู้สึกของเรา ณ เวลานั้น ก็เพียงพอแล้ว โดยให้อัตราความปลอดภัยประมาณสี่เท่า เปอร์เซ็นต์การดำเนินการคือประมาณ 80 ในเวลาเดียวกัน ราคาก็ลดลงเหลือ ~2 รูเบิลต่อบทเรียน พร้อมการพัฒนาและการสนับสนุน
กลับมาที่หัวข้อการสื่อสารผ่านวิดีโอ
เราติดตามผลตอบรับจากนักเรียนและครูอย่างต่อเนื่องเพื่อระบุและแก้ไขปัญหาได้ทันท่วงที ในช่วงฤดูร้อนปี 2018 คุณภาพการโทรอยู่ในอันดับหนึ่งในบรรดาข้อร้องเรียน ในด้านหนึ่ง นี่หมายความว่าเราเอาชนะข้อบกพร่องอื่นๆ ได้สำเร็จ ในทางกลับกัน จำเป็นต้องทำอะไรอย่างเร่งด่วน: หากบทเรียนหยุดชะงัก เราเสี่ยงที่จะสูญเสียคุณค่าของบทเรียน บางครั้งอาจมาพร้อมกับค่าใช้จ่ายในการซื้อแพ็คเกจถัดไป และหากบทเรียนเบื้องต้นหยุดชะงัก เราก็เสี่ยงที่จะสูญเสียลูกค้าที่มีศักยภาพ โดยสิ้นเชิง
ตอนนั้นการสื่อสารผ่านวิดีโอของเรายังอยู่ในโหมด MVP พูดง่ายๆ ก็คือ พวกเขาเปิดตัวมัน ใช้งานได้ พวกเขาปรับขนาดมันหนึ่งครั้ง พวกเขาเข้าใจวิธีการทำ เยี่ยมมาก ถ้าได้ผลอย่าซ่อมเลย ไม่มีใครจงใจพูดถึงปัญหาคุณภาพการสื่อสาร ภายในเดือนสิงหาคม เห็นได้ชัดว่าสิ่งนี้ไม่สามารถดำเนินต่อไปได้ และเราได้เปิดตัวแนวทางแยกต่างหากเพื่อค้นหาว่ามีอะไรผิดปกติกับ WebRTC และ Janus
ทิศทางนี้ได้รับจากข้อมูลนำเข้า: โซลูชัน MVP, ไม่มีตัวชี้วัด, ไม่มีเป้าหมาย, ไม่มีกระบวนการสำหรับการปรับปรุง ในขณะที่ครู 7% บ่นเกี่ยวกับคุณภาพของการสื่อสาร (ไม่มีข้อมูลเกี่ยวกับนักเรียนเช่นกัน)
ทิศทางใหม่กำลังดำเนินการอยู่
คำสั่งมีลักษณะดังนี้:
- หัวหน้าแผนกซึ่งเป็นผู้พัฒนาหลักด้วย
- QA ช่วยทดสอบการเปลี่ยนแปลง ค้นหาวิธีใหม่ในการสร้างเงื่อนไขการสื่อสารที่ไม่เสถียร และรายงานปัญหาจากแนวหน้า
- นักวิเคราะห์มองหาความสัมพันธ์ต่างๆ ในข้อมูลทางเทคนิคอย่างต่อเนื่อง ปรับปรุงการวิเคราะห์ความคิดเห็นของผู้ใช้ และตรวจสอบผลลัพธ์ของการทดลอง
- ผู้จัดการผลิตภัณฑ์ช่วยกำหนดทิศทางโดยรวมและการจัดสรรทรัพยากรสำหรับการทดลอง
- นักพัฒนาคนที่สองมักจะช่วยเรื่องการเขียนโปรแกรมและงานที่เกี่ยวข้อง
ขั้นแรก เราได้ตั้งค่าตัวชี้วัดที่ค่อนข้างเชื่อถือได้ซึ่งติดตามการเปลี่ยนแปลงในการประเมินคุณภาพการสื่อสาร (โดยเฉลี่ยในช่วงวัน สัปดาห์ เดือน) ตอนนั้นเป็นเกรดของครู และเกรดต่อมาของนักเรียนก็เพิ่มเข้ามาด้วย จากนั้นพวกเขาก็เริ่มสร้างสมมติฐานเกี่ยวกับสิ่งที่ผิดพลาด แก้ไข และดูการเปลี่ยนแปลงของไดนามิก เราเลือกผลไม้แขวนต่ำ: ตัวอย่างเช่นเราแทนที่ตัวแปลงสัญญาณ vp8 ด้วย vp9 ประสิทธิภาพดีขึ้น เราพยายามเล่นกับการตั้งค่า Janus และทำการทดลองอื่นๆ โดยส่วนใหญ่แล้วการทดลองเหล่านี้ไม่ได้นำไปสู่อะไรเลย
ในขั้นตอนที่สอง มีสมมติฐานเกิดขึ้น: WebRTC เป็นโซลูชันแบบเพียร์ทูเพียร์ และเราใช้เซิร์ฟเวอร์ตรงกลาง บางทีปัญหาอาจอยู่ที่นี่? เราเริ่มขุดและพบการปรับปรุงที่สำคัญที่สุดจนถึงตอนนี้
ในขณะนั้น เซิร์ฟเวอร์จากพูลถูกเลือกโดยใช้อัลกอริธึมที่ค่อนข้างงี่เง่า: เซิร์ฟเวอร์แต่ละตัวมี "น้ำหนัก" ของตัวเอง ขึ้นอยู่กับช่องสัญญาณและพลัง และเราพยายามส่งผู้ใช้ไปยังเซิร์ฟเวอร์ที่มี "น้ำหนัก" มากที่สุด โดยไม่มี ให้ความสนใจกับตำแหน่งทางภูมิศาสตร์ของผู้ใช้ ด้วยเหตุนี้ ครูจากเซนต์ปีเตอร์สเบิร์กจึงสามารถสื่อสารกับนักเรียนจากไซบีเรียผ่านมอสโกว ไม่ใช่ผ่านเซิร์ฟเวอร์ Janus ของเราในเซนต์ปีเตอร์สเบิร์ก
อัลกอริธึมได้รับการทำใหม่: ตอนนี้เมื่อผู้ใช้เปิดแพลตฟอร์มของเรา เราจะรวบรวม Ping จากเขาไปยังเซิร์ฟเวอร์ทั้งหมดที่ใช้ Ajax เมื่อสร้างการเชื่อมต่อ เราจะเลือกคู่ของ Ping (เซิร์ฟเวอร์ครู และเซิร์ฟเวอร์นักเรียน) ด้วยจำนวนที่น้อยที่สุด ping ที่น้อยลงหมายถึงระยะทางเครือข่ายไปยังเซิร์ฟเวอร์น้อยลง ระยะทางที่สั้นลงหมายถึงความน่าจะเป็นที่ลดลงในการสูญเสียแพ็กเก็ต การสูญเสียแพ็คเก็ตเป็นปัจจัยลบที่ใหญ่ที่สุดในการสื่อสารผ่านวิดีโอ ส่วนแบ่งของการปฏิเสธลดลงครึ่งหนึ่งในสามเดือน (พูดตามตรง การทดลองอื่น ๆ ได้ดำเนินการในเวลานี้ แต่การทดลองนี้เกือบจะมีผลกระทบมากที่สุดอย่างแน่นอน)
เมื่อเร็วๆ นี้ เราได้ค้นพบอีกสิ่งหนึ่งที่ไม่ชัดเจนแต่มีความสำคัญอย่างเห็นได้ชัด: แทนที่จะมีเซิร์ฟเวอร์ Janus อันทรงพลังตัวเดียวบนแชนเนลที่มีความหนาแน่น ควรมีเซิร์ฟเวอร์ที่เรียบง่ายกว่าสองเซิร์ฟเวอร์และมีแบนด์วิธที่บางลงจะดีกว่า สิ่งนี้ชัดเจนหลังจากที่เราซื้อเครื่องจักรที่ทรงพลังโดยหวังว่าจะอัดห้องจำนวนมาก (เซสชันการสื่อสาร) เข้าไปในเครื่องในเวลาเดียวกัน เซิร์ฟเวอร์มีการจำกัดแบนด์วิธ ซึ่งเราสามารถแปลเป็นจำนวนห้องได้อย่างแม่นยำ เรารู้ว่าสามารถเปิดได้กี่ห้อง เช่น ที่ความเร็ว 300 Mbit/s ทันทีที่มีห้องเปิดบนเซิร์ฟเวอร์มากเกินไป เราจะหยุดเลือกห้องนั้นสำหรับกิจกรรมใหม่จนกว่าโหลดจะลดลง แนวคิดก็คือเมื่อซื้อเครื่องที่ทรงพลัง เราจะโหลดช่องสัญญาณนั้นให้สูงสุด เพื่อว่าท้ายที่สุดแล้ว มันจะถูกจำกัดโดยโปรเซสเซอร์และหน่วยความจำ ไม่ใช่ด้วยแบนด์วิดท์ แต่ปรากฎว่าหลังจากเปิดห้องจำนวนหนึ่ง (420) แม้ว่าโหลดบนโปรเซสเซอร์หน่วยความจำและดิสก์จะยังห่างไกลจากขีด จำกัด มาก แต่ฝ่ายสนับสนุนด้านเทคนิคก็เริ่มที่จะปฏิเสธ เห็นได้ชัดว่ามีบางอย่างแย่ลงในตัว Janus บางทีอาจมีข้อจำกัดบางประการเช่นกัน เราเริ่มการทดลอง ลดขีดจำกัดแบนด์วิดท์จาก 300 เป็น 200 Mbit/s และปัญหาก็หมดไป ตอนนี้เราซื้อเซิร์ฟเวอร์ใหม่สามเซิร์ฟเวอร์พร้อมกันโดยมีข้อจำกัดและคุณลักษณะต่ำ เราคิดว่าสิ่งนี้จะนำไปสู่การปรับปรุงคุณภาพการสื่อสารอย่างมั่นคง แน่นอนว่าเราไม่ได้พยายามคิดว่าเกิดอะไรขึ้นที่นั่น ไม้ค้ำของเราคือทุกสิ่ง ในการป้องกันของเรา สมมติว่าในขณะนั้นจำเป็นต้องแก้ไขปัญหาเร่งด่วนให้เร็วที่สุด และไม่ทำให้สวยงาม นอกจากนี้ Janus สำหรับเราคือกล่องดำที่เขียนด้วยภาษา C ซึ่งมีราคาแพงมากสำหรับคนจรจัด
ในกระบวนการนี้เรา:
- อัปเดตการพึ่งพาทั้งหมดที่สามารถอัปเดตได้ทั้งบนเซิร์ฟเวอร์และบนไคลเอนต์ (สิ่งเหล่านี้เป็นการทดลองด้วย เราตรวจสอบผลลัพธ์)
- แก้ไขข้อบกพร่องที่ระบุทั้งหมดที่เกี่ยวข้องกับกรณีเฉพาะ เช่น เมื่อการเชื่อมต่อหลุดและไม่ได้รับการกู้คืนโดยอัตโนมัติ
- เราจัดการประชุมหลายครั้งกับบริษัทที่ทำงานด้านการสื่อสารผ่านวิดีโอ และคุ้นเคยกับปัญหาของเรา เช่น การสตรีมเกม การจัดงานสัมมนาผ่านเว็บ เราลองทุกอย่างที่ดูมีประโยชน์สำหรับเรา
- ดำเนินการตรวจสอบทางเทคนิคเกี่ยวกับคุณภาพฮาร์ดแวร์และการสื่อสารของครูที่ได้รับการร้องเรียนมากที่สุด
การทดลองและการเปลี่ยนแปลงที่ตามมาทำให้สามารถลดความไม่พอใจในการสื่อสารระหว่างครูจาก 7,1% ในเดือนมกราคม 2018 เหลือ 2,5% ในเดือนมกราคม 2019
มีอะไรต่อไป
การรักษาเสถียรภาพแพลตฟอร์ม Vimbox ของเราเป็นหนึ่งในโครงการหลักของบริษัทในปี 2019 เรามีความหวังสูงว่าเราจะสามารถรักษาโมเมนตัมและไม่เห็นการสื่อสารผ่านวิดีโอในการร้องเรียนอันดับต้นๆ อีกต่อไป เราเข้าใจดีว่าส่วนสำคัญของข้อร้องเรียนเหล่านี้เกี่ยวข้องกับความล่าช้าในคอมพิวเตอร์และอินเทอร์เน็ตของผู้ใช้ แต่เราต้องพิจารณาส่วนนี้และแก้ไขส่วนที่เหลือ อย่างอื่นเป็นปัญหาทางเทคนิค ดูเหมือนว่าเราน่าจะรับมือกับมันได้
ปัญหาหลักคือเราไม่รู้ว่าจะปรับปรุงคุณภาพได้จริงถึงระดับใด การค้นหาเพดานนี้เป็นภารกิจหลัก ดังนั้นจึงมีการวางแผนการทดลอง XNUMX ครั้ง:
- เปรียบเทียบวิดีโอผ่าน Janus กับ p2p ปกติในสภาวะการต่อสู้ การทดลองนี้ดำเนินการไปแล้ว ไม่พบความแตกต่างที่มีนัยสำคัญทางสถิติระหว่างโซลูชันของเรากับ p2p
- มาจัดหาบริการ (ราคาแพง) จากบริษัทที่สร้างรายได้จากโซลูชันการสื่อสารผ่านวิดีโอโดยเฉพาะ และเปรียบเทียบปริมาณข้อเสียจากบริษัทเหล่านั้นกับบริการที่มีอยู่
การทดลองทั้งสองนี้จะช่วยให้เราระบุเป้าหมายที่ทำได้และมุ่งเน้นไปที่เป้าหมายนั้น
นอกจากนี้ ยังมีงานที่สามารถแก้ไขได้เป็นประจำอีกจำนวนหนึ่ง:
- เราสร้างตัวชี้วัดทางเทคนิคของคุณภาพการสื่อสารแทนการทบทวนเชิงอัตนัย
- เราสร้างบันทึกเซสชันที่มีรายละเอียดมากขึ้นเพื่อวิเคราะห์ความล้มเหลวที่เกิดขึ้นได้แม่นยำยิ่งขึ้น ทำความเข้าใจว่าเหตุการณ์เหล่านั้นเกิดขึ้นเมื่อใดและที่ไหน และเหตุการณ์ใดที่ดูเหมือนจะไม่เกี่ยวข้องเกิดขึ้นในขณะนั้น
- เราเตรียมการทดสอบคุณภาพการเชื่อมต่ออัตโนมัติก่อนบทเรียน และยังให้โอกาสลูกค้าทดสอบการเชื่อมต่อด้วยตนเอง เพื่อลดปริมาณเชิงลบที่เกิดจากฮาร์ดแวร์และช่องทางของเขา
- เราจะพัฒนาและดำเนินการทดสอบโหลดการสื่อสารผ่านวิดีโอมากขึ้นในสภาวะที่ไม่ดี โดยมีการสูญเสียแพ็กเก็ตแบบแปรผัน ฯลฯ
- เราเปลี่ยนพฤติกรรมของเซิร์ฟเวอร์ในกรณีที่เกิดปัญหาเพื่อเพิ่มความทนทานต่อข้อผิดพลาด
- เราจะเตือนผู้ใช้หากมีสิ่งผิดปกติเกิดขึ้นกับการเชื่อมต่อของเขา เช่นเดียวกับ Skype เพื่อที่เขาจะได้เข้าใจว่าปัญหาอยู่ฝั่งเขา
ตั้งแต่เดือนเมษายน ทิศทางการสื่อสารผ่านวิดีโอได้กลายเป็นโครงการแยกต่างหากภายใน Skyeng โดยเกี่ยวข้องกับผลิตภัณฑ์ของตัวเอง ไม่ใช่แค่ส่วนหนึ่งของ Vimbox ซึ่งหมายความว่าเรากำลังเริ่มมองหาผู้คนบน . ก็เช่นเคย .
และแน่นอนว่า เรายังคงสื่อสารอย่างกระตือรือร้นกับผู้คนและบริษัทที่ทำงานกับการสื่อสารผ่านวิดีโอ หากคุณต้องการแลกเปลี่ยนประสบการณ์กับเราเราจะยินดี! แสดงความคิดเห็นติดต่อเรา - เราจะตอบทุกคน
ที่มา: will.com