WebRTC, Google Meet, Zoom’un web istemcisi ve çoğu ürünleşmiş ses odasının arkasındaki tarayıcı yığınıdır. Kamera ve mikrofon eklenti, Flash veya önce masaüstü uygulaması indirmeden çalışır. Toplantı, teletıp veya canlı işbirliği satan SaaS ekipleri için bu yerel yol, çıkan özellik ile hiç bitmeyen destek kuyruğu arasındaki farktır.
Bu yazı WebRTC’nin hat üzerinde ne yaptığını, eşler arası modelin birkaç kişiden sonra neden ölçeklenmediğini, STUN ve TURN’ün bağlantıyı nasıl belirlediğini ve bir SFU’yu Avrupa’daki Cloud VPS üzerinde UDP ile trafik tahminine düşmeden nasıl barındıracağınızı anlatır. Medya ile mesajlaşma yığınları arasında hâlâ seçim yapıyorsanız WebRTC vs WebSocket okuyun. Kamera olmadan uzun ömürlü uygulama verisi için WebSocket nedir rehberine bakın.
WebRTC nedir ve neden önemli
WebRTC (Web Real-Time Communication), etkileşimli ses, görüntü ve veri için tarayıcı API’leri ile ağ protokollerinin birleşimidir. Tarayıcı medyayı yakalar, oturumu müzakere eder, her paketi şifreler ve kayıp ile titreşime uyum sağlar. Ürün UX’i ve backend’i size aittir; yakalama ve oynatmanın zor kısmı tarayıcıdadır.
WebRTC öncesi web videosu eklenti, kapalı istemci veya “uygulamamızı indirin” demekti. Meet sınıfı ürünler bu kalıbı bitirdi: link aç, mikrofon/kameraya bir kez izin ver, katıl. Bu beklenti artık “tarayıcıda konuşun” diyen her SaaS için geçerlidir. Yığınınız bu yolu veremiyorsa, özellik listeniz daha uzun olsa bile rakipler daha hızlı hissedilir.
WebRTC tek bir sunucu ürünü değildir. İstemci yeteneği artı bir müzakere modelidir. Üretim sistemleri neredeyse her zaman sinyalizasyon, gruplar için SFU ve zor ağlar için TURN ekler. Bunları yok saymak, ofis Wi‑Fi’sinde çalışan demoların mobil veride çökmesinin yoludur.
WebRTC nasıl çalışır (sade dil)
Operatörlerin arızayı ayırması için dört fikir yeterlidir.
getUserMedia
getUserMedia tarayıcıdan mikrofon ve kamera akışı ister (isteğe bağlı ekran paylaşımı). İzinler, cihaz etiketleri ve yankı giderme burada yaşar. Yakalama başarısızsa SFU ayarı işe yaramaz — önce izin ve cihaz seçimini düzeltin.
RTCPeerConnection
RTCPeerConnection oturum nesnesidir. Yerel ve uzak medya izlerini, şifreleme durumunu ve ICE bağlantısını tutar. Bir bağlantı birden çok iz taşıyabilir; SFU tasarımlarında her katılımcı genelde tüm eşlere değil medya sunucusuna bağlanır.
SDP
Session Description Protocol (SDP), kodekleri, yönleri ve medya satırlarını listeleyen metin “teklif/yanıt”tır. İstemciler SDP’yi sizin sinyal kanalınız üzerinden değiş tokuş eder — HTTPS, WebSocket veya kontrol ettiğiniz başka bir kontrol düzlemi. WebRTC sinyal taşımasını tanımlamaz; SDP’yi isteğe bağlı meta veri saymak kolay hatadır.
ICE
Interactive Connectivity Establishment (ICE) uçlar arasında çalışan bir yol bulur. Adaylar host (yerel), server-reflexive (STUN ile) veya relay (TURN ile) olabilir. Trickle ICE adayları toplama bitmeden gönderir — açın, yoksa kullanıcılar “Bağlanıyor…” ekranında gereksiz bekler.
Uçtan uca akış: yakalama → teklif oluştur → SDP’yi sinyal ile gönder → uzak yanıtı ayarla → ICE topla/trickle → DTLS el sıkışması → SRTP medya. Bir şey kırıldığında yakalama, sinyal, ICE veya medya kalitesinden hangisinin düştüğüne karar verin. Bunlar farklı ticket’lardır.
P2P gerçeği ve grupların neden SFU’ya ihtiyacı var
İki tarayıcı dost ağlarda medyayı eşler arası gönderebilir. Bu mesh 1:1 ve çok küçük odalar için çalışır. Birkaç katılımcıdan sonra her istemci akışının bir kopyasını diğer herkese yükler. Önce yük bandı ve CPU çöker; destek talepleri peşinden gelir.
SFU (Selective Forwarding Unit) ortada durur. İstemciler bir kez yükler; SFU şifreli paketleri abonelere iletir — klasik MCU gibi her kareyi tam çözüp yeniden kodlamadan (MCU karışımı ağır CPU ister). CPU yine önemlidir: kriptografi, paket yönlendirme ve simulcast seçimi gerçek iştir, ama topoloji ürünün büyümesine uyar.
- Mesh — 1:1 veya çok küçük odalar; her istemci N−1 akış yükler
- SFU — ürünler için varsayılan: LiveKit, mediasoup, Janus, Jitsi Videobridge ve benzerleri
- MCU — tek düzene karıştırır; ağır CPU; zorunluysa (eski SIP köprüleri, sabit kompozit)
Çoğu yol haritası ilk günden SFU + TURN varsaymalıdır. Lansman haftasından sonra TURN eklemek, ilk düğümle birlikte açmaktan daha pahalıdır.
STUN ve TURN: çağrı “Bağlanıyor”da kalınca
STUN istemciye internetten görünen genel adresini buldurur. Her iki taraf UDP yolu açabiliyorsa bu yeterlidir. Birçok kurumsal ağ, operatör NAT’ı ve otel Wi‑Fi’si bu yolu keser. O zaman ICE’nin röleye ihtiyacı vardır.
TURN medyayı sizin kontrol ettiğiniz sunucudan iletir. Röle dakikaları bant genişliği maliyetidir (çoğu zaman tek yön yolun kabaca iki katı) ve doğru genel IP ilanı ile açık UDP/TCP dinleyicileri ister. Coturn yaygındır; bazı SFU’lar TURN gömer. Süreli kimlik bilgisi zorunludur — tarayıcıya statik röle şifresi göndermeyin.
Bağlanıyorda kalan çağrılar genelde ICE başarısızlığıdır, “kodek yanlış” değildir. Kontrol listesi:
- UDP medya genel IP’de erişilebilir mi, yalnızca özel Docker ağında mı?
- Coturn (veya eşdeğeri) doğru
external-ipilan ediyor mu? - Mobil verideki bir telefon Trickle ICE ile
relayadayı tamamlayabiliyor mu? - Sinyal SDP ve adayları iki yönde gerçekten iletiyor mu?
Açık Wi‑Fi’deki laboratuvar dizüstü bilgisayarları bu hataları gizler. Yığını üretime hazır saymadan önce kısıtlı bir ağdan test edin.
DataChannel ve medya
WebRTC, aynı ICE/DTLS oturumu üzerinden DataChannel da sunar. Oyun durumu, dosya parçaları veya çağrıya sıkı bağlı kontrol mesajları için işe yarar. Uygulama WebSocket’lerinin bedava yerine geçmez: tıkanıklık denetimi, güvenilirlik kipileri ve operasyon araçları farklıdır. Çağrı dışındaki sohbet, varlık ve ürün olayları için normal WebSocket (veya HTTPS) kontrol düzlemi genelde daha nettir. DataChannel’ı çağrıya yakın veri için tutun; ürün mesajlaşmasını WebSocket nedir kalıplarında tutun.
2026: simulcast, SVC, AV1/Opus, WebTransport ve MoQ
Simulcast ve ölçeklenebilir video kodlama (SVC), abone zayıfken SFU’nun tüm odayı yeniden kodlamadan alt katmanı iletmesini sağlar. Karışık ağlarda grup çağrılarını kullanılabilir tutmanın hâlâ pratik yoludur.
Kodekler hareket ediyor: Opus ses için ana işçi kalır; AV1 ve modern video profilleri kalite/bit için tarayıcılarda daha sık görünür. SFU ve istemci SDK’ları SDP’de ne teklif edildiğinde anlaşmalıdır — “her yerde AV1” yalnızca barındırma kararı değildir.
WebTransport (QUIC/HTTP3) ve Media over QUIC (MoQ), düşük gecikmeli istemci–sunucu yayılımı ve yayın tarzı teslimat için önemlidir. İki yönlü toplantı ve ses odaları için WebRTC’yi emekli etmezler. Barındırmayı ICE/TURN için Avrupa düğümüne UDP çalışacak şekilde planlayın; MoQ’yu ürününüz tek-çok canlıya ihtiyaç duyduğunda ek yol olarak görün, SFU’yu silme gerekçesi olarak değil.
Diller ve SDK’lar
WebRTC tek bir dil çalışma zamanı değil, W3C/IETF standardıdır. İstemci ve sunucu yığınları ayrılır:
- JavaScript / TypeScript — tarayıcı Web API (
getUserMedia,RTCPeerConnection). Web ürünleri için varsayılan; MDN ve webrtc.org üzerinde belgelenir. - Node.js — SFU worker’ları için mediasoup ve benzeri kütüphaneler; sinyalizasyon çoğu zaman uygulamanızla aynı Node sürecini paylaşır.
- Go — Pion WebRTC ve LiveKit SFU’su; yüksek pps medya sunucuları için yaygındır.
- Python — botlar, AI katılımcılar ve araçlar için
aiortc(çok kiracılı SFU için olağan seçim değildir). - Java / Kotlin ve Swift — platform WebRTC derlemeleriyle yerel Android ve iOS istemcileri.
- C++ — Google’ın referans
libwebrtc’i; gömülü ve yüksek performanslı medya yolları. - Rust — güvenli sistem servisleri için
webrtc-rs. - C# / .NET — yerel WebRTC etrafında masaüstü ve sunucu sarmalayıcıları.
Toplantıların ötesinde WebRTC niş akış istemcilerinde de görülür — örneğin NVIDIA Isaac Sim’in tarayıcı akış yolu, etkileşimli sim görünümleri için WebRTC kullanır (Isaac Sim WebRTC istemci rehberi). Protokol aynıdır; ürün bir Zoom klonu değildir.
Kurulum ve işletim sistemleri
İstemciler: Chrome, Firefox, Safari ve Edge WebRTC’yi Windows, macOS, Linux, Android ve iOS’ta taşır. Son kullanıcı eklenti kurmaz. Mobil uygulamalar yalnızca uygulama içi tarayıcıya güvenmek yerine yerel bir WebRTC SDK bağlar.
Sunucular: Üretim SFU ve Coturn kurulumları ezici çoğunlukla Linux’tur (Ubuntu/Debian). Windows Server bazı yığınları barındırabilir, ancak Docker imajları, UDP ayar belgeleri ve topluluk runbook’ları Linux varsayar. Ubuntu’da tipik ilk adımlar:
sudo apt update
sudo apt install -y coturn
# SFU örneği: satıcınızın Docker rehberini izleyin (LiveKit, mediasoup worker’ları, Janus)
# Genel arayüzde UDP medya aralığı + TURN için 3478/443 açınLiveKit tarzı düğümler genelde TCP/UDP 443, sertifikalar için TCP 80, bir TCP yedek portu, UDP 3478 ve ana makine ağında geniş bir UDP medya aralığı ister — yalnızca özel bir Docker köprüsü içinde değil. Medya konteynerleri için host ağını tercih edin.
İnanmaya değer gecikme sayıları
Hiç kamera açmayan ham MB/s bench’ten gelen “daha hızlı protokol” iddiasına güvenmeyin. Bunun yerine sektörün gecikme kovalarını kullanın. OpenVidu’nun düşük gecikmeli canlı yayın özeti, görüntülü konferans ve bulut oyununu 100 ms altı etkileşimli katmana yerleştirir (konuşmalar kabaca ~150 ms’den sonra bozulur); Low-Latency HLS/DASH tipik olarak 2–5 saniye civarına düşer; çok saniyelik segmentli klasik HLS/DASH ise çalma listesi tamponu dahil sıkça onlarca saniyede kalır (WebRTC vs HLS and DASH, Part 1). İnsan döngüde tepki vermek zorundaysa WebRTC kazanır; CDN ölçeğinde tek yönlü teslimat isteyip gecikmeyi tolere edebiliyorsanız HLS/DASH kazanır.
Güvenlik varsayılanları ve hâlâ size ait boşluklar
WebRTC’de medya tasarım gereği şifrelidir: anahtar değişimi için DTLS, medya yolu için SRTP — tarayıcılar “şifresiz RTP” anahtarı sunmaz. Bu temel WebRTC Security: How Safe Is It? (DEV) yazısında iyi özetlenir. Boşluklar genelde sizin uygulamanızdadır:
- Sinyal için
wss://yerine düzws://(SDP/ICE üzerinde MITM) - Anonimlik önemliyken P2P host adaylarının IP sızdırması — SFU topolojileri eş IP’lerini birbirinden gizler
- Zayıf uygulama kimliği: şifreli medya, oda token’ı çalan birini durdurmaz
WSS, kısa ömürlü TURN kimlik bilgileri ve yayınlama/abonelik için sunucu tarafı yetkilendirme zorunlu tutun. Kamera/mikrofon erişimi hâlâ tarayıcı izin istemlerinden geçer — bu katman isteğe bağlı değildir.
Kendi barındırma ve yönetilen RTC
Yönetilen RTC SaaS zaman kazandırır: SDK’lar, küresel uçlar, daha az nöbet. Kendi barındırma kontrol kazandırır: veri yerleşimi, ölçekte öngörülebilir birim ekonomi, medyayı bölge hikâyenizin içinde tutma. Birçok ekip yönetilenle başlar; fatura veya uyumluluk zorlayınca sıcak odaları veya yalnızca AB kiracılarını kendi SFU’suna taşır.
Kendi barındırma maliyeti yalnızca VPS satırı değildir. Coturn kimlik bilgileri, sertifika yenileme, UDP güvenlik duvarı, sürüm yükseltmeleri ve yük testleri size aittir. Ekipte ICE istatistiği okuyan yoksa yönetilende daha uzun kalın. Avrupa’da zaten düzenli Linux filoları işletiyorsanız SFU düğümü normal bir servistir — WordPress kutusu gibi değil, ağ cihazı gibi boyutlandırın.
Avrupa’da WebRTC barındırma: gecikme, UDP ve trafik
Etkileşimli medya RTT ve kayba duyarlıdır. Avrupa’da barındırmak, AB kullanıcılarını medyayı başka kıtaya “API orada diye” sektirmeden daha kısa yolda tutar. SFU ve TURN’ü katılımcılara yakın koyun; sohbet veritabanlarını uyumluluk modeliniz nereyi gerektiriyorsa orada tutabilirsiniz, ama her RTP paketini yanlış bölgeden zorlamayın.
WebRTC UDP tercih eder. Kapalı UDP aralıklı şık bir panel yine bozuk çağrıdır. Bütçelemeniz gerekenler:
- Genel arayüzde açık UDP medya portları (SFU’ya göre değişir; örnek
10000–20000veya50000–60000) - UDP/TCP üzerinde TURN ve kilitli istemciler için sıkça 443 üzerinde TLS
- Sürekli çıkış — HD odalar ve röleli TURN dakikaları aylık trafik kotasını statik sitelerden hızlı yer
EuroVDC Bulut Sunucu planlarında Avrupa düğümü için pratik tabanlar:
- Cloud VPS Medium Plus — 4 vCPU / 8 GB — laboratuvar, 1:1, küçük odalar, Coturn + hafif SFU; katalog yaklaşık €66.99/ay (KDV hariç; ürün sayfasından doğrulayın)
- Cloud VPS XL Plus — 8 vCPU / 24 GB — orta eşzamanlılık için üretim SFU + TURN; katalog yaklaşık €169.99/ay
- Cloud VPS XXL — 12 vCPU / 32 GB — daha yoğun odalar veya simulcast ağır yükler
Küçük, RAM açlığı çeken örnekler yerine hesaplama ağır şekilleri tercih edin. Tek VPS saniye başına paket veya trafik kotasını doyurunca TURN’ü SFU’dan ayırın, sonra sürekli çok gigabit yayılım için dedicated kapasite düşünün. Sofia veri merkezimizden yumuşak yol kontrolü: satış sunumunda bölgesel gecikme vaat etmeden önce Looking Glass.
Operatör kontrol listesi
- Genel IPv4 (ve ilan ediyorsanız IPv6), uygulama + TURN için DNS, güvenilir TLS — tarayıcılar kamuya açık sitelerde gelişigüzel self-signed’ı reddeder
- UDP medya aralığını uçtan uca açın; yalnızca ofis LAN’ından değil mobil veriden doğrulayın
- Süreli TURN kimlik bilgileri; oda veya kullanıcıya göre kapsam ve rotasyon
- Coturn / TURN’e doğru genel IP’yi bildirin (
external-ip); Docker SFU’larda host ağı iç içe NAT’tan iyidir - Yük altında açıklanamayan kayıp görürseniz UDP tamponlarını yükseltin:
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.rmem_default = 26214400
net.core.wmem_default = 26214400- Trickle ICE’yi açın; ICE istatistiklerini toplayın (RTT, aday tipi host / srflx / relay)
- SFU’nun yeniden kodlamadan düşebilmesi için simulcast veya SVC teklif edin
- Yeniden bağlanma fırtınalarını ve TURN ağır istemcileri yük test edin; lansman haftasından önce trafiği boyutlandırın
LiveKit tarzı bir düğüm için tipik port yüzeyi (yığınıza göre ayarlayın): TCP/UDP 443, sertifikalar için TCP 80, kullanılıyorsa SFU TCP yedek yolu, TURN için UDP 3478, artı genel IP’de UDP medya aralığı.
İlgili rehberler
Cloud VPS kapasitesi sipariş edin, UDP yolunu açın, SFU + TURN kurun ve kısıtlı bir ağdan test edin. Medyasız uygulama mesajlaşması için WebSocket nedir ile devam edin. Yan yana karar matrisi ve hibrit kalıp için WebRTC vs WebSocket okuyun.
