ICE Candidate: co to jest, typy kandydatów i jak działa

Co to jest ICE Candidate?

ICE Candidate (Interactive Connectivity Establishment Candidate) — to podstawowa jednostka w procesie nawiązywania połączenia P2P za pośrednictwem protokołu WebRTC. Stanowi parę adres IP + port, która może zostać wykorzystana do przesyłania danych między dwoma peerami. Każdy kandydat zawiera informacje o protokole transportowym (UDP, TCP), typie połączenia i priorytecie.

ICE Candidate jest tworzony na każdym urządzeniu osobno. Urządzenie zbiera wszystkie dostępne interfejsy sieciowe, pobiera adres zewnętrzny przez serwer STUN i dodaje adres relay z serwera TURN. Otrzymana lista kandydatów jest wysyłana do zdalnego peera kanałem sygnalizacyjnym w formacie SDP (Session Description Protocol).

Według specyfikacji RFC 8445 (IETF, 2018) ICE korzysta z mechanizmu nominated pairs: po zebraniu wszystkich kandydatów przeprowadzane jest ich testowanie parami za pomocą żądań STUN. Para, która jako pierwsza pomyślnie przejdzie test, zostaje ogłoszona nominated (wyznaczoną) i służy do przesyłania multimediów. Pozostałe pary pozostają w rezerwie na wypadek zerwania połączenia.

Rola ICE w stosie WebRTC

WebRTC to otwarty standard komunikacji P2P, ale bezpośrednie połączenie między urządzeniami jest często niemożliwe ze względu na NAT (Network Address Translation) i firewalle. ICE Candidate rozwiązuje ten problem, oferując kilka alternatywnych ścieżek połączenia. Protokół ICE (Interactive Connectivity Establishment) jest obowiązkowym komponentem WebRTC i został opisany w specyfikacji W3C WebRTC (2025).

Wielu twórców aplikacji mobilnych korzysta z bibliotek WebRTC, takich jak Google WebRTC (dla Androida) i natywnych nakładek dla iOS. W każdej z nich proces ICE jest zarządzany automatycznie, ale zrozumienie typów kandydatów pozwala programiście skonfigurować infrastrukturę serwerową i zoptymalizować jakość połączenia.

Format SDP z kandydatami ICE

ICE Candidate jest przesyłany w składzie komunikatu SDP jako atrybuty a=candidate. Każdy wiersz zawiera foundation, identyfikator komponentu, protokół transportowy, priorytet, adres IP, port i typ kandydata. Poniżej znajduje się przykład fragmentu SDP z trzema kandydatami różnych typów:

// Przykład SDP z kandydatami 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

Pole priority określa kolejność testowania kandydatów. Im wyższy priorytet — tym wcześniej kandydat zostanie sprawdzony. Kandydaci host zawsze mają najwyższy priorytet, a relay — najniższy.

Typy kandydatów ICE

Specyfikacja RFC 8445 definiuje cztery typy kandydatów ICE, z których każdy odpowiada określonemu sposobowi dotarcia do zdalnego peera. Typ kandydata wpływa na jego priorytet, czas nawiązania połączenia i wymagania dotyczące infrastruktury serwerowej.

Kandydaci host

Kandydat host jest tworzony z adresu IP lokalnego interfejsu sieciowego urządzenia. Jeśli urządzenie znajduje się w tej samej sieci lokalnej co peer, kandydat host zapewnia bezpośrednie połączenie z minimalnym opóźnieniem. W przypadku urządzeń mobilnych kandydaci host są generowani dla interfejsu WiFi, połączenia komórkowego LTE/5G oraz w razie potrzeby — dla tuneli VPN.

Kandydaci host mają najwyższy priorytet (2130706431 dla UDP) i są testowani jako pierwsi. Jeśli obaj peerowie znajdują się za NAT, ich kandydaci host będą adresami prywatnymi (192.168.x.x, 10.x.x.x), a bezpośrednie połączenie za ich pośrednictwem jest niemożliwe. ICE przechodzi do testowania kandydatów srflx i relay.

Kandydaci SRFLX i PRFLX

Kandydat SRFLX (Server Reflexive) to zewnętrzny adres IP i port uzyskane od serwera STUN. Gdy urządzenie wysyła żądanie STUN, serwer widzi jego publiczny adres po NAT i zwraca go z powrotem. Kandydat ten pozwala na bezpośrednie połączenie między peerami za różnymi NAT, jeśli ich urządzenia NAT obsługują Hairpinning.

Kandydat PRFLX (Peer Reflexive) jest wykrywany dynamicznie, gdy żądanie STUN od jednego peera dociera na nieoczekiwany adres. Ten typ powstaje, gdy obaj peerowie wysyłają żądania jednocześnie, a NAT tworzy tymczasowe wiązanie. Kandydat PRFLX ma wyższy priorytet niż srflx, ale niższy niż host.

