نكتب بروتوكولنا فوق UDP

ظهرت أول عمليات البث المباشر من المشهد في روسيا منذ 70 عامًا تقريبًا وتم بثها من محطة تلفزيون محمولة (PTS) ، والتي بدت وكأنها عربة ترولي باص وسمحت لك بالبث من خارج الاستوديو. وقبل ثلاث سنوات فقط سمح بيريسكوب باستخدام الهاتف المحمول بدلاً من "ترولي باص".

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


بعد ستة أشهر ، في صيف عام 2016 ، أطلق Odnoklassniki تطبيقهم المتوافق مع البث المباشر للجوّال ، حيث حاولوا حل هذه المشاكل.

ألكسندر توبول مسؤول عن الجزء التقني من الفيديو في Odnoklassniki وفي Highload ++ 2017 تحدث عن كيفية كتابة بروتوكول UDP الخاص بك ، ولماذا قد يكون هذا مطلوبًا.

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


يقولون أننا يجب أن نبدأ دائمًا بالهندسة المعمارية والمعارف التقليدية - من المفترض أنه مستحيل بدون هذا! لذلك دعونا نفعل ذلك.

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

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


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

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

قررنا السير في الاتجاه المعاكس ورأينا ما لا يريد المستخدمون رؤيته من خدمة البث.

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

هذا ما تبدو عليه خدمة البث العادية. دعنا نرى ما يمكن فعله للقيام بخدمة دفق منتظمة بدلاً من الخدمة المعتادة.


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

ماذا لدى المنافسين؟

بدأنا باستكشاف خدمات المنافسين. افتح Periscope - ماذا لديهم؟

كالعادة ، الشيء الرئيسي هو العمارة.


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

نقوم باختبار Periscope على متطلباتنا الرئيسية الثلاثة.

لديهم سرعة بدء مقبولة (أقل من ثانية على شبكات جيدة) ، وجودة ثابتة تبلغ حوالي 600 بكسل (ليست عالية الدقة) ، وفي الوقت نفسه يمكن أن تصل التأخيرات إلى 12 ثانية .

بالمناسبة ، كيف تقيس التأخير في البث؟

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

عذرًا! إنها متخلفة قليلاً - حوالي 12 ثانية.

لمعرفة أسباب التأخير ، نقوم بدفق ملف الفيديو.

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

في الأساس ، هناك نقطتان صعبتان رئيسيتان يجب مراعاتهما:

• ترميز / فك تشفير الفيديو ؛
  
• بروتوكولات الشبكة .
  

ترميز / فك تشفير الفيديو

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

ما هو الفيديو؟ هذه مجموعة من الإطارات ، ولكنها ليست بسيطة للغاية. الإطارات من ثلاثة أنواع: I و P و B-frame:

• I-frame هو فقط jpg. في الواقع ، هذا إطار مرجعي ، لا يعتمد على أي شخص ويحتوي على صورة واضحة.
  
• يعتمد الإطار P فقط على الإطارات السابقة.
  
• قد يعتمد الإطار B الصعب على المستقبل. هذا يعني أنه من أجل حساب الإطار b ، من الضروري أن تأتي الإطارات المستقبلية أيضًا من الكاميرا. عندها فقط يمكن فك إطار b مع بعض التأخير.
  

هذا يدل على أن B- الإطارات ضارة . دعونا نحاول إزالتها.

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

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

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

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

4. وفي الخلفية ، تحتاج إلى إضافة برنامج ترميز zerolatency إلى H264 - سيسمح لك ذلك بعدم عمل تبعيات في الإطارات للمستقبل.

بروتوكولات نقل الفيديو

فكر في بروتوكولات التدفق التي تقدمها الصناعة. لقد قسمتها بشكل مشروط إلى نوعين:

1. بروتوكولات التدفق ؛
   
2. بروتوكولات المقطع.
   

