ICE Candidate: ما هو، أنواع المرشحين وكيف يعمل

ما هو ICE Candidate؟

ICE Candidate (Interactive Connectivity Establishment Candidate) هو وحدة أساسية في عملية إنشاء اتصال P2P عبر بروتوكول WebRTC. يمثل زوجًا من عنوان IP + منفذ يمكن استخدامه لنقل البيانات بين نظيرين. يحتوي كل مرشح على معلومات حول بروتوكول النقل (UDP، TCP)، نوع الاتصال والأولوية.

يتم تكوين ICE Candidate على كل جهاز بشكل منفرد. يجمع الجهاز جميع واجهات الشبكة المتاحة، يطلب عنوانًا خارجيًا عبر خادم STUN ويضيف عنوان ترحيل من خادم TURN. تُرسل قائمة المرشحين الناتجة إلى النظير البعيد عبر قناة إشارة بتنسيق SDP (Session Description Protocol).

وفقًا للمواصفات RFC 8445 (IETF، 2018)، يستخدم ICE آلية الأزواج المعينة: بعد جمع جميع المرشحين، يتم اختبارهم ثنائيًا عبر طلبات STUN. الزوج الذي يجتاز الفحص أولاً يتم تعيينه واستخدامه لنقل الوسائط. تبقى الأزواج المتبقية في احتياط في حال انقطاع الاتصال.

دور ICE في مكونة WebRTC

WebRTC هو معيار مفتوح للاتصالات P2P، لكن الاتصال المباشر بين الأجهزة غالبًا ما يكون مستحيلاً بسبب NAT (Network Address Translation) وجدران الحماية. يحل ICE Candidate هذه المشكلة بتقديم عدة مسارات اتصال بديلة. بروتوكول ICE (Interactive Connectivity Establishment) هو مكون إجباري في WebRTC وموصوف في مواصفات W3C WebRTC (2025).

يستخدم العديد من مطوري تطبيقات الهواتف المحمولة مكتبات WebRTC مثل Google WebRTC (لنظام Android) والأغلفة الأصلية لنظام iOS. في كل منها، تتم إدارة عملية ICE تلقائيًا، ولكن فهم أنواع المرشحين يسمح للمطور بتكوين بنية تحتية الخادم وتحسين جودة الاتصال.

تنسيق SDP مع مرشحي ICE

يتم نقل ICE Candidate ضمن رسالة SDP كسمات a=candidate. يحتوي كل سطر على foundation، component ID، بروتوكول نقل، أولوية، عنوان IP، منفذ ونوع المرشح. في الأسفل مثال على قطعة SDP بثلاثة مرشحين من أنواع مختلفة:

// نموذج SDP مع مرشحي ICE
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

يحدد حقل priority ترتيب اختبار المرشحين. كلما كانت الأولوية أعلى، كلما تم فحص المرشح في وقت أسبق. دائمًا ما تكون للمرشحين host أعلى أولوية، وللمرشحين relay أدنى أولوية.

أنواع مرشحي ICE

تحدد مواصفات RFC 8445 أربعة أنواع من مرشحي ICE، يتوافق كل منها مع طريقة محددة للوصول إلى نظير بعيد. يؤثر نوع المرشح على أولويته، وقت إنشاء الاتصال ومتطلبات بنية الخادم.

مرشحو host

يتكون مرشح host من عنوان IP لواجهة الشبكة المحلية للجهاز. إذا كان الجهاز على نفس الشبكة المحلية مع النظير، فإن مرشح host يوفر اتصالًا مباشرًا بأقل زمن استجابة. بالنسبة للأجهزة المحمولة، يتم توليد مرشحي host لواجهة WiFi، اتصال LTE/5G الخلوي، وعند الضرورة — لأنفاق VPN.

لمرشحي host أعلى أولوية (2130706431 لبروتوكول UDP) ويتم اختبارهم أولاً. إذا كان كلا النظيرين خلف NAT، فستكون عناوين مرشحي host خاصة (192.168.x.x، 10.x.x.x) ولن يكون الاتصال المباشر عبرهم ممكنًا. ينتقل ICE ثم إلى اختبار مرشحي srflx و relay.

مرشحو SRFLX و PRFLX

مرشح SRFLX (Server Reflexive) هو عنوان IP خارجي ومنفذ تم الحصول عليهما من خادم STUN. عندما يرسل الجهاز طلب STUN، يرى الخادم عنوانه العام بعد NAT ويعيده. يسمح هذا المرشح بإنشاء اتصال مباشر بين نظيرين خلف NATًا مختلفين، إذا كانت أجهزة NAT الخاصة بهما تدعم Hairpinning.

