#TL;DR

#WebRTC Nedir?

Belge, WebRTC'yi şöyle tanımlar: bir tarayıcının, bir JavaScript API'si üzerinden erişilen ve birlikte çalıştığında iki uç nokta arasında doğrudan ses, video ve veri akışını mümkün kılan bir yapı taşları kümesi.

Burada kritik olan şey "doğrudan" kelimesidir. Geleneksel ses/görüntü uygulamaları içeriği bir sunucu üzerinden geçirir; WebRTC'nin amacı ise mümkün olduğunca peer-to-peer, yani sunucu aracılığı olmadan çalışmaktır. Sunucu sadece "tanışma" aşamasında, iki tarafı birbirine tarif etmek için devreye girer — sonrasında medya doğrudan akar.

İki uygulamanın farklı geliştiriciler tarafından yapılması da mümkündür: Eğer her iki uygulama da WebRTC protokol takımına sadık kalırsa, aralarında uyumlu çalışırlar. Belge bu birlikte çalışabilirliğin bir tarayıcı varsayımına dayanmadığını özellikle vurgular: Bir uçta tarayıcı, diğer uçta C++ ile yazılmış native bir uygulama olabilir.

#Tasarım Felsefesi

WebRTC protokol takımının arkasındaki temel yaklaşım şudur: Zorunlu bir taban tanımla, üstüne özgürce inşa edilsin. Belge bunu özellikle önemser çünkü internet protokollerinin tarihi, "iyi ama opsiyonel" özelliklerin pratikte kimsenin uyumlu olmadığı bir kakofoniye dönüştüğü örneklerle doludur.

Bu nedenle her WebRTC uygulamasının destek vermesi zorunlu olan minimum bir kümesi vardır: belirli ses ve video codec'leri, ICE, DTLS, SRTP ve daha birkaç şey. Bu zorunlu temel sayesinde iki rastgele WebRTC uç noktası daima konuşabilir — bağlantının başarısızlığı için "ortak codec yoktu" gibi bir mazeret hiçbir zaman geçerli olmaz.

Ek olarak: zorunlu temel tanımlanırken yenilik özgürlüğü de korunur. Belirtim arayüzler üzerinden yapılır, uygulama detayları üzerinden değil. İki uygulama birbirleriyle anlaşabildiği sürece, bunu nasıl başardıkları kendi tasarım kararlarıdır.

#API ve Protokol Ayrımı

WebRTC iki ayrı standart çabasından oluşur ve bu ayrımı anlamak çok önemlidir:

• IETF tarafı — Kabloda ne olduğunu tanımlar. Yani iki uç nokta arasında akan baytların formatını, sırasını ve anlamını. Bu RFC ailesidir.
• W3C tarafı — Tarayıcıda ne olduğunu tanımlar. Yani JavaScript geliştiricisinin gördüğü API yüzeyini: RTCPeerConnection, getUserMedia(), RTCDataChannel gibi nesneler.

Bu iki taraf kasıtlı olarak ayrılmıştır. Amaç, protokole sadık kalan ama JavaScript API'sini hiç uygulamayan native uygulamaların da WebRTC ekosistemine katılabilmesidir. Yani bir tarayıcı, native bir mobil uygulamayla doğrudan WebRTC üzerinden konuşabilir — ikisi de aynı kabloyu konuştuğu sürece.

#Mimari Resim

Tarayıcı RTC Yamuğu

Belgenin en bilinen şeması "Tarayıcı RTC Yamuğu"dur (Browser RTC Trapezoid). Dört köşeli bu şekil, tipik bir WebRTC dağıtımının nasıl çalıştığını anlatır:

+-----------+                  +-----------+
|  Web      |                  |  Web      |
|  Sunucu A |◄────────────────►|  Sunucu B |
+-----------+   Sinyalleşme    +-----------+
      ▲                              ▲
      │ HTTPS / WS                   │ HTTPS / WS
      ▼                              ▼
+-----------+                  +-----------+
| Tarayıcı  |◄────────────────►| Tarayıcı  |
| (Peer A)  |    Ortam Yolu    | (Peer B)  |
+-----------+      (P2P)       +-----------+

