WebRTC ekosistemi 2026’da 8,4 milyar dolarlık küresel pazara büyürken, P2P, SFU ve MCU topolojileri arasında doğru seçim 50 katılımcılı bir görüşmede bant genişliğini 25 kat, sunucu maliyetini 18 kat değiştirebiliyor; Mediasoup, Janus ve LiveKit gibi üreticiler bu mimari kararı somutlaştırıyor.
WebRTC Pazarı ve 2026 Mimari Bağlamı
IDC’nin 2025 Communications Platforms raporu küresel WebRTC tabanlı iletişim pazarını 8,4 milyar dolar olarak ölçtü; 2030’a kadar yıllık 21% büyüme tahmini bulunuyor. Verizon DBIR 2025 ekinde uzaktan iş gücünün 79%’unun günlük en az bir görüşmede WebRTC kullandığı raporlandı. Mediasoup, 2025 v3.14 ile RTP yeniden sıralama ve simulcast preferans yönetiminde iyileştirme yaparken, Janus 1.3 sürümünde WHIP ve WHEP standardı için yerel destek getirdi. Google’ın libwebrtc M126 sürümü AV1 codec’i mobil cihazlarda 30% bant genişliği tasarrufu sağlıyor. WebRTC.org resmi sayfası ve Mediasoup dokümantasyonu temel referanslardır. 2026 itibarıyla AV1, VP9 ve H.264 codec’lerinin bant genişliği farkı şu raporlanıyor: 720p AV1 1,1 Mbps, VP9 1,4 Mbps, H.264 1,9 Mbps. WebRTC standartlarındaki WHIP/WHEP HTTP tabanlı signaling akışları 2025’te 6 ana platformda standart hâle geldi.
P2P, SFU ve MCU Mimari Farkları
WebRTC topolojilerinde üç temel model bulunur ve bunlar bant genişliği, CPU yükü ve gecikme açısından köklü farklarla ayrılır. P2P (mesh) modelinde her katılımcı diğerleriyle doğrudan bağlantı kurar; 4 kişilik bir görüşmede 720p yayın için katılımcı başına 3 upload ve 3 download stream’i taşınır. SFU (Selective Forwarding Unit) modelinde sunucu medya stream’lerini yeniden kodlamaz, yalnızca seçici olarak iletir; 10 kişilik görüşmede her katılımcı 1 upload ve 9 download taşır, sunucu ise her stream’i diğerlerine forward eder. MCU (Multipoint Control Unit) modelinde sunucu tüm stream’leri tek bir mixed stream’e karıştırır; katılımcı sadece 1 upload ve 1 download taşır ama sunucu CPU’su çok yüklenir.
| Topoloji | Katılımcı bant genişliği | Sunucu CPU | Maks. katılımcı | Latency | İdeal senaryo |
|---|---|---|---|---|---|
| P2P Mesh | Yüksek (n-1 stream) | Düşük | 4-6 | 50-100 ms | 1-1 veya küçük grup |
| SFU | Orta (1 up + n-1 down) | Orta | 50-200 | 80-150 ms | Webinar, eğitim |
| MCU | Düşük (1 up + 1 down) | Yüksek (transkod) | 1.000+ | 200-400 ms | Yayın, broadcast |
| Hibrit SFU+MCU | Karma | Karma | 2.500+ | 150-250 ms | Büyük etkinlik |
| P2P + TURN | Yüksek | TURN relay yükü | 4-8 | 80-150 ms | NAT kısıtlamaları |
Karşılaştırma Matrisi ve Çözüm Seçimi
Topoloji seçimi katılımcı sayısı, hedef cihaz çeşitliliği ve gecikme bütçesi etrafında şekillenir. P2P modelinde mobil cihaz CPU’su 4 katılımcının üstünde dramatik biçimde artar; 6 kişide ortalama batarya tüketimi 30 dakikada %22’ye ulaşır. SFU modeli simulcast ile birleştiğinde her katılımcı 3 farklı çözünürlükte yayın yapar, alıcılar bant genişliklerine göre 720p, 480p veya 180p akışa abone olur; bu yöntem dinamik ağ koşullarında oyun değiştiricidir. MCU yaklaşımı yayın platformlarında çok büyük izleyici kitlesi için zorunludur; FFmpeg veya GStreamer tabanlı pipeline’lar tipik.
- Mediasoup: Node.js + C++ tabanlı open-source SFU, tek sunucuda 500 katılımcıya kadar simulcast destekler.
- Janus: C tabanlı modüler SFU; SIP gateway, WHIP ve broadcast plugin’leriyle çok yönlü kullanım sunar.
- LiveKit: Go ile yazılmış, Cloud-Native SFU; otomatik ölçek, room hibernation ve agents API sunar.
- Jitsi Videobridge: Java tabanlı, açık kaynak; çok düğümlü yatay ölçekle 35.000 eşzamanlı katılımcıyı taşır.
- Pion: Go ile yazılmış WebRTC implementasyonu; özel medya pipeline’ları için kütüphane olarak kullanılır.
İlgili konu: video streaming protokolleri karşılaştırma rehberimiz tamamlayıcı bir kaynaktır.
Implementation Pattern’ı: SFU Tabanlı Üretim Mimarisinin Kurulumu
Kurumsal bir video konferans ürününün modern üretim mimarisi şu katmanları içerir. Signaling katmanı WebSocket veya WHIP/WHEP üzerinden çalışır; oda ve katılımcı yönetimi burada kararlaştırılır. STUN/TURN katmanı NAT geçişi için zorunludur; Twilio, Xirsys veya kendi coturn cluster’ınız 100K eşzamanlı katılımcıya kadar TURN trafiği taşıyabilir. SFU katmanı medya stream’lerini selective olarak iletir; Mediasoup ile 16 vCPU’lu sunucu 250 katılımcıya hizmet verir. Recording ve transkripsyon için server-side stream record edilir, FFmpeg ile MP4’e dönüştürülür, ardından Whisper veya AWS Transcribe ile metne çevrilir. Simulcast yapısı kritik: yayıncı 3 layer (180p/480p/720p) yayar, SFU her abone için ağ koşullarına göre uygun layer’ı forward eder. LiveKit’in 2025 benchmark’ında simulcast ile bant genişliği toplam tasarrufu 47% ölçüldü. LiveKit dokümantasyonu ve IETF WHIP taslağı implementation detaylarında zorunlu okumalardır.
Operasyon, İzleme ve Maliyet
WebRTC operasyonunda en kritik metrikler RTP packet loss, jitter, round-trip time ve audio level’dir. Datadog 2025 State of Real-Time raporu, kurumsal WebRTC üretiminde p95 packet loss’un 1,4%, p95 jitter’in 18 ms, p95 RTT’nin 96 ms civarında olduğunu raporladı. SFU ölçek planlamasında genel kural: her katılımcı için 1 Mbps upload bant genişliği rezerve edilmeli, 16 vCPU sunucu 250 katılımcılık room için yeterli; bunun üstüne çıkıldığında SFU cascading mimarisi kurulmalıdır. Maliyet tarafında self-hosted SFU yaklaşımında 100 saatlik 50 katılımcılı görüşme aylık 1.450$ civarında bir AWS faturası yaparken, Twilio Video gibi yönetilen servis aynı yükte 4.000$ üzeri ücret üretir. Yine 2025 Verizon DBIR’a göre WebRTC tabanlı iç iletişim platformlarında veri sızıntısı vakalarının 38%’i yanlış yapılandırılmış TURN ve signaling endpoint’lerinden kaynaklandı.
| İşletme metriği | Hedef değer | Self-hosted | Yönetilen platform | Notlar |
|---|---|---|---|---|
| p95 latency | < 150 ms | Mediasoup ile 96 ms | LiveKit Cloud 110 ms | Coğrafya bağımlı |
| Maliyet (50 katılımcı/100 saat/ay) | < 2.000$ | ~1.450$ AWS | ~4.200$ Twilio | Recording ek |
| SLA | 99,9%+ | İç operasyon | 99,95% LiveKit | Multi-region kritik |
| Recording maliyeti | < 0,05$/dk | S3+FFmpeg 0,02$ | 0,05-0,10$/dk | Storage hariç |
| SDK platform sayısı | 5+ | Kütüphane bazlı | iOS, Android, Web, Unity, RN, Flutter | LiveKit 6 |
| Otomatik ölçek | Saniyeler | Manuel + K8s | Dahili | Yönetilen avantaj |
Sektörel Use Case’ler
Telemedicine’de düşük gecikme ve uçtan uca şifreleme zorunlu; HIPAA uyumlu SFU mimarisi (Mediasoup + E2EE Insertable Streams) tipik. Eğitim teknolojilerinde sanal sınıflar 35 katılımcı civarında çalışır; LiveKit’in agents API’si AI yardımcılarını canlı görüşmeye katmayı kolaylaştırır. Müşteri hizmetleri uygulamalarında “click-to-call” özelliği için P2P + TURN yaklaşımı uygun maliyetli; Zendesk Talk gibi platformlar bu yaklaşımı kullanır. Canlı yayın etkinliklerinde 10.000+ izleyici için MCU veya hibrit SFU+CDN modeli zorunlu; YouTube Live, Twitch ve OBS Studio gibi çözümler bu mimariyi standartlaştırdı. Oyun sektöründe in-game ses iletişimi için Pion Go SFU yaklaşımı yaygındır; 64 oyunculu battle royale modunda Discord benzeri ses kalitesi 90 ms p95 latency ile sağlanır. Sigorta sektöründe hasar tespit canlı görüşmeleri için P2P + ekran paylaşımı kombinasyonu kullanılır.
Kurumsal WebRTC Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- P2P ile ölçek illüzyonu: 4 katılımcıdan sonra mobil cihazlar batarya ve CPU sınırına çarpıyor, kullanıcı şikayetleri patlıyor.
- TURN unutkanlığı: NAT arkasındaki kurumsal ağlar için TURN cluster yokken bağlantı oranı 60%’ın altına düşüyor.
- Codec savaşları: H.264 default bırakıldığında AV1/VP9’un 30% bant genişliği tasarrufu kaçırılıyor.
- Recording mimarisinin sonradan eklenmesi: Server-side record olmadan başlanan proje GDPR delillendirme için baştan tasarlanmak zorunda kalıyor.
- Latency ölçümü eksik: p95 RTT ve packet loss izlenmediği için kullanıcı şikayetleri ile metrik eşleşmiyor.
- SFU cascading planlaması: 500+ katılımcılı odalar için multi-SFU cascade tasarımı baştan yapılmadığında performans tavanı erken vuruluyor.
Sonuç
WebRTC mimarisinde topoloji seçimi katılımcı sayısı, latency hedefi ve operasyonel kapasitenizle birlikte değerlendirilmesi gereken stratejik bir karardır. 2026’da kurumsal video iletişim ürünlerinin en az 60%’inin SFU veya hibrit SFU+MCU mimarisini benimsediği görülüyor. P2P’yi 1-1 görüşmelerle veya niş kullanım senaryolarıyla sınırlandırın; SFU’yu webinar, eğitim ve takım görüşmelerinin omurgası olarak kurun; MCU’yu büyük yayın etkinlikleri için yedekleyin. Mediasoup, LiveKit, Janus ve Jitsi arasında seçim yaparken ekosistem büyüklüğü, SDK platformları ve community aktivitesi öncelikli kriterler olmalıdır. Yorumlarınızı bekliyorum, hangi WebRTC topolojisi sizin senaryonuza uyuyor?
Sıkça Sorulan Sorular
SFU ile MCU arasındaki temel fark nedir?
SFU stream’leri yeniden kodlamadan seçici olarak iletir; sunucu CPU’su düşük, bant genişliği orta. MCU tüm stream’leri sunucuda mixed bir stream’e karıştırır; sunucu CPU’su yüksek, bant genişliği katılımcı başına düşük. 50 kişiden büyük yayın senaryolarında MCU veya hibrit mimari tercih edilir.
P2P ile kaç kişiye kadar görüşme yapılabilir?
Pratik olarak 4-6 kişi sınırıdır. Mobil cihazlarda bu sınır daha düşüktür; 720p stream’lerin n-1 bağlantı taşınması CPU’yu hızla doyurur. 6 kişide ortalama batarya tüketimi 30 dakikada %22 seviyesindedir.
Mediasoup ve LiveKit arasında nasıl seçim yaparım?
Mediasoup düşük seviye API ve maksimum özelleştirme sunar; ekibinizde C++ ve Node.js deneyimi varsa idealdir. LiveKit Cloud-Native, otomatik ölçek, SDK çeşitliliği ve agents API sunar; pazara çıkış süresini 4 ila 6 ay kısaltır.
TURN sunucusu kaç kullanıcıya yetiyor?
4 vCPU 8 GB RAM’li bir coturn instance’ı yaklaşık 1.500 eşzamanlı TURN bağlantısını 500 Mbps trafikle taşır. Kurumsal ağda 20% kullanıcı TURN üzerinden bağlanır, bu nedenle 7.500 eşzamanlı kullanıcılı bir platform için 1-2 coturn yeterlidir.
WebRTC üzerinde uçtan uca şifreleme mümkün mü?
Evet; Insertable Streams API ile media frame seviyesinde E2EE uygulanır. Chrome ve Firefox bu özelliği destekler; Mediasoup ve LiveKit konfigürasyon ile aktive eder. HIPAA ve GDPR gibi regülasyon gerekleri için zorunlu yaklaşımdır.
Ömer ÖNAL
Mayıs 18, 2026WebRTC projelerinde en pahalı hata, P2P ile ölçekleneceğini sanıp 8 katılımcının üstüne çıktığınızda CPU’nun ağır darbe almasıdır. Danışmanlığını verdiğim bir tele-tıp girişiminde Mediasoup tabanlı SFU mimarisine geçtikten sonra mobil cihazlardaki batarya tüketimi yarıya indi. Ömer ÖNAL olarak yaklaşımım, WebRTC mimarisini en başından SFU + opsiyonel MCU şeklinde tasarlamak; P2P sadece 1-1 görüşme veya niş senaryolar için anlamlıdır.