مليون مكالمة فيديو في اليوم أو "Call mom!"

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



مزيد من النسخة النصية من التقرير على HighLoad ++ سيبيريا ، والتي سوف تتعلم منها:

• كيف تعمل خدمات مكالمات الفيديو تحت غطاء المحرك ؛
• كم هو جميل اختراق NAT - سيكون هذا مثيرًا للاهتمام لمتخصصي الألعاب الذين يحتاجون إلى اتصال نظير إلى نظير ؛
• كيف يعمل WebRTC ، ما هي البروتوكولات التي يتضمنها ؛
• كيف يمكنني ضبط WebRTC من خلال BigData.

عن المتحدث: ألكسندر توبول يقود تطوير منصات الفيديو والشريط على ok.ru.

سجل مكالمات الفيديو

ظهر أول جهاز مكالمات فيديو في عام 1960 ، وكان يطلق عليه هاتف picherphone ، واستخدم شبكات مخصصة وكان باهظ الثمن للغاية. في عام 2006 ، أضاف Skype مكالمات فيديو إلى تطبيقه. في عام 2010 ، دعم Flash بروتوكول RTMFP ، وأطلقنا في Odnoklassniki مكالمات فيديو Flash. في عام 2016 ، توقف Chrome عن دعم Flash ، وفي أغسطس 2017 ، قمنا بإعادة تشغيل المكالمات باستخدام التكنولوجيا الجديدة ، والتي سأتحدث عنها اليوم. بعد الانتهاء من الخدمة ، لمدة ستة أشهر أخرى ، حصلنا على زيادة كبيرة في المكالمات المكتملة بنجاح. في الآونة الأخيرة ، لدينا أيضًا أقنعة في المكالمات.

العمارة والمعارف التقليدية

نظرًا لأننا نعمل في شبكة اجتماعية ، فليس لدينا مهام فنية ، ولا نعرف ما هي المعارف التقليدية. عادة ما تلائم الفكرة بأكملها على صفحة واحدة وتبدو على هذا النحو.


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

المواصفات الفنية

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

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


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


ولكن أكثر ما يزعج المستخدم هو تأخر المكالمات. يعد الكمون أحد الخصائص المهمة للمكالمات. مع الكمون في محادثة تستغرق 5 ثوانٍ ، من المستحيل تمامًا إجراء حوار.


لقد حددنا لأنفسنا خصائص مقبولة:

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

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


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

الإنترنت مقابل TTX

ما الذي يمنعك من تحقيق هذه الميزات الرائعة؟ الإنترنت!


على الإنترنت ، هناك أشياء مثل وقت الذهاب والإياب (RTT) ، والتي لا يمكن التغلب عليها ، هناك عرض نطاق متغير ، هناك NAT.

في السابق ، قمنا بقياس سرعة الإرسال في شبكات مستخدمينا.


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


هناك مشاكل أخرى على الإنترنت:

• خسارة الحزم - قمنا بقياس خسارة الحزم العشوائية بنسبة 0.6٪ (نحن لا نأخذ في الحسبان فقدان حزم الازدحام بعدد كبير من الحزم).
• إعادة الترتيب - يمكنك إرسال الحزم بنفس الترتيب ، وتقوم الشبكة بإعادة فرزها.
• Jitter - إرسال مقطع فيديو أو دفق صوتي في فترة زمنية معينة ، وتجتمع الحزم معًا من جانب العميل في حزم ، على سبيل المثال ، بسبب التخزين المؤقت على أجهزة الشبكة.
• NAT - اتضح أن أكثر من 97 ٪ من المستخدمين هم وراء NAT. سنتحدث عن لماذا وماذا وكيف.

ضع في اعتبارك إعدادات الشبكة المذكورة أعلاه بمثال بسيط.

قمت باستدعاء موقع جامعة Novosibirsk State على الويب من مكتبي وحصلت على مثل هذا الأمر الغريب.


متوسط ​​الارتعاش في هذا المثال هو 30 مللي ثانية ، أي أن متوسط ​​الفاصل الزمني بين مرات ping المجاورة يبلغ حوالي 30 مللي ثانية ، ومتوسط ​​ping هو 105 مللي ثانية.

