الآن ، يبدو من المستحيل العثور على رسول بدون ميزة الاتصال. هذا مناسب للمستخدمين ، لأنه يمكن إجراء جميع الاتصالات في تطبيق واحد. إذا قمنا بدمج جميع الإحصاءات المتوفرة في وسائل الإعلام ، فقد اتضح أن الناس يتحدثون عبر الإنترنت لأكثر من مليار دقيقة في اليوم. ومع تطور التكنولوجيا ، تتزايد حصة اتصال الفيديو ، لأن الفيديو ينقل بشكل أفضل مشاعر المحاور ويسمح لك بإنشاء تأثير التواجد.

يتمثل أحد التحديات الجديدة لخدمة مكالمات الفيديو في جمع عائلة بأكملها أو مجموعة من الأصدقاء الموجودين في أنحاء مختلفة من العالم ، أو زملاء يعملون عن بُعد في نفس المشروع ، للتخطيط.

سيوضح رئيس قسم تطوير منصات الفيديو والشرائط ، ألكساندر توبول ( alatobol ) ، أنه تحت الغطاء ، توجد خدمة مكالمات الفيديو ، والتي تستخدم التقنيات والمختراقات لجعل خادم المؤتمرات الخاص بك ، وكيفية نقل الفيديو بشكل صحيح. تعال إلى أسفل وتعلم كيفية نقل خدمة مكالمة فردية لمكالمات جماعية تستقبل 100 شخص ولماذا تحتاج إلى الدعم للعديد من المشاركين.


تستند المقالة إلى تقرير حول HighLoad ++ Siberia ، يحاول فيه ألكساندر توبول تقديم صورة كاملة. إذا كنت على دراية بالفعل بالمواد الأخرى المتعلقة بالموضوع (على سبيل المثال ، حول ميزات نقل الفيديو وبروتوكولات الشبكة ) ، فيمكنك تخطي الجزء النظري والانتقال مباشرة إلى الحل .

الخطوط العريضة للمقال:

• التاريخ والمكالمات الجهاز.
• الانتقال من مكالمات فردية إلى مكالمات المجموعة.
• خدمة استدعاء المجموعة DIY.
• خادم المؤتمرات: استكشاف المنافسين والقيام بعمل أفضل.

سجل المكالمات

أول تطبيق معروف للمكالمات ، ومع الفيديو ، كان Skype ، فقد ظهر في عام 2006. في Odnoklassniki ، أطلقنا مكالمات بناءً على حل من Adobe في 2010-2012 ... قبل عامين ، قمنا بتجديده بالكامل على WebRTC (المزيد حول هذا الإطلاق هنا ) ، أضفنا في العام الماضي مكالمات جماعية. ستتم مناقشة هذا الانتقال في المقالة.

لماذا أعتقد أنني يمكن أن أقول لك كيفية القيام بذلك؟ لأن جمهورنا الشهري الذي يستخدم المكالمات يتجاوز 10 ملايين شخص ، ولدينا أكثر من مليوني مكالمة في اليوم . علاوة على ذلك ، يحدث أكثر من نصفهم عبر منصات متحركة.

المكالمات الجماعية هي أسرع الخدمات نمواً ، وهدفنا هو 100 مشارك في المؤتمر في وقت واحد. لماذا كثيرا؟ أولاً ، أحيانًا تريد مشاركة لقطة جميلة مع أصدقائك وزملائك في الصف أو عقد ندوة. ثانياً ، حتى لو كنت تعتقد أن خدمتك لا تحتاج إلى شيء ، يمكن أن يتغير كل شيء.

قد يبدو الآن أن مؤتمرات الفيديو لـ 100 مشارك ليست مطلوبة ، وقبل خمس سنوات سألوني لماذا نطلق الفيديو في 4K. أصبح الآن جهاز تلفزيون 4K شائعًا ، وقد استعدنا في عام 2014.

النقطة ليست في وقت مبكر. إذا كنت ترغب في تقديم خدمة جيدة ، فقم برفع متطلباتك أعلى.

إذا كنت تستطيع إجراء مكالمات جيدة الأداء من 50 إلى 100 شخص ، فسيكون كل شيء على ما يرام من 6 إلى 10 مستخدمين.

تحتوي كل خدمة اتصال على 4 مكونات مستقلة نسبيًا:

• الإشارة. تتمثل المهمة في استدعاء المشترك ، وتبادل البيانات الأولية ، وإبلاغ ما يمكن لكل مشترك القيام به ، ثم إنشاء قناة يمكن من خلالها نقل بيانات الفيديو.
• فيديو / صوت. يتم ضغط بيانات الفيديو والصوت باستخدام برامج الترميز.
• الشبكة. من الضروري ضمان العمل في الشبكات السيئة ، وتنفيذ استرداد الحزمة ، واتصالات P2P ، إلخ.
• طوبولوجيا - أضيفت في حالة مكالمات المجموعة.

