بروتوكول المراسلة في الوقت الحقيقي

📅 آخر تحديث: ٢٥ يوليو ٢٠٢٦
✍️ نُشر في: ٢٥ يوليو ٢٠٢٦
📷 يحتوي على 2 صور
الموسوعة الحرة

بروتوكول المراسلة في الوقت الحقيقي ( RTMP ) هو بروتوكول اتصال لبث الصوت والفيديو والبيانات عبر الإنترنت. طُوّر في الأصل كبروتوكول خاص بشركة ماكروميديا ​​للبث بين مشغل فلاش وخادم اتصالات فلاش، وقد أصدرت أدوبي (التي استحوذت على ماكروميديا) نسخة غير مكتملة من مواصفات البروتوكول للاستخدام العام.

يحتوي بروتوكول RTMP على العديد من الاختلافات:

  1. بروتوكول RTMP الصحيح، وهو البروتوكول "العادي" الذي يعمل فوق بروتوكول التحكم في الإرسال (TCP) ويستخدم رقم المنفذ 1935 بشكل افتراضي.
  2. RTMPS، وهو بروتوكول RTMP عبر اتصال أمان طبقة النقل (TLS/SSL).
  3. RTMPE، وهو بروتوكول RTMP مشفر باستخدام آلية أمان خاصة بشركة Adobe. على الرغم من أن تفاصيل التنفيذ سرية، إلا أن الآلية تستخدم أساسيات التشفير القياسية في هذا المجال. [ 1 ]
  4. يُستخدم بروتوكول RTMPT، الذي يُغلّف ضمن طلبات HTTP لتجاوز جدران الحماية ، بشكل متكرر عبر استخدام طلبات نصية غير مشفرة على منفذي TCP 80 و443 لتجاوز معظم عمليات تصفية حركة البيانات في الشركات. وقد تحمل الجلسة المُغلّفة حزم بيانات RTMP أو RTMPS أو RTMPE.
  5. بروتوكول RTMFP هو بروتوكول RTMP عبر بروتوكول بيانات المستخدم (UDP) بدلاً من بروتوكول TCP، ويحل محل بروتوكول RTMP Chunk Stream. وقد طورت شركة Adobe Systems مجموعة بروتوكولات تدفق الوسائط الآمنة في الوقت الحقيقي، والتي تُمكّن المستخدمين النهائيين من الاتصال والتواصل مباشرةً فيما بينهم (P2P).
  6. يُعدّ بروتوكول E-RTMP، أو بروتوكول RTMP المُحسّن، تطويرًا لمواصفات RTMP وFLV، وهو مصمم لتحسين إمكانيات البث مع الحفاظ على التوافق مع البنية التحتية الحالية لبروتوكول RTMP. [ 2 ] يُحسّن بروتوكول E-RTMP بروتوكول RTMP بإضافة ميزات مثل دقة الطابع الزمني المتقدمة، وإمكانيات المسارات المتعددة، ودعم موسع لبرامج الترميز، وإشارات FourCC، وميزة طلب إعادة الاتصال.

بينما كان الدافع الرئيسي لبروتوكول RTMP هو أن يكون بروتوكولًا لتشغيل فيديو فلاش ، إلا أنه يستخدم أيضًا في بعض التطبيقات الأخرى، مثل Adobe LiveCycle Data Services ES .

التشغيل الأساسي

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

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

على مستوى أعلى، يقوم بروتوكول RTMP بتغليف تدفقات الوسائط المتعددة الصوتية بصيغتي MP3 أو AAC والفيديو بصيغة FLV1 ، ويمكنه إجراء استدعاءات الإجراءات عن بُعد (RPCs) باستخدام تنسيق رسالة الإجراء . تُنفَّذ أي خدمات RPC مطلوبة بشكل غير متزامن، باستخدام نموذج طلب/استجابة واحد بين العميل والخادم، بحيث لا تكون هناك حاجة إلى اتصال في الوقت الفعلي . [ 3 ] [ 4 ]

التشفير

يمكن تشفير جلسات RTMP باستخدام إحدى الطريقتين التاليتين:

  • باستخدام آليات TLS/SSL القياسية في المجال . يتم ببساطة تغليف جلسة RTMP الأساسية داخل جلسة TLS/SSL عادية.
  • باستخدام RTMPE، الذي يغلف جلسة RTMP بطبقة تشفير أخف وزناً.

نفق HTTP

في بروتوكول RTMP Tunneled (RTMPT)، يتم تغليف بيانات RTMP وتبادلها عبر HTTP ، ويتم توجيه الرسائل من العميل (مشغل الوسائط، في هذه الحالة) إلى المنفذ 80 (الافتراضي لبروتوكول HTTP) على الخادم.