مرشح PRFLX (Peer Reflexive) يتم اكتشافه ديناميكيًا عندما يصل طلب STUN من أحد النظيرين إلى عنوان غير متوقع. يحدث هذا النوع عندما يرسل كلا النظيرين طلبات في نفس الوقت وينشئ NAT ارتباطًا مؤقتًا. لمرشح PRFLX أولوية أعلى من srflx ولكن أقل من host.

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

مرشحو Relay عبر TURN

مرشح relay هو عنوان على خادم TURN يتم عبره ترحيل الحركة من نظير إلى آخر. يستخدم هذا النوع كخيار احتياطي عندما تكون الاتصال المباشر P2P غير ممكن (NAT متماثل، جدار حماية مؤسسي). يضيف قناة relay زمن استجابة ويزيد حمل الخادم، لذا في التكوينات المثلى، يستخدم خادم TURN فقط لنسبة 10–15% من جميع الجلسات.

تطبيقات شائعة لخوادم TURN: coturn (مصدر مفتوح)، Twilio Network Traversal، Metered TURN. يؤثر اختيار مورد TURN على جودة اتصال الوسائط في تطبيقات الهواتف المحمولة — يجب أن يكون الخادم قريبًا جغرافيًا من المستخدمين لتقليل زمن الاستجابة الإضافي.

كيف تعمل عملية ICE

عملية ICE هي بروتوكول متعدد المراحل يضمن إنشاء اتصال P2P موثوق في ظروف عدم اليقين بشأن توبولوجيا الشبكة. تم وصف الخوارزمية في RFC 8445 وتشمل أربع مراحل إجبارية: جمع المرشحين، ترتيبهم، اختبارهم وتعيينهم.

المرحلة 1: جمع المرشحين

يجمع كل جهاز جميع عناوين الشبكة المتاحة. للقيام بذلك، يقوم محرك WebRTC بتعداد الواجهات المحلية (host)، يرسل طلبًا إلى خادم STUN (srflx) ويطلب عنوان ترحيل من خادم TURN. في نفس الوقت، يقد يكتشف الجهاز مرشح prflx إذا تلقى طلب STUN واردًا من نظير.

في تطوير التطبيقات المحمولة، هذه المرحلة حاسمة لـ وقت إنشاء الاتصال. على iOS و Android، يمكن أن يستغرق جمع المرشحين من 200 مس إلى ثانيتين حسب سرعة الشبكة، توفر خوادم STUN/TURN وعدد واجهات الشبكة النشطة.

المرحلة 2: تكوين الأزواج والترتيب

بعد استلام قائمة المرشحين من النظير البعيد عبر قناة الإشارة، يقوم محرك ICE المحلي بتكوين جميع أزواج المرشحين الممكنة (محلي + بعيد). يتلقى كل زوج أولوية وفقًا لصيغة RFC 8445، مع مراعاة أولويات كلا المرشحين والاتجاه (وارد/صادر).

يتم ترتيب الأزواج بتنازل الأولوية. يتم اختبار أفضل الأزواج أولاً. يضمن الخوارزمية أن يتم فحص زوج host-host قبل host-srflx، host-relay أو relay-relay، مما يقلل تأخير الاتصال في تكوينات الشبكة البسيطة.

المرحلة 3: الاختبار والتعيين

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

يمكن أن يستغرق عملية الاختبار حتى عدة ثوان مع عدد كبير من المرشحين. يستخدم WebRTC مؤقتات: لأزواج host المؤقت عدواني (20 مس)، لأزواج relay — أكثر تحفظًا (200 مس). يمكن لمطوري تطبيقات الهواتف المحمولة تسريع الاتصال عن طريق تحديد عدد خوادم ICE أو تكوين iceTransportPolicy.

إعادة تشغيل ICE

إعادة تشغيل ICE هي إعادة تشغيل عملية ICE دون إعادة إنشاء RTCPeerConnection بأكملها. هي ضرورية عند تغيير الشبكة، فقدان الاتصال أو التبديل بين WiFi والشبكة المحمولة. أثناء إعادة التشغيل، يتم تجاهل جميع المرشحين الحاليين وتبدأ العملية من جديد مع توليد ufrag و pwd جديدين.

في تطوير iOS، يتم استدعاء إعادة تشغيل ICE باستخدام الميثود restartIce() على RTCPeerConnection. في Android، يتم استخدام ميثود مماثل في الفئة PeerConnection من Google WebRTC. يعد التعامل الصحيح مع إعادة تشغيل ICE متطلبًا حاسمًا للتطبيقات التي تعمل على الأجهزة المحمولة باتصالات شبكة غير مستقرة.

خوادم STUN و TURN في ICE

STUN (Session Traversal Utilities for NAT) و TURN (Traversal Using Relays around NAT) هما مكونان رئيسيان للخادم بدونهما لا يمكن ICE Candidate ضمان اتصال ناجح في ظروف الإنترنت الحقيقية. يؤثر تكوينهما الصحيح مباشرة على جودة المكالمة في تطبيقات الهواتف المحمولة.