يمكنك التحدث عن أي من هذه الأجزاء بشكل منفصل. لكنني أريد أن أقدم صورة كبيرة عن كيفية عمل المكالمات ، لذلك سأحاول دمج كل شيء في قصة واحدة.

قبل أن تبدأ العمل في الخدمة ، تحتاج إلى تحديد المتطلبات :

• قم بتأسيس اتصال بسرعة حتى يتم تأسيس الاتصال مباشرة بعد أن يلتقط المحاور الهاتف.
• جودة اتصال عالية بحيث لا ينهار الفيديو ولا يتجمد.
• عدد المشاركين في المكالمة ، بحيث يمكنك الاتصال في الدردشات ، والتي يصل عدد المشاركين فيها إلى 100.
• الكمون المنخفض بين المتصلين. كمون 1.3 ثانية كما Polycom لا يناسبنا على الإطلاق.

فيما يلي المعاني المحددة التي يتم التعبير عنها في هذه المتطلبات للمكالمات الجماعية: بدء مكالمة لا تزيد عن ثانية واحدة ؛ شبكة يعمل فيها الفيديو بسرعة 300 كيلوبت في الثانية على نحو مستقر ؛ الكمون من المتصل إلى المستمع لا يزيد عن 0.5 ثانية ؛ 100 مستخدم في مكالمة واحدة.

ما هو في الطريق؟

كما تعلمون ، يتم نقل البيانات الموجودة في الشبكات في حزم: هناك مأخذ توصيل ، يمكنك إرسال دفق بيانات هناك ، كل شيء يطير بعيدًا ، كما لو كان في الصندوق الأسود ، يتم تجميعه ويعمل.

لكن الشبكات مختلفة. يتم إجراء نصف المكالمات من خلال شبكات المحمول ، ولا تبدو دائمًا كطريق سريع.

يمكن تحميل الشبكات بشكل مفرط ، ثم ستفقد البيانات وستتم استعادتها ، مما يؤدي إلى زيادة تحميل الشبكة. هناك شبكات يبدو أن كل شيء على ما يرام ، ولكن لا تزال الحزم تختفي - على سبيل المثال ، بسبب وجود جهاز توجيه Wi-Fi خلف جدار خرساني مقوى.

ميزات الشبكة

سنقوم بتحليل الخصائص الرئيسية التي تصف جودة الشبكة.

RTT

مدة الرحلة ذهابًا وإيابًا - الوقت بين خادم إرسال البيانات إلى العميل وتلقي الإقرار مرة أخرى.

تذكر ، نحن نريد إقامة اتصال في 1 ثانية. إذا كانت مدة الرحلة ذهابًا وإيابًا تبلغ 200 مللي ثانية ، فعندئذ يتم إنشاء الاتصال ، على سبيل المثال ، عبر TCP ، بالإضافة إلى بعض TLS ، يمكنك فقد 500 مللي ثانية فقط على الاتصال . ستبقى 500 مللي ثانية فقط ، أي طلبات أكثر زوجين ، وبعد ذلك ينبغي تأسيس الاتصال. لذلك ، مع طلبات إضافية مع RTT تحتاج إلى العمل بعناية فائقة.

مثال:

$ ping google.com 64 bytes from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms RTT = 220ms $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: %{time_appconnect}\n" -s https://www.google.com HTTP time taken: 0.231 HTTPS time taken: 0.797 HTTP = 230ms HTTPS = 800ms 

مع RTT = 220ms ، يستغرق تلقي استجابة عبر https ما يصل إلى 800 مللي ثانية. لذلك ، إذا كان لديك اتصال آمن بمأخذ توصيل الويب ، فحينئذٍ سوف تختفي الثانية بأكملها.

يوضح الجدول تأخيرات المصافحة المقاسة في شبكات المحمول (في هذا التقرير ، مزيد من التفاصيل حول تشغيل التطبيقات في شبكات المحمول).

قدرة

يمكنك إرسال حزم إلى الشبكة كما تريد: على دفعات أو مطرقة فورًا كل شيء في المخزن المؤقت ، ستظل تأتي إلى العميل بالتساوي. عدد الحزم أو البيانات في الثانية هو النطاق الترددي أو النطاق الترددي.

المشكلة هي أن النطاق الترددي في شبكات المحمول يتغير باستمرار . إذا انخفض بشكل حاد ، وتم نقل البيانات بنفس معدل البت ، فسوف تمر بوضوح مع الخسائر ، وستتوقف مكالمة المستخدم. هذا يجب أيضا أن يحارب.