بروتوكولات التدفق هي بروتوكولات من عالم مكالمات p2p: RTMP ، webRTC ، RTSP / RTP . تختلف في أن المستخدمين يتفقون على القناة التي لديهم ، حدد معدل بت الترميز وفقًا للقناة. ولديهم أيضًا فرق إضافية من هذا النوع ، مثل "أعطني لقطة مرجعية". إذا فقدت إطارًا ، يمكنك طلبه مرة أخرى في هذه البروتوكولات.

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

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

بروتوكولات الجري

يستخدم Periscope RTMP. ظهر هذا البروتوكول في عام 2009 ، وفي البداية لم تحدده Adobe بالكامل. ثم واجه صعوبة معينة في حقيقة أن Adobe أرادت بيع خادمها حصريًا. أي أن RTMP تطورت صعبة للغاية. مشكلته الرئيسية هي أنه يستخدم TCP ، ولكن لسبب ما اختاره بيريسكوب.



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



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

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

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

واو!

ولكن مع ذلك ، لدينا RTMP عبر TCP ، ولم يؤمننا أحد من حجب بداية قائمة الانتظار.



هذا موضح في الشكل: نتلقى إطارات الصوت والفيديو ، حزم RTMP لهم ، ربما يقومون بخلطها بطريقة ما ، ويطيرون إلى الشبكة.

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


هناك مشكلة أخرى في استخدام بروتوكول TCP في التدفق.

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

ليس لدينا إدارة عازلة ، ولا تحديد أولويات ، لذا فإن TCP غير مناسب للغاية للبث .



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

• 1.1 ميغابت في الثانية حركة المرور ؛
  
• 0.1٪ فقدان الحزمة ؛
  
• متوسط ​​RT 300 مللي ثانية.
  

وإذا نظرت إلى بعض المناطق وعوامل التشغيل المحددة ، فحينئذٍ يكون متوسط ​​نسبة فقدان الحزمة اليومية أكثر من 3٪ ، و RTT من 600 مللي ثانية أمر طبيعي.

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

يؤدي فقدان حتى 0.001٪ من الحزم إلى انخفاض معدل النقل بنسبة 30٪. أي أن مستخدمنا لا يستخدم القناة بنسبة 30٪ بسبب عدم كفاءة بروتوكول TCP في الشبكات التي تفقد حزمًا عشوائية.

في بعض المناطق ، يصل فقدان الحزمة إلى 1٪ ، ثم يحصل المستخدم على حوالي 10٪ من عرض النطاق الترددي.

لذلك ، لن نقوم TCP .

دعونا نرى ما هو آخر في عالم البث من UDP.

عمل بروتوكول WebRTC بشكل جيد للغاية مع مكالمات p2p. يكتبون على المواقع الشهيرة جدًا أن استخدامه للمكالمات رائع جدًا ، ولكن لتقديم الفيديو والموسيقى ليس جيدًا.

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

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



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

المشكلة الثانية هي أنه إذا كان أحد عملائك لا يدعم أي امتداد ، فلن يعمل البروتوكول.

بروتوكولات المقطع

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



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

مثال آخر على التدفق المجزأ هو HLS .

MPEG-Dash هو حل من Google ، وهو يعمل بشكل جيد في Android ، وحل Apple أقدم ، ولديه عدد من العيوب المحددة.



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

إذا نظرت بمزيد من التفصيل ، فإن كل مقطع هو MPEG2-TS. تم إعداد هذا البروتوكول أيضًا للقمر الصناعي ؛ حجم الرزمة هو 188 بايت . من غير المناسب حزم الفيديو بهذا الحجم ، خاصةً لأنك تزوده برأس صغير طوال الوقت.

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



لكن أبل لا تقف مكتوفة الأيدي. في عام 2016 ، أعلنوا أخيرًا أن لديهم الفرصة لاقتحام جزء من MPEG4 في HLS. ثم وعدوا بإضافة هذا فقط للمطورين ، ولكن يبدو أن الدعم الآن لنظامي macOS و iOS يجب أن يظهر.

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

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

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

الصعوبة مقابل التأخير

دعونا نلقي نظرة على جميع البروتوكولات المتاحة وفرزها حسب معلمتين:

• الكمون الذي يقدمونه بين البث والمشاهد ؛
• التعقيد

وكلما كان التأخير قصيرًا ، تضمن البروتوكول وقتًا أكثر تعقيدًا.

ماذا نريد؟

نريد عمل بروتوكول UDP للتدفق من 1 إلى N بتأخير مماثل لاتصالات p2p ، مع خيار التشفير الاختياري للحزم اعتمادًا على البث الخاص أو العام.

ما الخيارات الأخرى المتاحة؟ يمكنك الانتظار ، على سبيل المثال ، عندما تُصدر Google QUIC.

سأخبرك قليلاً ما هو. تقوم Google بوضع Google QUIC كبديل لـ TCP - وهو نوع من TCP 2.0. تم تطويره منذ عام 2013 ، والآن ليس لديه مواصفات ، ولكنه متاح بالكامل في Google Chrome ، ويبدو لي أنهم يقومون في بعض الأحيان بتشغيله لبعض المستخدمين من أجل معرفة كيفية عمله. من حيث المبدأ ، يمكنك الانتقال إلى الإعدادات وتشغيل QUIC والانتقال إلى أي موقع من مواقع Google والحصول على هذا المورد عبر UDP.

قررنا عدم الانتظار حتى يحددوا جميعًا ، ورفع قرارنا.

متطلبات البروتوكول:

1. multithreading ، لدينا العديد من التدفقات - التحكم والفيديو والصوت.
   
2. ضمان تسليم اختياري - يضمن تيار التحكم ضمان 100٪ ، والفيديو الذي نحتاجه على الأقل - يمكننا إسقاط الإطار هناك ، وما زلنا نرغب في الصوت.
   
3. تحديد أولويات التدفقات - بحيث يتقدم الصوت ، ويطير المدير بشكل عام.
   
4. تشفير اختياري : إما جميع البيانات ، أو فقط الرؤوس والبيانات الهامة.
   

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

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

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

التنمية

لنبدأ في كتابة بروتوكول UDP ، لكن لنلقي نظرة أولاً على الإحصائيات.



هذه هي إحصاءاتنا على شبكات الجوال. هنا يمكنك أن ترى أن متوسط ​​الإنترنت يزيد قليلاً عن ميغابت ، وفقدان الحزمة بحوالي 1٪ أمر طبيعي ، و RTT في منطقة 600 مللي ثانية - على 3G ، إنه متوسط ​​فقط.

سنركز على هذا عند كتابة البروتوكول - دعنا نذهب!

بروتوكول UDP

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



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



تم إصلاح هذا كمعيار. يوضح الرسم التوضيحي الحياة بدون Pacer والحياة مع Pacer .

Pacer هو شيء ينشر الحزم في الوقت المناسب ويتحكم في فقدها ؛ تبحث في فقدان الحزمة الآن ، وهذا يتوقف على سرعة القناة.

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

أعد الإرسال

في TCP ، كما تعلم ، هناك خوارزمية إعادة إرسال سريعة: نرسل حزمة واحدة ، والثانية ، إذا فقدت الحزمة ، ثم بعد فترة (فترة إعادة الإرسال) نرسل نفس الحزمة.

ما هي المزايا؟ لا توجد مشاكل ، لا تكرار ، ولكن هناك ناقص - بعض فترة إعادة الإرسال .



يبدو الأمر بسيطًا للغاية: بعد مرور بعض الوقت ، تحتاج إلى تكرار الحزمة إذا لم تتلق تأكيدًا عليها. منطقياً ، قد يكون هذا الوقت يساوي وقت اختبار الاتصال. ping — , RTT time , , .

, , , , jitter: ping-. , , 46 . jitter — 50.



. RTT , , acknowledge . , RFC6298, TCP , .

jitter. jitter ping 15%. , retransmit period , , 20% , RTT.



retransmit. acknowledge . , , . retransmit period, . , .

, retransmit . , , packet loss 5%, 400 , 400 1 packet-drop, , retransmit period , .

, . , , acknowledge . , — , , speculative retransmit .

retransmit, .

. , Forward Error Correction ? , , XOR. , , .



! round trip, .

, , ? XOR — , Reed-Solomon, Fountain codes .. : K , N , N .

!

, , , Forward Error Correction negative acknowledgement.

NACK

, parity protection ( ) , .

NACK:

• , negative acknowledgement, .
  
• FEC.
  

, :

1. , FEC + NACK;
   
2. , Fast retransmit.
   

, .



, , ( ). , , 11 , 60-80 . , , .

6 .



, , . , . , Wi-Fi 22 5 , 3G 34 8 .



: , 90% packet loss 10 , gap 25 , — FEC + NACK Fast retransmit?

, , , Google, QUIC 2013 , Forward Error Correction , , . 2015 .

FEC + NACK, .

, .



, , c :

• 1 / ;
  
• 1% packet loss;
  
• 300 RTT;
  
• 1 000 — ;
  
• 1 000 .
  

10 . packet loss 1% 1 000 10. — 100 1 — , 2 , .

, . 500- , 10 .

:

• 500 Forward Error Correction. , .
  
• NACK, , .
  
• Fast Retransmit, .
  

Forward Error Correction , — gap 200-300 .

Fast Retransmit

: , 10 , , , retransmit period , .



, retransmit period 350 , packet gap — 25-30 , 100. , , retransmit , .

, .

UDP , .



, , p/b-. . , .

, , , , , , 0,5 .

, , , , p/b, , , .

MTU

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



لدينا خادم ، يرسل بعض الحزم إلى الشبكة ، ويأتون إلى جهاز التوجيه ويصبح عند مستواه MTU (الحد الأقصى لوحدة الإرسال) أقل من حجم الحزمة التي وصلت. يقسم الحزمة إلى كبيرة وصغيرة (هنا 1100 و 400 بايت) ويرسل.

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

كيف نحسبها؟

في الواقع ، لا تهتم Google ، وتضع حوالي 1200 بايت في QUIC ولا تحددها ، لأن تجزئة IP ستجمع كل الحزم.



نفعل الشيء نفسه تمامًا - أولاً نعين بعض الحجم الافتراضي ونبدأ في إرسال الحزم - دعنا نقوم بتجزئتها.

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

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

في الواقع ، يتغير في بعض الأحيان. لقد فوجئنا ، ولكن في عملية تبديل Wi-Fi ، إلخ. MTU يتغير. من الأفضل عدم إيقاف هذه العملية المتوازية وتصحيح MTU من وقت لآخر.



توزيع MTU أعلى في العالم. حصلنا على حوالي 1100 بايت على البوابة.

التشفير

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



إذا كان البث خاصًا ، فيمكننا أيضًا إضافة تشفير لجميع البيانات.

يتم تشفير الحزم باستخدام AES-256 بشكل مستقل ، بحيث لا يؤثر إسقاط الحزمة على المزيد من تشفير الحزم.

تحديد الأولويات

تذكر ، أردنا المزيد من الأولويات من البروتوكول.



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

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

كعكة إضافية حول UDP

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



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

يقول العديد من المشككين أن أجهزة التوجيه مصممة بطريقة تجعل NAT Unbinding تعطل بشكل أساسي مسارات UDP. لكن ما سبق يظهر أنه إذا كانت Keep-Alive أو ping أقل من 30 ثانية ، فمن المحتمل أن تصل إلى العميل بنسبة 99٪.

توفر UDP على الأجهزة المحمولة في العالم

تقول Google 6٪ ، ولكن تبين أن 7٪ من مستخدمي الجوال لا يمكنهم استخدام UDP . في هذه الحالة ، نترك بروتوكولنا الجميل مع تحديد الأولويات والتشفير وكل شيء ، فقط على TCP.

على UDP ، يعمل VOIP الآن على WebRTC و Google QUIC والعديد من الألعاب تعمل على UDP. لذلك ، لا أعتقد أنه سيتم إغلاق UDP على الأجهزة المحمولة.

