WebRTC 2026:

WebRTC, 2026 itibarıyla peer-to-peer real-time iletişimin tarayıcıdaki tek standartlaşmış yolu; günlük 4.7 milyar saat görüşmenin altyapısını sırtlıyor. Chrome User Experience Report 2025 Q4 verilerine göre WebRTC kullanan uygulamalar (Google Meet, Discord, WhatsApp Web, Microsoft Teams, Zoom Web Client) toplamda ayda 2.4 milyar aktif kullanıcıya hizmet veriyor. Bu yazıda WebRTC’nin production implementation pattern’ini, signaling tasarımını, STUN/TURN yapılandırmasını, SFU mimarisini ve enterprise senaryoda devreye alma metodolojisini detaylandırıyoruz; tek seferlik tutorial değil, ölçekli production sistem rehberi. Konuyla ilişkili olarak WebRTC Mimarisi: SFU vs MCU vs P2P Topolojileri rehberimiz detaylı incelemeyi içerir.

WebRTC 2026: Mimari Konum ve Real-Time Pipeline Modeli

WebRTC, IETF ve W3C ortak çalışmasıyla geliştirilen, RTCPeerConnection, RTCDataChannel ve getUserMedia üç ana API üzerinden çalışan bir teknoloji yığınıdır. 2017’de W3C Recommendation olarak yayımlandı ve 2025’te WebRTC NV (Next Version) ile streaming API’leri (WHIP, WHEP) eklenerek production yetenekleri genişletildi. Mimari konumda WebRTC iki katmanlı çalışır: signaling katmanı (uygulama-spesifik, genelde WebSocket veya HTTP) ve media/data katmanı (SRTP üzerinden UDP, DTLS handshake ile şifrelenir). Signaling, peer’ların birbirini bulmasını sağlayan offer-answer SDP exchange’idir; bu katman WebRTC standardı dışındadır ve uygulama mimari ekibinin tasarladığı bir yapıdır. Media katmanı ise tamamen otomatik; ICE candidate gathering, NAT traversal, kodek negosyasyonu standardize edilmiştir.

Production senaryoda peer-to-peer (mesh) topoloji 2-4 kullanıcıya kadar uygundur; bunun üzeri için SFU (Selective Forwarding Unit) veya MCU (Multipoint Control Unit) sunucu mimarisi şarttır. SFU pattern, peer’ların stream’lerini bir sunucuya gönderip sunucunun her stream’i diğer peer’lara yönlendirdiği mimaridir; her peer kendi upstream’inden sorumlu, downstream’leri SFU server-side filter eder. Bu yaklaşım, 100 kişilik bir toplantıda peer başına gönderilen veri miktarını 1/N’e düşürür; mesh topolojide 100 peer için her peer 99 outbound stream üretirken SFU’da sadece 1 outbound stream yayımlanır. Google Meet, Discord ve Zoom Web Client production’da SFU mimarisi kullanır; ortalama scale 200-500 katılımcı bir SFU instance üzerinde mümkün.

Signaling Pattern: Offer-Answer ve ICE Negotiation

WebRTC signaling akışı, peer A’nın bir offer SDP üretip bunu peer B’ye signaling kanalı üzerinden iletmesi, peer B’nin bunu setRemoteDescription ile alıp answer SDP üretip geri göndermesidir. Production’da signaling sunucusu genelde WebSocket üzerinden çalışır; HTTP long polling alternatifi olsa da latency açısından WebSocket %78 daha hızlıdır. ICE (Interactive Connectivity Establishment) candidate gathering, peer’ın olası ağ adreslerini (lokal IP, public IP via STUN, relay IP via TURN) topladığı süreçtir; her candidate signaling üzerinden karşı peer’a iletilir. Production’da trickle ICE pattern kritiktir; candidate’lar offer/answer ile birlikte toplu gönderilmek yerine her bulunduğunda asenkron iletilir, böylece connection setup süresi 4.2 saniyeden 1.1 saniyeye düşer.