على الرغم من أن الرسائل في RTMPT أكبر من رسائل RTMP غير النفقية المكافئة بسبب رؤوس HTTP، إلا أن RTMPT قد يسهل استخدام RTMP في السيناريوهات التي لا يكون فيها استخدام RTMP غير النفقية ممكنًا، كما هو الحال عندما يكون العميل خلف جدار حماية يحظر حركة المرور الصادرة غير HTTP وغير HTTPS.

يعمل البروتوكول عن طريق إرسال الأوامر عبر عنوان URL الخاص بطلب POST، ورسائل AMF عبر نص طلب POST. مثال على ذلك:

POST /open/1 HTTP/1/1.1

لفتح اتصال.

وثيقة المواصفات ورخصة براءة الاختراع

أصدرت أدوبي مواصفات الإصدار 1.0 من البروتوكول، بتاريخ 21 ديسمبر 2012. [ 5 ] وتشير صفحة الويب التي تقود إلى تلك المواصفات إلى أنه "لصالح العملاء الذين يرغبون في حماية محتواهم، لا تتضمن مواصفات RTMP المفتوحة تدابير RTMP الآمنة الخاصة بأدوبي". [ 6 ]

تمنح وثيقة مرفقة بمواصفات Adobe ترخيص براءة اختراع "غير حصري، مجاني، غير قابل للتحويل، غير قابل للترخيص من الباطن، شخصي، عالمي" لجميع تطبيقات البروتوكول، مع قيدين: الأول يحظر استخدامه لاعتراض بيانات البث ("أي تقنية تعترض محتوى الفيديو أو الصوت أو البيانات المتدفقة لتخزينها في أي جهاز أو وسيط")، والثاني يحظر التحايل على "التدابير التقنية لحماية محتوى الصوت والفيديو والبيانات، بما في ذلك أي من تدابير RTMP الآمنة الخاصة بـ Adobe". [ 7 ]

أشار ستيفان ريختر، مؤلف بعض الكتب عن فلاش ، في عام 2008 إلى أنه على الرغم من أن شركة أدوبي غامضة بشأن براءات الاختراع التي تنطبق على RTMP، إلا أن براءة الاختراع الأمريكية رقم 7,246,356 تبدو واحدة منها. [ 3 ]

في عام 2011، رفعت شركة أدوبي دعوى قضائية ضد شركة واوزا ميديا ​​سيستمز، مدعيةً، من بين أمور أخرى، انتهاك براءات اختراعها الخاصة بتقنية RTMP. [ 8 ] [ 9 ] [ 10 ] وفي عام 2015، أعلنت أدوبي وواوزا عن تسوية الدعاوى القضائية ورفضها نهائياً. [ 11 ]

بنية الحزمة

مخطط حزمة RTMP

تُرسل الحزم عبر اتصال TCP، الذي يُنشأ أولًا بين العميل والخادم. تحتوي الحزم على رأس وجسم، يُشفّر في حالة أوامر الاتصال والتحكم باستخدام تنسيق رسالة الإجراء (AMF). ينقسم الرأس إلى رأس أساسي (موضح منفصلًا عن باقي أجزاء الحزمة في الرسم التخطيطي) ورأس رسالة الجزء . الرأس الأساسي هو الجزء الثابت الوحيد في الحزمة، ويتكون عادةً من بايت مركب واحد ، حيث يمثل البتّان الأكثر أهمية نوع الجزء ( fmt في المواصفات)، بينما تشكل البتات المتبقية معرّف التدفق. بناءً على قيمة النوع، يمكن حذف بعض حقول رأس الرسالة، وتُستمد قيمتها من الحزم السابقة. أما بناءً على قيمة معرّف التدفق، فيمكن توسيع الرأس الأساسي ببايت واحد أو بايتين إضافيين (كما في الرسم التخطيطي الذي يحتوي على ثلاثة بايتات إجمالًا (c)). إذا كانت قيمة البتات الستة المتبقية من رأس الحزمة الأساسي (BH) (الأقل أهمية) تساوي صفرًا، فإن رأس الحزمة الأساسي يتكون من بايتين ويمثل من معرف التدفق 64 إلى 319 (64 + 255). أما إذا كانت القيمة تساوي واحدًا، فإن رأس الحزمة الأساسي يتكون من ثلاثة بايتات (مع ترميز آخر بايتين بنظام Little Endian ذي 16 بت) ويمثل من معرف التدفق 64 إلى 65599 (64 + 65535). وإذا كانت القيمة تساوي اثنين، فإن رأس الحزمة الأساسي يتكون من بايت واحد ويُخصص لرسائل وأوامر التحكم في البروتوكول منخفضة المستوى. يحتوي رأس رسالة الجزء على معلومات البيانات الوصفية مثل حجم الرسالة (مقاسًا بالبايتات)، وفرق الطابع الزمني ، ونوع الرسالة . هذا النوع الأخير عبارة عن بايت واحد ويحدد ما إذا كانت الحزمة صوتية أو فيديو أو أمرًا أو حزمة RTMP "منخفضة المستوى" مثل RTMP Ping.

