WebRTC ile P2P dosya aktarımı neden hâlâ önemli?
Bulut depolama servisleri pratik ama her zaman ideal değil: büyük dosyalarda yükleme süresi, kota sınırları, bağlantı hızına bağlı gecikmeler ve kimi senaryolarda gizlilik endişeleri devreye giriyor. WebRTC (Web Real-Time Communication) ise tarayıcıların birbirleriyle doğrudan haberleşmesini sağlayarak, arada dosyayı tutan bir “depo” olmadan aktarımı mümkün kılıyor. Bu yazıda, ileri seviye ama uygulanabilir bir yaklaşımla, tarayıcıdan tarayıcıya güvenli P2P dosya transferi için gerekli bileşenleri ve kritik ayarları adım adım ele alacağım.
Mimarinin özeti: Sinyal mi, medya mı?
WebRTC, bağlantıyı “kendi kendine” başlatmaz. İki tarayıcının birbirini bulması ve bağlantı parametrelerini paylaşması için bir sinyal (signaling) kanalına ihtiyacı vardır. Bu kanal genellikle WebSocket ile kurulur. Sinyal sunucusu sadece şu verileri iletir: SDP teklif/yanıtları (offer/answer) ve ICE adayları. Dosyanın kendisi ise ideal durumda RTCDataChannel üzerinden P2P akar.
Özet akış: (1) İstemciler sinyal sunucusuna bağlanır. (2) Bir oda/kimlik üzerinden eşleşir. (3) SDP/ICE alışverişi yapılır. (4) NAT arkasından geçiş için STUN/TURN devreye girer. (5) DataChannel açılır ve dosya parçalı şekilde gönderilir.
Gereksinimler: STUN/TURN, HTTPS ve tarayıcı kısıtları
Modern tarayıcılarda WebRTC çoğu zaman “secure context” ister. Üretimde HTTPS kullanmanız önemlidir (localhost istisna). NAT/kurumsal ağ koşullarında yalnız STUN yetmeyebilir; bu nedenle bir TURN sunucusu kritik bir güvence katmanıdır. TURN, doğrudan bağlantı kurulamadığında trafiği relay eder; bu da maliyetli ama erişilebilirliği artıran bir çözümdür.
Pratik öneri: Geliştirme aşamasında STUN ile başlayın; sahaya çıkarken TURN ekleyin. En çok kullanılan açık kaynak TURN çözümü coturn’dür. Ayrıca aktarımın güvenliği WebRTC’de varsayılan olarak DTLS ile sağlanır; yani DataChannel üzerinde giden veri şifrelenir.
1) Basit bir sinyal sunucusu (Node.js + WebSocket)
Sinyal sunucusunun görevi “mesaj taşımak”tır, dosya aktarmak değil. Basit bir odalı yapı kurgulayabilirsiniz: istemci bir odaya katılır, diğer istemci gelince birbirlerinin mesajlarını iletir. Aşağıdaki yaklaşım üretim için değil, mantığı netleştirmek içindir: tek sunucu, oda eşleşmesi, mesaj yönlendirme.
İpucu: Mesajları tip alanıyla sınıflandırın: offer, answer, ice, join. Böylece istemci tarafı daha okunaklı olur ve hataları ayıklamak kolaylaşır.
2) İstemci tarafı: RTCPeerConnection ve RTCDataChannel
Tarayıcı tarafında iki temel nesne kullanılır: RTCPeerConnection ve RTCDataChannel. PeerConnection, ICE/STUN/TURN ile bağlantıyı kurar; DataChannel ise dosya parçalarını taşır. Buradaki kritik konu, dosyayı tek seferde göndermeye kalkmamak. Büyük bir Blob’u tek mesajla yollamak bellek patlamasına, tarayıcı takılmalarına veya kanal buffer’ının dolmasına yol açabilir.
Sağlıklı yöntem: Dosyayı chunk’lara bölün (örneğin 16 KB–256 KB arası), sırayla gönderin ve backpressure yönetin. WebRTC tarafında bunun için dataChannel.bufferedAmount değerini izleyip belirli eşiğin üstünde beklemek iyi bir pratiktir.
3) Chunk stratejisi, akış kontrolü ve bütünlük
Dosya transferinde üç konu genelde gözden kaçar: akış kontrolü, bütünlük ve yeniden birleştirme. Akış kontrolü için bufferedAmount eşiği belirleyin (ör. 8–16 MB). Bütünlük için en basit yaklaşım: dosya boyutu, parça sayısı, her parçanın indeks bilgisi ve isteğe bağlı hash (ör. SHA-256) gönderin. Yeniden birleştirmede alıcı tarafta parçaları sıraya koyup ArrayBuffer/Blob olarak birleştirin.
Ayrıca DataChannel için iki mod var: ordered (varsayılan) ve unordered. Dosya aktarımında genelde ordered işinizi kolaylaştırır. Paket kaybına dayanıklılık isterseniz, parçaları indeksleyip unordered kullanabilir, eksikleri yeniden isteyebilirsiniz; bu ileri seviye bir iyileştirmedir.
4) ICE yapılandırması: STUN ve TURN örneği
PeerConnection oluştururken ICE sunucularını tanımlarsınız. STUN, dış IP/port keşfine yardım eder; TURN ise relay görevi görür. Kurumsal ağlarda UDP engellenmiş olabilir; TURN’u TCP/TLS ile de sunmak gerekir. Üretimde en çok takılınan yer burasıdır: “Aynı Wi‑Fi’da çalışıyor, dış ağda çalışmıyor.” Sebebi genellikle TURN eksikliği veya yanlış kimlik bilgisidir.
Güvenlik notu: TURN kullanıcı adı/parola bilgilerini statik tutmak yerine zaman kısıtlı (time-limited) kimlik doğrulama kullanmak daha güvenlidir. coturn bu konuda esnektir.
5) Test, hata ayıklama ve performans ipuçları
Test aşamasında önce iki sekme arasında (aynı makine) deneyin; sonra aynı LAN, sonra farklı ağlar. Chrome’da chrome://webrtc-internals sayfası ICE adaylarını, bağlantı durumlarını ve kanal istatistiklerini incelemek için çok değerlidir. Bağlantı kurulamıyorsa genellikle sorun sinyal değil, ICE/TURN tarafındadır.
Performans için öneriler: Chunk boyutunu cihazlara göre ayarlayın, gereksiz kopyalamaları azaltın, alıcı tarafta parçaları birleştirirken bellek kullanımını izleyin. Çok büyük dosyalarda (ör. birkaç GB) tarayıcı sınırlarına yaklaşabilirsiniz; bu durumda indirme/streaming yaklaşımı ve dosya sistemi erişimi (File System Access API) gibi ek teknikler gündeme gelir.
Sonuç: Bulutsuz paylaşım için sağlam bir temel
WebRTC ile tarayıcıdan tarayıcıya dosya aktarımı, doğru kurgulandığında hem hızlı hem de şifreli bir deneyim sunar. Bu işin kalbi dosyayı taşımaktan çok, bağlantıyı güvenilir biçimde kurmaktır: sinyal sunucusu basit kalabilir, fakat ICE/STUN/TURN ayarları ve chunk tabanlı aktarım stratejisi projenin başarısını belirler. Buradaki yaklaşımı bir temel olarak alıp; oda yönetimi, kimlik doğrulama, yeniden deneme mekanizmaları ve transfer ilerleme göstergesi gibi parçalarla üretim seviyesine rahatça taşıyabilirsiniz.