Şemanın anlattığı en kritik şey şu: üst yol (sunucular arası sinyalleşme) WebRTC'nin kapsamı dışındadır. SIP, XMPP, kendi REST API'niz, Socket.IO — ne kullanırsanız kullanın, WebRTC bunu umursamaz. Alt yol ise tamamen WebRTC'ye aittir: ses, video ve data doğrudan iki tarayıcı arasında akar.

Bu ikilik tasarımın kalbidir. Sinyalleşme katmanını standartlaştırmamak, belge yazarlarının kasıtlı bir tercihiydi — çünkü her uygulamanın kullanıcı modeli, oda yapısı ve kimlik doğrulama ihtiyacı farklıdır.

İşlevsellik Katmanları

Belge, tarayıcıda gerekli olan işlevleri aşağıdan yukarı altı gruba ayırır. Bu gruplandırmayı bilmek, "şu an hangi parça ile uğraşıyorum?" sorusuna cevap vermenizi kolaylaştırır:

1. Veri Aktarımı — TCP/UDP soketleri, NAT geçişi, tıkanıklık kontrolü.
2. Veri Çerçeveleme — RTP, SCTP, DTLS gibi paket biçimleri ve güvenlik.
3. Veri Biçimleri — Ses ve video codec'leri (Opus, VP8, H.264 vb).
4. Bağlantı Yönetimi — SDP teklif/yanıt müzakeresi (JSEP).
5. Sunum & Kontrol — Kullanıcı arayüzü, kimin konuştuğu, ekran düzeni.
6. Yerel Destek — Yankı giderme, AGC, kamera kontrolü gibi cihaz işlevleri.

Belge bu altı grubu iki büyük blokta toplar: ilk üçü "ortam aktarım altyapısı", son üçü "ortam hizmeti". Birlikte çalışabilirlik için en azından ilk beşinin standartlaştırılması gerekir — altıncı grup (yerel destek) tamamen uygulamaya bırakılmıştır.

#Yapı Taşları

Veri Aktarımı

WebRTC için tercih edilen aktarım UDP'dir. Sebep basit: gerçek zamanlı ses ve videoda düşük gecikme, düşmüş paketlerin kusursuz teslim edilmesinden daha kritiktir. UDP üzerinden çalışmak, hem tıkanıklık kontrolünü hem de kayıp kurtarma stratejilerini WebRTC'nin kendi sorumluluğuna alır.

NAT'lar arkasındaki cihazlar arasında doğrudan UDP bağlantısı kurmak kolay değildir; bu yüzden ICE (RFC 8445) devreye girer. ICE, candidate'ler — yani olası ağ adresleri — toplar ve hangisinin çalıştığını deneyerek bulur. STUN sunucuları "public IP'mi söyle" için, TURN sunucuları ise "her şey başarısız oldu, sen relay et" için kullanılır.

Çerçeveleme & Güvenlik

Medya, RTP (RFC 3550) ile çerçevelenir — ama saf RTP asla kabul edilmez. WebRTC, RTP'yi her zaman SRTP'ye sarar (Secure RTP); yani şifreleme opsiyonel değildir:

SRTP anahtarları DTLS el sıkışmasından türetilir. DTLS, TLS'in UDP üzerinde çalışan versiyonudur; ICE bağlantısı kurulduğu anda, iki taraf birbirinin sertifikasını doğrular ve ortak anahtarları üretir. Sertifika doğrulamasının kalbi, SDP içinde taşınan fingerprint alanıdır — bu sayede sinyalleşme kanalına güvenmek zorunda kalmadan kimlik doğrulanabilir.

Veri kanalları (DataChannel) için kullanılan protokol SCTP'dir; bu da DTLS üzerinde çalışır. SCTP, hem sıralı (TCP gibi) hem de sırasız (UDP gibi) modu desteklediği için, aynı API üzerinden farklı tipte verileri taşımayı mümkün kılar.

Veri Biçimleri

Codec savaşı WebRTC tarihinin en zorlu standartlaşma süreçlerinden biriydi. Sonuç şu: her WebRTC uç noktası en azından şu codec'leri desteklemek zorundadır:

• Ses: Opus ve G.711 (RFC 7874)
• Video: VP8 ve H.264 Constrained Baseline (RFC 7742)

Bu zorunlu liste, "iki rastgele WebRTC uç noktası daima konuşabilir" garantisinin somut biçimidir. Geliştiriciler ek codec'ler kullanmakta serbesttir, ama destekledikleri her şey bu temelin üzerine eklenir.