W aplikacjach mobilnych kandydaci srflx są szczególnie ważni podczas przełączania między WiFi a siecią komórkową. Gdy urządzenie zmienia sieć, zmienia się adres IP, a ICE musi ponownie zebrać kandydatów. Proces ten nazywany jest ICE restart i wymaga ponownego wysłania nowego SDP.

Kandydaci relay przez TURN

Kandydat relay to adres na serwerze TURN, przez który ruch jest retransmitowany od jednego peera do drugiego. Ten typ jest używany jako opcja zapasowa, gdy bezpośrednie połączenie P2P jest niemożliwe (NAT symetryczny, firewall korporacyjny). Kanał relay dodaje opóźnienie i zwiększa obciążenie serwera, dlatego w optymalnych konfiguracjach serwer TURN jest wykorzystywany tylko dla 10–15% wszystkich sesji.

Popularne implementacje serwerów TURN: coturn (open source), Twilio Network Traversal, Metered TURN. Wybór dostawcy TURN wpływa na jakość połączenia multimedialnego w aplikacjach mobilnych — serwer powinien znajdować się geograficznie blisko użytkowników, aby zminimalizować dodatkowe opóźnienie.

Jak działa proces ICE

Proces ICE to wieloetapowy protokół, który gwarantuje nawiązanie niezawodnego połączenia P2P w warunkach niepewnej topologii sieci. Algorytm opisano w RFC 8445, obejmuje cztery obowiązkowe fazy: zbieranie kandydatów, sortowanie, testowanie i nominację.

Faza 1: zbieranie kandydatów

Każde urządzenie zbiera wszystkie dostępne adresy sieciowe. W tym celu silnik WebRTC wylicza lokalne interfejsy (host), wysyła żądanie do serwera STUN (srflx) i pobiera adres relay z serwera TURN. Jednocześnie urządzenie może wykryć kandydata prflx, jeśli otrzyma przychodzące żądanie STUN od peera.

W tworzeniu aplikacji mobilnych ten etap jest krytyczny dla czasu nawiązania połączenia. Na iOS i Androida zbieranie kandydatów może trwać od 200 ms do 2 sekund w zależności od prędkości sieci, dostępności serwerów STUN/TURN oraz liczby aktywnych interfejsów sieciowych.

Faza 2: tworzenie par i sortowanie

Po otrzymaniu listy kandydatów od zdalnego peera kanałem sygnalizacyjnym lokalny silnik ICE tworzy wszystkie możliwe pary kandydatów (lokalny + zdalny). Każda para otrzymuje priorytet według wzoru z RFC 8445, uwzględniającego priorytety obu kandydatów oraz kierunek (incoming/outgoing).

Pary są sortowane według malejącego priorytetu. Najlepsze pary są testowane jako pierwsze. Algorytm gwarantuje, że para host-host zostanie sprawdzona wcześniej niż host-srflx, host-relay lub relay-relay, minimalizując opóźnienie połączenia w prostych konfiguracjach sieciowych.

Faza 3: testowanie i nominacja

ICE wysyła żądania STUN-binding dla każdej pary kandydatów. Jeśli odpowiedź STUN zostanie odebrana — para jest prawidłowa. Pierwsza prawidłowa para zostaje nominowana (nominated) jako główna. Silnik WebRTC zaczyna przesyłać multimedia za pośrednictwem tej pary, a pozostałe pary są nadal sprawdzane na wypadek awarii głównej.

Proces testowania może potrwać kilka sekund przy dużej liczbie kandydatów. WebRTC używa timerów: dla par host timer jest agresywny (20 ms), dla relay — bardziej konserwatywny (200 ms). Twórcy aplikacji mobilnych mogą przyspieszyć połączenie, ograniczając liczbę serwerów ICE lub konfigurując iceTransportPolicy.

ICE Restart

ICE restart to ponowne uruchomienie procesu ICE bez odtwarzania całego RTCPeerConnection. Jest konieczny przy zmianie sieci, utracie połączenia lub przełączaniu między WiFi a siecią mobilną. Podczas restartu wszystkie bieżące kandydaty są resetowane, a proces rozpoczyna się od nowa, od wygenerowania nowych ufrag i pwd.

W tworzeniu aplikacji na iOS restart ICE jest wywoływany metodą restartIce() na RTCPeerConnection. Na Androida stosuje się analogiczną metodę w klasie PeerConnection z Google WebRTC. Prawidłowa obsługa restartu ICE to krytyczny wymóg dla aplikacji działających na urządzeniach mobilnych z niestabilnym połączeniem sieciowym.

Serwery STUN i TURN w ICE