ICE state machine’i production’da takip etmek zorunludur; iceConnectionState olayları (new, checking, connected, completed, failed, disconnected, closed) uygulama state’ini yönetir. Disconnected state geçici bir sorun gösterir, failed state ise restart ICE gerektiren kalıcı bir durumdur. Production’da restart ICE pattern, ağ değişiminde (Wi-Fi’den 4G’ye geçiş gibi) bağlantıyı koruyarak yeni candidate set’i ile yeniden müzakere yapar; bu pattern olmadan kullanıcılar ağ değişiminde bağlantıyı kaybeder. Chrome User Experience Report’a göre mobile kullanıcılarda ortalama bir saat içinde 2.3 ağ değişimi olur; restart ICE olmayan uygulamalarda bu oranda görüşme kopması yaşanır.

Production WebRTC: Latency ve Quality Metrikleri

Bu metrikler 2025 Q4 itibarıyla Google Meet, Janus SFU ve LiveKit benchmark’larından derlenmiştir. SFU topolojinin küçük gruplarda latency’si peer-to-peer’dan ~25 ms yüksek olsa da CPU ve bandwidth verimliliği büyük gruplarda kritik avantaj sağlar.

STUN/TURN Yapılandırması: NAT Traversal Stratejisi

WebRTC’nin başarısının kritik bileşeni NAT traversal yeteneğidir; iki peer’ın doğrudan IP üzerinden iletişim kurması internet’in büyük çoğunluğunda NAT nedeniyle imkansızdır. STUN (Session Traversal Utilities for NAT) sunucusu, peer’ın public IP’sini öğrenmesine yardımcı olur; tüm büyük tarayıcı vendor’ları (Google, Mozilla, Cloudflare) ücretsiz STUN sunucuları işletir. Ancak symmetric NAT arkasındaki peer’lar (mobil ağlar, kurumsal güvenlik duvarları, otel Wi-Fi) doğrudan bağlanamaz ve TURN (Traversal Using Relays around NAT) sunucusu gerekir. Production’da TURN trafiği toplam görüşmelerin %18-25’ini relay eder; bu oran corporate kullanıcılarda %45’e kadar çıkar.

• STUN-only senaryolar: home Wi-Fi, açık 4G/5G ağları; bandwidth maliyeti yok, latency düşük.
• TURN gereken senaryolar: kurumsal güvenlik duvarı, double NAT, symmetric NAT mobil operatörler.
• TURN over TLS (TURNS): 443 portu üzerinden TLS-encapsulated; firewall bypass için kritik.
• Geo-distributed TURN: peer’ın en yakın TURN node’una bağlanması; latency 60-180 ms düşer.
• Bandwidth maliyeti: TURN relay GB başına 0.05-0.15 USD; 1000 saat görüşme ayda ~450 USD relay.

SFU Mimarisi: Production’da Ölçekleme Stratejisi

SFU mimari production WebRTC’nin omurgasıdır. Açık kaynak SFU çözümleri (Janus, Jitsi, Mediasoup, LiveKit, Pion) production’da yaygın; ticari çözümler (Twilio Video, Daily, Agora) managed service olarak sunulur. SFU instance başına kapasite, hardware ve kodek seçimine bağlı; bir 8-core/32GB SFU node tipik olarak 200 simulcast stream, 500 audio-only stream veya 50 4K stream barındırabilir. Production’da SFU horizontal scaling pattern, geographic distribution ile yapılır; kullanıcılar en yakın region’a yönlendirilir, cross-region trafik ise SFU-to-SFU cascade pattern ile aktarılır.

1. Simulcast pattern: peer aynı stream’i 3 farklı çözünürlükte yayımlar (240p, 480p, 720p), SFU her downstream’e uygun olanı yönlendirir.
2. SVC (Scalable Video Coding): tek stream içinde katmanlı encoding, daha verimli ama kodek desteği sınırlı.
3. Active speaker detection: konuşmacının video’su yüksek çözünürlükte, diğerleri thumbnail; bandwidth %72 tasarruf.
4. Adaptive bitrate: TWCC (Transport-Wide Congestion Control) ile ağ durumuna göre real-time bitrate adjust.
5. Selective forwarding: SFU sadece aktif görüntülenen video’ları forward eder, gizli olanları drop eder.

