كيف يعمل JS: اتصالات WebRTC و P2P

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

مراجعة

ما هو WebRTC؟ بادئ ذي بدء ، من الجدير بالذكر أن الاختصار RTC هو اختصار لـ Real Time Communication (التواصل في الوقت الحقيقي). هذا وحده يعطي الكثير من المعلومات حول هذه التكنولوجيا.

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

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

• اتصالات P2P.
• جدران الحماية وتكنولوجيا NAT Traversal.
• التشوير والجلسات والبروتوكولات.
• واجهة برمجة تطبيقات WebRTC

اتصالات P2P

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

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

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

جدران الحماية وبروتوكول اجتياز NAT

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

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

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

بالنظر إلى أن NAT تشارك في عملية تفاعل نظامك مع العالم الخارجي ، يحتاج متصفحك ، من أجل إنشاء اتصال WebRTC ، إلى معرفة عنوان IP للكمبيوتر الذي يعمل عليه المتصفح الذي تريد الاتصال به.

هذا هو المكان الذي تدخل فيه خوادم STUN (Session Traversal Utilities for NAT) و TURN (Traversal Using Relays around NAT) إلى المشهد. لضمان تشغيل تقنية WebRTC ، يتم أولاً تقديم طلب إلى خادم STUN ، من أجل معرفة عنوان IP الخارجي الخاص بك. في الواقع ، نحن نتحدث عن طلب مقدم إلى خادم بعيد من أجل معرفة عنوان IP الذي يتلقى الخادم هذا الطلب. بعد تلقي طلب مماثل ، سيرسل الخادم البعيد استجابة تحتوي على عنوان IP المرئي له.

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

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

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

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

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

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

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

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

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

هنا رسم تخطيطي مع MDN يوضح عملية تبادل البيانات أعلاه.

عملية تبادل البيانات اللازمة لإنشاء اتصال P2P

إنشاء اتصال

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

هذه "القنوات" غير معروفة ولا يمكن الوصول إليها من العالم الخارجي ؛ مطلوب معرف فريد للوصول إليها.

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

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

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

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

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

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

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

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

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

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

لنتحدث عن واجهات برمجة التطبيقات هذه.

التقاط وسائط API وتيارات

واجهة برمجة تطبيقات Media Capture and Streams ، والتي يشار إليها غالبًا باسم Media Stream API أو Stream API ، هي واجهة برمجة تطبيقات تدعم العمل مع تدفقات بيانات الصوت والفيديو ، وطرق العمل معها. باستخدام واجهة برمجة التطبيقات هذه ، يمكنك تعيين قيود تتعلق بأنواع البيانات ، وهنا توجد عمليات استدعاء لاستكمال العمليات بنجاح وغير ناجح والتي يتم استخدامها عند استخدام آليات غير متزامنة للعمل مع البيانات ، والأحداث التي يتم رفعها أثناء التشغيل.

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

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

يمكنك الوصول إلى MediaDevice singleton من خلال كائن navigator :

 navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { /*   */ }) .catch(function(err) { /*   */ }); 

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

بدءا من الإصدار 25، المتصفحات على أساس الكروم، يسمح لك لنقل البيانات الصوتية من getUserMedia() عناصر الصوت أو الفيديو (ومع ذلك، علما بأن الافتراضية سوف عناصر الوسائط تعطيل).

