מסקייפ ל-WebRTC: איך ארגנו תקשורת וידאו דרך האינטרנט

תקשורת וידאו היא דרך התקשורת העיקרית בין מורה לתלמיד בפלטפורמת Vimbox. ויתרנו על סקייפ לפני זמן רב, ניסינו כמה פתרונות של צד שלישי ובסופו של דבר הסתפקנו בשילוב WebRTC - Janus-gateway. במשך זמן מה היינו מרוצים מהכל, אבל עדיין כמה היבטים שליליים המשיכו לצוץ. כתוצאה מכך, נוצר כיוון וידאו נפרד.

ביקשתי מקיריל רוגובוי, ראש הכיוון החדש, לדבר על האבולוציה של תקשורת הווידאו ב-Skyeng, הבעיות שהתגלו, הפתרונות והקביים שבהם השתמשנו בסופו של דבר. אנו מקווים שהמאמר יהיה שימושי עבור חברות שגם יוצרות וידאו בעצמן באמצעות אפליקציית אינטרנט.

קצת היסטוריה

בקיץ 2017, ראש הפיתוח של Skyeng, סרגיי ספונוב, דיבר ב-Backend Conf עם סיפור על איך "נטשנו את סקייפ והטמענו את WebRTC". המעוניינים יוכלו לצפות בהקלטת הנאום ב קשר (~45 דקות), וכאן אתאר בקצרה את מהותו.

עבור בית הספר Skyeng, תקשורת וידאו תמיד הייתה דרך עדיפות לתקשורת מורה-תלמיד. בתחילה נעשה שימוש בסקייפ, אך היא לא הייתה מספקת באופן קטגורי ממספר סיבות, בעיקר בשל היעדר יומנים וחוסר האפשרות להשתלב ישירות באפליקציית האינטרנט. לכן, ביצענו כל מיני ניסויים.

למעשה, הדרישות שלנו לתקשורת וידאו היו בערך הבאות:
- יציבות;
- מחיר נמוך לשיעור;
- הקלטת שיעורים;
- מעקב אחר מי מדבר כמה (חשוב לנו שהתלמידים ידברו יותר מהמורה במהלך השיעורים);
- קנה מידה ליניארי;
- יכולת להשתמש גם ב-UDP וגם ב-TCP.

הראשון שניסה היה ליישם את Tokbox ב-2013. הכל היה טוב, אבל התברר שהוא יקר מאוד - 113 רובל לשיעור - ואכל את הרווח.

ואז בשנת 2015, ווקסימפלנט שולבה. כאן הייתה הפונקציה שהיינו צריכים כדי לעקוב אחר מי דיבר כמה, ובמקביל הפתרון היה הרבה יותר זול: אם רק הוקלט אודיו, זה עלה 20 רובל לשיעור. עם זאת, זה עבד רק דרך UDP ולא יכול היה לעבור ל-TCP. עם זאת, כ-40% מהסטודנטים בסופו של דבר השתמשו בו.

שנה לאחר מכן, התחלנו לקבל לקוחות ארגוניים עם דרישות ספציפיות משלהם. לדוגמה, הכל צריך לעבוד דרך דפדפן, החברה פותחת רק http ו-https; כלומר אין סקייפ או UDP. לקוחות עסקיים = כסף, אז הם חזרו לטוקבוקס, אבל בעיית המחיר לא נעלמה.

פתרון - WebRTC ויאנוס

הוחלט להשתמש פלטפורמת דפדפן לתקשורת וידאו עמית לעמית WebRTC. הוא אחראי על יצירת חיבור, קידוד ופענוח זרמים, סנכרון מסלולים ובקרת איכות עם טיפול בתקלות רשת. אנו מצידנו חייבים לדאוג לקריאת זרמים מהמצלמה ומהמיקרופון, ציור וידאו, ניהול החיבור, יצירת חיבור WebRTC והעברת זרמים אליו, וכן העברת הודעות איתות בין לקוחות ליצירת חיבור (WebRTC עצמו מתאר רק את פורמט נתונים, אך לא העברות המנגנון שלו). אם לקוחות נמצאים מאחורי NAT, WebRTC מחבר שרתי STUN; אם ​​זה לא עוזר, TURN שרתי.