ونتيجة لذلك ، فإننا:

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

• التأخير في تطبيق OK Live للهاتف المحمول هو 25 مللي ثانية - 10 مللي ثانية أطول من عمل ماسح الكاميرا ، لكنه ليس مخيفًا جدًا.
  
• البث الشبكي يظهر تأخير 690 مللي ثانية فقط - مسافة!
  

ماذا يمكن أن يتدفق على Odnoklassniki

• يقبل بروتوكول OKMP الخاص بنا من الأجهزة المحمولة ؛
  
• يمكن قبول RTMP و WebRTC ؛
  
• يعطي HLS ، MPEG-Dash ، إلخ.
  

إذا كنت حذرًا ، فقد لاحظت أنني قلت أنه يمكننا ، على سبيل المثال ، أخذ WebRTC من المستخدم وتحويله إلى RTMP.



هناك فارق بسيط. في الواقع ، WebRTC هو بروتوكول موجه للحزم ويستخدم برنامج ترميز الصوت OPUS. لا يمكنك استخدام OPUS في RTMP.

على خوادم الواجهة الخلفية ، نستخدم RTMP في كل مكان. لذلك ، كان علينا إجراء المزيد من الإصلاح في FF MPEG ، مما يسمح لنا بدفع OPUS إلى RTMP ، وتحويله إلى AAC ومنحه للمستخدمين بالفعل في HLS أو أي شيء آخر.

كيف تبدو في داخلنا؟

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

بالنسبة للحديد ، لدينا ما يلي:


سأخبرك المزيد عن التسامح مع الخطأ:

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

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

سنقوم باختبار تحمل الخطأ بسرعة. نبدأ فورًا باختفاء مركز البيانات بالكامل.

ماذا سيحدث؟

• سيأخذ مستخدم DNS عنوان IP التالي لخادم تحميل آخر.
  
• بحلول هذا الوقت ، سيفهم ZooKeeper أن الخادم في مركز البيانات هذا قد مات ، وسيختار خادم تشريح خادم آخر.
  
• سوف تكتشف خوادم التنزيل من المسؤول الآن عن تحويل هذا الدفق وسيتم توزيعه.
  

من حيث المبدأ ، كل هذا سيحدث بأقل قدر من التأخير.

استخدام البروتوكول في المنتج

لقد صنعنا تطبيق جوال OK Live Streaming. تم دمجها بالكامل مع البوابة. يمكن للمستخدمين هناك التواصل وإجراء البث المباشر ، وهناك خريطة للبث وقائمة بالبث الشعبي - بشكل عام ، كل ما تريده.



أضفنا أيضًا القدرة على البث في FullHD. يمكنك توصيل كاميرا الحركة على Android بجهاز Android.



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

هذا ، في الواقع ، يوفر تياران قادمان مع الحد الأدنى من التأخير تنسيقًا معينًا للمؤتمرات العامة.

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

في الواقع ، تمكنا من إعادة إنتاج شيء قابل للمقارنة مع برنامج التعاون الفني الحديث الحالي.



البث المباشر هو الاتجاه الحالي. على مدار العام ونصف العام الماضي على بوابة OK ، فقد تضاعف ثلاث مرات (ليس بدون مساعدة تطبيق OK Live).



يتم تسجيل جميع عمليات البث بشكل افتراضي. لدينا حوالي 50 ألف تيار يوميًا ، وهذا يولد حوالي 17 تيرابايت من حركة المرور يوميًا ، ولكن بشكل عام فإن كل الفيديو على البوابة يولد حوالي بيتابايت من البيانات شهريًا.



ماذا حصلنا عليه:

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

ماذا تعلمت:

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

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

في نفس القسم ، يتم تخطيط التقارير حول مواضيع متخصصة للغاية:

• يوجين روسينسكي (ivi) على نظام جمع إحصائيات مفصلة حول تشغيل عقد CDN.
  
• أنطون روساكوفا (Badoo) حول تكامل أنظمة الدفع دون استخدام الفواتير الخاصة بهم.