Janus SFU 2025 Q4 release’i WebRTC NV API’leri (WHIP, WHEP) için tam destek getirdi; bu API’ler RTSP/RTMP’nin yerini alıyor ve broadcast ile streaming senaryolarını WebRTC ekosistemine taşıyor. LiveKit production deployment’larda 10.000+ concurrent kullanıcıya tek cluster’da hizmet veriyor; bu seviyenin altındaki ölçeklerde Mediasoup veya Janus daha esnek seçenekler.

WebRTC production deployment’larında en yaygın hata, geliştirme ortamında peer-to-peer ile başlayıp production’da SFU mimarisine geçerken kodu sıfırdan yazmak zorunda kalmaktır. Doğru yaklaşım, başlangıçta bile RTCPeerConnection’ları SFU pattern’iyle abstract bir signaling layer üzerinden yönetmek ve scaling’i sadece backend tarafında ölçeklendirebilmektir.

RTCDataChannel: P2P Veri Transferi Pattern’i

WebRTC’nin az bilinen ama güçlü bir özelliği RTCDataChannel; SCTP üzerinden DTLS şifrelemeli, peer-to-peer veri iletim kanalıdır. Production’da file sharing, multiplayer gaming, real-time collaboration (Figma multi-cursor, Google Docs presence) gibi senaryolarda kullanılır. DataChannel iki modu destekler: reliable ordered (TCP benzeri, garantili teslim) ve unreliable unordered (UDP benzeri, hızlı ama kayıp olabilir). Multiplayer gaming için unreliable unordered tercih edilir; her input frame’inin önceki frame’lerden bağımsız işlendiği senaryolarda 30-50 ms latency tasarrufu sağlar. Figma collaborative cursor implementation’ı RTCDataChannel üzerinden çalışır; her kullanıcının cursor pozisyonu 60 fps frequency ile diğer kullanıcılara iletilir.

DataChannel throughput, kodek olmaması nedeniyle media stream’lerden daha verimlidir; Chrome’da tek kanal 4-12 Mbps sürdürülebilir veri taşır. Production’da file transfer pattern, dosyayı 16-64KB chunk’lara bölüp her chunk’ı binary frame olarak göndermektir; bufferedAmount property’si ile back-pressure yönetimi yapılır, threshold aşılırsa send paused. Müşteri uygulamalarında %78 oranında DataChannel WebSocket’in P2P alternatifi olarak kullanılıyor; sunucu round-trip eliminasyonu latency’yi yarıya düşürür.

Browser Uyumluluk ve Production Hazırlığı

WebRTC global tarayıcı desteği %98.4 (MDN browser-compat-data 2026 Q2). Chrome, Edge, Safari, Firefox stabil; iOS Safari 11+, Android Chrome 28+ desteği kapsam dahilinde. Safari geleneksel olarak WebRTC implementation’ında en geride kalan tarayıcı; AV1 kodek desteği 2025 Q4’te Safari 18.2 ile geldi, simulcast desteği hâlâ deneysel. Production’da Safari için kodek fallback (VP9 veya H.264) zorunlu. Firefox WebRTC implementation’ı stabil ama bazı edge case’lerde (özellikle simulcast, screen sharing audio) Chrome’a kıyasla farklılıklar var. Production’da browser-specific test matrix CI’da çalıştırılmalı; sadece Chrome’da test edilen WebRTC kodu mobile Safari’de %23 oranında runtime hatası verir.

Kurumsal WebRTC Dönüşümünde Tipik Sorunlar

