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 از مکانیزم nominated pairs استفاده می‌کند: پس از جمع‌آوری همه کاندیداها، آزمایش جفتی آنها از طریق درخواست‌های STUN انجام می‌شود. اولین جفتی که آزمایش را با موفقیت پشت سر بگذارد، nominated (منصوب) اعلام می‌شود و برای انتقال چندرسانه‌ای استفاده می‌شود. جفت‌های دیگر در صورت قطع اتصال در ذخیره باقی می‌مانند.

نقش 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 restart نامیده می‌شود و نیاز به ارسال مجدد SDP جدید دارد.

کاندیداهای Relay از طریق TURN

کاندیدای relay — آدرسی در سرور TURN است که ترافیک از طریق آن از یک همتا به همتای دیگر بازپخش می‌شود. این نوع به عنوان گزینه پشتیبان زمانی استفاده می‌شود که اتصال مستقیم P2P غیرممکن باشد (NAT متقارن، فایروال شرکتی). کانال رله تأخیر اضافه می‌کند و بار سرور را افزایش می‌دهد، بنابراین در تنظیمات بهینه، سرور TURN تنها برای 10–15٪ از تمام جلسات استفاده می‌شود.

پیاده‌سازی‌های محبوب سرورهای TURN: coturn (منبع باز)، Twilio Network Traversal، Metered TURN. انتخاب ارائه‌دهنده TURN بر کیفیت اتصال رسانه‌ای در برنامه‌های موبایل تأثیر می‌گذارد — سرور باید از نظر جغرافیایی نزدیک به کاربران قرار گیرد تا تأخیر اضافی به حداقل برسد.

فرآیند ICE چگونه کار می‌کند

فرآیند ICE — یک پروتکل چندمرحله‌ای است که برقراری اتصال P2P قابل اعتماد را در شرایط عدم قطعیت توپولوژی شبکه تضمین می‌کند. الگوریتم در RFC 8445 توضیح داده شده است و شامل چهار مرحله اجباری است: جمع‌آوری کاندیداها، مرتب‌سازی آنها، آزمایش و نامزدی.

مرحله 1: جمع‌آوری کاندیداها

هر دستگاه تمام آدرس‌های شبکه موجود را جمع‌آوری می‌کند. برای این کار، موتور WebRTC رابط‌های محلی را شمارش می‌کند (host)، درخواستی به سرور STUN ارسال می‌کند (srflx) و آدرس رله را از سرور TURN درخواست می‌کند (relay). همزمان، دستگاه ممکن است کاندیدای prflx را شناسایی کند اگر درخواست STUN ورودی از همتا دریافت کند.

در توسعه موبایل، این مرحله برای زمان برقراری اتصال حیاتی است. در iOS و Android، جمع‌آوری کاندیداها بسته به سرعت شبکه، در دسترس بودن سرورهای STUN/TURN و تعداد رابط‌های شبکه فعال می‌تواند از 200 میلی‌ثانیه تا 2 ثانیه طول بکشد.

مرحله 2: تشکیل جفت‌ها و مرتب‌سازی

پس از دریافت لیست کاندیداها از همتای راه دور از طریق کانال سیگنالینگ، موتور ICE محلی تمام جفت کاندیداهای ممکن (محلی + راه دور) را تشکیل می‌دهد. هر جفت اولویتی بر اساس فرمول RFC 8445 دریافت می‌کند که اولویت‌های هر دو کاندیدا و جهت (incoming/outgoing) را در نظر می‌گیرد.

جفت‌ها به ترتیب نزولی اولویت مرتب می‌شوند. بهترین جفت‌ها ابتدا آزمایش می‌شوند. الگوریتم تضمین می‌کند که جفت host-host زودتر از host-srflx، host-relay یا relay-relay بررسی می‌شود و تأخیر اتصال را در پیکربندی‌های ساده شبکه به حداقل می‌رساند.

مرحله 3: آزمایش و نامزدی

ICE برای هر جفت کاندیدا درخواست‌های STUN-binding ارسال می‌کند. اگر پاسخ STUN دریافت شود — جفت معتبر است. اولین جفت معتبر به عنوان اصلی نامزد (nominated) می‌شود. موتور WebRTC شروع به انتقال رسانه از طریق این جفت می‌کند و جفت‌های دیگر برای بررسی در صورت خرابی اصلی ادامه می‌یابند.

فرآیند آزمایش می‌تواند با تعداد زیادی کاندیدا تا چند ثانیه طول بکشد. WebRTC از تایمرها استفاده می‌کند: برای جفت‌های host تایمر تهاجمی (20 میلی‌ثانیه)، برای relay — محافظه‌کارانه‌تر (200 میلی‌ثانیه). توسعه‌دهندگان برنامه‌های موبایل می‌توانند با محدود کردن تعداد سرورهای ICE یا پیکربندی iceTransportPolicy اتصال را تسریع کنند.

ICE Restart

ICE restart — راه‌اندازی مجدد فرآیند ICE بدون ایجاد مجدد کل RTCPeerConnection است. در تغییر شبکه، قطع اتصال یا جابجایی بین WiFi و شبکه موبایل ضروری است. هنگام restart، همه کاندیداهای فعلی بازنشانی می‌شوند و فرآیند با تولید ufrag و pwd جدید از نو آغاز می‌شود.

در توسعه iOS، ICE restart با متد restartIce() روی RTCPeerConnection فراخوانی می‌شود. در Android از متد مشابه در کلاس PeerConnection از Google WebRTC استفاده می‌شود. مدیریت صحیح ICE restart — نیاز حیاتی برای برنامه‌هایی که روی دستگاه‌های موبایل با اتصال شبکه ناپایدار کار می‌کنند.

سرورهای 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 (2025)، حدود 8–15٪ از جلسات WebRTC در شبکه‌های موبایل به TURN نیاز دارند. برای بهینه‌سازی هزینه‌های ترافیک TURN، توسعه‌دهندگان از آزمایش اولیه اتصال استفاده می‌کنند و تنها در صورت شکست P2P کانال TURN را فعال می‌کنند.

انتخاب 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 connection state)، تغییر وضعیت جمع‌آوری (ICE gathering state) و کشف کاندیدای جدید. پس از اتمام جمع‌آوری و آزمایش ICE، وضعیت آن به connected یا completed تغییر می‌کند.

در شبکه‌های موبایل، جابجایی‌های مکرر بین WiFi و ارتباط سلولی رخ می‌دهد. هنگام تغییر شبکه، ICE باید restart کند، در غیر این صورت جریان رسانه قطع می‌شود. توسعه‌دهندگان نظارت NetworkManager (iOS) یا ConnectivityManager (Android) را برای فراخوانی خودکار restartIce() پیاده‌سازی می‌کنند.

پیاده‌سازی موفق ICE در برنامه موبایل شامل: انتخاب سرورهای STUN/TURN قابل اعتماد، مدیریت صحیح ICE restart در تغییر شبکه، پیکربندی iceConnectionState برای نمایش وضعیت اتصال در UI و نظارت بر آمار از طریق RTCStatsReport است.