يظهر أدناه مثال تم التقاطه عند قيام عميل فلاش بتنفيذ الكود التالي:

تيار فار : NetStream = new NetStream ( connectionObject )؛

سيؤدي هذا إلى إنشاء الجزء التالي:

رمز سداسي عشريASCII
03 00 0B 68 00 00 19 14 00 00 00 00 0200 0C63 72 65 61 74 65 53 74 72 65 61 6D 00 40 00 00 00 00 00 00 00 05␃ ␀ @ I ␀ ␀ ␙ ␔ ␀ ␀ ␀ ␀ ␂␀ ␌c r e a t e S t r e a m ␀ @ ␀ ␀ ␀ ␀ ␀ ␀ ␀ ␅

تبدأ الحزمة برأس أساسي مكون من بايت واحد (0x03)، حيث يحدد البتّان الأكثر أهمية (b 00 000011) نوع رأس الجزء 0، بينما تحدد البتات المتبقية (b00 000011 ) معرّف دفق الجزء 3. القيم الأربع الممكنة لنوع الرأس وأهميتها هي:

  • b00 = رأسية بحجم 12 بايت (رأسية كاملة).
  • b01 = 8 بايت - مثل النوع b00، باستثناء معرف الرسالة (آخر 4 بايت).
  • b10 = 4 بايت - يتم تضمين الرأس الأساسي والطابع الزمني (3 بايت).
  • b11 = 1 بايت - يتم تضمين الترويسة الأساسية فقط.

يُستخدم النوع الأخير (b11) دائمًا في حالة الرسائل المُجمّعة، حيث تبدأ الرسالة الثانية، في المثال أعلاه، بمعرّف 0xC3 (b11000011)، ما يعني أن جميع حقول رأس الرسالة يجب أن تُشتق من الرسالة ذات معرّف التدفق 3 (وهي الرسالة التي تسبقها مباشرةً). يمكن أن تأخذ البتات الستة الأقل أهمية، التي تُشكّل معرّف التدفق، قيمًا بين 3 و63. بعض القيم لها دلالة خاصة، مثل 1 الذي يُمثّل تنسيق معرّف مُوسّع، وفي هذه الحالة، سيتبعه بايتان. أما القيمة 2 فهي للرسائل منخفضة المستوى مثل Ping وSet Client Bandwidth.

يتم فك تشفير البايتات التالية من رأس RTMP (بما في ذلك القيم الموجودة في حزمة المثال أعلاه) على النحو التالي:

  • البايت رقم 1 (0x03) = نوع رأس الكتلة.
  • البايت رقم 2-4 (0x000b68) = فرق الطابع الزمني.
  • البايت رقم 5-7 (0x000019) = طول الحزمة - في هذه الحالة هو 0x000019 = 25 بايت.
  • البايت رقم 8 (0x14) = معرف نوع الرسالة - 0x14 (20) يحدد رسالة أمر مشفرة AMF0 .
  • البايت رقم 9-12 (0x00000000) = معرف دفق الرسائل. هذا بترتيب النهاية الصغرى.

يُحدد بايت مُعرّف نوع الرسالة ما إذا كانت الحزمة تحتوي على بيانات صوتية/مرئية، أو كائن بعيد، أو أمر. بعض القيم المُحتملة له هي:

  • 0x01 = رسالة تحديد حجم الحزمة.
  • 0x02 = إجهاض.
  • 0x03 = إقرار.
  • 0x04 = رسالة تحكم.
  • 0x05 = عرض نطاق الخادم
  • 0x06 = عرض النطاق الترددي للعميل.
  • 0x07 = التحكم الافتراضي.
  • 0x08 = حزمة صوتية.
  • 0x09 = حزمة الفيديو.
  • 0x0F = بيانات موسعة.
  • 0x10 = حاوية موسعة.
  • 0x11 = أمر موسع (أمر من نوع AMF3).
  • 0x12 = البيانات (استدعاء (onMetaData يتم إرسال المعلومات على هذا النحو)).
  • 0x13 = حاوية.
  • 0x14 = أمر (أمر من نوع AMF0).
  • 0x15 = UDP
  • 0x16 = المجموع
  • 0x17 = موجود