ما هو المهم في المكالمات ، لماذا سنقاتل من أجل p2p؟


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

لذلك ، فإن معظم المقال مخصص لكيفية جعل p2p جيدة.

التاريخ أو الإرث

كما قلت ، لدينا خدمة مكالمات منذ عام 2010 ، والآن قمنا بإعادة تشغيلها.


في عام 2006 ، عندما بدأ Skype ، اشترى Flash شركة Amicima ، التي صنعت RTMFP. يحتوي Flash بالفعل على RTMP ، والذي يمكن استخدامه من حيث المبدأ للمكالمات ، وغالبًا ما يتم استخدامه للدفق. فتح Flash مواصفات RTMP فيما بعد. أتساءل لماذا كانوا بحاجة إلى RTMFP؟ في عام 2010 ، استخدمنا RTMFP.

قارن بين متطلبات بروتوكولات الاستدعاء وبروتوكولات التدفق الحقيقي ومعرفة مكان هذا الحد.


RTMP هو أكثر من بروتوكول دفق الفيديو. يستخدم TCP ، ولديه تأخير تراكمي. إذا كان لديك اتصال جيد بالإنترنت ، فستعمل مكالمات RTMP.

بروتوكول RTMFP ، على الرغم من الاختلاف في حرف واحد فقط ، هو بروتوكول UDP. وهي خالية من مشاكل التخزين المؤقت - تلك الموجودة على TCP ؛ إنه محروم من حظر رأس الخط - هذا عندما تفقد حزمة واحدة ، ولا يقوم TCP بإعادة الحزم التالية حتى يحين الوقت لإرسال الحزمة المفقودة مرة أخرى. كان RTMFP قادرًا على التعامل مع NAT وكان يواجه تغييرًا في عنوان IP للعملاء. لذلك ، أطلقنا الويب على RTMFP في عام 2010.


ثم في عام 2011 فقط ظهرت المسودة الأولية WebRTC ، والتي لم تكن تعمل بكامل طاقتها بعد. في عام 2012 ، بدأنا في دعم المكالمات على iOS / Android ، ثم حدث شيء آخر ، وفي عام 2016 توقف Chrome عن دعم Flash. كان علينا القيام بشيء ما.


نظرنا إلى جميع بروتوكولات VoIP: كما هو الحال دائمًا ، من أجل القيام بشيء ما ، نبدأ بالنظر إلى المنافسين.

المنافسين أو من أين تبدأ

لقد اخترنا أشهر المنافسين: Skype و WhatsApp و Google Duo (على غرار Hangouts) و ICQ.

بادئ ذي بدء ، قمنا بقياس التأخير.


من السهل القيام بذلك. أعلاه صورة حيث:

• ساعة التوقيف (انظر الهاتف في أعلى اليسار) ، والذي يوضح الوقت (03:08).
• يقوم الهاتف القريب بإجراء مكالمة ويأخذ الهاتف الأول كفيديو. من لحظة دخول الصورة إلى كاميرا الهاتف ، ورأيتها ، استغرق الأمر حوالي 100 مللي ثانية.
• مكالمة إلى هاتف آخر (أبيض) ومرة ​​أخرى. هنا التأخير حوالي 310 مللي ثانية مع Google Duo.

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


لا يزال Skype يقاطع قليلاً. اتضح أنه مع Skype ، في حالة فشل توصيل p2p ، فإن التأخير هو 1.1 ثانية.

كانت بيئة الاختبار معقدة. اختبرنا في ظروف مختلفة (EDGE و 3G و LTE و WiFi) ، وأخذنا في الاعتبار أن القنوات غير متماثلة ، وأعطي متوسط ​​القيم لجميع القياسات.


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


والنتيجة هي:

