TURN Sunucusu: nedir, nasıl çalışır ve nerede kullanılır

TURN Sunucusu Nedir

TURN Sunucusu (Traversal Using Relays around NAT), RFC 5766da tanımlanan ve RFC 8656da güncellenen, NAT veya güvenlik duvarı kısıtlamaları nedeniyle doğrudan P2P bağlantısı mümkün olmadığında iki istemci arasında UDP ve TCP trafiğini aktaran bir ağ hizmetidir. WebRTC mimarisinde, TURN sunucusu son geri dönüş mekanizması olarak görev yapar ve her tür ağ koşulunda bağlantıyı garanti eder.

Yalnızca bir istemciye dış adresini bildiren STUNun aksine, TURN sunucusu veri iletimine aktif olarak katılır. Her eş, TURN sunucusuna bir bağlantı kurar ve medya verilerini ona gönderir. TURN sunucusu da bu verileri diğer eşe iletir. Sonuç olarak, eşler arasında doğrudan bir bağlantı yoktur — tüm trafik aktarma sunucusundan geçer ve en katı NAT kısıtlamaları altında bile teslimat garanti edilir.

TURN Protokolü

TURN, STUN protokolünün bir uzantısıdır. TURN mesajları aynı 20 baytlık başlığı ve öznitelik mekanizmasını kullanır. Temel fark, TURNün yeni mesaj türleri (Allocate, Refresh, Send, Data, CreatePermission, ChannelBind) ve aktarma tahsislerini yönetmek için gerekli öznitelikleri tanımlamasıdır. İstemci, Allocate mesajı aracılığıyla TURN sunucusunda bir tahsis oluşturur, aktarılmış bir taşıma adresi (relayed transport address) alır ve sunucu üzerinden veri gönderip almak için bunu kullanır.

TURN Sunucusu Nasıl Çalışır

TURN sunucusu aşağıdaki adım sırasına göre çalışır. İstemci, kimlik doğrulama (username, credential) ile bir Allocate İsteği gönderir. Sunucu, kimlik bilgilerini doğrular ve bir tahsis oluşturur — istemciye aktarılmış bir adresin (TURN sunucusunda IP:bağlantı noktası) geçici bağlanması. Sunucu, bir aktarılmış taşıma adresi ile Allocate Yanıtı döndürür — diğer eşlerin TURN sunucusu aracılığıyla bu istemciye veri göndermek için kullanacağı adres.

Tahsis oluşturulduktan sonra, istemci Send Indication mesajları veya kanallar (ChannelBind) aracılığıyla TURN sunucusu üzerinden veri gönderebilir. İstemciden veri aldığında, TURN sunucusu izinleri (belirli eşlere veri gönderme yetkisi) kontrol eder ve verileri hedef eşe aktarır. Gelen verileri almak için, istemcinin önce veri beklediği eş için bir izin oluşturması gerekir; aksi takdirde TURN sunucusu gelen paketi atar. Bir izin, eşin IP adresi belirtilerek CreatePermission mesajı aracılığıyla oluşturulur.

Tahsis ve Ömür

TURN sunucusundaki bir tahsisin sınırlı bir ömrü vardır — varsayılan olarak 10 dakika. İstemci, tahsisi uzatmak için periyodik olarak Refresh İsteği göndermelidir. Ömür, LIFETIME özniteliğinde saniye cinsinden belirtilir. Herhangi bir Refresh alınmazsa, sunucu tahsisi kaldırır ve aktarılmış adresi serbest bırakır. Önerilen yenileme aralığı — Refresh paket kaybına karşı koruma için 5 dakika (300 saniye).

WebRTCde TURN Sunucusu Yapılandırma

WebRTCde, TURN sunucusu iceServers dizisindeki RTCPeerConnection yapılandırması aracılığıyla yapılandırılır. TURN sunucuları UDP, TCP veya TLS taşıma kullanabilir. Kimlik doğrulama tipik olarak, uygulama sunucusunda sınırlı geçerlilik süresiyle oluşturulan zaman sınırlı kimlik bilgileri (TURN kimlik bilgileri) kullanır.

JavaScriptte HMAC-SHA1 jeton kimlik doğrulaması ile TURN sunucusu yapılandırmasına bir örnek ele alalım.

async function createPeerConnection(turnServerUrl) {
    const credentials = await fetchTurnCredentials();

    const config = {
        iceServers: [
            {
                urls: "stun:stun.l.google.com:19302"
            },
            {
                urls: turnServerUrl,
                username: credentials.username,
                credential: credentials.credential
            }
        ],
        iceTransportPolicy: "all"
    };

    return new RTCPeerConnection(config);
}

async function fetchTurnCredentials() {
    const response = await fetch("/api/turn-credentials");
    return response.json();
}

const turnUrl = "turn:turn.example.com:3478";
const pc = await createPeerConnection(turnUrl);