بعد العنوان، يشير 0x02 إلى سلسلة بحجم 0x000C وقيم 0x63 و0x72 ... و0x6D (أمر "createStream"). يلي ذلك 0x00 (رقم) وهو معرّف المعاملة بقيمة 2.0. البايت الأخير هو 0x05 (فارغ)، مما يعني عدم وجود وسائط.

استدعاء بنية الرسالة (0x14، 0x11)

تُعتبر بعض أنواع الرسائل الموضحة أعلاه، مثل Ping و Set Client/Server Bandwidth، رسائل بروتوكول RTMP منخفضة المستوى لا تستخدم تنسيق ترميز AMF. أما رسائل الأوامر، سواءً كانت AMF0 (نوع الرسالة 0x14) أو AMF3 (0x11)، فتستخدم التنسيق ولها الشكل العام الموضح أدناه:

(نص) <اسم الأمر> (رقم) <معرف المعاملة> (مختلط) <وسيط> مثال: فارغ، سلسلة نصية، كائن: {key1:value1, key2:value2 ... }

يُستخدم مُعرّف المعاملة للأوامر التي يمكن أن يكون لها رد. يمكن أن تكون القيمة إما سلسلة نصية كما في المثال أعلاه، أو كائنًا واحدًا أو أكثر، يتكون كل منها من مجموعة من أزواج المفاتيح/القيم، حيث تُشفّر المفاتيح دائمًا كسلاسل نصية، بينما يمكن أن تكون القيم أي نوع بيانات AMF، بما في ذلك الأنواع المعقدة مثل المصفوفات.

بنية رسالة التحكم (0x04)

لا تُشفّر رسائل التحكم باستخدام AMF. تبدأ هذه الرسائل بمعرف تدفق 0x02، مما يعني وجود رأس كامل (من النوع 0)، ويكون نوع الرسالة 0x04. يلي الرأس ستة بايتات، تُفسّر على النحو التالي:

  • #0–1 - نوع التحكم.
  • #2–3 - المعامل الثاني (هذا له معنى في أنواع تحكم محددة)
  • #4–5 - المعامل الثالث (نفسه)

يحدد أول بايتين من نص الرسالة نوع Ping، والذي يمكن أن يأخذ على ما يبدو [ 12 ] ست قيم ممكنة.

  • النوع 0 - تدفق البيانات الواضح: يُرسل عند إنشاء الاتصال ولا يحمل أي بيانات إضافية
  • النوع 1 - مسح المخزن المؤقت.
  • النوع 2 - التجفيف بالتيار.
  • النوع 3 - وقت التخزين المؤقت للعميل. يحتوي المعامل الثالث على القيمة بالمللي ثانية.
  • النوع 4 - إعادة ضبط البث.
  • النوع 6 - اختبار اتصال العميل من الخادم. المعامل الثاني هو الوقت الحالي.
  • النوع 7 - رد بونغ من العميل. المعامل الثاني هو الوقت الذي يتلقى فيه العميل إشارة بينغ.
  • النوع 8 - طلب UDP.
  • النوع 9 - استجابة UDP.
  • النوع 10 - حد النطاق الترددي.
  • النوع 11 - عرض النطاق الترددي.
  • النوع 12 - عرض نطاق الخانق.
  • النوع 13 - تم إنشاء التدفق.
  • النوع 14 - تم حذف البث.
  • النوع 15 - تعيين إمكانية الوصول للقراءة.
  • النوع 16 - تعيين إمكانية الوصول للكتابة.
  • النوع 17 - طلب بيانات تعريف البث.
  • النوع 18 - استجابة بيانات التعريف للتدفق.
  • النوع 19 - الحصول على حدود القطعة.
  • النوع 20 - تعيين حدود القطعة.
  • النوع 21 - عند قطع الاتصال.
  • النوع 22 - تعيين الرابط الحرج.
  • النوع 23 - قطع الاتصال.
  • النوع 24 - تحديث التجزئة.
  • النوع 25 - مهلة التجزئة.
  • النوع 26 - طلب التجزئة.
  • النوع 27 - استجابة التجزئة.
  • النوع 28 - فحص عرض النطاق الترددي.
  • النوع 29 - ضبط الوصول إلى عينة الصوت.
  • النوع 30 - تعيين الوصول إلى عينة الفيديو.
  • النوع 31 - بدء الخانق.
  • النوع 32 - طرف الخانق.
  • النوع 33 - إشعار إدارة الحقوق الرقمية.
  • النوع 34 - RTMFP Sync.
  • النوع 35 - استعلام IHello.
  • النوع 36 - إعادة توجيه IHello.
  • النوع 37 - إعادة توجيه IHello.
  • النوع 38 - إخطار نهاية الملف.
  • النوع 39 - متابعة الوكيل.
  • النوع 40 - إزالة الخادم الوكيل من المصدر.
  • النوع 41 - مجموعة RTMFP للحفاظ على استمرارية الحياة.
  • النوع 46 - لم يتم العثور على المقطع.

