دردشة فيديو من نظير إلى نظير تعتمد على WebRTC. دردشة فيديو P2P تعتمد على تثبيت WebRTC Webrtc

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

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

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

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

وبعد فترة وجيزة، تلقى Chrome وFirefox محركات WebRTC الخاصة بهما. حاليًا، تم تجهيز إصدارات الأجهزة المحمولة الخاصة بهم بهذه التقنية ومحرك WebView 3.6 المثبت بنظام Android 5.0، والذي تستخدمه التطبيقات.

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

بالتوازي مع التكامل في المتصفح، مجموعة عمل الكونسورتيوم شبكة الانترنتقامت (W3C) بتسريع عملية توحيد WebRTC. وينبغي الانتهاء منه في عام 2015.

WebRTC يكتفي بالقليل

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

لإنشاء اتصال دفق مباشر مع المحاور، يتلقى المتصفح عنوان IP الخاص به وبيانات التكوين من خدمة WebRTC. عارض الويب الخاص بالشخص الآخر يفعل الشيء نفسه.

لكي يعمل اتصال البث بسلاسة وبجودة جيدة، تعمل ثلاثة محركات في المتصفح. اثنان منهم يقومان بتحسين وضغط بيانات الصوت والفيديو، والثالث مسؤول عن نقلها. يرسل البيانات عبر بروتوكول SRTP(بروتوكول النقل الآمن في الوقت الحقيقي)، والذي يسمح بالبث المشفر في الوقت الحقيقي.

إذا تعذر إنشاء اتصال مباشر، يبحث WebRTC عن مسار آخر. على سبيل المثال، يحدث هذا عندما اعدادات الشبكةمنع خادم STUN من الإبلاغ عن عنوان IP. ينص معيار WebRTC على أنه في هذه الحالة ستتم المحادثة، ولكن مع التنشيط المتوسط ​​لخادم TURN (الاجتياز باستخدام المرحلات حول NAT). لذلك، على موقع الويب netscan.co، يمكنك التحقق من تنفيذ WebRTC على جهاز الكمبيوتر الخاص بك ومن خلال وصولك إلى الشبكة.

كيف يتم الاتصال

يجب عليك أولا تسجيل المحادثة (1). توفر خدمة WebRTC رابطًا يجب إرساله إلى المحاور. يكتشف المتصفح، باستخدام خادم STUN، عنوان IP الخاص به (2)، ويرسله إلى الخدمة ويستقبل عنوان IP الخاص بالشريك لإنشاء اتصال مباشر (3). إذا فشل STUN، تتم إعادة توجيه المحادثة باستخدام خادم TURN (4).

يتم إطلاق الاتصال باستخدام تقنية WebRTC في المتصفح باستخدام كود JavaScript. بعد ذلك، تكون ثلاثة محركات مسؤولة عن الاتصال: تقوم محركات الصوت والفيديو بجمع بيانات الوسائط المتعددة من كاميرا الويب والميكروفون، ويجمع محرك النقل المعلومات ويرسل الدفق في شكل مشفر باستخدام SRTP (بروتوكول الوقت الحقيقي الآمن).

ما هي المتصفحات التي تعمل مع WebRTC؟

يحتوي Chrome وFirefox على محرك WebRTC يستخدم خدمات مثل talky.io. يمكن لمتصفح Mozilla العمل مباشرة مع عميله.

تواصل Google وMozilla تطوير فكرة الاتصال في الوقت الفعلي: يستطيع Chrome استضافة مؤتمرات WebRTC مع مشاركين متعددين، كما تم تطوير عميل Hello الجديد من Firefox بالتعاون مع شركة تابعة لشركة Telefonica العملاقة للاتصالات. لا تزال شركة Apple على الهامش في الوقت الحالي، ولا ينبغي أن تتوقع وجود WebRTC في Safari بعد. ومع ذلك، هناك الكثير تطبيقات بديلةلنظام التشغيل iOS والمكونات الإضافية لمتصفح Safari.

تتخذ Microsoft مسارًا مختلفًا قليلاً. كمالك تنافسية خدمة سكايبهذه الشركة لن تستسلم لـ WebRTC بهذه السهولة. وبدلاً من ذلك، تعمل Microsoft على تطوير تقنية تسمى ORTC (اتصالات الكائنات في الوقت الحقيقي) من أجل متصفح الانترنت.

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

صورة:الشركات المصنعة؛ Goodluz/Fotolia.com

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

WebRTC