• كان الأبطأ في التأخير هو ICQ و Skype ، والأسرع - Telegram. هذه ليست مقارنة صحيحة تمامًا ، نظرًا لأن Telegram لا تحتوي على مكالمات فيديو ، ولكن لديها الحد الأدنى من الكمون في الصوت. يعمل WhatsApp (حوالي 200 مللي ثانية) و Hangouts - 390 مللي ثانية بشكل رائع.
• حسب درجة الحرارة ، يأكل Telegram الأقل بدون فيديو ، وسكايب أكثر.
• من حيث وقت الاستجابة ، ينشئ Telegram الاتصال لأطول وقت ، وأسرع WhatsApp و Google Duo.

رائع ، لدينا بعض المقاييس!


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

دعونا نرى ما يتم تنفيذه كله.


لدى Skype بروتوكول خاص بها ، ويستخدم أي شخص آخر إما تعديل WebRTC ، أو بشكل عام WebRTC بشكل مباشر. يمكن لـ Hangouts و Google Duo و WhatsApp و Facebook Messenger العمل مع الويب ، وجميعهم لديهم WebRTC تحت الغطاء. كلهم مختلفون للغاية ، مع خصائص مختلفة ، ولديهم WebRTC واحد! لذا ، يجب أن تكون قادرًا على طهيه بشكل صحيح. بالإضافة إلى وجود Telegram ، حيث تتحمل بعض أجزاء WebRTC الجزء الصوتي ، هناك ICQ ، الذي تعمد WebRTC لفترة طويلة واستمر في تطوير طريقه الخاص.

WebRTC العمارة

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

WebRTC تجريبي

لنبدأ بعرض توضيحي بسيط. هناك 5 خطوات بسيطة لإنشاء اتصال WebRTC.


تقول ما يلي:

1. التقط مقطع فيديو وقم بإنشاء اتصال نظير ، وانقل نوعًا من iceServers (لا يتضح على الفور ما هو).
   
2. قم بإنشاء عرض SDP وإرساله إلى إرسال الإشارات ، ولن يتم تطبيق إشارة WebRTC لك بأي شكل من الأشكال.
   
3. ثم تحتاج إلى إنشاء غلاف للواحد من الإشارات ، وهذا أيضًا ليس جزءًا من WebRTC.
   
4. مزيد من تبادل بعض المرشحين.
   
5. أخيرا الحصول على دفق الفيديو عن بعد.
   

دعونا نكتشف ما يحدث هناك وما نحتاجه لتنفيذ أنفسنا.


نحن ننظر إلى الصورة من الأسفل إلى الأعلى. توجد مكتبة WebRTC مدمجة بالفعل في المتصفح ، مدعومة من Chrome و Firefox وما إلى ذلك. يمكنك إنشائها تحت Android / iOS والتواصل معها من خلال API و SDP (بروتوكول وصف الجلسة) ، الذي يصف الجلسة نفسها. أدناه سأقول لك ما هو مدرج فيه. لاستخدام هذه المكتبة في تطبيقك ، يجب عليك إنشاء اتصال بين المشتركين من خلال التشوير. التشوير هو أيضًا خدمتك التي يجب أن تكتبها بنفسك ، لا يوفرها WebRTC.

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

شبكة WebRTC أو p2p (في الواقع c2s2c)

يبدو أن إعداد اتصال P2P أمر بسيط للغاية.


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


في الواقع ، من المرجح أن يجلس كلا المستخدمين خلف أجهزة توجيه Wi-Fi وهذه هي عناوين IP المحلية الرمادية. يوفر لهم جهاز التوجيه ميزة مثل ترجمة عنوان الشبكة (NAT). كيف تعمل؟


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

فيما يلي توضيح لكيفية ظهوره في مكاني.


هذا هو عنوان IP الداخلي الخاص بي وعنوان جهاز التوجيه (بالمناسبة ، رمادي أيضًا). إذا قمت بتتبع المسار ورأيت ، فسترى جهاز توجيه Wi-Fi الخاص بي: حزمة من عناوين الموفر الرمادي وعنوان IP خارجي أبيض. وبالتالي ، في الواقع ، سيكون لدي نوعان من NAT: أحدهما أستخدمه على شبكة Wi-Fi ، والآخر من المزود ، ما لم أشتري بالطبع عنوان IP خارجيًا مخصصًا.