بونغ هو اسم الرد على بينغ، مع استخدام القيم كما هو موضح أعلاه.

بنية رسالة ServerBw/ClientBw (0x05، 0x06)

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

ضبط حجم القطعة (0x01)

القيمة المستلمة موجودة في أربعة بايتات من نص الرسالة. القيمة الافتراضية هي 128 بايت، ولا تُرسل الرسالة إلا عند الرغبة في إجراء تغيير.

بروتوكول

مخطط مصافحة RTMP

مصافحة

بعد إنشاء اتصال TCP، يُنشأ اتصال RTMP أولًا، حيث تتم عملية المصافحة من خلال تبادل ثلاث حزم بيانات من كل طرف (يُشار إليها أيضًا باسم Chunks في الوثائق الرسمية). يُشار إلى هذه الحزم في المواصفات الرسمية باسم C0-2 لحزم العميل المرسلة وS0-2 لحزم الخادم على التوالي، ويجب عدم الخلط بينها وبين حزم RTMP التي لا يمكن تبادلها إلا بعد اكتمال المصافحة. تتميز هذه الحزم ببنية خاصة بها، وتحتوي C1 على حقل يُحدد الطابع الزمني "epoch"، ولكن نظرًا لإمكانية ضبط هذا الحقل على الصفر، كما هو الحال في تطبيقات الطرف الثالث، يمكن تبسيط الحزمة. يُهيئ العميل الاتصال بإرسال حزمة C0 بقيمة ثابتة 0x03 تُمثل إصدار البروتوكول الحالي. ثم يُرسل مباشرةً حزمة C1 دون انتظار استلام S0 أولًا، والتي تحتوي على 1536 بايت، حيث تُمثل الأربعة الأولى الطابع الزمني "epoch"، والأربعة الثانية جميعها أصفار، والباقي عشوائي (ويمكن ضبطه على الصفر في تطبيقات الطرف الثالث). يمثل كل من C2 و S2 صدىً لكل من S1 و C1 على التوالي، باستثناء أن البايتات الأربعة الأخيرة تمثل وقت استلام الرسالة المعنية (بدلاً من 0). وبعد استلام C2 و S2، تُعتبر عملية المصافحة مكتملة.

يتصل

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

( استدعاء ) "اتصال" ( معرف المعاملة ) 1.0 ( الكائن 1 ) { التطبيق : "sample" ، إصدار الفلاش : "MAC 10,2,153,2" ، عنوان URL للملفات البرمجية : لا شيء ، عنوان URL لـ tc : "rtmpt://127.0.0.1/sample" ، fpad : خطأ ، الإمكانيات : 9947.75 ، ترميز الصوت : 3191 ، ترميز الفيديو : 252 ، وظيفة الفيديو : 1 ، عنوان URL للصفحة : لا شيء ، ترميز الكائن : 3.0 }

يستخدم خادم Flash Media Server والتطبيقات الأخرى مفهوم "التطبيق" لتعريف حاوية للمحتوى الصوتي/المرئي وغيره، ويتم تنفيذها كمجلد في جذر الخادم يحتوي على ملفات الوسائط المراد بثها. يحتوي المتغير الأول على اسم هذا التطبيق "sample"، وهو الاسم الذي يوفره خادم Wowza لأغراض الاختبار. السلسلة النصية flashVerهي نفسها التي تُرجعها دالة ActionScript getversion(). يتم ترميز audioCodecالقيمتين كأعداد عشرية مزدوجة ، ويمكن الاطلاع على معناهما في المواصفات الأصلية. وينطبق الأمر نفسه على المتغير ، وهو في هذه الحالة الثابت SUPPORT_VID_CLIENT_SEEK الذي يُوضح معناه بنفسه . من المهم بشكل خاص تحديد ما إذا كانت بقية عملية الاتصال ستستخدم تنسيق AMF3 الموسع أم لا. بما أن الإصدار 3 هو الإصدار الافتراضي الحالي، يجب إخبار عميل Flash صراحةً في كود ActionScript باستخدام AMF0 إذا طُلب ذلك. ثم يرد الخادم بتسلسل رسائل ServerBW وClientBW وSetPacketSize، متبوعًا أخيرًا برسالة Invoke، مع رسالة مثال.videoCodecvideoFunctionobjectEncoding

( استدعاء ) "_result" ( معرف المعاملة ) 1.0 ( الكائن 1 ) { fmsVer : "FMS/3,5,5,2004" ، الإمكانيات : 31.0 ، الوضع : 1.0 } ( الكائن 2 ) { المستوى : "الحالة" ، الرمز : "NetConnection.Connect.Success" ، الوصف : "تم الاتصال بنجاح" ، البيانات : ( مصفوفة ) { الإصدار : "3,5,5,2004" }، معرف العميل : 1728724019 ، ترميز الكائن : 3.0 }

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