مقدمة

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

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

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

الشكل 1: كلا العقدتين على نفس الشبكة

الشكل 2: العقد في شبكات مختلفة (واحدة خاصة وواحدة عامة)

الشكل 3: العقد في شبكات خاصة مختلفة، ولكن بعناوين متساوية عدديًا

في الأشكال أعلاه، يشير الحرف الأول في التدوين المكون من حرفين إلى نوع العقدة (p = نظير، ص = جهاز التوجيه). في الشكل الأول، الوضع مناسب: يتم تحديد العقد الموجودة في شبكتها بالكامل بواسطة الشبكة الملكية الفكريةعناوين وبالتالي يمكن الاتصال ببعضها البعض مباشرة. في الشكل الثاني لدينا شبكتان مختلفتان لهما أرقام عقد متشابهة. هذا هو المكان الذي تظهر فيه أجهزة التوجيه (أجهزة التوجيه)، والتي تحتوي على اثنين واجهة الشبكة- داخل شبكتك وخارج شبكتك. لهذا السبب لديهم اثنان الملكية الفكريةعناوين. تحتوي العقد العادية على واجهة واحدة فقط يمكنها التواصل من خلالها فقط داخل شبكتها. إذا قاموا بنقل البيانات إلى شخص خارج شبكتهم، فسيتم استخدامها فقط ناتداخل جهاز التوجيه (جهاز التوجيه) وبالتالي يكون مرئيًا للآخرين الموجود تحته الملكية الفكريةعنوان جهاز التوجيه هو لهم خارجي الملكية الفكريةعنوان. وهكذا، في العقدة ص1هنالك الداخلية الملكية الفكرية = 192.168.0.200 و خارجي الملكية الفكرية = 10.50.200.5 وسيكون العنوان الأخير أيضًا خارجيًا لجميع العقد الأخرى في شبكته. حالة مماثلة للعقدة ص2. ولذلك، فإن اتصالهم مستحيل إذا كنت تستخدم فقط الداخلية (الخاصة بهم) الملكية الفكريةعناوين. يمكنك استخدام عناوين خارجية، أي عناوين جهاز التوجيه، ولكن نظرًا لأن جميع العقد الموجودة في نفس الشبكة الخاصة لها نفس العنوان الخارجي، فهذا أمر صعب للغاية. يتم حل هذه المشكلة باستخدام الآلية نات

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

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

مرحلتان من WebRTC

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

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

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

• البادئ (المتصل - المتصل):
  1. عرض لبدء نقل بيانات الفيديو (createOffer)
  2. الحصول على لك الحزب الديمقراطي الاجتماعي الحزب الديمقراطي الاجتماعي)
  3. الحصول على لك مرشح الجليد مرشح الجليد)
• خدمة انتظار المكالمات ( كالي):
  1. تلقي دفق الوسائط المحلي (الخاص بك) وإعداده للإرسال (getUserMediaStream)
  2. تلقي عرض لبدء نقل بيانات الفيديو وإنشاء إجابة (createAnswer)
  3. الحصول على لك الحزب الديمقراطي الاجتماعيالكائن ونقله من خلال آلية الإشارة ( الحزب الديمقراطي الاجتماعي)
  4. الحصول على لك مرشح الجليدالأشياء وانتقالها من خلال آلية الإشارة ( مرشح الجليد)
  5. استقبال دفق الوسائط عن بعد (الأجنبي) وعرضه على الشاشة (onAddStream)

والفرق الوحيد هو في النقطة الثانية.

على الرغم من التعقيد الواضح للخطوات، هناك في الواقع ثلاث خطوات: إرسال دفق الوسائط الخاص بك (البند 1)، وتعيين معلمات الاتصال (البنود 2-4)، واستقبال دفق الوسائط الخاص بشخص آخر (البند 5). وأصعب خطوة هي الخطوة الثانية، لأنها تتكون من جزأين: التأسيس بدنيو منطقيروابط. الأول يشير طريق، والتي يجب أن تنتقل عبرها الحزم للانتقال من عقدة شبكة إلى أخرى. ويشير الثاني معلمات الفيديو/الصوت– ما هي الجودة التي يجب استخدامها، وما هي برامج الترميز التي يجب استخدامها.

المرحلة العقلية createOfferأو createAnswerيجب أن تكون مرتبطة بمراحل الإرسال الحزب الديمقراطي الاجتماعيو مرشح الجليدأشياء.

الكيانات الأساسية

تدفقات الوسائط (MediaStream)

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