חיבור p2p רגיל לא מספיק לנו, כי אנחנו רוצים להקליט שיעורים להמשך ניתוח במקרה של תלונות. לכן אנו שולחים זרמי WebRTC דרך ממסר Janus Gateway מאת Meetecho. כתוצאה מכך, לקוחות אינם יודעים זה את הכתובות של זה, ורואים רק את כתובת שרת Janus; הוא גם מבצע את הפונקציות של שרת אותות. ל-Janus יש הרבה מהתכונות שאנחנו צריכים: עובר אוטומטית ל-TCP אם הלקוח חסם UDP; יכול להקליט גם זרמי UDP וגם TCP; ניתן להרחבה; יש אפילו תוסף מובנה לבדיקות הד. במידת הצורך, שרתי STUN ו-TURN מ-Twilio מחוברים אוטומטית.

בקיץ 2017 פעלו לנו שני שרתי Janus, בתוספת שרת נוסף לעיבוד קבצי אודיו ווידאו גולמיים מוקלטים, כדי לא להעסיק את המעבדים של הראשיים. בעת החיבור, שרתי Janus נבחרו על בסיס זוגי זוגי (מספר חיבור). באותו זמן זה הספיק, לפי תחושותינו, זה נתן בערך מרווח בטיחות של פי ארבעה, אחוז היישום היה בערך 80. במקביל, המחיר הופחת ל~2 רובל לשיעור, בתוספת פיתוח ותמיכה.

חוזרים לנושא תקשורת וידאו

אנו עוקבים כל הזמן אחר משוב מתלמידים ומורים על מנת לזהות ולתקן בעיות בזמן. בקיץ 2018, איכות השיחות הייתה במקום הראשון בין התלונות. מצד אחד, זה אומר שהתגברנו בהצלחה על חסרונות אחרים. מצד שני, היה צורך לעשות משהו דחוף: אם השיעור מופרע אנחנו מסתכנים באיבוד ערכו, לפעמים לצד עלות רכישת החבילה הבאה, ואם שיעור ההיכרות מופרע אנחנו מסתכנים באובדן לקוח פוטנציאלי לְגַמרֵי.

באותו זמן, תקשורת הווידאו שלנו עדיין הייתה במצב MVP. במילים פשוטות, הם השיקו את זה, זה עבד, הם הגדילו את זה פעם אחת, הם הבינו איך עושים את זה - טוב, נהדר. אם זה עובד, אל תתקן את זה. אף אחד לא התייחס בכוונה לסוגיית איכות התקשורת. באוגוסט, התברר שזה לא יכול להימשך, והשקנו כיוון נפרד כדי להבין מה לא בסדר עם WebRTC ו-Janus.

בקלט התקבל הכיוון הזה: פתרון MVP, ללא מדדים, ללא יעדים, ללא תהליכי שיפור, בעוד 7% מהמורים מתלוננים על איכות התקשורת (גם על התלמידים לא היו נתונים).

כיוון חדש יוצא לדרך

הפקודה נראית בערך כך:

• ראש המחלקה, שהוא גם היזם הראשי.
• QA עוזר לבחון שינויים, מחפש דרכים חדשות ליצור תנאי תקשורת לא יציבים ומדווח על בעיות מהקו הקדמי.
• האנליסט מחפש כל הזמן מתאמים שונים בנתונים טכניים, משפר את ניתוח המשוב של המשתמשים ובודק את תוצאות הניסויים.
• מנהל המוצר עוזר בהכוונה הכוללת והקצאת המשאבים לניסויים.
• מפתח שני עוזר לעתים קרובות בתכנות ובמשימות נלוות.

מלכתחילה, הקמנו מדד אמין יחסית שעוקב אחר שינויים בהערכות איכות התקשורת (ממוצע על פני ימים, שבועות, חודשים). באותה תקופה היו אלה ציונים של מורים, מאוחר יותר נוספו להם ציונים של תלמידים. אחר כך הם התחילו לבנות השערות לגבי מה שעובד לא נכון, לתקן את זה ולהסתכל על שינויים בדינמיקה. הלכנו על הפרי התלוי נמוך: למשל, החלפנו את ה-codec vp8 ב-vp9, הביצועים השתפרו. ניסינו לשחק עם ההגדרות של יאנוס ולערוך ניסויים אחרים - ברוב המקרים הם לא הובילו לכלום.