تشغيل الفيديو

لبدء بث الفيديو، يرسل العميل أمر "createStream" متبوعًا برسالة "ping"، ثم أمر "play" مع اسم الملف كوسيط. سيرد الخادم بعد ذلك بسلسلة من أوامر "onStatus" متبوعة ببيانات الفيديو مغلفة ضمن رسائل RTMP.

بعد إنشاء الاتصال، يتم إرسال الوسائط عن طريق تغليف محتوى علامات FLV في رسائل RTMP من النوع 8 و 9 للصوت والفيديو على التوالي.

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

نفق HTTP (RTMPT)

يشير هذا إلى نسخة بروتوكول HTTP المُغلَقة. يتم التواصل عبر المنفذ 80، ويتم تمرير بيانات AMF ضمن طلبات واستجابات HTTP POST. تسلسل الاتصال كالتالي:

POST /fcs/ident2 HTTP / 1.1 Content-Type : application/x-fcs\r\n HTTP/1.0 404 غير موجود 
POST /open/1 HTTP / 1.1 Content-Type : application/x-fcs\r\n HTTP/1.1 200 OK نوع المحتوى: تطبيق/x-fcs\r\n 1728724019

يحتوي الطلب الأول على /fcs/ident2مسار، والرد الصحيح هو خطأ 404 (غير موجود). ثم يرسل العميل طلبًا من نوع /open/1، حيث يجب على الخادم الرد برمز 200 (موافق) مع إضافة رقم عشوائي يُستخدم كمعرّف للجلسة. في هذا المثال، يُعاد الرقم 1728724019 في نص الرد.

POST /idle/1728724019/0 HTTP / 1.1 HTTP/1.1 200 OK 0x01

من الآن فصاعدًا، هذا /idle/<session id>/<sequence #>طلب استطلاع حيث يتم إنشاء معرّف الجلسة وإعادته من الخادم، والتسلسل عبارة عن رقم يزيد بمقدار واحد مع كل طلب. الاستجابة المناسبة هي 200 OK، مع عدد صحيح مُعاد في نص الطلب يشير إلى الفاصل الزمني. يتم إرسال بيانات AMF عبر/send/<session id>/<sequence #>

تطبيقات البرمجيات

يتم تطبيق بروتوكول RTMP في هذه المراحل الثلاث:

  • مُشفّر الفيديو المباشر
  • خادم بث الوسائط المباشرة وعند الطلب
  • عميل مباشر وعند الطلب

rtmpdump

صُممت أداة سطر الأوامر rtmpdump، وهي أداة عميل RTMP مفتوحة المصدر، لتشغيل أو حفظ بث RTMP كامل، بما في ذلك بروتوكول RTMPE الذي تستخدمه Adobe للتشفير. تعمل RTMPdump على أنظمة Linux وAndroid وSolaris و Mac OS X ومعظم أنظمة التشغيل الأخرى المشتقة من Unix، بالإضافة إلى Microsoft Windows. كانت الأداة تدعم في الأصل جميع إصدارات Windows 32 بت، بما في ذلك Windows 98، ولكن بدءًا من الإصدار 2.2، أصبح البرنامج يعمل فقط على Windows XP والإصدارات الأحدث (مع العلم أن الإصدارات السابقة لا تزال تعمل بكفاءة كاملة).

تتوفر حزم برامج rtmpdump في مستودعات البرامج مفتوحة المصدر الرئيسية (توزيعات لينكس). وتشمل هذه الحزم تطبيقات الواجهة الأمامية "rtmpdump" و"rtmpsrv" و"rtmpsuck".

استؤنف تطوير برنامج RTMPdump في أكتوبر 2009، خارج الولايات المتحدة، على موقع MPlayer . [ 13 ] يتميز الإصدار الحالي بتحسينات كبيرة في الأداء، وقد أُعيدت كتابته للاستفادة من مزايا لغة البرمجة C. وعلى وجه الخصوص، تم دمج الوظائف الرئيسية في مكتبة (librtmp) يسهل استخدامها من قِبل تطبيقات أخرى. كما قام مطورو RTMPdump بتطوير دعم لمكتبة librtmp لبرامج MPlayer و FFmpeg و XBMC و cURL و VLC ، بالإضافة إلى عدد من مشاريع البرمجيات مفتوحة المصدر الأخرى. يُتيح استخدام librtmp لهذه المشاريع دعمًا كاملاً لبروتوكول RTMP بجميع إصداراته دون الحاجة إلى أي جهد تطوير إضافي.