في WebRTCهناك تسلسل هرمي مربك إلى حد ما داخل الموضوع. يمكن أن يتكون كل تيار من عدة مسارات وسائط ( ميدياتراك) والتي بدورها يمكن أن تتكون من عدة قنوات إعلامية ( قناة الوسائط). وقد يكون هناك أيضًا العديد من تدفقات الوسائط نفسها.

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

الشكل 4: تياران مختلفان للوسائط. واحدة لنا، وواحدة لطاولتنا

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

الشكل 5: تتكون تدفقات الوسائط من مسارات الوسائط

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

ولكن كيف نميز تدفقات الوسائط على الطرف الآخر من الاتصال؟ للقيام بذلك، كل دفق الوسائط لديه الخاصية ملصق– تسمية الدفق واسمه (الشكل 6). مسارات الوسائط لها نفس الخاصية. على الرغم من أنه يبدو للوهلة الأولى أنه يمكن تمييز الفيديو عن الصوت بطرق أخرى.

الشكل 6: يتم تحديد تدفقات الوسائط ومساراتها بواسطة التسميات

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

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

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

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

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

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

واصف الجلسة (SDP)

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

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

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

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

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

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

الشكل 7: تفاوض برنامج الترميز

مرشح الجليد

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

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

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

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

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

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

الشكل 8: عقدتان على نفس الشبكة

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

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

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

الشكل 9: إحدى العقدتين خلف NAT، والأخرى ليست كذلك

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

لنفترض أن خادم الويب متصل بالإنترنت مباشرة، أي أنه يحتوي على عام الملكية الفكرية* عنوان. دع هذه تكون عقدة ص2. عقدة ص1(عميل الويب) يرسل طلبًا إلى العنوان 10.50.200.10 . أولا تذهب البيانات إلى جهاز التوجيه ص1، أو بالأحرى عليه الداخليةواجهه المستخدم 192.168.0.1 . وبعد ذلك، يتذكر جهاز التوجيه عنوان المصدر (address ص1) ويدخله في جدول خاص نات، ثم قم بتغيير عنوان المصدر إلى عنوانك( ص1 → ص1). علاوة على ذلك، بطريقتي الخاصة خارجيالواجهة، يرسل جهاز التوجيه البيانات مباشرة إلى خادم الويب ص2. يقوم خادم الويب بمعالجة البيانات، وإنشاء استجابة، ثم إرسالها مرة أخرى. يرسل إلى جهاز التوجيه ص1لأنه هو الموجود في عنوان المرسل (استبدل جهاز التوجيه العنوان بعنوانه الخاص). يتلقى جهاز التوجيه البيانات وينظر إلى الجدول ناتويعيد توجيه البيانات إلى العقدة ص1. يعمل جهاز التوجيه كوسيط هنا.

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

دعونا نعود إلى التكنولوجيا WebRTCأو بالأحرى إلى الجزء الذي يستخدمه جليدالبروتوكول (وبالتالي جليدمرشحين). عقدة ص2لديه مرشح واحد (موقعه في الشبكة – 10.50.200.10 )، والعقدة ص1، والذي يقع خلف جهاز التوجيه مع NAT، سيكون له مرشحان - محلي ( 192.168.0.200 ) ومرشح جهاز التوجيه ( 10.50.200.5 ). الأول ليس مفيدًا، لكنه مع ذلك يتم إنشاؤه منذ ذلك الحين WebRTCلا يعرف حتى الآن شيئًا عن العقدة البعيدة - فقد تكون أو لا تكون على نفس الشبكة. سيكون المرشح الثاني مفيدًا، وكما نعلم بالفعل، سيلعب المنفذ دورًا مهمًا (المرور عبره). نات).

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

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

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

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

خوادم STUN و TURN

عند التهيئة WebRTCيجب عليك الإشارة إلى المتاحة صاعقةو دورالخوادم، والتي سوف نسميها كذلك جليدالخوادم. إذا لم يتم تحديد الخوادم، فسيتم فقط العقد الموجودة في نفس الشبكة (المتصلة بها بدون نات). على الفور تجدر الإشارة إلى ذلك 3 جرام-يجب استخدام الشبكات دورالخوادم.

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

دعونا نلقي نظرة على هذه العملية مع مثال.

مثال (عملية خادم STUN)

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

لذلك، في البداية لدينا طاولة فارغة r1_nat.

الجدول 2: رأس الحزمة

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

تم تغيير رأس الحزمة:

الجدول 4: تم تحديث جدول NAT بإدخال جديد

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

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

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

إس آر سي آي بي	ميناء سرك	عنوان IP المقصود	ميناء الوجهة
10.50.200.5	888	12.62.100.200	6000

الجدول 5: تلقى خادم STUN الحزمة

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

والآن لدينا حزمة ثانية تسير في الاتجاه المعاكس:

الجدول 7: يرسل خادم STUN حزمة تحتوي على هذا المحتوى

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

الملكية الفكرية الداخلية	ميناء داخلي	الملكية الفكرية الخارجية	منفذ خارجي
192.168.0.200	35777	10.50.200.5	888

الجدول 8: جدول NAT

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

الجدول 10: يستبدل جهاز التوجيه عنوان جهاز الاستقبال

إس آر سي آي بي	ميناء سرك	عنوان IP المقصود	ميناء الوجهة
12.62.100.200	6000	192.168.0.200	35777

الجدول 11: قام جهاز التوجيه بتغيير عنوان جهاز الاستقبال

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

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

من المثال أعلاه يمكنك الحصول على فكرة عن كيفية عمله ناتوالجوهر صاعقةالخادم. وبشكل عام الآلية جليدو الصاعقة / بدورهتهدف الخوادم على وجه التحديد إلى التغلب على القيود نات.

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

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

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

هكذا دورهناك حاجة إلى خادم عند تحديد موقع كلا المحاورين متماثل نات(كل واحد لنفسه).

ملخص موجز

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

• تيار وسائل الإعلام
  • يتم تجميع بيانات الفيديو والصوت في تدفقات الوسائط
  • تقوم تدفقات الوسائط بمزامنة مسارات الوسائط التي تتكون منها
  • لا تتم مزامنة تدفقات الوسائط المختلفة مع بعضها البعض
  • يمكن أن تكون تدفقات الوسائط محلية وبعيدة، وعادةً ما يكون التدفق المحلي متصلاً بكاميرا وميكروفون، وتتلقى التدفقات البعيدة البيانات من الشبكة في شكل مشفر
  • هناك نوعان من مسارات الوسائط - للفيديو وللصوت.
  • تتمتع مسارات الوسائط بالقدرة على التشغيل/الإيقاف
  • تتكون المسارات الإعلامية من قنوات إعلامية
  • تقوم مسارات الوسائط بمزامنة قنوات الوسائط التي تتكون منها
  • تحتوي تدفقات الوسائط ومسارات الوسائط على تسميات يمكن تمييزها من خلالها
• مقبض الجلسة
  • يتم استخدام واصف الجلسة لتوصيل عقدتين بالشبكة بشكل منطقي
  • يقوم واصف الجلسة بتخزين معلومات حول الطرق المتاحةترميز بيانات الفيديو والصوت
  • WebRTCيستخدم آلية إشارات خارجية - مهمة إعادة توجيه واصفات الجلسة ( com.sdp) يقع على التطبيق
  • تتكون آلية الاتصال المنطقي من مرحلتين - الجمل ( يعرض) والجواب ( إجابة)
  • لا يمكن إنشاء واصف الجلسة دون استخدام دفق الوسائط المحلي في حالة وجود اقتراح ( يعرض) وغير ممكن بدون استخدام مقبض الجلسة البعيدة في حالة الاستجابة ( إجابة)
  • يجب إعطاء الواصف الناتج للتنفيذ WebRTCولا يهم ما إذا تم الحصول على هذا الواصف عن بعد أو محليًا من نفس التنفيذ WebRTC
  • من الممكن تعديل واصف الجلسة قليلاً
• مرشحين
  • مُرَشَّح ( مرشح الجليد) هو عنوان العقدة على الشبكة
  • يمكن أن يكون عنوان العقدة خاصًا بك، أو يمكن أن يكون عنوان جهاز توجيه أو دورالخوادم
  • هناك دائما العديد من المرشحين
  • يتكون المرشح من الملكية الفكريةالعنوان والميناء ونوع النقل ( برنامج التعاون الفنيأو UDP)
  • يتم استخدام المرشحين لإنشاء اتصال فعلي بين عقدتين في الشبكة
  • يجب أيضًا إرسال المرشحين من خلال آلية الإشارة
  • يحتاج المرشحون أيضًا إلى النقل إلى عمليات التنفيذ WebRTC، ولكن البعيدة فقط
  • في بعض التنفيذات WebRTCلا يمكن إرسال المرشحين إلا بعد تعيين واصف الجلسة