فقدان الحزمة

عند نقل البيانات ، قد تفقد الحزمة. في هذه الحالة ، هناك خيار: إما تخطي جزء من الحزم والحصول على التشوهات ، أو محاولة إعادة إرسال الحزم والحصول على إطار التجميد.

غضب

والحقيقة هي أن الحزم لا تصل بالتساوي واحدة في كل مرة ، ولكن في الحزم المجمعة في بعض الفواصل الزمنية.


من السهل قياس الارتعاش:

 PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 

Pinganuli highload.ru عدة مرات (ping قيمة غير مستقرة ، فمن الضروري أن متوسط) ، حصلنا على متوسط ​​غضب: ((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 .

لنفترض أننا ننقل مقطع فيديو ، وإطار واحد هو حزمة شبكة. يتم لعب العديد من الإطارات دون انقطاع ، ولكن يتم تأخير الطيور الثالثة بسبب الارتعاش - نحصل على إطار التجميد. لذلك ، تحتاج إلى تجميع الحزم في مكان ما وتحقيق المساواة في هذا التأثير.

وهذا يعني ، لوصف الشبكات اللاسلكية ، أنه يكفي معرفة القيم التالية: RTT (وقت ذهابا وإيابا) ؛ عرض النطاق الترددي BW (عرض النطاق الترددي) ؛ نسبة فقدان الحزمة ؛ غضب.

كيف يبدو المستخدم؟

قبل أن تبدأ في تحسين العمل مع الشبكة ، تحتاج إلى معرفة نوع الإنترنت الذي يمتلكه المستخدمون - ربما كل شخص لديه شبكة مثالية ، أي حل سوف يعمل.

في 80٪ من الحالات ، يستخدم المستخدم النهائي اتصالًا لاسلكيًا: إما شبكة للهاتف المحمول أو Wi-Fi.



في روسيا ، خارج المنطقة الغربية والمدن الكبرى ، فإن متوسط ​​خصائص الشبكة هي: RTT - 200 مللي ثانية ، عرض النطاق الترددي - 1.1 ميغابت في الثانية ، فقدان الحزمة - 0.6٪ ، الارتعاش - 5 مللي ثانية.

قمنا بتقسيم هذه القيم على أنواع الشبكات وأدركنا أن تعلم العمل على هذا أمر ضروري.

دعوة تطوير الميزات

ينسى الكثير من الناس ، لكن LTE و 3G هما قنوات اتصال غير متماثلة: الوصلة الهابطة هي أكثر من مجرد وصلة صاعدة. اعتمادًا على نوع البروتوكول ، يمكن أن تختلف هذه النسبة من 15/85 إلى 30/70. عند تصميم المكالمات ، هذا مهم.

كيفية التحقق من القناة التي يملكها عملاؤك؟



يمكنك إلقاء نظرة على اختبار السرعة ، ما هي نسبة السرعة في العالم بين الإنترنت الثابت والمحمول. اتضح أن الإنترنت الثابت حول العالم غير متماثل أيضًا. لحسن الحظ ، اتضح في روسيا أنه متماثل: نسبة الوصلة الصاعدة / الهابطة على الإنترنت الثابت عبر شبكة Wi-Fi في روسيا هي 50/50. سوف نركز على هذه القيم.



خلاصة القول: الشبكات اللاسلكية شائعة وغير مستقرة.

• أكثر من 80 ٪ من العملاء يستخدمون الإنترنت اللاسلكي.
• الإعدادات اللاسلكية تتغير ديناميكيًا.
• تتمتع الشبكات اللاسلكية بمعدلات عالية من فقد الحزمة والارتعاش وإعادة الترتيب.
• قناة الوصلة الصاعدة / الهابطة غير المتماثلة بنسبة 30/70.

المكالمات

من خلال مخزن المعرفة هذا ، دعنا نعود إلى تنفيذ مكالمات المجموعة. فكر في خوارزمية لإجراء مكالمة جماعية بسيطة ، والتي سنقوم بتحسينها بعد ذلك.

الخطوة 1. Alice تريد الاتصال بوريس وترسل له عرضًا ، حيث تبلغ عن كل ما تستطيع ، والذي يدعم البروتوكولات والإعدادات ، إلخ.

الخطوة 2. بوريس يجيب أليس ، وبعد ذلك يتم تأسيس اتصال النقل.

الخطوة 3. بعد ذلك ، يبدأ تبادل بيانات الصوت / الفيديو.

تبدو بنية أي مكالمات مثل المخطط أدناه.

يوجد دائمًا خادم مشترك ، ولكن عند إنشاء الاتصال ، يمكن للمستخدمين بالفعل نقل بيانات p2p أو من خلال خوادم خارجية.

يتم التقاط البيانات بواسطة كاميرا تقوم بترميزها على الجهاز وإرسالها إلى اتصال المقبس. إنها تمر عبر الشبكة ، ويتم تشغيلها على الجانب الآخر بواسطة برنامج الترميز ، ويتم عرضها على الشاشة.

فكر في جميع خطوات الخوارزمية بالتفصيل وحاول التبديل من مكالمات 1 إلى 1 إلى مكالمات المجموعة.

تأشير

المهمة: الإبلاغ عن مكالمة وإنشاء اتصالات البيانات.

كل شيء بسيط للغاية:

• مكالمات أليس ، يتم إرسال إشعار إلى بوريس على جهاز محمول أو متصفح.
• تم تأسيس مقبس ويب أو أي اتصال آخر.
• بعد ذلك ، يحدث التفاوض - توافق أليس وبوريس.
• عند التقاط سماعة الهاتف على جهاز واحد ، تنتهي المكالمة تلقائيًا على الجهاز الآخر.

منصة الاتصال في Odnoklassniki تدعم مختلف العملاء ووسائل النقل. انهم جميعا على مقربة من نوع من الخادم ، والتي تعمل في خدمة مكالمة وإعادة توجيه الرسائل.

في حالة تعطل الخادم أو تثبيت التحديثات ، يوجد تخزين ثابت يتم فيه تسجيل جميع الرسائل. في حالة فقدان الخادم ، يمكنك التبديل بسهولة إلى واحد آخر. هذا ما يفعله ZooKeeper.

الصعوبة الوحيدة هي بالضبط مرة واحدة . لا نريد تطبيق بعض الرسائل مرتين. يتم حل هذه المشكلة ببساطة: كل الرسائل لها رقم تسلسلي - مرتين لن تصل رسالة واحدة.

بالإضافة إلى ذلك ، عليك أن تكون حذراً عند إنشاء مكالمة. يمكن لأي شخص إنشاء مكالمة ، شنق وإنشاء مكالمة أخرى. أو قد لا يتعطل ، ولكن لا يزال إنشاء واحد آخر. جميع هذه المكالمات ليست فريدة من نوعها - ليس من الواضح ما إذا كان هذا الترحيل أو نقر المستخدم نقرًا مزدوجًا فوق زر الاتصال. يتم إصلاحه بسهولة: يتم إنشاء معرف فريد على العميل ، ويتم إجراء إلغاء البيانات المكررة عليه. من حيث المبدأ ، لا توجد صعوبات في الإشارة .

الانتهاء من الإشارة P2P إلى المجموعة بسهولة.

نفس العروض والإجابات التي أرسلتها أليس الآن ليس فقط إلى بوريس ، ولكن أيضًا إلى ديما. يستقبلونهم ، ويوافقون ، وتظهر قنوات تبادل البيانات بينهما.

الصوت / الفيديو

من أجل مواجهة مكالمة جماعية وفهم التقنيات المطلوبة ، سيتعين علينا التحدث قليلاً حول ماهية الفيديو.

الفيديو هو 24 أو 60 لقطة في الثانية الواحدة. من أجل ضغطها ، يتم استخدام برامج الترميز. يتمثل الجوهر الرئيسي لبرامج الترميز في وجود إطار مرجعي (مثل JPEG) ، كل الإطارات القليلة ، ويتم تحديد الإطارات المتوسطة من خلال التغييرات.

في الصورة أعلاه ، يكون الإطار الأول مع الجهاز هو الإطار المرجعي ، وفي الإطار التالي ، يتم تشفير التغييرات فقط (حركة الجهاز) ، وفي المرة التالية فقط يتم تشفير التغييرات.

وهذا ما يسمى مجموعة من الصور - مجموعة مستقلة من الإطارات المترابطة التي يمكن فك تشفيرها. الترميز هو خوارزمية التحول بين الإطارات. كلما كان برنامج الترميز أكثر حدة ، كلما كان ضغط البيانات أفضل ، والمزيد من الموارد التي يحتاجها.
حول نسبة معدل البت الترميز هناك قواعد عامة (انظر الرابط ).

برامج الترميز الأكثر شيوعًا المستخدمة للمكالمات هي H.264 و VP8 . H.264 جيد لأنه يعمل بجد في كل مكان ولا يأكل بطارية. ولكن عادة على الهواتف واحد التشفير (التشفير) و 4 أجهزة فك التشفير. لكل شيء آخر ، تحتاج إلى برنامج VP8 ، الذي يستهلك بطارية جيدة. يجدر تغيير الأولوية إلى H.264 للمكالمات الجماعية (انظر الرابط الخاص بكيفية القيام بذلك).

يمكن ترميز برنامج الترميز باستخدام متغير (معدل البت المتغير) أو معدل البت الثابت (معدل البت الثابت). العديد من برامج الترميز على الأجهزة لا تدعم معدل البت الثابت ، لذلك عليك أن تعيش مع الصورة على اليسار.

برامج ترميز الصوت

هناك العديد من برامج الترميز القديمة للصوت ، مثل G711. يعتبر برنامج الترميز Opus شائعًا للغاية - فهو يحل مشكلة الترميز عند معدل البت المنخفض والعالي ، لأنه يحتوي داخلها على SILK من Skype وترميز CELT للموسيقى.

تجدر الإشارة إلى أن Opus لديها خوارزمية تصحيح خطأ تصحيح للأمام (FEC). بالنسبة للصوت ، تعمل هذه الخوارزمية كما يلي: في كل حزمة توجد بيانات بجودة عالية وبيانات من إطارات سابقة لبعض الوقت بجودة منخفضة. وفقًا لذلك ، إذا فقدت الحزمة السابقة ، يمكنك الحصول على بيانات الحزمة السابقة بجودة منخفضة وفقدانها بطريقة أو بأخرى. في المتوسط ​​، اتضح جيدًا.

عند العمل مع برامج الترميز الصوتي ، من المثير للاهتمام أن ننظر إلى الرسم البياني ، والذي يوضح نسبة جودة إشارة الدخل ومعدل البت.

يمكن ملاحظة أن Opus يحل جميع المشكلات تقريبًا. من المثير للاهتمام الانتباه إلى AAC ، والذي يستخدم عند ترميز الفيديو في مختلف خدمات الاستضافة ، وترميز Speex القديم ، الذي تم استخدامه حصريًا للصوت ويعمل حتى 32 كيلوبت في الثانية.

بيانات علم أمراض الوسائط

لفهم كيفية عمل الطوبولوجيا ، وما هي الميزات التي لديها ، تحتاج إلى فهم كيفية معالجة برنامج ترميز الفيديو للخسائر.

في الحالة الأولى ، لم نفقد شيئًا ، ونرى صورة جيدة. في السطر الثاني ، يتم فقد إطار عشوائي واحد - توجد قطع أثرية صغيرة في الصورة. في الحالة الثالثة ، اختفى الإطار المرجعي ، لذلك ، حتى يتم عرض الإطار المرجعي التالي ، سيتم عرض التغييرات المتداخلة عشوائيًا مع بعضها البعض.

من الواضح أن صنع أطر مرجعية غالبًا ما يكون مكلفًا لأن معدل البت ينمو. لذلك ، تدعم جميع خدمات الاتصال تقريبًا بطريقة ما القدرة على طلب إطار مرجعي في حالة الخسارة. في WebRTC ، يُطلق على هذا الإطار INTRA الكامل.

أبسط طوبولوجيا هو إرسال جميع مقاطع الفيديو الخاصة بك إلى جميع المشاركين الآخرين في المؤتمر.

نبدأ برنامج ترميز واحد ونبدأ في نقل الفيديو. تقوم أليس بتشغيل الكاميرا ، ويقوم برنامج الترميز بإرسال الفيديو إلى بوريس وديما. ولكن إذا كان لدى Dima إنترنت سيء ، فإن Boris يعاني ، لأنك تحتاج إلى خفض جودة الفيديو بأكمله. وإذا فقد ديما الطلقة وطلب دعمًا ، فسوف يحصل عليها بوريس أيضًا ، رغم أنه لم يكن بحاجة إليها.

من ناحية أخرى ، يمكنك لصق جميع مقاطع الفيديو في تيار واحد. سيتطلب ذلك معدات خاصة ، وربما سيكون هناك تأخير إضافي ، ولكن يوجد مثل هذا الحل أيضًا.

نقل أو تسليم الفيديو والصوت مع الحد الأدنى من التأخير

لدينا خيار من بروتوكولات TCP أو UDP.
من المحتمل أن يتذكر الجميع أن TCP بروتوكول يمكن الاعتماد عليه ، وفي حالة فقد الحزمة يرسلهم مرة أخرى. هذا هو السبب في أن ترتيب الإطارات هذا ممكن ، كما في الصورة أدناه.

إذا كانت الحزمة مفقودة في الحزمة ، فيمكنك تخطي هذا الإطار بحرية من الإطارات الأربعة والعشرين ، لكن برنامج التعاون الفني لن يسمح لك باستلام ما يلي حتى ترسل الرسالة المفقودة. تسليم الفيديو عبر TCP غير فعال للغاية. يوصى باستخدام UDP لمثل هذه المهام ، وتستخدمها جميع خدمات الاتصال.

توفر هذه المقالة جميع ميزات كلا البروتوكولين وتشرح لماذا تعمل جميع الدفق على UDP. كجزء من موضوع اليوم ، يكفي أن نعرف أن UDP غير متوفر في كل مكان ، إنه لا يعمل في 3٪ من الشبكات.

بشكل عام ، يمكن للمستخدمين إنشاء اتصالات P2P فيما بينهم.

هذا هو الأكثر ربحية ، لأنه إذا اتصلنا ببعضنا في نوفوسيبيرسك ، فمن الأفضل بكثير التواصل مباشرة وعدم استخدام خادم إضافي من شأنه أن يوفر قوة.

ولكن NAT موجود ، وأكثر من 97٪ من المستخدمين موجودون الآن خلفه - قليل منهم لديهم عناوين IP خارجية. من ناحية ، سيتم حل هذه المشكلة عاجلاً أم آجلاً بواسطة IPv6. بالمناسبة ، في روسيا ، كان MTS أول من أطلقه. الآن يدعمون IPv6 بشكل كامل ، وجميع عملائهم لديهم عناوين IP بيضاء.

قد يخترق NAT ، قد لا يخترق ، وبعد ذلك سوف تضطر إلى استخدام الإرجاع عبر الخادم. هناك أيضا مقال عن كيفية اختراق NAT.

غضب العازلة بين النقل والإطارات

نحن نمضي قدما. الآن نحن بحاجة إلى غضب العازلة لمستوى تأثير غضب

نبدأ بشكل استباقي في عرض الإطارات مع بعض التأخير وفي الوقت نفسه نصطف الإطارات في نفس الفترة الزمنية في المخزن المؤقت.

يزيد المخزن المؤقت بشكل حيوي.

إذا تم فقد الإطار ، وتم تجميد الصورة ، فسوف يزيد المخزن المؤقت ، ثم نعمل بالفعل مع مخزن مؤقت بهذا الحجم.

ولكن قد يكون هناك موقف عكسي عندما تحتاج إلى تقليل المخزن المؤقت. على سبيل المثال ، استقرت الشبكة ، ويلزم اكتشاف الوقت. إذا قمت ببساطة بتقليل المخزن المؤقت ، فسيكون الأمر سخيفًا ، وسيبدأ الناس في التحدث بسرعة شديدة بصوت جنوم. لذلك ، هناك خوارزميات خاصة تقوم بضبط سرعة الصوت بشكل غير محسوس: قم بإزالة الإيقاف المؤقت بين الكلمات أو انهيار الأصوات الطويلة جدًا في الكلام.

إذا كنت ترغب في تحويل رمز فيديو وإصلاح شيء ما ، فأنت بحاجة أولاً إلى وجود مخزن مؤقت للتوتر ، ولن يقل زمن الوصول عن تردد الارتداد لهذه الشبكة. وهذا يعني ، بالتأكيد زيادة الكمون ، ونتذكر أننا نريد حقا أن نبقى داخل 0.5 ثانية.

الزفير - انتهت النظرية!

يدعو إلى موافق

قبل إجراء مكالمات جماعية ، كان لدينا مكالمات P2P ، تم استخدام مكتبة WebRTC ، وتم جمع عملاء الويب والجوّال ، وتم كتابة الإشارة.

تحليل المنافس

عندما لا تعرف ماذا تفعل ، انظر إلى منافسيك. كمرجع ، اخترنا مجموعة: Skype و WhatsApp و Hangouts و ICQ و Zoom. قمنا بقياس الحد الأقصى لعدد المشاركين في مكالمة جماعية ، الكمون ، استهلاك البطارية ، والجودة.

الشيء الأكثر إثارة للاهتمام هو تحديد التأخير. نحن نفعل ذلك بهذه الطريقة: قم بتشغيل الموقت ، وابدأ تصوير الفيديو ، وقم بإجراء مكالمة.

100 مللي ثانية - تأخير الكاميرا من اللحظة التي اصطدم فيها الفيديو بالعدسة ، قبل رسمها على مصفوفة الهاتف. بعد ذلك ، يتم إرسال الفيديو إلى الشبكة ، ونرى تأخيرًا قدره 310 مللي ثانية بالفعل في المكالمة.

لا تنسَ قياس استخدام وحدة المعالجة المركزية على الجهاز. بدءًا من نظام التشغيل iOS 12 ، أصبح من الممكن القيام بذلك بشكل منهجي ، لكننا نستخدم البيرومتر بالطريقة القديمة.

حصلت على النتائج التالية:

يكون لكل من WhatsApp و ICQ 4 مشاركين في المكالمة ، ويحتوي Skype على 25 (Skype for Business 250) ، ولكل من Hangouts و Zoom 100 مشارك. اعتدت Hangouts أن تضم حوالي 35 عضوًا ، والآن قفز إلى قسم 100+.

يتمتع Zoom بفترة تأخير أطول قليلاً ، لكن Hangouts تستهلك طاقة بطارية أكثر. يبدو لي أن Zoom يتمتع بجودة أفضل ، ولكن هناك مقالات تقول عكس ذلك - وهذا مقياس شخصي.

تستخدم بعض الخدمات WebRTC المفتوحة ، بينما يستخدم البعض الآخر بروتوكولات خاصة. ولكن من الواضح أن نوع النقل الذي تستخدمه أدناه لا يؤثر على عدد المشاركين في المكالمة. هناك حلول مع 100 مكالمة وبروتوكولاتها الخاصة (Zoom) و WebRTC (Hangouts).

مقياس من 2 إلى N

النظر في حالة مثيرة للاهتمام: هناك عميل مع قناة غير المتماثلة ، وإدخال 3 ميغابت / ثانية ، خرج 1.5 ميغابت / ثانية ، وفقدان الحزمة 0.6 ٪ ، غضب 50 مللي ثانية. يوجد فيديو بدقة عالية (1280 × 720) مع معدل بت قدره 1.5 ميغابت في الثانية وفيديو بدقة 640 × 360 (دعنا نسمي LOW) بسرعة 600 كيلوبت في الثانية. نريد أن ننقل أشرطة الفيديو بارد.

في حالة استدعاء شخصين p2p ، فكل شيء بسيط. لديهم شبكة إدخال كافية ، وشبكة الإخراج كافية بإحكام ، لأن القناة غير متماثلة ، ولا توجد مشاكل مع برامج الترميز - جميع برامج الترميز مجانية.

عندما نبدأ في إجراء مكالمات جماعية ، نحتاج إلى إعادة الاتصال بالجميع. أبسط إصدار من الطوبولوجيا هو Mesh أو "الكل للجميع".

من الرائع ألا تكون هناك حاجة للخوادم الوسيطة ، ولكن أصبح من الصعوبة بمكان إعطاء الجميع مقطع الفيديو الخاص بك للعملاء بهذه الخصائص. وإذا تعذر على العميل توزيع الفيديو على شخص ما بمفرده ، فأنت بحاجة إلى خفض الجودة ، لأن البث المشترك تم ترميزه للجميع.

في هذه الحالة ، لا يكفي 5 مشاركين أو 4 ميغابت في الثانية.

لذلك ، في WhatsApp في مكالمة جماعية ، هناك 4 مشاركين بحد أقصى ، ولن يكون هناك ما دامت تستخدم Mesh.

خيار آخر هو جمع الصورة كاملة على الخادم . هذا هو الأكثر ربحية للعميل: لديه اتصال واحد بالخادم ، ويقوم الخادم بجمع الصورة ، ويستقبلها العميل.

ولكن لنفترض أن مستخدمينا من بتروبافلوفسك كامتشاتسكي وكومسومولسك أون أمور ونوفوسيبيرسك يريدون الدردشة عبر خادم موسكو. بطبيعة الحال ، سوف تتحول بشكل سيء للغاية. سيساعد وجود CDN قليلاً ، ولكن لا يزال سيحصل على كمية كبيرة من المخازن المؤقتة المزعجة ، والتي ستجعل في المجموع إضافة جيدة إلى الكمون.

يقترح الهيكل التالي - خلط النهاية - عدم جمع صورة عامة على الخادم لتجنب هذه التأخيرات ، ولكن ببساطة يرمي الحزم.

بمعنى أن الخادم في هذا الهيكل هو مجرد ترحيل ينقل البيانات.

كل شيء يتحسن قليلاً: يتلقى المستخدم تيارات جميع المشاركين الآخرين في المكالمة ويرسل رسالة خاصة به مرة واحدة فقط. ولكن مرة أخرى هناك مشاكل:

• الجودة. جميع مستلمي الدفق لديك لديهم شبكة مختلفة. إذا كان هناك شخص واحد متصل بالإنترنت السيئ ، فيجب أن يتم تسليم الفيديو إليه بدقة منخفضة ، وبالتالي فإن الصورة ستكون سيئة للجميع.
• الأطر المرجعية العاصفة . إذا طلب شخص ذو إنترنت فقير باستمرار إطارًا مرجعيًا ، فسيبدأ الجميع أيضًا في تلقي oporniks. هذا استخدام غير فعال لمعدل البت ، تنخفض الجودة مرة أخرى.

في حالة استخدام نظام مركزي ، يتم جمع كل الفيديو على الخادم. يتطلب هذا العديد من مراحل الترميز ، والتي تضيف كلاً من الكمون وتتطلب أجهزة إضافية. في النهاية ، على العكس ، كل شيء سريع وسهل.

السلبيات طبولوجيا:

• شبكة - الحد الأقصى 4 أعضاء.
• مركزية - مشاكل في الترميز والارتعاش.
• خلط النهاية - الحد من الجودة والإطارات المرجعية العاصفة.

يعمل كل من ICQ و Skype فقط على طوبولوجيا Mesh ، وكل ما تبقى يعمل على الاختلاط النهائي. ولكن ، كما نتذكر ، تختلف جميع الخدمات من حيث الخصائص - مما يعني أنه لا يوجد مجرد خلط نهائي ، ولكن هناك شيء آخر.

فعلت Hangouts الخدعة مع End Mixing.

يتم إطلاق جهازي تشفير على كل عميل: H.264 بجودة عالية و VP8 بجودة منخفضة. وفقًا لذلك ، بالنسبة للمستخدمين الذين لديهم إنترنت جيد ، ينقل الخادم فيديو عالي الجودة ، ولأولئك الذين لديهم إنترنت رديء ، إنه أسوأ ، ويتأقلم النوعية الرديئة مع أسوأ شبكة. هناك نوعان من الميزات الجيدة ، ولكن هذا يمثل حركة مرور إضافية من العملاء واستهلاك البطارية. ولكن ليس هناك غضب العازلة

يوضح الجدول أنه مع تشغيل Hangouts للهاتف ، ترتفع درجة التأخير إلى الحد الأدنى ، لكن النوعية تعاني ، لأن الجودة المنخفضة لا تزال تستهلك معدل البت العالي.

, : - , H.264, ( ) End mixing . centralized-, , , , .

, : . , , , , - . , .

.

, , , latency . , , , , . centralized, , , jitter- . , , .

«», . 100, 50, 20 . .

— , 5 . . : , , , — .

«» , , , — . : , - , fps. , — . - , . , .

Mesh 3-4 latency, , Mesh. , HD End mixing, a SD — centralized.

Zoom.

, - , Zoom , WebRTC. WebRTC , .

.

CPU , . — , , , , CPU , . , .

: , , .

screen sharing . screen sharing, , . screen sharing . , fps — , , .

. — centralized, , . , .

, , , . , , .

, , - . .

Packet pacing

-, UDP- . UDP pacing. UDP- , .

, UDP , 21 100%. — .

pacing? , ( ) — , . , , , , , , - .

:

• pacing, .
• pacing, , , , .

: , pacing , —.

packet pacing?

, ( ) , , - . ( ), , , .

— packet loss , pacing.

MTU

TCP , MTU. UDP, , MTU — , .

MTU 1500, MTU 1100, . , , , , , ( ). , MTU .

TCP , . , MTU: - , , , MTU. , MTU, , .

.

, : , , . 98% 1350. MTU = 1350 , , 2% — , .

WebRTC SACK, NACK, FEC. .

, 1–3% — , .

WebRTC negative acknowledgement (NACK).

, , - , .

, TCP acknowledgement, selective acknowledgement. negative acknowledgement , FEC (Forward Error Correction).

, SACK, NACK, FEC, .

FEC , , . : , , . , , — .

FEC — XOR, , , . , - .

, . , , , FEC-. , , , , .

, , . , :

• 90% 500 /.
• — 3-4, Mesh End mixing.
• — 27 (, ).

Check List

:

• Packet pacing.
• MTU discovery.
• .
• C .

, signalling, WebRTC, , , - .

, :

• Packet loss: , packet pacing, FEC, MTU.
• : back pressure , FEC-.
• Jitter jitter buffer, latency.
• RTT: , signaling.

WebRTC — . RTP, , , . WebRTC .

, Zoom, Skype Line, . . . , , UDP- ( , WebRTC), . , , . , Google STADIA.

STADIA — , . WebRTC, , . Google WebRTC. WebRTC SRTP WebRTC QUIC. , , .

QUIC, . Chrome c Android Google YouTube, TCP — QUIC UDP Google. 30% QUIC/UDP.

QUIC 20-30%, TCP. - QUIC , .

النتائج

, . , : signaling; / ; . , , .

?

• , - , .
• , .

/ .

, , — . , latency, . , ! - :)

HighLoad++ . ( ) , 6-7 2020 . , .