FLVstreamer

FLVstreamer هو نسخة معدلة من RTMPdump، بدون الكود البرمجي الذي تدّعي Adobe أنه ينتهك قانون الألفية الرقمية لحقوق المؤلف (DMCA) في الولايات المتحدة. وقد طُوّر هذا البرنامج ردًا على محاولة Adobe في عام 2008 لحظر RTMPdump. FLVstreamer هو عميل RTMP يقوم بحفظ بث محتوى الصوت أو الفيديو من أي خادم RTMP على القرص، في حال عدم تفعيل التشفير (RTMPE) على البث.

الإضافات

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

تمديد مخصص

يستخدم بروتوكول RTMP داخليًا "معرّف ترميز" خاصًا به مكونًا من أربعة بتات بدلاً من معيار FourCC لتحديد مجموعة الترميزات التي يدعمها. تُعتبر معرّفات ترميز الصوت والفيديو ضمن نطاقات أسماء مختلفة، لذا فإن استخدام القيمة نفسها لا يُسبب أي تعارض: على سبيل المثال، في معيار Adobe الأساسي، يكون ترميز الصوت 7 هو G.711A وترميز الفيديو 7 هو H.264.

في الصين، خصصت شركة Kingsoft Cloud ترميز الفيديو H.265 للرقم "12" في عام 2018، وهي ممارسة سرعان ما تبنتها شركات أخرى في هذا المجال مثل Bilibili . وفي عام 2020، خصص شيا تشو من شركة ZLMediaKit ترميز الصوت Opus للرقم "13 ". [ 14 ]

أصبحت جميع الإضافات المخصصة لحقل المعرّف المشفر غير مستخدمة في بروتوكول E-RTMP. لا يعيد بروتوكول E-RTMP استخدام المعرّفين 12 و13، مما يجعله متوافقًا مع الامتدادات المخصصة الصينية .

بروتوكول RTMP المحسن

يُعدّ بروتوكول RTMP المُحسّن (E-RTMP) تطويرًا لبروتوكول المراسلة في الوقت الحقيقي (RTMP) ومواصفات FLV ، حيث يُحدّث عمليات البث المباشر مع الحفاظ على التوافق مع البنية التحتية الحالية لبروتوكول RTMP. [ 2 ] طُوّر بروتوكول E-RTMP كمواصفة مفتوحة المصدر، ونُشر بواسطة منظمة Veovera Software، بمساهمات من Adobe و Google و Twitch وغيرها.

تشمل التحسينات التي تم إدخالها في نظام E-RTMP ما يلي:

  • تنسيقات رأسية جديدة للصوت والفيديو FLV، والتي يتم الإشارة إليها باستخدام أجزاء محجوزة من تنسيقات الرأس الأصلية.
    • كانت الترويسات القديمة تستخدم أعدادًا صحيحة من أربعة بتات لتحديد أنواع الترميز، مما حدّ من إمكانية التوسع. أما التنسيق الجديد فيستخدم أرقام FourCC لتحديد الترميزات الجديدة. تشمل الخيارات القياسية AC-3 و E-AC-3 و Opus و FLAC للصوت، و VP8 و VP9 و HEVC و AV1 مع إمكانيات HDR للفيديو، مع إمكانية استخدام أي ترميز يحمل مُعرّف FourCC مُتفق عليه.
    • تتضمن الرؤوس الجديدة طوابع زمنية على مستوى النانو ثانية لتحسين التزامن مع تنسيقات الوسائط الحديثة.
    • تتضمن الرؤوس الجديدة القدرة على وصف تكوين متعدد المسارات، مما يسمح بمعالجة الصوت والفيديو والبيانات الوصفية في وقت واحد ضمن دفق واحد.
    • يمكن لرأس الصوت الجديد وصف تكوينات الصوت متعددة القنوات، مما يجعله أكثر مرونة.
    • يستخدم رأس الفيديو الجديد أنواع الحزم بدلاً من أنواع الإطارات. أحد هذه الأنواع VideoPacketType.Metadataيسمح بكتابة أي بيانات وصفية للفيديو بتنسيق رسالة الإجراء (AMF). (يُستخدم تنسيق AMF في بروتوكول RTMP الأصلي على طبقة مراسلة البروتوكول، وليس كجزء من دفق فيديو FLV).
  • إعلان عن إمكانيات الترميز الجديدة بتنسيق FourCC.
  • حقول جديدة لـ onMetaData، وهي آلية بيانات وصفية موجودة في RTMP (الاستخدام الحالي لـ AMF).
  • ميزة طلب إعادة الاتصال لتحسين استقرار الاتصال ومرونته في عمليات البث المباشر.