Belge önemli bir notu vurgular: yeni bir codec eklemek için tarayıcı API'sinin değişmesine gerek yoktur. Yeni codec için sadece SDP düzeyinde bir tanım yeterlidir; tarayıcı onu desteklediği gün, JavaScript uygulamaları tek satır değişiklik olmadan otomatik olarak kullanmaya başlar.

Bağlantı Yönetimi

İki uç noktanın "ne konuşacağına karar vermesi" sürecine müzakere denir. WebRTC bunun için SDP tabanlı bir offer/answer modeli kullanır; bu modelin tarayıcıdaki uygulanışı JSEP (RFC 8829) belgesinde tanımlıdır.

Belge burada önemli bir karara dikkat çeker: SDP'yi seçmenin asıl sebebi zarafeti değil, SIP dünyasıyla geriye dönük uyumluluktur. Yani eski bir SIP telefonu ile bir WebRTC uygulaması arasına bir sinyal ağ geçidi koymak, ortam ağ geçidine ihtiyaç duymadan mümkündür. Bu pratik bir trade-off'tur.

Ek olarak, belge ağ katmanıyla ilgili bazı zorunlu mekanizmaları sıralar:

• BUNDLE (RFC 8843) — ses, video ve data için tek bir transport kullan.
• rtcp-mux (RFC 5761) — RTP ve RTCP'yi aynı portta çoğulla.
• Trickle ICE (RFC 8838) — candidate'leri toplandıkça hemen gönder.

Sunum & Kontrol

Sunum katmanı, kullanıcının ne gördüğü ile ilgilidir: hangi kamera açık, ses nereye gidiyor, kim konuşuyor, ekranda kim görünüyor. Bu büyük ölçüde tarayıcı, işletim sistemi ve uygulama arasındaki yerel bir konudur ve W3C'nin mediacapture-streams ve webrtc belirtimlerinde tanımlanır.

Belge burada temel bir gizlilik prensibini vurgular: kullanıcı her zaman ne paylaştığını bilmelidir. Kameranın hangi siteye akış verdiği, mikrofonun ne zaman açık olduğu, kim tarafından kontrol edildiği — bu bilgilere kullanıcının görsel olarak erişebilmesi gerekir.

Yerel Destek İşlevleri

Bu kategori — yankı giderme, otomatik kazanç kontrolü (AGC), gürültü bastırma, kamera odak/zoom kontrolü gibi şeyler — standartlaştırılması gerekmeyen tek katmandır. Sebebi: bu işlevlerin kalitesi kullanıcı deneyimini güçlü etkiler, ama belirli algoritması diğer tarafı hiç ilgilendirmez. Her uygulama kendi en iyi yöntemini kullanır.

Yine de belge bazı pratik hedefler koyar:

• Yankı giderme, akustik geri bildirim döngülerini algılanabilir seviyenin altında tutmalıdır.
• AGC, mevcut olduğunda konuşmayı makul bir dB aralığına normalleştirmelidir.
• Kamera uzaktan kontrol ediliyorsa, kullanıcı kimin kontrol ettiğini görmeli ve kontrolü iptal edebilmelidir.

#Güvenlik

Belge güvenliği üç açıdan ele alır:

• Bileşen güvenliği — Tarayıcının kendisinin saldırı yüzeyi olmaması. WebRTC eklenmesi tarayıcıya yeni güvenlik açığı katmamalıdır.
• Kanal güvenliği — İki uç nokta arasındaki trafiğin gizliliği ve bütünlüğü. Bu, zorunlu DTLS-SRTP şifrelemesiyle sağlanır.
• Kimlik güvenliği — Konuştuğunuz kişinin gerçekten o olduğunu doğrulama (veya tersi: anonimliğin korunması gerektiğinde kimliğin sızdırılmaması).

Detaylı analiz RFC 8826 (Güvenlik Değerlendirmeleri) ve RFC 8827 (Güvenlik Mimarisi) belgelerindedir. Bu iki belge WebRTC uygulamak için zorunlu okumadır — sadece iyi bir öneri değil.

#Önemli Terimler

Belge, kendi sözlüğünü tanımlar. En sık karşılaşılan ve yanlış anlaşılması en kolay olan birkaçı: