النقل في الوقت الحقيقي باستخدام بروتوكول RTP في الشبكات الحاسوبية

كانت معظم التطبيقات معنيّةً بنقل الملفات في الأيام الأولى من تقنيات تبديل الرزم، على الرغم من أنه في وقت مبكر من عام 1981، كانت التجارب جاريةً لنقل حركة المرور في الوقت الحقيقي، مثل عينات الصوت الرقمية. نطلق على التطبيق صفة "الوقت الحقيقي" عندما يكون لديه متطلبات قوية لتسليم المعلومات في الوقت المناسب. يُعَد بروتوكول Voice over IP أو اختصارًا VoIP مثالًا كلاسيكيًا لتطبيق الوقت الحقيقي لأنه لا يمكنك إجراء محادثة بسهولة مع شخص إذا استغرق الأمر أكثر من جزء من الثانية للحصول على رد. تفرُض تطبيقات الوقت الحقيقي بعض المتطلبات المحدَّدة على بروتوكول النقل التي لم تلبيها جيدًا البروتوكولات التي ناقشناها سابقًا.

تُقسم تطبيقات الوسائط المتعددة، التي تتضمن الفيديو والصوت والبيانات، إلى فئتين: التطبيقات التفاعلية interactive applications وتطبيقات التدفق streaming applications. يظهر الشكل السابق مؤلفَي السلسلة اللذين يستخدمان نموذجًا لأداة مؤتمرات نموذجية للصف التفاعلي. هذه هي أنواع التطبيقات الأكثر صرامة في الوقت الحقيقي إلى جانب بروتوكول VoIP.

تقدم تطبيقات التدفق عادةً تدفقًا صوتيًا أو تدفق فيديو من خادمٍ إلى عميل وتتميز بمُنتجات تجارية مثل Spotify. أصبح تدفق الفيديو، مثل YouTube و Netflix، أحد الأشكال السائدة لحركة المرور على الإنترنت. تضع تطبيقات التدفق متطلباتٍ في الوقت الحقيقي أقل صرامةً إلى حدٍ ما على البروتوكولات الأساسية نظرًا لأنها تفتقر إلى التفاعل بين البشر. لا يزال التوقيت مهمًا على الرغم من ذلك، فقد تريد على سبيل المثال أن يبدأ تشغيل مقطع فيديو بعد الضغط على "تشغيل play"، وبمجرد أن يبدأ التشغيل، فإن الرزم المتأخرة إما ستؤدي إلى تباطئه أو إنشاء نوع من التدهور البصري visual degradation. لذلك وعلى الرغم من أن تطبيقات التدفق ليست تمامًا في الوقت الحقيقي، ولكن لا يزال لديها ما يكفي من القواسم المشتركة مع تطبيقات الوسائط المتعددة التفاعلية لضمان النظر في بروتوكولٍ مشترك لكلا النوعين من التطبيقات.

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

يُستمد الكثير من RTP في الواقع من وظائف البروتوكول التي كانت مضمَّنةً في الأصل في التطبيق نفسه. كان اثنان من أوائل هذه التطبيقات هما تطبيقَي VIC و VAT، حيث يدعم الأول الفيديو في الوقت الحقيقي ويدعم الآخر الصوت في الوقت الحقيقي. شُغِّل كلا التطبيقين في الأصل مباشرة عبر بروتوكول UDP، بينما اكتشف المصممون الميزات اللازمة للتعامل مع طبيعة الاتصال في الوقت الحقيقي، وأدركوا لاحقًا أن هذه الميزات يمكن أن تكون مفيدة للعديد من التطبيقات الأخرى وعرّفوا بروتوكولًا بهذه الميزات، ثم جرى توحيد هذا البروتوكول في النهاية كبروتوكول RTP.

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

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

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

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

تمكين مستقبل تدفق البيانات من تحديد علاقة التوقيت بين البيانات المستلمة مطلبٌ مهم آخر. حيث تحتاج تطبيقات الوقت الحقيقي إلى وضع البيانات المستلمة في مخزن تشغيلٍ مؤقت playback buffer لتخفيف الاضطراب jitter الذي قد يكون أُدخِل في تدفق البيانات أثناء النقل عبر الشبكة. وبالتالي سيكون من الضروري وجود نوعٍ من استخدام العلامات الزمنية timestamping للبيانات لتمكين المستقبل من إعادة تشغيلها في الوقت المناسب.

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

يجب توفير وظيفة أخرى وهي الإشارة إلى فقدان رزمة. لاحظ أن التطبيق الذي له حدود وقت استجابةٍ ضيقة لا يمكنه عمومًا استخدام وسيلة نقل موثوقة مثل TCP لأن إعادة إرسال البيانات لتصحيح الخسارة قد يتسبب في وصول الرزمة بعد فوات الأوان لتكون مفيدة. وبالتالي يجب أن يكون التطبيق قادرًا على التعامل مع الرزم المفقودة، والخطوة الأولى في التعامل معها هي ملاحظة أنها مفقودة بالفعل. قد يتخذ تطبيق الفيديو الذي يستخدم تشفير MPEG إجراءاتٍ مختلفة عند فقدان رزمة، اعتمادًا على ما إذا كانت الحزمة تأتي من إطار I أو من إطار B أو من إطار P على سبيل المثال.

يُعَد فقدان الرزم أيضًا مؤشرًا محتملًا للازدحام. تفوّت تطبيقات الوسائط المتعددة أيضًا ميزات تجنب الازدحام في TCP نظرًا لأنها لا تعمل عبر TCP. ولكن العديد من تطبيقات الوسائط المتعددة قادرةٌ على الاستجابة للازدحام، مثل تغيير معاملات خوارزمية التشفير لتقليل حيز نطاق التراسلي المُستهلك. يحتاج المستقبِل، لإنجاز هذا العمل، إلى إعلام المرسل بحدوث فقدانٍ في الرزم حتى يتمكن المرسل من ضبط معاملات التشفير الخاصة به.

وظيفةٌ أخرى مشتركة بين تطبيقات الوسائط المتعددة هي مفهوم بيان حدود الإطار، والإطار في هذا السياق خاصٌ بالتطبيق. فقد يكون من المفيد إعلام تطبيق فيديو أن مجموعةً معينة من الرزم تتوافق مع إطار واحد على سبيل المثال. من المفيد في تطبيقٍ صوتي تحديد بداية مجموعة من الأصوات أو الكلمات المتبوعة بالصمت والتي تُعرَف بـ "talkspurt". يمكن للمتلقي بعد ذلك تحديد فترات الصمت بين talkspurt واستخدامها كفرص لتحريك نقطة التشغيل. يتبع ذلك ملاحظة أن الاختصار الطفيف أو إطالة الفراغات بين الكلمات أمرٌ غير محسوس للمستخدمين، في حين أن تقصير أو إطالة الكلمات نفسها أمرٌ محسوس ومزعج.

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

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

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

تصميم بروتوكول RTP

الآن وقد رأينا القائمة الطويلة إلى حدٍ ما من متطلبات بروتوكول النقل للوسائط المتعددة، ننتقل إلى تفاصيل البروتوكول الذي حُدِّد لتلبية هذه المتطلبات. طُوِّر بروتوكول RTP في منظمة IETF وهو قيد الاستخدام على نطاق واسع. يحدد معيار RTP بالفعل زوجًا من البروتوكولات، بروتوكول RTP وبروتوكول التحكم في النقل في الوقت الحقيقي Real-time Transport Control Protocol أو اختصارًا RTCP. يُستخدَم البروتوكول الأول لتبادل بيانات الوسائط المتعددة، بينما يُستخدَم البروتوكول الأخير لإرسال معلومات التحكم المرتبطة بتدفق بياناتٍ معين دوريًا. يستخدم تدفق بيانات RTP وتدفق تحكم RTCP المرتبط منافذ طبقة النقل المتتالية عند التشغيل عبر بروتوكول UDP. تستخدم بيانات RTP رقم منفذٍ زوجي وتستخدم معلومات تحكم RTCP رقم المنفذ التالي الأعلى الفردي.

إن بروتوكول RTP مصمَّمٌ لدعم مجموعةٍ متنوعة من التطبيقات، فهو يوفّر آليةً مرنة يمكن من خلالها تطوير تطبيقاتٍ جديدة دون إجراء مراجعة متكررة لبروتوكول RTP نفسه. يحدد بروتوكول RTP لكل صنفٍ من أصناف التطبيقات (الصوت مثلًا) ملفَّ تعريفٍ profile وتنسيقًا واحدًا format أو أكثر. يوفّر ملف التعريف مجموعة من المعلومات تضمن فهمًا مشتركًا للحقول الموجودة في ترويسة RTP لصنف التطبيق هذا، كما سيتضح عندما نفحص الترويسة بالتفصيل. تشرح مواصفات التنسيق كيفية تفسير البيانات التي تتبع ترويسة RTP. قد يتبع ترويسة RTP سلسلةٌ من البايتات على سبيل المثال، ويمثل كلٌّ منها عينةً صوتية واحدة مأخوذة بفاصل زمني محدد بعد الفاصل الزمني السابق. قد يكون تنسيق البيانات أعقد من ذلك، حيث يحتاج تدفق الفيديو المشفر بتنسيق MPEG، على سبيل المثال، إلى بنية كبيرة لتمثيل جميع أنواع المعلومات المختلفة.

يجسّد تصميم RTP مبدأً معماريًا يُعرف باسم تأطير مستوى التطبيق Application Level Framing أو اختصارًا ALF. طرح هذا المبدأ كلٌّ من كلارك Clark وتنينهاوس Tennenhouse في عام 1990 كطريقة جديدة لتصميم بروتوكولات لتطبيقات الوسائط المتعددة الناشئة. وقد أدركا أنه من غير المرجح تقديم هذه التطبيقات الجديدة جيدًا من خلال البروتوكولات الحالية مثل بروتوكول TCP، وأنها قد لا تقدَّم جيدًا من خلال أي بروتوكول من النوع "مقاس واحد يناسب الجميع". يكمن في قلب هذا المبدأ الاعتقاد بأن التطبيق يفهم احتياجاته الخاصة بصورةٍ أفضل، حيث يعرف تطبيق فيديو MPEG على سبيل المثال أفضل السبل لاستعادة الإطارات المفقودة وكيفية الاستجابة بصورةٍ مختلفة في حالة فقدان إطار I أو إطار B. يفهم نفس التطبيق أيضًا أفضل طريقة لتقسيم البيانات من أجل إرسالها، فمن الأفضل على سبيل المثال إرسال البيانات من إطارات مختلفة في مخططات بيانات مختلفة، بحيث لا تؤدي الرزمة المفقودة إلا إلى إتلاف إطارٍ واحد، وليس إطارَين، لذلك يترك بروتوكول RTP الكثير من تفاصيل البروتوكول لملف التعريف ووثائق التنسيق الخاصة بالتطبيق.

صيغة الترويسة

يوضح الشكل التالي صيغة الترويسة التي يستخدمها بروتوكول RTP. تكون أول 12 بايتًا موجودةً دائمًا، بينما تُستخدَم معرّفاتُ المصدرِ المشاركة في حالات معينة فقط. قد يكون هناك ترويسات لإضافات اختيارية بعد هذه الترويسة، كما هو موضح أدناه. أخيرًا، يتبع الترويسةَ حمولةُ RTP، والتي يحدّد التطبيق صيغتها. القصد من هذه الترويسة هو أن تحتوي فقط على الحقول المحتمل أن تستخدمها عدّة تطبيقات مختلفة، نظرًا لأن أي شيء خاص جدًا بتطبيقٍ معين سيُنقَل بكفاءة أكبر في حمولة RTP لهذا التطبيق فقط.

يشير أول بتين إلى معرّف الإصدار version identifier، والذي يحتوي على القيمة 2 في إصدار RTP المنشور وقت كتابة هذه السلسلة بنسختها الإنجليزية. قد تعتقد أن مصممي البروتوكول كانوا جريئين إلى حد ما للاعتقاد بأن 2 بت ستكون كافية لاحتواء جميع الإصدارات المستقبلية من RTP، لكن تذكر أن هذه البتات موجودةٌ في أعلى ترويسة RTP. إن استخدام ملفات تعريف التطبيقات المختلفة يجعل من غير المرجح أن تكون هناك حاجة إلى العديد من المراجعات لبروتوكول RTP الأساسي، ولكن إذا اتضح أن هناك حاجة إلى إصدار آخر من RTP بخلاف الإصدار 2، فمن الممكن التفكير في تغيير صيغة الترويسة بحيث يكون من الممكن وجود أكثر من إصدارٍ مستقبلي. يمكن أن تحتوي ترويسة RTP الجديدة ذات القيمة 3 في حقل الإصدار على حقل "التخريب subversion" في مكان آخر في الترويسة على سبيل المثال.

البت التالي هو بت الحاشية padding أو P، والتي تُضبَط في ظروفٍ تكون فيها حمولة RTP محشوَّةً لسببٍ ما. قد تكون بيانات RTP محشوَّةً لملء كتلة بحجم معين كما هو مطلوب بواسطة خوارزمية تشفير على سبيل المثال. ففي مثل هذه الحالة، سيُنقَل الطول الكامل لترويسة RTP والبيانات والحاشية بواسطة ترويسة بروتوكول الطبقة الدنيا (ترويسة UDP مثلًا)، وسيحتوي البايت الأخير من الحاشية على عدد البايتات التي يجب تجاهلها، وهذا موضح في الشكل الآتي. لاحظ أن طريقة الحشو هذه تزيل أي حاجةٍ إلى حقل طولٍ في ترويسة RTP، وبالتالي يخدم هدف إبقاء الترويسة قصيرةً، حيث يُستنتَج الطول من بروتوكول الطبقة الدنيا في الحالة الشائعة لعدم وجود حاشية.

يُستخدم بت التوسّع extension أو X للإشارة إلى وجود ترويسة توسّع، والذي سيُحدَّد لتطبيقٍ معين ويتبع الترويسة الرئيسية. نادرًا ما تُستخدم هذه الترويسات، نظرًا لأنه من الممكن عمومًا تحديد ترويسةٍ خاصة بالحمولة كجزءٍ من تعريف صيغة حمولة تطبيقٍ معين. يتبع البت X حقلٌ مؤلفٌ من 4 بتات يحسب عدد المصادر المشاركة contributing sources، إن وجدت في الترويسة.

لاحظنا أعلاه الحاجة المتكررة لنوع من تحديد الإطار، حيث يُوفَّر ذلك من خلال بت العلامة، الذي له استخدامٌ خاص بالملف التعريفي، ويمكن ضبط هذا البت في بداية talkpurt بالنسبة للتطبيق الصوتي على سبيل المثال. ثم حقل نوع الحمولة المؤلف من 7 بتات، حيث يشير إلى نوع بيانات الوسائط المتعددة التي تحملها هذه الرزمة. ويتمثل أحد الاستخدامات المحتملة لهذا الحقل في تمكين التطبيق من التبديل من مخطط تشفيرٍ إلى آخر بناءً على معلوماتٍ حول توفُّر الموارد في الشبكة أو ردًا على جودة التطبيق. يُحدَّد الاستخدام الدقيق لنوع الحمولة أيضًا بواسطة ملف تعريف التطبيق.

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

يُستخدَم الرقم التسلسلي لتمكين مستقبل تدفق RTP من اكتشاف الرزم المفقودة وغير المرتبة، حيث يزيد المرسل ببساطة القيمة بمقدار واحد لكل رزمةٍ مرسلة. لاحظ أن RTP لا يفعل أي شيء عندما يكتشف رزمةً مفقودة على عكس بروتوكول TCP الذي يصحح الفقدان عن طريق إعادة الإرسال، ويفسر هذا الفقدان على أنه مؤشر ازدحام مما قد يؤدي إلى تقليل حجم النافذة، وهنا يُترك للتطبيق بدلًا من ذلك أن يقرر ما يجب فعله عند فقد الرزمة لأن هذا القرار من المرجح أن يعتمد بصورةٍ كبيرة على التطبيق، فقد يقرر تطبيق الفيديو أن أفضل ما يمكن فعله عند فقدان رزمة هو إعادة تشغيل آخر إطار اُستلِم بصورةٍ صحيحة على سبيل المثال. قد تقرر بعض التطبيقات أيضًا تعديل خوارزميات التشفير الخاصة بها لتقليل احتياجات حيز النطاق التراسلي استجابةً لهذه الخسارة، ولكن هذه ليست وظيفة بروتوكول RTP. لن يكون من المعقول أن يقرر RTP بتوجُّب تخفيض معدل الإرسال، لأن هذا قد يجعل التطبيق عديم الفائدة.

تتمثل وظيفة حقل الطابع الزمني في تمكين جهاز الاستقبال من تشغيل العينات على فترات زمنية مناسبة وتمكين تزامن تدفقات الوسائط المختلفة. نظرًا لأن التطبيقات المختلفة قد تتطلب مستويات مختلفة من دقة التوقيت، فإن RTP نفسها لا تحدد الوحدات التي يُقاس فيها الوقت. بدلاً من ذلك، فإن الطابع الزمني هو مجرد عداد "لحظات الساعة ticks"، حيث يعتمد الوقت بين هذه اللحظات على الترميز المستخدم. على سبيل المثال ، يمكن لتطبيق صوتي يأخذ عينات البيانات مرة واحدة كل 125 ميكرو ثانية استخدام هذه القيمة كدِقة ساعة. دقة الساعة هي أحد التفاصيل المحددة في ملف تعريف RTP أو تنسيق الحمولة لتطبيق ما.

قيمة العلامة الزمنية في الرزمة هي رقمٌ يمثل الوقت الذي جرى فيه إنشاء العينة الأولى في الرزمة. لا تمثِّل العلامة الزمنية انعكاسًا لوقت اليوم، حيث أن الاختلافات بين العلامات الزمنية ذات صلة فقط. إذا كان الفاصل الزمني لأخذ العينات هو 125 ميكرو ثانية على سبيل المثال وأُنشئَت العينة الأولى في الرزمة رقم n + 1 بعد 10 ميلي ثانية من العينة الأولى في الرزمة رقم n، فإن عدد لحظات أخذ العينات بين هاتين العينتين هو:

TimeBetweenPackets الوقت بين الرزم / TimePerSample وقت كل عينة
= (10 × 10-3) / (125 × 10-6) = 80

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

مصدر المزامنة synchronization source أو اختصارًا SSRC هو رقمٌ مؤلف من 32 بتًا يحدد بشكل فريد مصدرًا واحدًا لتدفق RTP. يختار كل مرسلٍ مصدر مزامنة عشوائيًا في مؤتمر وسائط متعددة معين ويتوقع منه حل التعارضات في الحدث غير المحتمل الذي يختار فيه مصدران نفس القيمة. يضمن بروتوكول RTP الاستقلال عن بروتوكول الطبقة الدنيا من خلال جعل معرّف المصدر شيئًا آخر مختلفًا عن عنوان الشبكة أو عنوان النقل الخاص بالمصدر. كما أنه يمكّن عقدةً واحدة ذات مصادر متعددة (عدة كاميرات مثلًا) من التمييز بين تلك المصادر. ليس مطلوبًا استخدام نفس SSRC في كل تدفق عندما تولد عقدة واحدة تدفقات وسائط مختلفة (الصوت والفيديو على سبيل المثال)، إذ توجد آليات في RTCP (الموضحة أدناه) للسماح بمزامنة الوسائط.

يُستخدَم المصدر المشارك contributing source أو CSRC فقط عند مرور عدد من تدفقات RTP عبر مازجٍ mixer. يمكن استخدام المازج لتقليل متطلبات حيز النطاق التراسلي لمؤتمرٍ من خلال استقبال البيانات من عدة مصادر وإرسالها كتدفقٍ واحد. يمكن فك تشفير تدفقات الصوت من عدة مكبرات صوت متزامنة وإعادة تشفيرها على أنها تدفق صوتي واحد على سبيل المثال، وفي هذه الحالة، يحدّد المازج نفسه كمصدر للتزامن ولكنه يحدد أيضًا المصادر المشاركة أي قيم SSRC للمتحدثين الذين شاركوا في الرزمة المعنية.