تحظى NAT بشعبية كبيرة بسبب:

• لا يزال العديد من IPv4 مفقودًا ، ولا توجد عناوين كافية ؛
• يبدو أن NAT تحمي الشبكة ؛
• هذه وظيفة قياسية لجهاز التوجيه: الاتصال بشبكة Wi-Fi ، وهناك NAT هناك ، تعمل.

لذلك ، يجلس 3 ٪ فقط من المستخدمين مع IP خارجي ، في حين أن كل ما تبقى من خلال NAT.

يسمح لك NAT بالانتقال بأمان إلى أي عناوين بيضاء. ولكن إذا لم تذهب إلى أي مكان ، فلا يمكن لأحد أن يأتي إليك.


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

WebRTC لديه بروتوكول STUN لحل هذه المشكلة. يقترح نشر خادم STUN. ثم تتصل أليس بخادم STUN ، وتحصل على عنوان IP الخاص بها ، وترسله إلى بوب عبر الإشارة. يحصل بوب أيضًا على عنوان IP الخاص به ويرسله إلى Alice. يرسلون الحزم تجاه بعضهم البعض وبالتالي اختراق NAT.


السؤال : لدى Alice منفذ محدد مفتوح ، وقد تم بالفعل اختراق NAT / Firewall إلى هذا المنفذ ، و Bob مفتوح. يعرفون عناوين بعضهم البعض. يحاول أليس إرسال الحزمة إلى بوب ؛ يرسل الحزمة إلى أليس. هل تعتقد أنهم يستطيعون التحدث أم لا؟

في الواقع ، أنت على حق في أي حال ، تعتمد النتيجة على نوع زوج NAT لدى المستخدمين.

ترجمة عنوان الشبكة

هناك 4 أنواع من NAT:

1. مخروط كامل NAT ؛
   
2. مخروط مقيد NAT ؛
   
3. مخروط مقيد منفذ NAT ؛
   
4. NAT متماثل
   

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


فيما يلي مخطط التفاعل: ترسل أليس من بعض المنافذ حزمة إلى منفذ STUN ، فيجيبها STUN بعنوانها الخارجي. يمكن لـ STUN الرد من أي عنوان ، إذا كان NAT مخروطًا كاملًا ، فسيستمر في الضرب من خلال NAT ، ويمكن لـ Bob الرد على نفس العنوان.


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


كيف يتم حل هذه المشكلة؟ في مخطط بسيط (انظر الرسم التوضيحي أدناه) مثل هذا: ترسل أليس حزمة إلى STUN ، ويجيب عليها بعنوان IP الخاص بها. يمكن لـ STUN الرد عليه من أي منفذ طالما أنه مخروط مقيد NAT. لا يستطيع بوب الرد على أليس لأنه لديه عنوان مختلف. تستجيب أليس بحزمة ، مع العلم بعنوان IP الخاص بـ Bob. تفتح NAT لبوب ، يجيبها بوب. صرخة ، تحدثوا.


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

الشيء الأكثر ضررًا هو التناظر NAT .


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

في الاتجاه المعاكس ، إذا كان لدى بوب عنوان IP مفتوح ، فقد تأتي إليز Alice للتو وسيقيمون اتصالًا.

يتم جمع جميع الخيارات في جدول واحد أدناه.


يظهر أن كل شيء ممكن تقريبًا باستثناء عندما نحاول إنشاء اتصالات من خلال تناظر NAT مع مخروط مقيد منفذ NAT أو تناظر NAT على الطرف الآخر.


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

تدرب

تمتلك Google خوادم STUN مجانية. يمكنك وضعها في المكتبة ، وسوف تعمل.

خوادم TURN لها بيانات اعتماد (تسجيل الدخول وكلمة المرور). على الأرجح ، سيكون عليك رفع الخاص بك ، فمن الصعب إلى حد ما أن تجد مجانية.

أمثلة لخوادم STUN المجانية من Google:

• صاعقة: stun.l.google.com: 19302
• صاعقة: stun1.l.google.com: 19302
• صاعقة: stun2.l.google.com: 19302
• صاعقة: stun3.l.google.com: 19302