בשלב השני עלתה השערה: WebRTC הוא פתרון עמית לעמית, ואנחנו משתמשים בשרת באמצע. אולי הבעיה טמונה כאן? התחלנו לחפור ומצאנו את השיפור המשמעותי ביותר עד כה.

באותו רגע, שרת מהבריכה נבחר באמצעות אלגוריתם טיפשי למדי: לכל אחד היה "משקל" משלו, בהתאם לערוץ ולהספק, וניסינו לשלוח את המשתמש לזה עם ה"משקל" הגדול ביותר, ללא לשים לב למקום שבו המשתמש היה ממוקם גיאוגרפית. כתוצאה מכך, מורה מסנט פטרסבורג יכול היה לתקשר עם תלמיד מסיביר דרך מוסקבה, ולא דרך שרת יאנוס שלנו בסנט פטרסבורג.

האלגוריתם שופץ: כעת, כאשר משתמש פותח את הפלטפורמה שלנו, אנו אוספים ממנו פינגים לכל השרתים באמצעות Ajax. בעת יצירת חיבור, אנו בוחרים זוג פינגים (שרת-מורה ושרת-תלמיד) עם הכמות הנמוכה ביותר. פחות פינג פירושו פחות מרחק רשת לשרת; מרחק קצר יותר פירושו סבירות נמוכה יותר לאבד מנות; אובדן מנות הוא הגורם השלילי הגדול ביותר בתקשורת וידאו. חלקה של השליליות ירד בחצי בתוך שלושה חודשים (למען ההגינות, ניסויים אחרים בוצעו בשלב זה, אבל זה כמעט בוודאות השפיע הכי הרבה).

לאחרונה גילינו עוד דבר לא מובן מאליו, אבל כנראה חשוב: במקום שרת Janus חזק אחד על ערוץ עבה, עדיף שניים פשוטים יותר עם רוחב פס דק יותר. זה התברר לאחר שקנינו מכונות חזקות בתקווה לדחוס אליהן כמה שיותר חדרים (מפגשי תקשורת) בו זמנית. לשרתים יש מגבלת רוחב פס, אותה אנו יכולים לתרגם במדויק למספר החדרים – אנו יודעים כמה ניתן לפתוח, למשל, במהירות של 300 Mbit/s. ברגע שיש יותר מדי חדרים פתוחים בשרת, אנחנו מפסיקים לבחור בו לפעילויות חדשות עד שהעומס יורד. הרעיון היה שאחרי שקנינו מכונה חזקה, נטען את הערוץ אליו עד הסוף, כך שבסופו של דבר הוא יוגבל על ידי המעבד והזיכרון, ולא על ידי רוחב הפס. אבל התברר שאחרי מספר מסוים של חדרים פתוחים (420), למרות העובדה שהעומס על המעבד, הזיכרון והדיסק עדיין רחוק מאוד מהגבולות, מתחילה להגיע השליליות לתמיכה הטכנית. כנראה שמשהו מחמיר בתוך יאנוס, אולי גם שם יש כמה הגבלות. התחלנו להתנסות, הורדנו את מגבלת רוחב הפס מ-300 ל-200 Mbit/s והבעיות נעלמו. עכשיו קנינו שלושה שרתים חדשים בבת אחת עם מגבלות ומאפיינים נמוכים, אנחנו חושבים שזה יוביל לשיפור יציב באיכות התקשורת. כמובן, לא ניסינו להבין מה קורה שם; הקביים שלנו הם הכל. להגנתנו, נניח שבאותו רגע היה צורך לפתור את הבעיה הדוחקת במהירות האפשרית, ולא לעשות זאת יפה; חוץ מזה, יאנוס עבורנו היא קופסה שחורה שכתובה ב-C, מאוד יקר להתעסק איתה.

ובכן, בתהליך אנחנו:

• עדכנו את כל התלות שניתן לעדכן, הן בשרת והן בלקוח (אלה היו גם ניסויים, עקבנו אחר התוצאות);
• תיקן את כל הבאגים שזוהו הקשורים למקרים ספציפיים, למשל, כאשר החיבור נותק ולא שוחזר אוטומטית;
• קיימנו הרבה פגישות עם חברות העוסקות בתחום תקשורת הווידאו ומכירים את הבעיות שלנו: הזרמת משחקים, ארגון סמינרים מקוונים; ניסינו כל מה שנראה לנו שימושי;
• ערך סקירה טכנית של איכות החומרה והתקשורת של המורים, מהם הגיעו הכי הרבה תלונות.

הניסויים והשינויים הבאים אפשרו לצמצם את חוסר שביעות הרצון מהתקשורת בקרב המורים מ-7,1% בינואר 2018 ל-2,5% בינואר 2019.

מה הלאה

ייצוב פלטפורמת Vimbox שלנו הוא אחד הפרויקטים העיקריים של החברה לשנת 2019. יש לנו תקוות גדולות שנוכל לשמור על המומנטום ולא לראות יותר תקשורת וידאו בחלק העליון של התלונות. אנו מבינים שחלק ניכר מהתלונות הללו קשור בפיגור במחשבים ובאינטרנט של המשתמשים, אך עלינו לקבוע את החלק הזה ולפתור את השאר. כל השאר זה בעיה טכנית, נראה שאנחנו צריכים להיות מסוגלים להתמודד איתה.

הקושי העיקרי הוא שאנחנו לא יודעים עד לאיזו רמה אפשר בעצם לשפר את האיכות. לגלות את התקרה הזו היא המשימה העיקרית. לכן, תוכננו שני ניסויים:

1. השווה וידאו דרך יאנוס עם p2p רגיל בתנאי לחימה. ניסוי זה כבר בוצע, לא נמצא הבדל מובהק סטטיסטית בין הפתרון שלנו לבין p2p;
2. בואו נספק שירותים (יקרים) מחברות שמרוויחות כסף אך ורק על פתרונות תקשורת וידאו, ונשווה את כמות השליליות מהם לקיים.

שני הניסויים הללו יאפשרו לנו לזהות מטרה ברת השגה ולהתמקד בה.

בנוסף, ישנן מספר משימות שניתן לפתור באופן שגרתי:

• אנו יוצרים מדד טכני של איכות תקשורת במקום ביקורות סובייקטיביות;
• אנו יוצרים יומני מפגשים מפורטים יותר על מנת לנתח בצורה מדויקת יותר את הכשלים המתרחשים, להבין מתי ואיפה בדיוק הם התרחשו, ואילו אירועים לכאורה לא קשורים התרחשו באותו רגע;
• אנו מכינים בדיקת איכות חיבור אוטומטית לפני השיעור, וכן נותנים ללקוח אפשרות לבדוק את החיבור באופן ידני על מנת להפחית את כמות השליליות הנגרמת מהחומרה והערוץ שלו;
• נפתח ונבצע יותר בדיקות עומס של תקשורת וידאו בתנאים גרועים, עם אובדן מנות משתנה וכו';
• אנו משנים את התנהגות השרתים במקרה של בעיות כדי להגביר את סובלנות התקלות;
• אנו נזהיר את המשתמש אם יש משהו לא בסדר בחיבור שלו בכלל, כפי שעושה סקייפ, כדי שיבין שהבעיה בצד שלו.

מאז אפריל, כיוון תקשורת הווידאו הפך לפרויקט נפרד מן המניין בתוך Skyeng, העוסק במוצר משלו, לא רק בחלק מ-Vimbox. זה אומר שאנחנו מתחילים לחפש אנשים עבודה עם וידאו במצב מלא. ובכן, כמו תמיד אנחנו מחפשים הרבה אנשים טובים.

וכמובן, אנו ממשיכים לתקשר באופן פעיל עם אנשים וחברות שעובדים עם תקשורת וידאו. אם אתה רוצה להחליף איתנו ניסיון, נשמח! הגיבו, צרו קשר - אנחנו נענה לכולם.

מקור: www.habr.com