بروتوكول التحكم Control Protocol

يوفر بروتوكول RTCP تدفق تحكم مرتبط بتدفق بيانات تطبيق وسائط متعددة. يوفر تدفق التحكم هذا ثلاث وظائف رئيسية:

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

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

قد تعتقد أن الوظيفة الثانية يتم يوفّرها بالفعل معرّف مصدر المزامنة SSRC الخاص ببروتوكول RTP، ولكنها في الحقيقة ليست كذلك. قد تحتوي الكاميرات المتعددة من عقدة واحدة على قيم SSRC مختلفة، ولا يوجد شرطٌ بأن يستخدم تدفق الصوت والفيديو من نفس العقدة نفس SSRC، فقد يكون من الضروري تغيير قيمة SSRC للتدفق نظرًا لاحتمال حدوث تضارب في قيم SSRC. للتعامل مع هذه المشكلة، يستخدم بروتوكول RTCP مفهوم الاسم المتعارف عليه canonical name أو اختصارًا CNAME الذي يُسنَد لمرسل، والذي يرتبط بعد ذلك بقيم SSRC المختلفة التي يمكن أن يستخدمها هذا المرسل باتّباع آليات RTCP.

ربط تدفقين هو ببساطة جزءٌ من مشكلة مزامنة الوسائط فقط. يجب أن تكون هناك طريقةٌ لمزامنة التدفقات بدقة مع بعضها بعضًا نظرًا لأن التدفقات المختلفة قد تحتوي على ساعات مختلفة تمامًا وبدّقات granularities وجودة مختلفة وحتى بمقادير مختلفة من عدم الدقة inaccuracy أو الانزياح drift. يعالج بروتوكول RTCP هذه المشكلة عن طريق نقل معلومات التوقيت التي تربط الوقت الحقيقي من اليوم بالعلامات الزمنية المعتمدة على معدل الساعة والتي تُحمَل في رزم بيانات RTP.

يحدد بروتوكول RTCP عددًا من أنواع الرزم المختلفة مثل:

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

تُرسَل أنواع رزم RTCP المختلفة هذه عبر بروتوكول الطبقة الدنيا، والذي، كما لاحظنا، عادةً ما يكون بروتوكول UDP. يمكن وضع العديد من رزم RTCP في PDU واحد لبروتوكول المستوى الأدنى. يجب إرسال رزمتَي RTCP على الأقل في كل PDU بمستوى أدنى: رزمةٌ هي رزمة تقرير، والأخرى هي رزمة وصف المصدر. قد تُضمَّن رزمٌ أخرى حتى الوصول إلى حدود الحجم المفروضة من قِبل بروتوكولات الطبقة الدنيا.

نلاحظ أن هناك مشكلة محتملة مع كل عضو في مجموعة الإرسال المتعدد الذي يرسل حركة مرور تحكمٍ دورية. إذا لم نتخذ بعض الخطوات للحد من ذلك، فمن المحتمل أن تكون حركة مرور التحكم هذه مستهلكًا مهمًا لحيز النطاق التراسلي. لا يُحتمل أن يرسل أكثر من مرسلَين أو ثلاثة بياناتٍ صوتية في أي لحظة في مؤتمر صوتي على سبيل المثال، حيث لا فائدة من تحدث الجميع في آنٍ واحد، ولكن لا يوجد مثل هذا الحد الاجتماعي على كل شخصٍ يرسل حركة مرور تحكمٍ، وقد تكون هذه مشكلة خطيرة في مؤتمر يحضره الآلاف من المشاركين. فللتعامل مع هذه المشكلة، يكون لدى بروتوكول RTCP مجموعة من الآليات التي يقلّل المشاركون من خلالها من تكرار تقاريرهم مع زيادة عدد المشاركين. هذه القواعد معقدةٌ إلى حدٍ ما، لكن الهدف الأساسي هو: حدُّ كمية حركة RTCP الإجمالية إلى نسبةٍ صغيرة (عادةً 5%) من حركة بيانات RTP. لتحقيق هذا الهدف، يجب أن يعرف المشاركون مقدار حيز نطاق البيانات التراسلي المُحتمَل استخدامه (مقدار إرسال ثلاثة تدفقات صوتية على سبيل المثال) مع معرفة عدد المشاركين. يتعلّم المشاركون حيز نطاق البيانات التراسلي المُحتمَل استخدامه من وسائل خارج RTP، والمعروفة باسم إدارة الجلسة session management التي سنناقشها لاحقًا، ويتعلمون عدد المشاركين من تقارير RTCP للمشاركين الآخرين. قد يكون من الممكن فقط الحصول على عدد تقريبي للعدد الحالي للمستقبلين نظرًا لأنه قد تُرسَل تقارير RTCP بمعدلٍ منخفض جدًا، ولكن هذا عادةً يكون كافيًا. يوصَى أيضًا بتخصيص المزيد من حيز نطاق RTCP التراسلي للمرسلين النشطين، على افتراض أن معظم المشاركين يرغبون في رؤية تقارير منهم، لمعرفة مَن يتحدث على سبيل المثال.

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

