ICE Candidate: tanımı, aday türleri ve çalışma şekli

ICE Candidate Nedir?

ICE Candidate (Interactive Connectivity Establishment Candidate), WebRTC protokolü aracılığıyla P2P bağlantı kurma sürecinde temel bir birimdir. İki eş arasında veri iletimi için kullanılabilecek bir IP adresi + port çiftini temsil eder. Her aday, aktarım protokolü (UDP, TCP), bağlantı türü ve öncelik hakkında bilgi içerir.

ICE Candidate her cihazda ayrı ayrı oluşturulur. Cihaz, mevcut tüm ağ arabirimlerini toplar, bir STUN sunucusu aracılığıyla harici adresi ister ve TURN sunucusundan aktarma adresini ekler. Elde edilen aday listesi, SDP (Session Description Protocol) biçiminde sinyal kanalı aracılığıyla uzaktaki eşe gönderilir.

RFC 8445 (IETF, 2018) spesifikasyonuna göre ICE, nominated pairs mekanizmasını kullanır: tüm adaylar toplandıktan sonra STUN istekleri aracılığıyla çift çift test yapılır. İlk kontrolü geçen çift nominated (atanmış) olarak belirlenir ve multimedya iletimi için kullanılır. Diğer çiftler, bağlantının kopması durumunda yedekte kalır.

WebRTC Yığınında ICE'ın Rolü

WebRTC, P2P iletişim için açık bir standarttır, ancak NAT (Network Address Translation) ve güvenlik duvarları nedeniyle cihazlar arasında doğrudan bağlantı genellikle imkânsızdır. ICE Candidate, birden fazla alternatif bağlantı yolu sunarak bu sorunu çözer. ICE (Interactive Connectivity Establishment) protokolü, WebRTC'nin zorunlu bir bileşenidir ve W3C WebRTC (2025) spesifikasyonunda açıklanmıştır.

Birçok mobil uygulama geliştiricisi, Google WebRTC (Android için) ve iOS için yerel sarmalayıcılar gibi WebRTC kütüphanelerini kullanır. Bunların her birinde ICE süreci otomatik olarak yönetilir, ancak aday türlerini anlamak, gelişiricinin sunucu altyapısını yapılandırmasına ve bağlantı kalitesini optimize etmesine olanak tanır.

ICE Adaylarıyla SDP Biçimi

ICE Candidate, SDP mesajı içinde a=candidate özniteliği olarak iletilir. Her satır foundation, component ID, aktarım protokolü, öncelik, IP adresi, port ve aday türünü içerir. Aşağıda, farklı türlerde üç aday içeren bir SDP parçası örneği verilmiştir:

// ICE adaylarıyla SDP örneği
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 alanı adayların test sırasını belirler. Öncelik ne kadar yüksekse aday o kadar erken kontrol edilir. Host adaylar her zaman en yüksek önceliğe sahiptir, relay ise en düşük.

ICE Aday Türleri

RFC 8445 spesifikasyonu, her biri uzaktaki eşe ulaşmanın belirli bir yoluna karşılık gelen dört tür ICE adayı tanımlar. Aday türü, önceliğini, bağlantı kurma süresini ve sunucu altyapısı gereksinimlerini etkiler.

Host Adaylar

Host aday, cihazın yerel ağ arabiriminin IP adresinden oluşturulur. Cihaz, eşle aynı yerel ağdaysa, host aday minimum gecikmeyle doğrudan bağlantı sağlar. Mobil cihazlar için host adaylar WiFi arabirimi, hücresel LTE/5G bağlantısı ve gerektiğinde VPN tünelleri için oluşturulur.

Host adaylar en yüksek önceliğe (UDP için 2130706431) sahiptir ve ilk önce test edilir. Her iki eş de NAT arkasındaysa, host adayları özel adresler olacaktır (192.168.x.x, 10.x.x.x) ve bunlar üzerinden doğrudan bağlantı mümkün değildir. ICE, srflx ve relay adaylarını test etmeye geçer.

SRFLX ve PRFLX Adaylar

SRFLX (Server Reflexive) adayı, STUN sunucusundan alınan harici IP adresi ve porttur. Cihaz bir STUN isteği gönderdiğinde, sunucu NAT sonrası genel adresini görür ve geri döndürür. Bu aday, NAT cihazları Hairpinning'i destekliyorsa, farklı NAT'lar arkasındaki eşler arasında doğrudan bağlantı kurulmasını sağlar.

PRFLX (Peer Reflexive) adayı, bir eşten gelen STUN isteği beklenmeyen bir adrese ulaştığında dinamik olarak keşfedilir. Bu tür, her iki eş aynı anda istek gönderdiğinde ve NAT geçici bir bağlama oluşturduğunda ortaya çıkar. PRFLX adayı srflx'ten daha yüksek önceliğe ancak host'tan daha düşük önceliğe sahiptir.