وخادم TURN مجاني مع كلمات المرور: url: 'turn: 192.158.29.39: 3478؟ Transport = udp' ، بيانات الاعتماد: 'JZEOEt2V3Qb0y27GRntt2u2PAYA =' ، اسم المستخدم: '28224511: 1379330808 ′.

نستخدم coturn .


ونتيجة لذلك ، يمر 34٪ من حركة المرور عبر اتصال p2p ، وكل شيء آخر يتم تحويله عبر خادم TURN.

ما هو المثير للاهتمام في بروتوكول STUN؟

يسمح لك STUN بتحديد نوع NAT.


رابط الشريحة

عند إرسال حزمة ، يمكنك الإشارة إلى رغبتك في تلقي استجابة من نفس المنفذ أو مطالبة STUN بالاستجابة من منفذ مختلف أو من IP مختلف أو حتى من IP ومنفذ مختلفين. وبالتالي ، بالنسبة إلى 4 استعلامات إلى خادم STUN ، يمكنك تحديد نوع NAT .


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

قد تسأل لماذا أخبرك بكل هذا إذا كان بإمكانك فقط أخذ STUN من Google ، ووضعه في WebRTC ، ويبدو أن كل شيء سيعمل.

لأنه يمكنك بالفعل تحديد نوع NAT بنفسك.


هذا رابط إلى تطبيق Java لا يفعل شيئًا صعبًا: فهو يدقق فقط في المنافذ المختلفة وخوادم STUN المختلفة ، وينظر إلى المنفذ الذي يراه في النهاية. إذا كان لديك Open Full cone NAT ، فسيكون خادم STUN له نفس المنفذ. مع مخروط مقيد NAT ، سيكون لديك منافذ مختلفة لكل طلب STUN.


مع Symmetric NAT ، اتضح مثل هذا في مكتبي. هناك منافذ مختلفة تمامًا.

ولكن في بعض الأحيان يكون هناك نمط مثير للاهتمام أنه لكل اتصال ، يزداد رقم المنفذ بمقدار واحد.


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


وهكذا نكسر NAT - نذهب إلى خادم STUN ، إلى خادم آخر ، انظر إلى الاختلاف ، وقارن وحاول مرة أخرى لإعطاء منفذنا بالفعل مع هذه الزيادة أو النقصان. أي أن أليس تحاول منح بوب ميناءها ، الذي تم تعديله بالفعل لثابت ، مع العلم أنه في المرة القادمة سيكون الأمر كذلك.


لذا تمكنا من لحام 12٪ من نظير إلى نظير .

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

ترحيل CDN أو ماذا تفعل إذا لم تتمكن من إنشاء اتصال P2P

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

1. صدر بطريق الخطأ لبعض مستخدمي موقع موسكو ، والبعض الآخر - بعيد.
   
2. قمنا بجمع إحصائيات حول IP للمستخدم ، على الخوادم وخصائص الشبكة.
   
3. بواسطة maxMind ، قمنا بتجميع الشبكات الفرعية ، ونظرنا إلى الإحصائيات وتمكننا من فهم IP من هو المستخدم الذي لديه أقرب خادم TURN للاتصال.
   

يوجد CDN في نوفوسيبيرسك. إذا كان كل شيء يصلح لك من خلال موسكو ، فإن النسبة المئوية 99 من RTT هي 1.3 ثانية. من خلال CDN ، يعمل كل شيء بشكل أسرع (0.4 ثانية).

هل من الأفضل دائمًا استخدام اتصال p2p وعدم استخدام خادم؟ مثال مثير للاهتمام هو مزودي Krasnoyarsk Optibyte و Mobra (ربما تغيرت الأسماء). لسبب ما ، فإن الاتصال بينهما على p2p أسوأ بكثير من MSK. ربما ليسوا أصدقاء مع بعضهم البعض.


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

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


كيف تفهم أيهما أفضل: إنترنت بسرعة 2 ميجابت / ثانية و 400 مللي ثانية RTT و 5٪ فقدان للحزمة أو 100 كيلوبت / ثانية وتأخير 100 مللي ثانية وفقدان ضئيل للحزم؟

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

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