يمكن أيضًا استخدام طريقة getUserMedia() كعقدة إدخال لـ Web Audio API :

 function gotStream(stream) {   window.AudioContext = window.AudioContext || window.webkitAudioContext;   var audioContext = new AudioContext();   //  AudioNode     var mediaStreamSource = audioContext.createMediaStreamSource(stream);   //       ,    ,   //       !   mediaStreamSource.connect(audioContext.destination); } navigator.getUserMedia({audio:true}, gotStream); 

القيود المتعلقة بحماية المعلومات الشخصية

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

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

واجهة RTCPeerConnection

واجهة RTCPeerConnection هي اتصال WebRTC بين الكمبيوتر المحلي والنظير البعيد. يوفر طرقًا للاتصال بنظام بعيد ، لدعم الاتصال ومراقبة حالته ، ولإغلاق الاتصال بعد عدم الحاجة إليه.

هنا رسم تخطيطي لهندسة WebRTC يوضح دور RTCPeerConnection.


دور RTCPeerConnection

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

• إخفاء فقدان الحزمة.
• إلغاء الصدى.
• التكيف مع عرض النطاق الترددي.
• التخزين المؤقت الديناميكي للقضاء على التشويه.
• التحكم التلقائي في مستوى الصوت.
• الحد من الضوضاء وقمعها.
• "تنظيف" الصورة.

RTCDataChannel API

كما هو الحال مع بيانات الصوت والفيديو ، يدعم WebRTC الإرسال الفوري لأنواع أخرى من البيانات. تسمح لك RTCDataChannel API بتنظيم تبادل P2P للبيانات العشوائية.

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

• ألعاب
• دردشات نصية في الوقت الفعلي.
• نقل الملفات.
• تنظيم الشبكات اللامركزية.

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

• العمل الفعال مع الجلسات باستخدام RTCPeerConnection.
• دعم العديد من قنوات الاتصال المستخدمة في وقت واحد مع تحديد الأولويات.
• دعم طرق موثوقة وغير موثوق بها لتسليم الرسالة.
• إدارة الأمن المدمجة (DTLS) والازدحام.

الصيغة هنا مشابهة لتلك المستخدمة عند العمل مع تقنية WebSocket. يتم تطبيق طريقة send() وحدث message هنا:

 var peerConnection = new webkitRTCPeerConnection(servers,   {optional: [{RtpDataChannels: true}]} ); peerConnection.ondatachannel = function(event) {   receiveChannel = event.channel;   receiveChannel.onmessage = function(event){       document.querySelector("#receiver").innerHTML = event.data;   }; }; sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){   var data = document.querySelector("textarea#send").value;   sendChannel.send(data); } 

WebRTC في العالم الحقيقي

في العالم الحقيقي ، يتطلب اتصال WebRTC خوادم. الأنظمة ليست معقدة للغاية ؛ وبفضلها ، يتم تنفيذ التسلسل التالي من الإجراءات:

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

وبعبارة أخرى ، يحتاج WebRTC إلى أربعة أنواع من وظائف الخادم:

• وسيلة لاكتشاف المستخدمين وتنظيم تفاعلهم.
• التشوير.
• تجاوز NAT والجدران النارية.
• تُستخدم خوادم الترحيل عندما يتعذر إنشاء اتصال P2P.

يتم استخدام بروتوكول STUN وملحق TURN الخاص به من قبل ICE لتمكين RTCPeerConnection للعمل مع آليات تجاوز NAT والتعامل مع الصعوبات الأخرى التي تتم مواجهتها عند نقل البيانات عبر شبكة.

كما ذكرنا من قبل ، فإن ICE هو بروتوكول لتوصيل النظراء ، مثل اثنين من عملاء محادثة الفيديو. في بداية جلسة الاتصال ، يحاول ICE توصيل النظراء مباشرة ، بأقل تأخير ممكن ، عبر UDP. أثناء هذه العملية ، يكون لخوادم STUN مهمة واحدة: السماح للنظراء وراء NAT بالتعرف على عنوانها العام ومنفذها. ألق نظرة على هذه القائمة من خوادم STUN المتاحة (لدى Google أيضًا مثل هذه الخوادم).


خوادم STUN

كشف مرشح ICE

إذا تعذر إنشاء اتصال UDP ، فستحاول ICE إنشاء اتصال TCP: أولاً عبر HTTP ، ثم عبر HTTPS. إذا تعذر إنشاء اتصال مباشر - على وجه الخصوص ، بسبب عدم القدرة على تجاوز NATs والجدران النارية للشركات ، تستخدم ICE وسيطًا (مرحلًا) في شكل خادم TURN. بمعنى آخر ، سيحاول ICE أولاً استخدام STUN مع UDP للاتصال المباشر للأقران ، وإذا لم يفلح ذلك ، فسيستخدم خيارًا احتياطيًا مع مستأجر في شكل خادم TURN. يشير مصطلح "بحث المرشح" إلى عملية البحث عن واجهات الشبكة والمنافذ.


إيجاد واجهات ومنافذ شبكة مناسبة

الأمان

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

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

لدى WebRTC العديد من الآليات المصممة للتعامل مع هذه التهديدات:

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

الملخص

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

أعزائي القراء! هل تستخدم تقنية WebRTC في مشاريعك؟