تتكون المعلومات الإضافية في تقرير المرسل من:

علامة زمنية تحتوي على الوقت الحقيقي من اليوم الذي أُنشئ فيه هذا التقرير.
علامة RTP الزمنية المقابلة للوقت الذي أُنشئ فيه هذا التقرير.
الأعداد التراكمية للرزم والبايتات التي أرسلها هذا المرسل منذ أن بدأ الإرسال.

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

تحتوي كلٌّ من تقارير المرسل والمستقبل على كتلة واحدة من البيانات لكل مصدرٍ سُمِع منه منذ التقرير الأخير. تحتوي كل كتلة على الإحصائيات التالية للمصدر المعني:

SSRC الخاص به.
جزء رزم البيانات من هذا المصدر التي فُقِدت منذ إرسال التقرير الأخير (يُحسَب بموازنة عدد الرزم المستقبَلة مع عدد الرزم المتوقعة، ويمكن تحديد هذه القيمة الأخيرة من أرقام RTP التسلسلية).
إجمالي عدد الرزم المفقودة من هذا المصدر منذ أول مرة سُمِع من هذا المصدر.
أعلى رقم تسلسلي اُستلِم من هذا المصدر (يتوسّع إلى 32 بتًا لحساب التفاف الرقم التسلسلي).
الاضطراب jitter الداخلي التقديري للمصدر (محسوب بموازنة التباعد بين الرزم المستقبَلة مع التباعد المتوقَّع في وقت الإرسال).
آخر علامة زمنية فعلية مستلمة عبر بروتوكول RTCP لهذا المصدر.
التأخير منذ استقبال آخر تقرير مرسل عبر بروتوكول RTCP لهذا المصدر.

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

الجانب الأخير من بروتوكول RTCP الذي سننظر فيه هو رزمة وصف المصدر. تحتوي هذه الرزمة، على الأقل، على SSRC الخاص بالمرسل وCNAME الخاص بالمرسل. يُشتق الاسم المتعارف عليه canonical name بطريقةٍ تجعل جميع التطبيقات، التي تنشئ تدفقات وسائط والممكن أن تكون بحاجةٍ إلى مزامنة (مثل تدفقات الصوت والفيديو التي أُنشئتمنفصلةً من نفس المستخدم)، تختار نفس CNAME على الرغم من أنها قد تختار قيم SSRC مختلفة، ويتيح ذلك لجهاز الاستقبال تحديدَ تدفق الوسائط الذي يأتي من نفس المرسل. صيغة CNAME الأكثر شيوعًا هي user@host، حيث يكون المضيف host هو اسم النطاق المؤهَّل الكامل لجهاز الإرسال. وبالتالي يعمل التطبيق، الذي يشغّله المستخدم الذي يكون اسم المستخدم user name الخاص به هو jdoe، على الجهاز cicada.cs.princeton.edu، ويستخدم السلسلة jdoe@cicada.cs.princeton.edu باعتبارها CNAME الخاص به. إن العدد الكبير والمتغير من البايتات المُستخدمة في هذا التمثيل سيجعل منه اختيارًا سيئًا لصيغة SSRC، حيث يُرسَل SSRC مع كل رزمة بيانات ويجب معالجتها في الوقت الحقيقي. يمكّن السماح لأسماء CNAME بالالتزام بقيم SSRC في رسائل RTCP الدورية بصيغة SSRC مضغوطة وفعالة.

