Signaling Server: nedir, nasıl çalışır ve nerede kullanılır

Signaling Server Nedir

Signaling Server — iki veya daha fazla eş arasında WebRTC bağlantısı kurma sürecini koordine etmekten sorumlu bir ağ hizmetidir. Medya verilerini (ses, video, DataChannel verileri) iletmez, yalnızca eş keşfi ve bağlantı parametrelerinin müzakere edilmesi için gerekli kontrol bilgilerini iletir. Başarılı bir P2P kanalı kurulduktan sonra, Signaling Server artık gerekli olmayabilir, ancak bazı mimarilerde sonraki sinyal alışverişi (örneğin, çağrı sonlandırma, katılımcı ekleme) için kalır.

Sinyalleme mimarisi üç bileşen içerir: Signaling Server, Sinyal Kanalı (istemci ve sunucu arasındaki taşıma protokolü) ve istemci API'si (genellikle tarayıcının WebRTC yığınına yerleşik). WebRTC spesifikasyonu (W3C, 2024) kasıtlı olarak sinyalleme protokolünü standartlaştırmaz — geliştiriciler uygulamaları için uygun herhangi bir taşımayı seçebilirler. Bu esnek yaklaşım, web uygulamaları için WebSocket, sohbet sistemleri için XMPP veya telekomünikasyon altyapısı ile entegrasyon için SIP kullanılmasına olanak tanır.

Sinyalleme Süreci: Üst Düzey Genel Bakış

Bir WebRTC bağlantısı kurmadan önce, eşler üç tür mesaj alışverişi yapmalıdır: oturum açıklamaları (offer ve answer), ICE adayları ve oturum sonlandırma/değişiklik bilgileri. Signaling Server, adresleme için oda veya kullanıcı tanımlayıcıları kullanarak bu mesajları eşler arasında yönlendirir. Standart desen, iki katılımcının bağlandığı bir “oda” oluşturmak ve sunucunun her katılımcıdan gelen mesajları yalnızca muhatabına iletmesidir.

WebRTC'de Sinyalleme Nasıl Çalışır

Signaling Server aşağıdaki tipik WebRTC bağlantı kurma protokolünü uygular. Eşler, WebSocket (veya başka bir taşıma) aracılığıyla sunucuya bağlanır ve bir odaya kaydolur. Eş A (başlatıcı), RTCPeerConnection.createOffer() aracılığıyla bir teklif (giden medya akışının SDP açıklaması) oluşturur, bunu yerel açıklama olarak ayarlar ve Signaling Server'a gönderir. Sunucu teklifi Eş B'ye iletir. Eş B teklifi alır, bunu uzak açıklama olarak ayarlar, createAnswer() aracılığıyla bir yanıt oluşturur, bunu yerel açıklama olarak ayarlar ve sunucu aracılığıyla geri gönderir. Bu sürece SDP Offer/Answer denir.

SDP değişimine paralel olarak, her eş ICE adaylarını (host, srflx, relay) toplar ve Signaling Server aracılığıyla diğer eşe gönderir. Uzaktaki eş, alınan adayları RTCPeerConnection.addIceCandidate() aracılığıyla ekler. ICE süreci, çalışan bir yol bulmak için tüm aday kombinasyonlarını test eder. Çalışan bir yol bulunduğunda (genellikle 1–5 saniye içinde), medya trafiği doğrudan eşler arasında akmaya başlar ve Signaling Server artık veri iletimine katılmaz — bir sonraki kontrol olayına (çağrı sonlandırma, akış kalitesi değişikliği) kadar rolü sona erer.

Oda Mekanizması ve Kayıt

Mesaj adresleme için Signaling Server bir oda veya kanal mekanizması kullanır. Her yeni WebRTC oturumu, benzersiz bir tanımlayıcıya (genellikle UUID) sahip bir oda oluşturur. Başlatıcı odayı oluşturur ve ikinci eşin bağlanmasını bekler. İkinci eş, harici bir kanal (örneğin, bir davet bağlantısı) aracılığıyla alınan ID'yi kullanarak odaya katılır. Sunucu, her ID'nin bağlı istemcilerin bir listesine karşılık geldiği bir oda haritası tutar. Katılımcı sayısı ikiye ulaştığında, sunucu aralarında sinyalleme mesajlarını iletmeye başlar.

WebRTC Sinyalleme Protokolleri

Signaling Server, her biri kendi avantaj ve dezavantajlarına sahip farklı taşıma protokollerini kullanabilir. Protokol seçimi, uygulama türüne, altyapı kısıtlamalarına ve uyumluluk gereksinimlerine bağlıdır. Aşağıda en yaygın protokoller ve özellikleri verilmiştir.

WebSocket, web uygulamalarında Signaling Server için en popüler protokoldür. SDP ve ICE adaylarının asenkron değişimi için önemli olan tam çift yönlü iletişim sağlar ve WebSocket API aracılığıyla tüm modern tarayıcılar tarafından yerel olarak desteklenir. Sunucu tarafı WebSocket uygulamaları tüm popüler platformlarda (Node.js, Python, Java, Go) mevcuttur. Milyonlarca kullanıcıya sahip uygulamalar için, Signaling Server örnekleri arasında senkronizasyon için Redis Pub/Sub veya Kafka tabanlı ölçeklenebilir WebSocket çözümleri kullanılır.

Signaling Server Uygulama Örneği

ws kitaplığını (WebSocket) ve yerleşik HTTP sunucusunu kullanarak Node.js'de basit bir Signaling Server uygulamasına bakalım. Sunucu, kullanıcı kaydı, oda oluşturma ve katılımcılar arasında mesaj iletimini destekler.

const WebSocket = require("ws");
const server = new WebSocket.Server({ port: 8080 });
const rooms = new Map();

server.on("connection", (ws) => {
    ws.roomId = null;

    ws.on("message", (data) => {
        const msg = JSON.parse(data);

        switch (msg.type) {
            case "join":
                handleJoin(ws, msg.roomId);
                break;
            case "offer":
            case "answer":
            case "ice-candidate":
                relayToPeer(ws, msg);
                break;
            case "leave":
                handleLeave(ws);
                break;
        }
    });

    ws.on("close", () => handleLeave(ws));
});

function handleJoin(ws, roomId) {
    if (!rooms.has(roomId)) {
        rooms.set(roomId, []);
    }

    const room = rooms.get(roomId);
    room.push(ws);
    ws.roomId = roomId;

    if (room.length === 2) {
        room[0].send(JSON.stringify({ type: "peer-joined" }));
        room[1].send(JSON.stringify({ type: "peer-joined" }));
    }
}

function relayToPeer(sender, msg) {
    const room = rooms.get(sender.roomId);
    if (!room) return;

    room.forEach(peer => {
        if (peer !== sender && peer.readyState === WebSocket.OPEN) {
            peer.send(JSON.stringify(msg));
        }
    });
}

function handleLeave(ws) {
    if (!ws.roomId) return;
    const room = rooms.get(ws.roomId);
    if (!room) return;

    const idx = room.indexOf(ws);
    if (idx !== -1) room.splice(idx, 1);
    if (room.length === 0) rooms.delete(ws.roomId);
}

Bu Signaling Server temel işlevselliği uygular: bir odaya bağlanma, iki eş arasında WebRTC mesajlarını (offer, answer, ice-candidate) iletme ve bağlantı kesilme yönetimi. Sunucu, bağlı WebSocket istemcileri olan odaları depolamak için bir Map kullanır. relayToPeer işlevi, gönderen hariç odadaki tüm katılımcılara bir mesaj gönderir. Üretim için, mesaj türü doğrulaması, JSON ayrıştırma hata işleme ve kopuk bağlantıları tespit etmek için bir heartbeat mekanizması eklemeniz gerekecektir.

İstemci ile Signaling Server Entegrasyonu

İstemci tarafında, Signaling Server tarayıcının WebSocket API'si aracılığıyla entegre edilir. İstemci sunucuya bir bağlantı kurar, bir odaya katılma isteği gönderir ve ardından gelen WebRTC mesajlarını setRemoteDescription() ve addIceCandidate() aracılığıyla RTCPeerConnection'a ileterek işler. İstemci kodu ayrıca onicecandidate olayı aracılığıyla ve offer/answer oluşturduktan sonra RTCPeerConnection'dan elde edilen kendi SDP ve ICE adaylarını sunucuya gönderir.

Sinyallemede SDP ve ICE'nin Rolü

Signaling Server iki ana meta veri türünü iletir: SDP (Session Description Protocol) ve ICE adayları. SDP, medya akışı parametrelerini — codec'ler, örnekleme hızı, kanal sayısı, iletim yönü (sendrecv, sendonly, recvonly, inactive) tanımlar. ICE adayları, bir eşin bağlantı için erişilebilir olabileceği ağ adreslerini (yerel, STUN'dan alınan, TURN'den röle) içerir.

SDP, oturum ve medya bölümleri içeren bir metin biçiminde sunulur. Oturum kısmı genel parametreleri (oturum ID'si, sürüm, ad) tanımlarken, medya bölümleri her medya akışını (ses, video, DataChannel) codec, bağlantı noktası ve protokolüyle birlikte tanımlar. ICE adayları foundation (gruplama tanımlayıcısı), öncelik, IP adresi, bağlantı noktası, tür (host, srflx, relay) ve protokol (UDP, TCP) içerir. Her aday ayrıca onu belirli bir ICE sürecine bağlayan bir ufrag (kullanıcı adı parçası) özniteliği içerir.

• SDP Offer — başlatıcı, medya yeteneklerinin bir açıklamasını oluşturur ve Signaling Server aracılığıyla uzaktaki eşe gönderir.
• SDP Answer — uzaktaki eş, medya biçimlerini ve codec'leri onaylayarak veya ayarlayarak kendi açıklamasıyla yanıt verir.
• ICE Candidate — her eş, ICE çerçevesi tarafından keşfedildikçe ağ adaylarını sinyalleme sunucusuna gönderir.
• Trickle ICE — adayların toplama tamamlandıktan sonra hepsi bir anda gönderilmek yerine, keşfedildikçe tek tek gönderildiği modern bir optimizasyon.
• Yeniden Müzakere — medya parametreleri değiştiğinde (videoyu etkinleştirme/devre dışı bırakma, katılımcı ekleme), eşler Signaling Server aracılığıyla yeni bir SDP değişimi başlatır.

Trickle ICE, WebRTC bağlantı kurulumunu önemli ölçüde hızlandırır. Tüm ICE adaylarının tamamen toplanmasını beklemek yerine (karmaşık ağlarda 2–10 saniye sürebilir), her aday keşfedildikten hemen sonra Signaling Server'a gönderilir. Uzaktaki eş adayı alır ve ICE çerçevesi aracılığıyla hemen bağlantı testine başlar. Bu, çoğu durumda bağlantı kurulum süresini 500–1500 ms'ye düşürür.