• صاعقة/دوران/جليد/NAT
  • نات– آلية لتوفير الوصول إلى الشبكة الخارجية
  • تدعم أجهزة التوجيه المنزلية جدولًا خاصًا نات
  • يستبدل جهاز التوجيه العناوين الموجودة في الحزم - عنوان المصدر بعنوانه الخاص، إذا كانت الحزمة تنتقل إلى شبكة خارجية، وعنوان الوجهة بعنوان المضيف على الشبكة الداخلية، إذا كانت الحزمة واردة من شبكة خارجية
  • لتوفير وصول متعدد القنوات إلى الشبكة الخارجية ناتيستخدم المنافذ
  • جليد- آلية التجاوز نات
  • صاعقةو دورالخوادم - خوادم مساعدة للتجاوز نات
  • صاعقةيسمح لك الخادم بإنشاء السجلات اللازمة في الجدول نات، ويعيد أيضًا العنوان الخارجي للعقدة
  • دورتعميم الخادم صاعقةآلية ويجعلها تعمل دائما
  • في أسوأ الحالات دوريتم استخدام الخادم كوسيط ( تناوب)، إنه p2pيتحول إلى اتصال بين العميل والخادم والعميل.

WebRTC (اتصالات الويب في الوقت الحقيقي) هو معيار يصف نقل تدفق البيانات الصوتية وبيانات الفيديو والمحتوى من وإلى المتصفح في الوقت الفعلي دون تثبيت مكونات إضافية أو ملحقات أخرى. يسمح لك المعيار بتحويل متصفحك إلى محطة لعقد مؤتمرات الفيديو؛ ما عليك سوى فتح صفحة ويب لبدء الاتصال.

ما هو WebRTC؟

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

ما الذي تريد معرفته عن WebRTC؟

تطور معايير وتقنيات الاتصال المرئي

سيرجي يوتسايتيس، سيسكو، مؤتمر الفيديو+2016

كيف يعمل WebRTC

جانب العميل

• يفتح المستخدم صفحة تحتوي على علامة HTML5
• يطلب المتصفح الوصول إلى كاميرا الويب والميكروفون الخاصين بالمستخدم.
• يتحكم رمز JavaScript الموجود على صفحة المستخدم في معلمات الاتصال (عناوين IP ومنافذ خادم WebRTC أو عملاء WebRTC الآخرين) لتجاوز NAT وجدار الحماية.
• عند تلقي معلومات حول المحاور أو حول الدفق من المؤتمر المختلط على الخادم، يبدأ المتصفح في التفاوض على برامج ترميز الصوت والفيديو المستخدمة.
• تبدأ عملية التشفير ونقل البيانات المتدفقة بين عملاء WebRTC (في حالتنا، بين المتصفح والخادم).

على جانب خادم WebRTC

لا يلزم وجود خادم فيديو لتبادل البيانات بين اثنين من المشاركين، ولكن إذا كنت بحاجة إلى الجمع بين عدة مشاركين في مؤتمر واحد، فيجب وجود خادم.

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

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

مزايا المعيار

• لا يلزم تثبيت البرامج.
• جودة تواصل عالية جدًا، وذلك بفضل:
  • استخدام الفيديو الحديث (VP8، H.264) وبرامج ترميز الصوت (Opus).
  • الضبط التلقائي لجودة الدفق حسب ظروف الاتصال.
  • المدمج في نظام الحد من الصدى والضوضاء.
  • الضبط التلقائي لمستوى حساسية الميكروفونات المشاركة (AGC).
• مستوى عالٍ من الأمان: جميع الاتصالات محمية ومشفرة باستخدام بروتوكولات TLS وSRTP.
• هناك آلية مدمجة لالتقاط المحتوى، على سبيل المثال، سطح المكتب.
• إمكانية تنفيذ أي واجهة إدارة تعتمد على HTML5 وJavaScript.
• القدرة على دمج الواجهة مع أي أنظمة خلفية تستخدم WebSockets.
• المشروع مفتوح مصدر الرمز- يمكن تنفيذها في منتجك أو خدمتك.
• صحيح عبر الأنظمة الأساسية: سيعمل نفس تطبيق WebRTC بشكل جيد على أي نظام أساسي نظام التشغيلأو سطح المكتب أو الهاتف المحمول، بشرط أن يدعم المتصفح WebRTC. وهذا يوفر بشكل كبير الموارد اللازمة لتطوير البرمجيات.