STUN (Session Traversal Utilities for NAT) i TURN (Traversal Using Relays around NAT) to kluczowe komponenty serwerowe, bez których ICE Candidate nie może zagwarantować udanego połączenia w realnych warunkach internetowych. Ich prawidłowa konfiguracja bezpośrednio wpływa na jakość połączenia w aplikacjach mobilnych.

STUN: wykrywanie adresu zewnętrznego

Serwer STUN pozwala urządzeniu poznać swój publiczny adres IP i port, który NAT przydzielił dla połączenia wychodzącego. Protokół STUN zdefiniowano w RFC 8489; działa na UDP na porcie 3478, a także obsługuje TCP. Google udostępnia publiczne serwery STUN (stun.l.google.com:19302), z których można korzystać bezpłatnie.

W tworzeniu aplikacji mobilnych żądanie STUN to lekka operacja, trwająca 50–200 ms. Jednak niektóre sieci korporacyjne i mobilne blokują ruch UDP, zmuszając ICE do korzystania z TCP dla komunikacji STUN lub do przejścia od razu na TURN.

TURN: retransmisja ruchu

Serwer TURN to retransmiter ruchu medialnego. Gdy bezpośrednie połączenie P2P jest niemożliwe (NAT symetryczny, firewall), urządzenie wysyła dane do TURN, który przekazuje je drugiemu peerowi. TURN to niezawodny, ale kosztowny mechanizm: dodaje opóźnienie (30–100 ms) i wymaga przepustowości serwera równej sumie wszystkich sesji medialnych.

Według WebRTC Stats Report (2025) około 8–15% sesji WebRTC w sieciach mobilnych wymaga TURN. Aby zoptymalizować koszty ruchu TURN, twórcy aplikacji przeprowadzają wstępne testowanie połączenia i tylko przy niepowodzeniu P2P aktywują kanał TURN.

Wybór STUN/TURN dla aplikacji mobilnej

Przy wyborze infrastruktury dla ICE w projekcie mobilnym bierze się pod uwagę: lokalizację geograficzną serwerów w celu minimalizacji opóźnień, obsługę UDP i TCP, koszt ruchu TURN oraz SLA. Popularne rozwiązania: coturn do samodzielnej instalacji oraz Twilio, Agora i LiveKit do użytku w chmurze.

ICE Candidate w tworzeniu aplikacji mobilnych

Dla twórców aplikacji mobilnych zrozumienie ICE Candidate wykracza poza teorię — to praktyczna konieczność przy tworzeniu aplikacji z połączeniami głosowymi i wideo. Platformy iOS i Android udostępniają natywne API dla WebRTC, które automatyzują pracę z ICE, ale programista odpowiada za konfigurację serwerów ICE i obsługę zdarzeń zmiany sieci.

Konfiguracja ICE na iOS

Na iOS WebRTC jest dostępny przez framework WebRTC.framework lub bibliotekę GoogleWebRTC za pośrednictwem CocoaPods. Serwery ICE konfiguruje się przez tablicę RTCIceServer w 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)

Po utworzeniu RTCPeerConnection i wywołaniu offer() lub answer() silnik automatycznie zbiera kandydatów ICE. Zdarzenie iceGatheringStateChange informuje o zmianie stanu zbierania, a iceConnectionState — o stanie połączenia.

Konfiguracja ICE na Androidzie

Android korzysta z tej samej biblioteki Google WebRTC. Serwery ICE określa się przez PeerConnection.RTCConfiguration. Programista może zarządzać polityką ICE przez iceTransportsType — tryb relay wymusza korzystanie wyłącznie z TURN, co zwiększa niezawodność, ale wydłuża opóźnienie:

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

Parametr bundlePolicy wpływa na liczbę kandydatów ICE — tryb MAXBUNDLE łączy wszystkie strumienie mediów w jeden transport, zmniejszając całkowitą liczbę kandydatów i przyspieszając połączenie.

Obsługa zdarzeń ICE w aplikacji mobilnej

Kluczowe zdarzenia ICE, które programista powinien obsługiwać: połączenie ICE (ICE connection state), zmiana stanu zbierania (ICE gathering state) oraz wykrycie nowego kandydata. Po zakończeniu zbierania i testowania stan ICE przechodzi w connected lub completed.

W sieciach mobilnych często dochodzi do przełączeń między WiFi a siecią komórkową. Przy zmianie sieci ICE musi wykonać restart, w przeciwnym razie strumień medialny zostanie przerwany. Twórcy wdrażają monitorowanie NetworkManager (iOS) lub ConnectivityManager (Android), aby automatycznie wywoływać restartIce().

Skuteczna implementacja ICE w aplikacji mobilnej obejmuje: wybór niezawodnych serwerów STUN/TURN, prawidłową obsługę restartu ICE przy zmianie sieci, konfigurację iceConnectionState do wyświetlania statusu połączenia w interfejsie oraz monitorowanie statystyk przez RTCStatsReport.