العودة إلى مخططنا للمقال ، ما زلنا نناقش الشبكة.

كيف يبدو إعداد الاتصال؟


نقوم بإرسال خوادم STUN و TURN إلى PeerConnection () ، ويتم إنشاء اتصال. تكتشف أليس عنوان IP الخاص بها وترسله إلى الإشارات ؛ يتعلم بوب عن عنوان IP الخاص بأليس. أليس تحصل على عنوان IP الخاص بـ Bob. يتبادلون الحزم ، ربما اختراق NAT ، ربما تعيين TURN والتواصل.


في الخطوات الخمس لتأسيس الاتصال الذي ناقشناه سابقًا ، اكتشفنا الخوادم ، وحددنا مكان الحصول عليها ، وأن مرشحي ICE هم عناوين IP خارجية نتبادلها من خلال الإشارات. يمكن أيضًا محاولة اختراق عناوين IP الداخلية للعملاء ، إذا كانت في نطاق شبكة Wi-Fi واحدة.

دعنا ننتقل إلى جزء الفيديو.

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

يدعم WebRTC مجموعة معينة من برامج ترميز الفيديو والصوت ، ولكن يمكنك إضافة برنامج الترميز الخاص بك هناك. مدعوم بشكل أساسي من H.264 و VP8 للفيديو . VP8 هو برنامج ترميز ، لذلك يستهلك الكثير من البطارية. لا يتوفر H.264 على جميع الأجهزة (عادةً ما يكون أصليًا) ، لذلك تكون الأولوية الافتراضية على VP8.

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

بالنسبة إلى الصوت ، يحتوي WebRTC على OPUS أو G711 ، وعادة ما تعمل جميع OPUS دائمًا ، ولا يلزم فعل أي شيء به.

فيما يلي قياسات درجة الحرارة بعد 10 دقائق من الاستخدام.


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

الشيء الثاني الذي يمكنك تمكينه إذا كنت تستخدم WebRTC هو إيقاف تشغيل الفيديو تلقائيًا عندما يكون الاتصال ضعيفًا للغاية .


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


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

يعمل WhatsApp مع مقاطع الفيديو والصابون للغاية ، ولكن مع تأخيرات صغيرة ، حيث يضغط بقوة على معدل البت من الأعلى.

قمنا بجمع الإحصائيات باستخدام MaxMind ورسمناها.


هذه جودة بداية تقريبية نستخدمها للمكالمات في مناطق مختلفة من روسيا.

التشوير

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


هناك تطبيق بإشارات تتصل بالتبادل مع SDP ، و SDP أدناه هو واجهة WebRTC.

هذا هو شكل الإشارات البسيطة:


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

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

يجب أن نفعل شيئا حيال ذلك! ستقول لي أن كل شيء يمكن القيام به بكل بساطة.



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

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

فعلنا ذلك ، وبدا أن كل شيء كان رائعًا. لكن لا.


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


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


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

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


ماذا أفعل مع أطول جزء بعد أن التقط الهاتف وبدأ التبادل؟


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

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

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

يعمل بسرعة كبيرة. تمكنا باستخدام مثل هذه الخوارزمية للوصول إلى خصائص مشابهة لـ Google Duo و WhatsApp.


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

ما هي المشاكل الأخرى التي تنتظرك؟


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


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

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


رابط على الشريحة إلى الفيديو والارتباط بنسخة النص

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

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

تبدو الخوارزمية كما يلي:

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

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

من وجهة نظر قاعدة البيانات ، نستخدم وظيفة إضافية عبر كاساندرا ، والتي تتيح لك إجراء المعاملات عليها ( الفيديو هو حول ذلك).

لذا ، تعلمت:

• ما هي خوادم الجليد وكيفية نقلها ؛
• ما هو بروتوكول وصف الجلسة؟
• أنه يجب إنشاؤها وإرسالها إلى الجانب الآخر ؛
• أنه يجب أخذها من الإشارات ونقلها إلى WebRTC على الجانب الآخر ، مع تبادلها مع عناوين IP الخارجية ؛
• وابدأ في إرسال مقاطع الفيديو!