عيوب المعيار

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

أسرار WebRTC: كيف يستفيد البائعون من تكنولوجيا الويب المتقدمة

تساحي ليفنت ليفي، Bloggeek.me، مؤتمر فيديو + 2015

WebRTC لسوق مؤتمرات الفيديو

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

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

استخدامها في الحلول المتخصصة

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

المستخدمون السابقون لبرنامج Skype لنظام التشغيل Linux

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

المنافسة مع فلاش

كان WebRTC وHTML5 بمثابة ضربة قاضية لتقنية Flash، التي كانت تمر بالفعل بأسوأ سنواتها. منذ عام 2017، توقفت المتصفحات الرائدة رسميًا عن دعم Flash واختفت التكنولوجيا تمامًا من السوق. ولكن يجب أن نعطي فلاش حقه، لأنه هو الذي أنشأ سوق مؤتمرات الويب وعرضها القدرات التقنيةللتواصل المباشر في المتصفحات.

عروض فيديو WebRTC

ديمتري أودينتسوف، TrueConf، فيديو + مؤتمر أكتوبر 2017

برامج الترميز في WebRTC

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

يستخدم WebRTC برامج الترميز Opus وG.711 لضغط حركة مرور الصوت.

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

G.711 مدعوم من قبل عدد كبير من الأجهزة. تعد الأنظمة التي تستخدم برنامج الترميز هذا أسهل في الاستخدام من تلك التي تعتمد على برامج ترميز الصوت الأخرى (G.723، G.726، G.728، وما إلى ذلك). من حيث الجودة، حصل G.711 على درجة 4.2 في اختبار MOS (الدرجة بين 4-5 هي الأعلى وتعني جودة جيدة، على غرار جودة نقل حركة المرور الصوتية في ISDN وحتى أعلى).

التأليفهو برنامج ترميز ذو زمن وصول منخفض للتشفير (من 2.5 مللي ثانية إلى 60 مللي ثانية)، ويدعم معدلات البت المتغيرة ومستويات الضغط العالية، وهو مثالي لنقل الإشارات الصوتية المتدفقة في الشبكات ذات المتغيرات الإنتاجية. Opus هو حل مختلط يجمع بين أفضل خصائص برامج الترميز SILK (ضغط الصوت، والقضاء على تشويه الكلام البشري) وبرامج الترميز CELT (ترميز البيانات الصوتية). برنامج الترميز متاح مجانًا، ولا يحتاج المطورون الذين يستخدمونه إلى دفع إتاوات لأصحاب حقوق الطبع والنشر. بالمقارنة مع برامج الترميز الصوتية الأخرى، فإن Opus يفوز بلا شك بعدة طرق. لقد تغلب على برامج الترميز ذات معدل البت المنخفض الشائعة جدًا مثل MP3 وVorbis وAAC LC. تعمل Opus على استعادة الصوت "الصورة" الأقرب إلى الصوت الأصلي من AMR-WB وSpeex. يعد برنامج الترميز هذا هو المستقبل، ولهذا السبب قام منشئو تقنية WebRTC بإدراجه في النطاق الإلزامي لمعايير الصوت المدعومة.

برامج ترميز الفيديو

استغرقت مسألة اختيار برنامج ترميز الفيديو لـ WebRTC المطورين عدة سنوات، وفي النهاية قرروا استخدام H.264 وVP8. تدعم جميع المتصفحات الحديثة تقريبًا كلا برنامجي الترميز. تحتاج خوادم مؤتمرات الفيديو فقط إلى دعم واحد للعمل مع WebRTC.

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

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

تعمل Google وMozilla بنشاط على الترويج لبرنامج الترميز VP8، وتعمل Microsoft وApple وCisco بنشاط على الترويج لـ H.264 (لضمان التوافق مع أنظمة مؤتمرات الفيديو التقليدية). وهنا تظهر مشكلة كبيرة جدًا لمطوري حلول WebRTC السحابية، لأنه إذا كان جميع المشاركين في مؤتمر يستخدمون نفس المتصفح، فيكفي خلط المؤتمر مرة واحدة ببرنامج ترميز واحد، وإذا كانت المتصفحات مختلفة وSafari/Edge من بينها، ثم سيتعين على المؤتمر أن يتم ترميزه مرتين برامج الترميز المختلفة، والتي سوف تضاعف متطلبات النظامإلى خادم الوسائط، ونتيجة لذلك، تكلفة الاشتراك في خدمات WebRTC.

