WebRTC dosya aktarımı, iki tarayıcının bir dosyayı bulut depolamaya yüklemeden birbirine göndermesini sağlar. Basit gibi görünüyor, ancak internet iki ev bilgisayarının birbirini doğrudan araması için kurulmadı. Bu rehber, perde arkasında gerçekte neler olduğunu — sinyalleşme, NAT, STUN, ICE, TURN, DTLS ve veri kanalları — StrongFolder'ı örnek alarak sade bir dille anlatıyor.
WebRTC nedir?
WebRTC (Web Real-Time Communication), tarayıcılar arasındaki gerçek zamanlı bağlantılar için W3C ve IETF tarafından standartlaştırılmış bir tarayıcı API'leri ve ağ protokolleri bütünüdür. Chrome, Edge, Firefox, Safari ve Opera'nın tamamı onu destekler. Görüntülü ve sesli görüşmeler için geliştirildi, ancak her türlü ikili veriyi taşıyan veri kanalları da vardır — bir dosya da tam olarak budur.
Temel özellik şudur: bir WebRTC bağlantısı kurulduğunda veriler bir sunucunun deposuna değil, iki uç arasında gider. Tarayıcıda P2P dosya aktarımını mümkün kılan da budur.
İki tarayıcı neden doğrudan birbirine bağlanamaz?
Çünkü neredeyse hiçbir cihazın kendine ait genel bir adresi yoktur. Dizüstü bilgisayarınız bir ev yönlendiricisinin, bir ofis güvenlik duvarının ya da bir mobil operatör ağının arkasındadır. Yönlendirici NAT (Network Address Translation) uygular: birçok özel cihaz tek bir genel IP adresini paylaşır ve yönlendirici yalnızca içeriden gönderilen bir şeye yanıt olan trafiği içeri alır.
Dolayısıyla iki tarayıcı, herhangi bir dosya verisi akmadan önce üç sorunla karşılaşır:
- Birbirlerine nasıl ulaşacaklarını bilmezler — hiçbiri diğerinin varlığından haberdar değildir.
- Kendi genel adreslerini bilmezler — yalnızca 192.168.1.20 gibi özel adreslerini bilirler.
- Yönlendiricileri istenmeyen gelen trafiği engelleyebilir.
WebRTC her sorunu ayrı bir mekanizmayla çözer.
Bir WebRTC dosya aktarımı adım adım nasıl çalışır?
"Paylaş"a tıklamaktan son bayta kadar tüm akış şöyle:
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
Adım 1–2 — Sinyalleşme. Gönderici dosyaları seçer; hizmet bağlantı için gereken meta verileri kaydeder. Alıcı bağlantıyı açtığında iki tarayıcı da bir sinyalleşme sunucusuna bağlanır. WebRTC sinyalleşmenin nasıl çalışacağını tanımlamaz; StrongFolder, PeerJS'i kendi sinyalleşme sunucusuyla kullanır.
Adım 3 — Teklif ve yanıt. Tarayıcılardan biri SDP (Session Description Protocol) biçiminde bir teklif (offer) oluşturur: "Bir veri kanalı istiyorum, işte şifreleme parmak izim ve yeteneklerim." Diğeri bir yanıtla (answer) karşılık verir. İkisi de sinyalleşme sunucusu üzerinden gider.
Adım 4 — STUN. Her tarayıcı bir STUN sunucusuna "Beni hangi adres ve porttan geliyor görüyorsun?" diye sorar. Yanıt, yönlendiricinin eşlediği genel adresidir. STUN sunucuları küçük bir isteği işler ve hiçbir dosya verisi görmez; StrongFolder, Google'ınkiler dahil herkese açık STUN sunucularını ve kendi sunucularını kullanır.
Adım 5 — ICE adayları. Her tarayıcı adayları — kendisine ulaşmanın olası yollarını — toplar: yerel ağ adresi (host), STUN'dan gelen genel adresi (server-reflexive) ve bir TURN aktarma sunucusundaki adres (relayed). Adayları sinyalleşme üzerinden paylaşırlar.
Adım 6 — Bağlantı kontrolleri. ICE (Interactive Connectivity Establishment) aday çiftlerini dener ve çalışanlar arasından en iyisini seçer. İki cihaz aynı Wi-Fi'daysa yerel yol kazanır. Yönlendiriciler izin veriyorsa doğrudan bir internet yolu ("hole punching") kazanır. Doğrudan hiçbir yol çalışmazsa aktarma sunucusu üzerinden geçen yol kullanılır.
Adım 7 — DTLS. Herhangi bir veri akmadan önce tarayıcılar bir DTLS el sıkışması (UDP'ye uyarlanmış TLS) yapar ve sertifika parmak izlerinin teklif ve yanıttakilerle eşleştiğini kontrol eder. Bundan sonra her şey şifrelidir.
Adım 8 — Veri kanalı. DTLS'in üzerinde, veri kanalına güvenilir ve sıralı teslimat sağlayan SCTP çalışır. StrongFolder'da alıcının tarayıcısı bir dosya ister, göndericinin tarayıcısı onu diskten parça parça okuyup gönderir ve alıcı her parçayı geldiği anda diske yazar — böylece çok büyük dosyaların bile belleğe sığması gerekmez.
STUN, TURN, ICE ve diğer terimler ne anlama gelir?
| Terim | Ne yapar | Dosya verisini görür mü? | Standart |
|---|---|---|---|
| Sinyalleşme | Teklifleri, yanıtları ve adayları tarayıcılar arasında iletir | Hayır | Standartlaştırılmamış (uygulamaya özel) |
| NAT | Tek bir genel IP'yi birçok cihaz arasında paylaştıran yönlendirici özelliği | — | — |
| STUN | Tarayıcıya genel adresini ve portunu söyler | Hayır | IETF RFC 8489 |
| ICE | Adayları toplar ve çalışan bir yol seçer | Hayır | IETF RFC 8445 |
| TURN | Doğrudan yol çalışmadığında trafiği aktarır | Yalnızca şifreli paketleri | IETF RFC 8656 |
| DTLS | Bağlantıyı şifreler (UDP için TLS) | Onu şifreler | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| SCTP veri kanalı | Parçaların güvenilir, sıralı teslimatı | Onu taşır (şifreli) | IETF RFC 8831 |
Bunların tamamı sözlükte kısaca açıklanmıştır.
TURN aktarma sunucusu ne zaman kullanılır ve neyi görür?
Aktarma sunucusu varsayılan değil, yedek yoldur. ICE onu yalnızca hiçbir doğrudan aday çifti bağlanamadığında kullanır — tipik olarak simetrik NAT kullanan ağlarda (bazı mobil operatörler), giden UDP'yi engelleyen kurumsal güvenlik duvarlarında ya da bazı VPN'lerde.
Doğrudan bağlantı kurulamıyorsa (katı kurumsal güvenlik duvarı, bazı mobil ağlar), şifreli akış bir StrongFolder aktarma (TURN) sunucusundan geçer. Aktarma sunucusu verileri iletir ve saklamaz.
Aktarma sunucusu DTLS ile şifrelenmiş paketleri alır ve iletir. Trafiğin aktığını, ne kadar ve ne zaman aktığını görebilir — içinde ne olduğunu değil. Aktarma sunucusu üzerinden yapılan bir aktarım, doğrudan aktarımdan yavaş olabilir; çünkü her bayt aktarma sunucusu üzerinden fazladan bir yol kat eder. Bir aktarım alışılmadık derecede yavaşsa başka bir ağ deneyin: bir ofis ağının bağlanamadığı yerde telefonun kişisel erişim noktası ya da ev Wi-Fi'ı çoğu zaman doğrudan bağlanır.
Ücretsiz · tarayıcınızda · kayıt gerekmez
WebRTC şifrelemesi ne kadar güvenli?
WebRTC şifrelemeyi zorunlu kılar: şifrelenmemiş bir veri kanalı açmanın bir yolu yoktur. DTLS, iki tarayıcının üzerinde anlaştığı modern şifreleri kullanır ve her bağlantı için yeni anahtarlar oluşturulur.
Her WebRTC hizmeti için geçerli olan dürüst bir çekince var. İki tarayıcı birbirini, sinyalleşme sunucusu üzerinden paylaşılan sertifika parmak izleri aracılığıyla doğrular. Dolayısıyla hizmetin sinyalleşmesinin bunları kurcalamayacağına güvenirsiniz. Bu nedenle StrongFolder korumasını aktarım sırasında şifreleme olarak tanımlar — elinizdeki anahtarlarla uçtan uca şifreleme ya da "sıfır bilgi" (zero-knowledge) olarak değil. "Güvenli"nin ne anlama geldiğine daha geniş bir bakış için Güvenli dosya paylaşımı ve Güvenlik ve gizlilik sayfalarını okuyun.
Göndericinin tarayıcısı neden açık kalmalı?
Çünkü kaynak göndericinin tarayıcısının kendisidir. Başvurulabilecek bir sunucu kopyası yoktur: veri kanalı, parçaları yalnızca sekme açıkken ve cihaz uyanıkken göndericinin diskinden okur. Alıcı indirmeyi bitirene kadar göndericinin tarayıcı sekmesi açık ve çevrimiçi kalmalıdır — dosyalar bir sunucudan değil, göndericinin cihazından gelir. Buna nasıl hazırlanacağınız Gönderici neden çevrimiçi kalır rehberinde anlatılıyor.
WebRTC dosya aktarımı ne kadar hızlıdır?
Sabit bir hız yoktur. Üst sınır, yoldaki en yavaş halkadır: genellikle göndericinin yükleme hızı. Kabaca, 1 GB 50 Mbit/sn'de yaklaşık 2,7 dakika, 100 Mbit/sn'de yaklaşık 80 saniye, hızlı bir yerel ağda ise bir dakikanın epey altında sürer. Gerçek aktarımlar protokol yükü, disk hızı ve aktarma sunucusu varsa fazladan atlama nedeniyle bu rakamların biraz altında kalır. Bir bağlantı birden fazla alıcı tarafından açılabilir; her biri doğrudan göndericiden indirir. Aynı anda yapılan birkaç indirme göndericinin yükleme hızını paylaşır.
Özet
Bir WebRTC dosya aktarımı, kısa bir pazarlığın ardından gelen uzun, şifreli bir akıştır: sinyalleşme tarayıcıları tanıştırır, STUN ve ICE NAT'ın arasından bir yol bulur, TURN son çare olarak aktarır ve DTLS ile şifrelenmiş veri kanalları dosyayı diskten diske taşır. Pratik taraf — bunun gönderici olarak sizin için ne anlama geldiği — için tarayıcıda P2P dosya aktarımı ve StrongFolder nasıl çalışır sayfalarıyla başlayın.