Bu örnekte, TURN sunucusu bir STUN sunucusuyla birlikte tek bir ICE yapılandırmasında belirtilmiştir. ICE süreci önce host adaylarını ve STUNdan elde edilen srflx adaylarını kullanmayı dener. Doğrudan bağlantı başarısız olursa, ICE otomatik olarak TURN sunucusundan elde edilen relay adayına geçer. iceTransportPolicy: "all" parametresi relay adaylarını etkinleştirir — alternatif değer "relay", TURN dışındaki tüm adayları devre dışı bırakır ve test için kullanışlıdır.

TURN Sunucusu Kimlik Doğrulaması

Yetkisiz kullanımı önlemek için, TURN sunucusu kimlik doğrulaması gerektirir. Standart yaklaşım, HMAC-SHA1 kullanılarak uygulama sunucusunda oluşturulan zaman sınırlı kimlik bilgileridir. Uygulama sunucusu, kullanıcı adını TURN sunucusunun gizli anahtarıyla şifreler ve kullanıcı adı ile kimlik bilgisini istemciye döndürür. İstemci bunları RTCPeerConnection yapılandırmasına iletir ve tarayıcı, TURN sunucusunda bir tahsis oluştururken bunları kullanır. Kimlik bilgilerinin süresi dolduğunda, istemci uygulama sunucusundan yenilerini alır.

TURN ve STUN: Karşılaştırma

TURN ve STUN, ilgili NAT geçiş görevlerini çözer ancak mekanizma ve maliyet açısından temel olarak farklılık gösterir. TURN, trafiği aktararak aracı görevi görürken, STUN yalnızca doğrudan P2P bağlantısı için dış adresin belirlenmesine yardımcı olur. Aralarındaki seçim, eşlerin NAT türüne ve performans gereksinimlerine bağlıdır.

Pratikte, TURN sunucusu yalnızca P2Pnin mümkün olmadığı bağlantılar için kullanılır. Googlea göre (WebRTC istatistikleri, 2023), tüm WebRTC bağlantılarının yaklaşık %15–20si TURN aktarımı gerektirir. Kalan %80–85i STUN veya yerel host adayları aracılığıyla bağlantı kurar. Bir uygulama tasarlarken, hedef kitleniz kurumsal ağlardan ve katı NAT kısıtlamaları olan bölgelerden kullanıcılar içeriyorsa, toplam medya hacminin %15–20si oranında TURN trafiği için bütçe ayırmalısınız.

TURN Sunucusu Maliyeti ve Performansı

TURN sunucusu, tüm medya trafiği üzerinden geçtiği için önemli ölçüde kaynak tüketir. TURN aktarımı kullanan her aktif arama, toplam medya trafiği verimine (gelen + giden akış) eşit sunucu bant genişliği kullanır. Bir HD video araması (720p) için, bu her bağlantıda her yönde 1,5–2,5 Mbps olabilir ve TURN sunucusu üzerinden toplam 3–5 Mbps trafik oluşur.

TURN altyapısı için birkaç dağıtım seçeneği vardır. Ücretsiz genel TURN sunucuları, kalite ve güvenlik garantilerinin olmaması nedeniyle üretim için önerilmez. Ticari sağlayıcılar (Twilio Network Traversal Service, Xirsys, Metered), TURNü gigabyte başına fiyatlandırmayla bir hizmet olarak sunar — tipik maliyet gigabyte başına $0,005–0,02dir. Coturn (açık kaynak TURN sunucusu) ile kendi kendine barındırma, yeterli bant genişliği kapasitesine ve izleme kurulumuna sahip bir sunucu gerektirir.

• coturn — en popüler açık kaynak TURN sunucusu, çoğu üretim sisteminde kullanılır, UDP, TCP, TLS ve DTLS taşımayı destekler.
• Twilio — trafik tabanlı fiyatlandırma ve zaman sınırlı jetonlarla kimlik doğrulama sağlayan ticari bir TURN + STUN hizmetidir.
• Xirsys — küresel sunucu ağı ve ayrıntılı kullanım analitiği ile uzmanlaşmış bir TURN sağlayıcısıdır.
• Metered.ca — ayda 50 GBa kadar ücretsiz limit ve bunun ötesinde kullandıkça öde ile TURN hizmetidir.
• Kendi kendine barındırılan coturn — yapılandırma üzerinde tam kontrol, ancak sunucu yönetimi ve izleme kurulumu gerektirir.

TURN sunucusu çözümü seçerken, kullanıcı coğrafyasını, trafik maliyetini ve güvenlik gereksinimlerini göz önünde bulundurun. Binlerce eşzamanlı aramaya sahip uygulamalar için, geniş kanallı (1+ Gbps) sunucularda kendi kendine barındırılan coturn, ticari sağlayıcılardan daha uygun maliyetli olabilir. Düzinelerce kullanıcıya sahip küçük projeler için, yönetim ve izleme masrafı olmadığından ticari TURN hizmetleri tercih edilir.