واجهة برمجة تطبيقات WebRTC

تعتمد تقنية WebRTC على ثلاث واجهات برمجة تطبيقات رئيسية:

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

قبل الوصول إلى ميكروفون المستخدم وكاميراه، يطلب المتصفح الإذن للقيام بذلك. في جوجل كروميمكنك تكوين الوصول مسبقًا في قسم "الإعدادات"؛ في Opera وFirefox، يتم تحديد الأجهزة مباشرة في وقت الوصول، من القائمة المنسدلة. سيظهر طلب الإذن دائمًا عند استخدام بروتوكول HTTP ومرة ​​واحدة فقط في حالة استخدام HTTPS:

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

• يرسل المشارك المبدئي إلى المشارك الثاني Offer-SDP (بنية البيانات مع خصائص دفق الوسائط الذي سيرسله)؛
• يقوم المشارك الثاني بإنشاء "استجابة" - Answer-SDP ويرسلها إلى البادئ؛
• ثم يتم تنظيم تبادل لمرشحي ICE بين المشاركين، في حالة اكتشاف أي منهم (إذا كان المشاركون خلف NAT أو جدران الحماية).

بعد الانتهاء بنجاح من هذا التبادل، يتم تنظيم النقل المباشر لتدفقات الوسائط (الصوت والفيديو) بين المشاركين.

قناة RTCData. ظهر دعم بروتوكول قناة البيانات في المتصفحات مؤخرًا نسبيًا، لذلك لا يمكن أخذ واجهة برمجة التطبيقات هذه بعين الاعتبار إلا في حالات استخدام WebRTC في المتصفحات موزيلا فايرفوكس 22+ وجوجل كروم 26+. بمساعدتها، يمكن للمشاركين التبادل رسائل نصيةفي المتصفح.

الاتصال عبر WebRTC

متصفحات سطح المكتب المدعومة

• Google Chrome (17+) وجميع المتصفحات المستندة إلى محرك Chromium؛
• موزيلا فايرفوكس (18+)؛
• أوبرا (12+)؛
• سفاري (11+)؛

متصفحات الجوال المدعومة لنظام Android

• جوجل كروم (28+)؛
• موزيلا فايرفوكس (24+)؛
• أوبرا موبايل (12+)؛
• سفاري (11+).

WebRTC، ومايكروسوفت، وإنترنت إكسبلورر

لفترة طويلة جدًا، ظلت Microsoft صامتة بشأن دعم WebRTC في Internet Explorer ومتصفح Edge الجديد. لا يحب رجال ريدموند حقًا وضع التقنيات التي لا يتحكمون فيها في أيدي المستخدمين، فهذه هي سياستهم. ولكن تدريجيا انتقل الأمر من نقطة ميتة، لأنه ولم يعد من الممكن تجاهل WebRTC، وتم الإعلان عن مشروع ORTC، وهو مشتق من معيار WebRTC.

وفقًا للمطورين، يعد ORTC امتدادًا لمعيار WebRTC مع مجموعة محسنة من واجهات برمجة التطبيقات المستندة إلى JavaScript وHTML5، والتي، عند ترجمتها إلى لغة عادية، تعني أن كل شيء سيكون كما هو، فقط Microsoft، وليس Google، هي التي ستتحكم في المعيار وتطورها. تم توسيع مجموعة برامج الترميز بدعم H.264 وبعض برامج الترميز الصوتية من سلسلة G.7ХХ، المستخدمة في أنظمة مؤتمرات الفيديو والهواتف. قد يكون هناك دعم مدمج لـ RDP (لنقل المحتوى) والمراسلة. وبالمناسبة، فإن مستخدمي Internet Explorer لم يحالفهم الحظ؛ ولن يتوفر دعم ORTC إلا في Edge. وبالطبع، تتفاعل هذه المجموعة من البروتوكولات وبرامج الترميز بسهولة مع Skype for Business، مما يفتح المزيد من تطبيقات الأعمال لـ WebRTC.

الغرض من هذه المقالة هو استخدام نموذج تجريبي للدردشة المرئية من نظير إلى نظير (دردشة فيديو p2p) للتعرف على هيكلها ومبدأ التشغيل. لهذا الغرض، سوف نستخدم العرض التوضيحي للدردشة المرئية من نظير إلى نظير متعدد المستخدمين webrtc.io-demo. يمكن تنزيله من الرابط: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

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

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

أرز. 1