Mobil uygulamalarda srflx adayları, WiFi ve hücresel ağ arasında geçiş yaparken özellikle önemlidir. Cihaz ağı değiştirdiğinde IP adresi değişir ve ICE adayları yeniden toplamalıdır. Bu sürece ICE restart denir ve yeni bir SDP'nin yeniden gönderilmesini gerektirir.

TURN Üzerinden Relay Adaylar

Relay aday, trafiğin bir eşten diğerine aktarıldığı TURN sunucusundaki bir adrestir. Bu tür, doğrudan P2P bağlantısı mümkün olmadığında (simetrik NAT, kurumsal güvenlik duvarı) yedek seçenek olarak kullanılır. Aktarma kanalı gecikme ekler ve sunucu yükünü artırır, bu nedenle optimal yapılandırmada TURN sunucusu tüm oturumların yalnızca %10–15'i için kullanılır.

Popüler TURN sunucusu uygulamaları: coturn (açık kaynak), Twilio Network Traversal, Metered TURN. TURN sağlayıcısının seçimi, mobil uygulamalarda medya bağlantı kalitesini etkiler — sunucu, ek gecikmeyi en aza indirmek için kullanıcılara coğrafi olarak yakın olmalıdır.

ICE Süreci Nasıl Çalışır

ICE süreci, ağ topolojisi belirsizliği koşullarında güvenilir bir P2P bağlantısı kurulmasını garanti eden çok aşamalı bir protokoldür. Algoritma RFC 8445'te açıklanmıştır ve dört zorunlu aşamayı içerir: aday toplama, sıralama, test ve atama.

Aşama 1: aday toplama

Her cihaz mevcut tüm ağ adreslerini toplar. Bunun için WebRTC motoru yerel arabirimleri (host) numaralandırır, STUN sunucusuna (srflx) istek gönderir ve TURN sunucusundan aktarma adresi ister. Aynı anda cihaz, eşten gelen bir STUN isteği alırsa prflx adayı keşfedebilir.

Mobil geliştirmede bu aşama, bağlantı kurma süresi için kritiktir. iOS ve Android'de aday toplama, ağ hızına, STUN/TURN sunucularının kullanılabilirliğine ve etkin ağ arabirimlerinin sayısına bağlı olarak 200 ms ile 2 saniye arasında sürebilir.

Aşama 2: çift oluşturma ve sıralama

Sinyal kanalı aracılığıyla uzaktaki eşten aday listesi alındıktan sonra, yerel ICE motoru mümkün tüm aday çiftlerini (yerel + uzak) oluşturur. Her çift, RFC 8445'teki formüle göre, her iki adayın önceliklerini ve yönü (gelen/giden) dikkate alan bir öncelik alır.

Çiftler azalan öncelik sırasına göre sıralanır. En iyi çiftler ilk önce test edilir. Algoritma, host-host çiftinin host-srflx, host-relay veya relay-relay'dan önce kontrol edilmesini sağlayarak basit ağ yapılandırmalarında bağlantı gecikmesini en aza indirir.

Aşama 3: test ve atama

ICE, her aday çifti için STUN-binding istekleri gönderir. STUN yanıtı alınırsa çift geçerlidir. İlk geçerli çift nominated (atanmış) olarak belirlenir. WebRTC motoru bu çift üzerinden medya iletmeye başlarken, diğer çiftler ana çiftin arızalanması durumunda kontrol edilmeye devam eder.

Test süreci, çok sayıda aday varken birkaç saniye sürebilir. WebRTC zamanlayıcılar kullanır: host çiftleri için agresif (20 ms), relay için daha muhafazakâr (200 ms). Mobil uygulama geliştiricileri, ICE sunucularının sayısını sınırlayarak veya iceTransportPolicy'yi yapılandırarak bağlantıyı hızlandırabilir.

ICE Restart

ICE restart, RTCPeerConnection'un tamamını yeniden oluşturmadan ICE sürecini yeniden başlatmaktır. Ağ değişikliği, bağlantı kaybı veya WiFi ile mobil ağ arasında geçiş yaparken gereklidir. Yeniden başlatmada tüm mevcut adaylar sıfırlanır ve süreç yeni ufrag ve pwd oluşturarak baştan başlar.

iOS geliştirmede ICE restart, RTCPeerConnection üzerinde restartIce() yöntemiyle çağrılır. Android'de Google WebRTC'nin PeerConnection sınıfında benzer bir yöntem kullanılır. ICE restart'ın doğru şekilde işlenmesi, dengesiz ağ bağlantısıyla çalışan mobil cihaz uygulamaları için kritik bir gerekliliktir.

ICE'de STUN ve TURN Sunucuları