STUN: اكتشاف العنوان الخارجي

يسمح خادم STUN للجهاز باكتشاف عنوان IP العام والمنفذ الذي خصصه NAT للاتصال الصادر. تم تعريف بروتوكول STUN في RFC 8489 ويعمل عبر UDP على المنفذ 3478، ويدعم أيضًا TCP. توفر Google خوادم STUN عامة (stun.l.google.com:19302) يمكن استخدامها مجانًا.

في تطوير التطبيقات المحمولة، طلب STUN هو عملية خفيفة تستغرق 50–200 مس. ولكن بعض الشبكات المؤسسية والمحمولة تحجب حركة UDP، مما يجبر ICE على استخدام TCP لاتصالات STUN أو الانتقال مباشرة إلى TURN.

TURN: ترحيل الحركة

خادم TURN هو مرحل حركة الوسائط. عندما يكون الاتصال المباشر P2P غير ممكن (NAT متماثل، جدار حماية)، يرسل الجهاز البيانات إلى TURN، الذي يعيد توجيهها إلى النظير الآخر. TURN هو آلية موثوقة ولكنها مكلفة: تضيف زمن استجابة (30–100 مس) وتتطلب عرض حزم الخادم يساوي مجموع جميع جلسات الوسائط.

وفقًا لـ WebRTC Stats Report (2025)، حوالي 8–15% من جلسات WebRTC في الشبكات المحمولة تتطلب TURN. لتحسين تكاليف حركة TURN، يستخدم المطورون اختبار الاتصال الأولي وينشطون قناة TURN فقط عند فشل P2P.

اختيار STUN/TURN لتطبيق محمول

عند اختيار البنية التحتية لـ ICE في مشروع محمول، تؤخذ العوامل التالية في الاعتبار: الموقع الجغرافي للخوادم لتقليل زمن الاستجابة، دعم UDP و TCP، تكلفة حركة TURN و SLA. الحلول الشائعة تشمل: coturn للاستضافة الذاتية، Twilio، Agora و LiveKit للاستخدام السحابي.

ICE Candidate في تطوير التطبيقات المحمولة

بالنسبة لمطوري التطبيقات المحمولة، يتجاوز فهم ICE Candidate النظرية — إنه ضرورة عملية عند بناء تطبيقات بمكالمات صوتية وفيديو. توفر منصات iOS و Android API أصلية لـ WebRTC تؤتمت التعامل مع ICE، ولكن المطور مسؤول عن تكوين خوادم ICE ومعالجة أحداث تغيير الشبكة.

تكوين ICE على iOS

على iOS، WebRTC متاح عبر إطار WebRTC.framework أو مكتبة GoogleWebRTC عبر CocoaPods. تتم تكوين خوادم ICE عبر مصفوفة من RTCIceServer في RTCConfiguration:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

بعد إنشاء RTCPeerConnection واستدعاء offer() أو answer()، يقوم المحرك بجمع مرشحي ICE تلقائيًا. يبلغ الحدث iceGatheringStateChange عن تغيرات حالة الجمع، بينما يبلغ iceConnectionState عن حالة الاتصال.

تكوين ICE على Android

يستخدم Android نفس مكتبة Google WebRTC. تتم تعيين خوادم ICE عبر PeerConnection.RTCConfiguration. يمكن للمطور إدارة سياسة ICE عبر iceTransportsType — يستخدم وضع relay TURN فقط بالقوة، مما يزيد من الموثوقية ولكن يضيف زمن استجابة:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

يؤثر المعلم bundlePolicy على عدد مرشحي ICE — يدمج وضع MAXBUNDLE جميع تدفقات الوسائط في نقل واحد، مما يقلل العدد الإجمالي للمرشحين ويسرع الاتصال.

معالجة أحداث ICE في التطبيقات المحمولة

تشمل أحداث ICE الرئيسية التي يجب على المطور معالجتها: حالة اتصال ICE، حالة جمع ICE واكتشاف مرشح جديد. بعد أن يكمل ICE الجمع والاختبار، تنتقل حالته إلى connected أو completed.

في الشبكات المحمولة، كثيراً ما تحدث تبديلات بين WiFi والاتصال الخلوي. عندما تتغير الشبكة، يجب على ICE إجراء إعادة تشغيل، وإلا فإن دفق الوسائط ينقطع. يقوم المطورون بتنفيذ مراقبة NetworkManager (iOS) أو ConnectivityManager (Android) لاستدعاء restartIce() تلقائيًا.

تشمل التطبيق الناجح لـ ICE في تطبيق محمول: اختيار خوادم STUN/TURN موثوقة، معالجة صحيحة لإعادة تشغيل ICE عند تغيير الشبكة، تكوين iceConnectionState لعرض حالة الاتصال في واجهة المستخدم ومراقبة الإحصاءات عبر RTCStatsReport.