على النحو التالي من الهيكل (الشكل 1)، تتكون الدردشة المرئية من نظير إلى نظير من نصوص العميل script.js والخادم server.js النصية، والتي يتم تنفيذها بلغة برمجة JavaScript. البرنامج النصي (المكتبة) webrtc.io.js (CLIENT) - يوفر تنظيم الاتصالات في الوقت الفعلي بين المتصفحات باستخدام نظام نظير إلى نظير: "client-client" وwebrtc.io.js (CLIENT) وwebrtc. io.js (الخادم)، باستخدام بروتوكول WebSocket، فإنها توفر اتصالاً مزدوجًا بين المتصفح وخادم الويب باستخدام بنية خادم العميل.

يتم تضمين البرنامج النصي webrtc.io.js (SERVER) في مكتبة webrtc.io ويقع في الدليلNode_modules\webrtc.io\lib. يتم تنفيذ واجهة دردشة الفيديو Index.html في HTML5 وCSS3. يمكن عرض محتويات ملفات تطبيق webrtc_demo باستخدام أحد برامج تحرير html، على سبيل المثال "Notepad++".

سوف نتحقق من مبدأ عمل الدردشة المرئية نظام الملفاتالكمبيوتر. لتشغيل الخادم (server.js) على جهاز كمبيوتر، تحتاج إلى تثبيت بيئة تشغيل Node.js. يسمح لك Node.js بتشغيل كود JavaScript خارج المتصفح. يمكنك تنزيل Node.js من الرابط: http://nodejs.org/ (الإصدار v0.10.13 اعتبارًا من 15/07/13). في الصفحة الرئيسية لموقع Node.org، انقر فوق زر التنزيل وانتقل إلى http://nodejs.org/download/. بالنسبة لمستخدمي Windows، قم أولاً بتنزيل win.installer (.msi)، ثم قم بتشغيل win.installer (.msi) على جهاز الكمبيوتر، ثم قم بتثبيت Nodejs و"npm package manager" في دليل ملفات البرامج.

أرز. 2

وبالتالي، يتكون Node.js من بيئة لتطوير وتشغيل تعليمات JavaScript البرمجية، بالإضافة إلى مجموعة من الوحدات الداخلية التي يمكن تثبيتها باستخدام المدير أو مدير الحزم npm.

لتثبيت الوحدات يجب عليك سطر الأوامرمن دليل التطبيق (على سبيل المثال، "webrtc_demo") قم بتشغيل الأمر: تثبيت npm Module_name. أثناء تثبيت الوحدات، يقوم مدير npm بإنشاء مجلد عقدة_وحدات في الدليل الذي تم إجراء التثبيت منه. أثناء التشغيل، تقوم Nodejs تلقائيًا بتوصيل الوحدات النمطية من دليل Node_modules.

لذلك، بعد تثبيت Node.js، افتح سطر الأوامر وقم بتحديث الوحدة النمطية Express في مجلد Node_modules في دليل webrtc_demo باستخدام مدير الحزم npm:

C:\webrtc_demo>npm تثبيت سريع

الوحدة السريعة هي إطار ويب لـnode.js أو منصة ويب لتطوير التطبيقات. للحصول على وصول عالمي إلى Express، يمكنك تثبيته على النحو التالي: تثبيت npm -g السريع.

ثم قم بتحديث وحدة webrtc.io:

C:\webrtc_demo>npm تثبيت webrtc.io

ثم في سطر الأوامر نقوم بتشغيل الخادم: server.js:

C:\webrtc_demo>عقدة server.js

أرز. 3

هذا كل شيء، الخادم يعمل بنجاح (الشكل 3). الآن، باستخدام متصفح الويب، يمكنك الاتصال بالخادم عن طريق عنوان IP وتحميل صفحة الويب Index.html، والتي سيستخرج متصفح الويب منها رمز البرنامج النصي للعميل - script.js ورمز البرنامج النصي webrtc.io.js، و تنفيذها. لتشغيل دردشة فيديو نظير إلى نظير (لتأسيس اتصال بين متصفحين)، تحتاج إلى الاتصال بخادم الإشارة الذي يعمل على Node.js من متصفحين يدعمان webrtc.

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

أرز. 4

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

أرز. 5

تجدر الإشارة إلى ذلك. الخادم هو خادم إشارات، وهو مصمم بشكل أساسي لإنشاء اتصالات بين متصفحات المستخدم. يتم استخدام Node.js لتشغيل البرنامج النصي للخادم server.js الذي يوفر إشارات WebRTC.