STUN (Session Traversal Utilities for NAT) ve TURN (Traversal Using Relays around NAT), gerçek internet koşullarında ICE Candidate'ın başarılı bağlantıyı garanti edemeyeceği temel sunucu bileşenleridir. Doğru yapılandırmaları, mobil uygulamalarda arama kalitesini doğrudan etkiler.

STUN: harici adres keşfi

STUN sunucusu, cihazın NAT'ın giden bağlantı için tahsis ettiği genel IP adresini ve portu öğrenmesini sağlar. STUN protokolü RFC 8489'da tanımlanmıştır ve UDP üzerinde 3478 numaralı portta çalışır ve ayrıca TCP'yi de destekler. Google, ücretsiz olarak kullanılabilen genel STUN sunucuları (stun.l.google.com:19302) sağlar.

Mobil geliştirmede STUN isteği, 50–200 ms süren hafif bir işlemdir. Ancak bazı kurumsal ve mobil ağlar UDP trafiğini engelleyerek ICE'ı STUN iletişimi için TCP kullanmaya veya doğrudan TURN'a geçmeye zorlar.

TURN: trafik aktarımı

TURN sunucusu bir medya trafiği aktarıcısıdır. Doğrudan P2P bağlantısı mümkün olmadığında (simetrik NAT, güvenlik duvarı), cihaz verileri TURN'a gönderir ve TURN bunları diğer eşe iletir. TURN güvenilir ancak maliyetli bir mekanizmadır: gecikme ekler (30–100 ms) ve tüm medya oturumlarının toplamına eşit bant genişliği gerektirir.

WebRTC Stats Report (2025)'e göre mobil ağlardaki WebRTC oturumlarının yaklaşık %8–15'i TURN gerektirir. TURN trafik maliyetlerini optimize etmek için geliştiriciler önceden bağlantı testi kullanır ve P2P başarısız olduğunda TURN kanalını etkinleştirir.

Mobil uygulama için STUN/TURN seçimi

Bir mobil projede ICE altyapısı seçilirken şunlar dikkate alınır: gecikmeyi en aza indirmek için sunucuların coğrafi konumu, UDP ve TCP desteği, TURN trafik maliyeti ve SLA. Popüler çözümler: kendi kurulum için coturn, bulut kullanımı için Twilio, Agora ve LiveKit.

Mobil Geliştirmede ICE Candidate

Mobil geliştiriciler için ICE Candidate anlayışı teorinin ötesine geçer — sesli ve görüntülü aramalar içeren uygulamalar oluştururken pratik bir gerekliliktir. iOS ve Android platformları, ICE ile çalışmayı otomatikleştiren yerel API'ler sağlar, ancak geliştirici ICE sunucularının yapılandırılmasından ve ağ değişikliği olaylarının işlenmesinden sorumludur.

iOS'ta ICE Yapılandırması

iOS'ta WebRTC, WebRTC.framework framework'ü veya CocoaPods aracılığıyla GoogleWebRTC kütüphanesi aracılığıyla kullanılabilir. ICE sunucuları, RTCConfiguration içindeki RTCIceServer dizisi aracılığıyla yapılandırılır:

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 oluşturulduktan ve offer() veya answer() çağrıldıktan sonra motor otomatik olarak ICE adaylarını toplar. iceGatheringStateChange olayı toplama durumundaki değişikliği bildirirken iceConnectionState bağlantı durumunu bildirir.

Android'de ICE Yapılandırması

Android aynı Google WebRTC kütüphanesini kullanır. ICE sunucuları PeerConnection.RTCConfiguration aracılığıyla ayarlanır. Geliştirici, ICE politikasını iceTransportsType aracılığıyla yönetebilir — relay modu yalnızca TURN'u zorla kullanır, güvenilirliği artırır ancak gecikmeyi yükseltir:

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 parametresi ICE aday sayısını etkiler — MAXBUNDLE modu tüm medya akışlarını tek bir aktarımda birleştirerek toplam aday sayısını azaltır ve bağlantıyı hızlandırır.

Mobil uygulamada ICE olaylarını işleme

Geliştiricinin işlemesi gereken temel ICE olayları: ICE bağlantı durumu, ICE toplama durumu değişikliği ve yeni aday keşfi. ICE toplama ve testi tamamladıktan sonra durumu connected veya completed olarak değişir.

Mobil ağlarda WiFi ve hücresel arasında sık sık geçişler olur. Ağ değiştiğinde ICE restart yapmalıdır, aksi takdirde medya akışı kesilir. Geliştiriciler, restartIce()'i otomatik olarak çağırmak için NetworkManager (iOS) veya ConnectivityManager (Android) izlemesi uygular.

Mobil uygulamada başarılı bir ICE uygulaması şunları içerir: güvenilir STUN/TURN sunucularının seçimi, ağ değişikliğinde ICE restart'ın doğru işlenmesi, bağlantı UI durumunu göstermek için iceConnectionState yapılandırması ve RTCStatsReport aracılığıyla istatistik izleme.