قد تُضمَّن عناصرٌ أخرى في رزمة وصف المصدر، مثل الاسم الحقيقي وعنوان البريد الإلكتروني للمستخدم، حيث تُستخدم في عرض واجهة المستخدم وللتواصل بالمشاركين، ولكنها أقل أهمية لتشغيل بروتوكول RTP من CNAME.

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

يُعَد بروتوكول HTTP هو الوسط الضيق الجديد وُصِف الإنترنت على أنه ذو معماريةٍ ضيقة الوسط narrow waist، ببروتوكولٍ عالمي واحد في المنتصف IP، يتسع لدعم العديد من بروتوكولات النقل والتطبيق فوقه، مثل TCP وUDP وRTP وSunRPC وDCE-RPC وgRPC وSMTP وHTTP وSNMP، ويستطيع العمل على العديد من تقنيات الشبكة تحته، مثل شبكات Ethernet وPPP وWiFi وSONET وATM. لقد كانت هذه البنية العامة مفتاحًا لانتشار الإنترنت في كل مكان: من خلال الحفاظ على طبقة IP التي يجب على الجميع الموافقة على الحد الأدنى الملائم لها. هذه الاستراتيجية الآن مفهومة على نطاق واسع لأي منصة تحاول تحقيق التكيُّف العالمي.

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

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

HTTPPlusTLSAndTCPAndIPFormingTheNarrowWaistOfToday’sInternetArchitecture.png

وُضعت علامة الوسط الضيق على بروتوكول HTTP للتبسيط. وهو في الواقع جهدٌ جماعي، حيث تعمل تركيبة HTTP / TLS / TCP / IP الآن مثل نظام أساسي مشتركٍ للإنترنت، حيث:

يوفر بروتوكول HTTP معرفات الكائنات العالمية (مثل معرّفات URI) وواجهة GET / PUT بسيطة.
يوفر بروتوكول TLS أمان اتصالات من طرفٍ إلى طرف.
يوفر بروتوكول TCP إدارة الاتصال، والنقل الموثوق، والتحكم في الازدحام.
يوفر بروتوكول IP عناوين مضيف عالمية وطبقة تجريد للشبكة.

لكن على الرغم من أنك حر في اختراع خوارزمية التحكم في الازدحام الخاصة بك، فإن بروتوكول TCP يحل هذه المشكلة جيدًا، لذلك من المنطقي إعادة استخدام هذا الحل. وعلى الرغم من أنك حر في اختراع بروتوكول RPC خاص بك، فإن HTTP يوفر بروتوكولًا صالحًا للخدمة تمامًا (لأنه يأتي مزوَّدًا بأمان مثبَت، ولديه ميزةٌ إضافية تتمثل في عدم حظره بواسطة جدران حماية خاصة بمؤسسة)، لذا فمن المنطقي مرة أخرى إعادة استخدامه بدلًا من إعادة اختراع شيء جديد.

يوفر بروتوكول HTTP أيضًا أساسًا جيدًا للتعامل مع التنقل mobility. إذا نُقل المورد الذي تريد الوصول إليه، فيستطيع HTTP أن يرجع استجابة إعادة توجيه redirect response والتي توجّه العميل إلى موقعٍ جديد. ويتيح بروتوكول HTTP حقن وكلاء التخزين المؤقت caching proxies بين العميل والخادم، مما يجعل من الممكن نسخ المحتوى الشائع في مواقع متعددة وتوفير تأخير وصول العملاء عبر الإنترنت لاسترداد بعض المعلومات. أخيرًا، اُستخدم HTTP لتوصيل الوسائط المتعددة في الوقت الحقيقي، في نهج يُعرف باسم التدفق التكيفي adaptive streaming.