لقد تلقينا:

• المكالمات التي لها تأخير أقل من متوسط ​​السوق ؛
• لم نقم بتسخين الهواتف كثيرًا ؛
• وقت الاستجابة في تطبيقنا على المستوى الأعلى.

واو!

الأمن رجل في الهجوم الأوسط على WebRTC

لنتحدث عن رجل في الهجوم الأوسط لـ WebRTC. في الواقع ، يعد WebRTC بروتوكولًا صعبًا للغاية لأنه يعتمد على RTP ، الذي لا يزال عام 1996 ، وجاء SDP في عام 1998 من SIP.


في الأسفل ، قائمة ضخمة هي مجموعة من RFC وامتدادات RTP الأخرى التي تجعل RTP WebRTC.

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

كان تاريخ WebRTC معقدًا. تم إصدار أول مسودة إصدار في عام 2011 ، في عام 2013 دعم Firefox هذا البروتوكول ، ثم بدأ بناؤه على iOS / Android ، في 2014 Opera. بشكل عام ، تطورت لسنوات عديدة ، لكنها لا تزال لا تحل مشكلة واحدة مثيرة للاهتمام.


عندما يتصل Alice و Bob بالإشارة ، فإنهما يستخدمان هذه القناة ، ويؤسسان مصافحة DTLS ويؤمنان الاتصال. كل شيء رائع ، ولكن إذا تبين أنه ليس إشارة لنا ، فإن الشخص الموجود في المنتصف لديه ، من حيث المبدأ ، الفرصة "لكسب المال" مع كل من أليس وبوب ، لمنع كل حركة المرور والتنصت على ما يحدث هناك.


إذا كانت لديك خدمة تتمتع بثقة عالية ، فأنت بالطبع بحاجة إلى استخدام HTTPS و WSS وما إلى ذلك. هناك حل آخر مثير للاهتمام - ZRTP ، يتم استخدامه ، على سبيل المثال ، بواسطة Telegram.

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

كيف يعمل؟


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

عندما يظهر ديف بين أليس وبوب ، يتبادلان المفاتيح نفسها معه ، ويحصلان على K ₁ و K _{2 ،} على التوالي. لا توجد وسيلة لتتبع وجود هذا الشخص في الوسط. ثم يتم تطبيق مثل هذه الخدعة. هذه المفاتيح هي K ₁ و K ₂سيكون ديف مختلفًا بالتأكيد ، حيث يقوم أليس وبوب بتوليد مفاتيحهما بشكل عشوائي. نأخذ فقط بعض التجزئة من K ₁ و K ₂ ونعرضها في الرمز التعبيري: في تفاحة أو كمثرى - في أي شيء ، والناس ببساطة يطلقون الصور التي يرونها بصوتهم. نظرًا لأنه يمكنك التعرف على بعضهم البعض بالصوت ، وإذا كانت هذه الصور مختلفة ، فهناك شخص بينك وربما يستمع إليك.

النتائج

• قمنا "بتعدين" نوع NAT واخترقنا NAT المتماثل.
• تم تقييمها إحصائيًا ، أيهما أفضل: p2p أو مرحل ، جودة ، CDN ؛ وتحسين جودة النجوم من وجهة نظر المستخدمين.
• تغيير أولويات برامج الترميز ، وفر القليل من البطارية.
• تقليل التأخير في الإرسال.

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

تعليمات بسيطة

إذا لم تكن بحاجة إلى كل هذا ، فهناك تعليمات بسيطة جدًا:

• قم بتنزيل الكود من WebRTC ( https://webrtc.org/native-code/development/ ) ، وقم بتجميعه تحت iOS / Android ، فهو موجود بالفعل في جميع المتصفحات ؛
• نشر coturn ( https://github.com/coturn/coturn ) ؛
• كتابة الإشارات.

كل شيء يرن ، والرنين جيد جدًا.

HighLoad++ 4-.

, . , 19 (10 9 -) , - . , , .