يعزز بروتوكول E-RTMP قدرات بروتوكول RTMP مع ضمان التوافق مع تطبيقات RTMP الحالية. على سبيل المثال، لن يتمكن جهاز فك التشفير القديم من فك تشفير الإطارات التي تحتوي على رؤوس محجوزة ("جديدة")، ولكنه سيظل قادرًا على إعادة توجيهها بشكل صحيح.

نظراً لأن العديد من التغييرات في بروتوكول E-RTMP تُجرى على طبقة تنسيق FLV، فإن E-RTMP يتضمن أيضاً امتداداً لتنسيق ملف FLV يمكن استخدامه بشكل مستقل عن E-RTMP. ويُطلق برنامج ffmpeg على هذا التنسيق اسم "FLV المحسّن". [ 15 ]

التطبيقات

المنتجون:

أجهزة الإدخال:

أجهزة الإدخال، المحسّنة بتقنية FLV فقط:

  • e-flv-js، وهو نسخة معدلة من مكتبة flv-js (الأصلية من Bilibili ) من تطوير Veovera. كما يمتلك مطور flv-js نسخة معدلة خاصة به تُسمى mpegts.js مع بعض الدعم لتقنية Enhanced-FLV. [ 19 ]

انظر أيضاً

مراجع

  1. ↑ "RTMPE" . مساعدة Adobe Flash Lite 4. Adobe. مؤرشف من الأصل في 4 ديسمبر 2017. تم الاسترجاع في 29 ديسمبر 2013 .
  2. 1 2 لوزبين، سلافيك (21 يناير 2025). "بروتوكول RTMP المحسّن (الإصدار 2)" . مؤسسة فيوفيرا للبرمجيات . تم الاطلاع عليه بتاريخ 25 فبراير 2025 .
  3. 1 2 "TheRealTimeWeb.com: Adobe Patents RTMP" . therealtimeweb.com . مؤرشف من الأصل بتاريخ 21 فبراير 2020. تم الاطلاع عليه بتاريخ 4 أغسطس 2014 .
  4. ↑ "استخدام خدمات RPC في Flex Data Services 2" . Adobe DevNet . Adobe. مؤرشف من الأصل في 3 أبريل 2007. تم الاطلاع عليه في 16 أبريل 2007 .
  5. ↑ هـ. بارمار، م. ثورنبورغ (محرران) بروتوكول المراسلة في الوقت الحقيقي من أدوبي ، أدوبي، 21 ديسمبر 2012
  6. ↑ "مواصفات بروتوكول المراسلة في الوقت الحقيقي (RTMP)" . مؤرشف من الأصل بتاريخ 21 أغسطس 2014. تم الاطلاع عليه بتاريخ 8 مايو 2014 .
  7. ↑ رخصة مواصفات بروتوكول RTMP ، نُشرت في أبريل 2009
  8. ↑ شوماخر-راسموسن، إريك (27 مايو 2011). "واوزا تنفي مزاعم أدوبي بانتهاك براءات الاختراع" . streamingmedia.com .
  9. ↑ لولر، رايان (31 مايو 2011). "واوزا ترد على أدوبي في دعوى براءة اختراع فلاش" . gigaom.com . مؤرشف من الأصل في 21 فبراير 2013.
  10. ↑ "شركة أدوبي سيستمز - رقم C 11-2243 CW. - 20120907565 - Leagle.com" . leagle.com .
  11. ↑ شركة Wowza Media Systems وشركة Adobe Systems تُسوّيان قضايا براءات الاختراع http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases
  12. ↑ مشروع Red5 (2009) Ping. متاح على الرابط: http://trac.red5.org/wiki/Documentation/Tutorials/Ping . تاريخ الوصول: 25 ديسمبر 2011
  13. ↑ "التحديثات: 2009-11-01" . تم الاطلاع عليه في 1 نوفمبر 2009 .
  14. ↑
  15. 1 2 "دعم ترميز HEVC VP9 AV1 في تنسيق flv المحسّن" . GitHub . 2 فبراير 2024. تم الاطلاع عليه في 1 أبريل 2024 .
  16. ↑ "تفعيل AV1 وHEVC عبر RTMP إلى يوتيوب" . جيت هاب . 25 مارس 2023. تم الاطلاع عليه في 1 أبريل 2024 .
  17. ↑ "أطلق العنان لقوة بروتوكول RTMP المحسّن مع خادم Ant Media" . 26 سبتمبر 2024.
  18. ↑ "تقديم النسخة التجريبية المحسّنة للبث" . جيت هاب . 8 يناير 2024. تم الاطلاع عليه في 1 أبريل 2024 .
  19. ↑ "xqq/mpegts.js" . 22 أكتوبر 2025.