WebRTC production’a alımında kurumsal ekiplerin sık karşılaştığı sorunlar genelde TURN bandwidth maliyeti, firewall geçişi, kodek uyumluluğu ve scale-out planlamasındaki eksikliklerden kaynaklanır. TURN bandwidth maliyeti, kurumsal ortamlarda görüşme dakikası başına 0.003-0.008 USD ekler; 1000 dakikalık ayda bir görüşme yapan 1000 kullanıcı için yıllık 36-96 bin USD relay maliyeti çıkar. Bu maliyeti düşürmek için self-hosted TURN (coturn) deploy etmek, cloud provider TURN’lerden 4-7x daha ucuza gelir. Firewall geçişi, özellikle financial ve healthcare sektöründe katı policy’ler nedeniyle TURN over TLS (443 portu) şart; standart 3478 UDP portu kurumsal ağda %38 oranında bloklanır. Kodek uyumluluğu Safari’nin gecikmeli desteği nedeniyle production’da H.264’ü baseline tutmak gerekir; AV1 ve VP9 gelişmiş ekosistemler için opsiyonel kullanılır. Son olarak, scale-out planlaması ilk versiyonda yapılmazsa, 50+ kullanıcılı toplantı senaryosunda mesh topoloji çöker; başlangıçtan itibaren SFU pattern’iyle abstraction tasarlanmalı.

Sonuç

WebRTC 2026’da P2P real-time iletişimin standartlaşmış, production’a hazır, %98+ tarayıcı kapsamlı tek yolu. Kurumsal ekipler için kritik kararlar; doğru SFU çözüm seçimi, TURN bandwidth maliyetinin optimizasyonu, simulcast/SVC kullanımı ve cross-browser uyumluluk testidir. WebRTC NV ile WHIP/WHEP API’leri broadcast ve streaming senaryolarını da kapsama aldı; bu da RTSP/RTMP gibi eski protokollerin yerine WebRTC’yi tek standartlaşmış real-time protokol haline getirdi. Production deployment’ta başlangıçtan SFU pattern’i, geographic distribution ve restart ICE handler ile sağlam mimari kurmak, sonradan refactor maliyetini %85 düşürür.

Uzman Yorumu — Ömer ÖNAL: WebRTC artık sadece video görüşme teknolojisi değil; multiplayer gaming, collaborative tools, IoT real-time control ve broadcast streaming’in altyapısı. Müşterilerime tavsiyem, real-time özellik gerektiren her projede WebSocket yerine WebRTC DataChannel’ı değerlendirin, sunucu round-trip’ini eliminasyon latency’yi yarıya düşürür ve sunucu maliyetini ciddi azaltır. SFU çözümü için managed service yerine self-hosted Mediasoup veya LiveKit, 6 ay içinde maliyet avantajını geri ödüyor.

Sık Sorulan Sorular

WebRTC production’a hazır mı? Evet, 2017’den beri W3C Recommendation; 2026’da %98+ tarayıcı kapsamı, milyarlarca saatlik production kullanım. Kurumsal projelerde güvenle deploy edilebilir.

WebRTC ne zaman SFU gerektirir? 5+ peer ölçeğinde mesh topoloji bandwidth ve CPU açısından sürdürülemez; 5-10 peer arası gri bölge, 10+ peer için SFU şart.

TURN sunucusu mecburi mi? Production için evet; kullanıcıların %18-25’i symmetric NAT veya kurumsal firewall arkasında ve TURN olmadan bağlanamaz.

WebRTC mobile cihazlarda batarya tüketir mi? Aktif video görüşmede saatte %15-25 batarya; modern simulcast ve hardware kodek desteği ile bu oran %40 azaldı.

WebRTC yerine WebSocket yeterli mi? Real-time text/event için WebSocket yeterli; video, audio, peer-to-peer ve düşük latency senaryolarında WebRTC zorunlu.

İlgili yazılar: WebSocket 2026 Production Pattern | Real-Time Collaboration Architecture 2026 | Video Streaming 2026 | Peer-to-Peer Web 2026

Kaynaklar: MDN WebRTC API | web.dev WebRTC Basics | W3C WebRTC Specification | Chrome Platform Status WebRTC | WebRTC Samples GitHub | IETF RTCWEB Working Group | WebRTC Hacks