Transfer file WebRTC memungkinkan dua browser saling mengirim file tanpa mengunggahnya ke penyimpanan cloud. Kedengarannya sederhana, tetapi internet tidak dirancang agar dua komputer rumahan bisa saling "menelepon" secara langsung. Panduan ini menguraikan apa yang sebenarnya terjadi — signaling, NAT, STUN, ICE, TURN, DTLS, dan saluran data — dengan bahasa sederhana, memakai StrongFolder sebagai contoh.
Apa itu WebRTC?
WebRTC (Web Real-Time Communication) adalah sekumpulan API browser dan protokol jaringan, yang distandarkan oleh W3C dan IETF, untuk koneksi real-time antarbrowser. Chrome, Edge, Firefox, Safari, dan Opera semuanya mendukungnya. WebRTC dibuat untuk panggilan video dan suara, tetapi juga punya saluran data yang membawa data biner apa pun — dan file memang data biner.
Sifat kuncinya: begitu koneksi WebRTC terbentuk, data berpindah antara kedua titik akhir, bukan ke penyimpanan server. Itulah yang memungkinkan transfer file P2P di browser.
Mengapa dua browser tidak bisa langsung saling terhubung?
Karena hampir tidak ada perangkat yang punya alamat publik sendiri. Laptop Anda berada di balik router rumah, firewall kantor, atau jaringan operator seluler. Router menjalankan NAT (Network Address Translation): banyak perangkat privat berbagi satu alamat IP publik, dan router hanya mengizinkan masuk lalu lintas yang merupakan balasan atas sesuatu yang dikirim dari dalam.
Jadi dua browser menghadapi tiga masalah sebelum data file bisa mengalir:
- Keduanya tidak tahu cara saling menjangkau — tidak ada yang tahu yang lain ada.
- Keduanya tidak tahu alamat publiknya sendiri — hanya alamat privat, seperti 192.168.1.20.
- Router mereka mungkin memblokir lalu lintas masuk yang tidak diminta.
WebRTC memecahkan setiap masalah dengan mekanisme terpisah.
Bagaimana transfer file WebRTC bekerja, langkah demi langkah?
Berikut alur lengkapnya, dari mengeklik "bagikan" hingga byte terakhir:
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
Langkah 1–2 — Signaling. Pengirim memilih file; layanan mencatat metadata yang diperlukan untuk tautan. Saat penerima membuka tautan, kedua browser terhubung ke server signaling. WebRTC tidak menentukan cara kerja signaling; StrongFolder memakai PeerJS dengan server signaling-nya sendiri.
Langkah 3 — Offer dan answer. Satu browser membuat offer dalam SDP (Session Description Protocol): "Saya ingin saluran data, ini fingerprint enkripsi dan kemampuan saya." Browser lain membalas dengan answer. Keduanya dikirim melalui server signaling.
Langkah 4 — STUN. Setiap browser bertanya kepada server STUN, "dari alamat dan port mana Anda melihat saya datang?" Jawabannya adalah alamat publiknya sebagaimana dipetakan oleh router. Server STUN menangani permintaan yang sangat kecil dan tidak ada data file; StrongFolder memakai server STUN publik, termasuk milik Google, dan server miliknya sendiri.
Langkah 5 — Kandidat ICE. Setiap browser mengumpulkan kandidat — kemungkinan cara untuk menjangkaunya: alamat jaringan lokalnya (host), alamat publiknya dari STUN (server-reflexive), dan alamat di relay TURN (relayed). Keduanya bertukar kandidat melalui signaling.
Langkah 6 — Pemeriksaan konektivitas. ICE (Interactive Connectivity Establishment) menguji pasangan kandidat dan memilih yang terbaik yang berfungsi. Jika kedua perangkat berada di Wi-Fi yang sama, jalur lokal yang menang. Jika router mengizinkan, jalur internet langsung ("hole punching") yang menang. Jika tidak ada jalur langsung yang berfungsi, jalur lewat relay yang dipakai.
Langkah 7 — DTLS. Sebelum data apa pun mengalir, browser menjalankan handshake DTLS (TLS yang disesuaikan untuk UDP) dan memeriksa bahwa fingerprint sertifikat cocok dengan yang ada di offer dan answer. Sejak saat itu, semuanya terenkripsi.
Langkah 8 — Saluran data. Di atas DTLS berjalan SCTP, yang memberikan pengiriman andal dan berurutan pada saluran data. Di StrongFolder, browser penerima meminta sebuah file, browser pengirim membacanya dari disk dalam potongan dan mengirimkannya, lalu penerima menulis setiap potongan ke disk begitu tiba — sehingga file yang sangat besar pun tidak perlu dimuat seluruhnya ke memori.
Apa arti STUN, TURN, ICE, dan istilah lainnya?
| Istilah | Fungsinya | Melihat data file? | Standar |
|---|---|---|---|
| Signaling | Meneruskan offer, answer, dan kandidat antarbrowser | Tidak | Tidak distandarkan (khusus aplikasi) |
| NAT | Fitur router yang membagi satu IP publik untuk banyak perangkat | — | — |
| STUN | Memberi tahu browser alamat publik dan port-nya | Tidak | IETF RFC 8489 |
| ICE | Mengumpulkan kandidat dan memilih jalur yang berfungsi | Tidak | IETF RFC 8445 |
| TURN | Meneruskan lalu lintas jika tidak ada jalur langsung | Hanya paket terenkripsi | IETF RFC 8656 |
| DTLS | Mengenkripsi koneksi (TLS untuk UDP) | Mengenkripsinya | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Saluran data SCTP | Pengiriman potongan yang andal dan berurutan | Membawanya (terenkripsi) | IETF RFC 8831 |
Semua istilah ini dijelaskan secara singkat di glosarium.
Kapan relay TURN dipakai, dan apa yang dilihatnya?
Relay adalah cadangan, bukan bawaan. ICE hanya memakainya jika tidak ada pasangan kandidat langsung yang tersambung — biasanya di jaringan dengan symmetric NAT (sebagian operator seluler), firewall kantor yang memblokir UDP keluar, atau VPN tertentu.
Jika koneksi langsung tidak memungkinkan (firewall kantor yang ketat, sebagian jaringan seluler), aliran terenkripsi melewati server relay (TURN) StrongFolder. Relay hanya meneruskan data dan tidak menyimpannya.
Relay menerima paket terenkripsi DTLS dan meneruskannya. Relay bisa melihat bahwa ada lalu lintas, seberapa banyak, dan kapan — bukan apa isinya. Transfer lewat relay bisa lebih lambat daripada transfer langsung, karena setiap byte menempuh perjalanan tambahan melalui relay. Jika transfer luar biasa lambat, coba jaringan lain: hotspot ponsel atau Wi-Fi rumah sering bisa terhubung langsung di saat jaringan kantor tidak bisa.
Gratis · di browser · tanpa daftar
Seberapa aman enkripsi WebRTC?
WebRTC mewajibkan enkripsi: tidak ada cara untuk membuka saluran data tanpa enkripsi. DTLS memakai cipher modern yang dinegosiasikan oleh kedua browser, dan kunci baru dibuat untuk setiap koneksi.
Ada satu catatan jujur yang berlaku untuk setiap layanan WebRTC. Kedua browser saling memverifikasi melalui fingerprint sertifikat yang dipertukarkan lewat server signaling. Karena itu, Anda memercayai bahwa signaling layanan tersebut tidak mengutak-atiknya. Itulah sebabnya StrongFolder menggambarkan perlindungannya sebagai enkripsi saat transit — bukan enkripsi end-to-end dengan kunci yang Anda pegang, dan bukan "zero-knowledge". Untuk gambaran yang lebih luas tentang arti "aman", baca Berbagi file dengan aman dan Keamanan & privasi.
Mengapa browser pengirim harus tetap terbuka?
Karena browser pengirim adalah sumbernya. Tidak ada salinan di server yang bisa dijadikan cadangan: saluran data membaca potongan dari disk pengirim hanya selama tab terbuka dan perangkat aktif. Tab browser pengirim harus tetap terbuka dan online sampai penerima selesai mengunduh — file berasal dari perangkat pengirim, bukan dari server. Cara merencanakannya dibahas di Mengapa pengirim tetap online.
Seberapa cepat transfer file WebRTC?
Tidak ada kecepatan yang tetap. Batas atasnya adalah tautan paling lambat di jalurnya: biasanya kecepatan unggah pengirim. Sebagai patokan, 1 GB memerlukan sekitar 2,7 menit pada 50 Mbit/s, sekitar 80 detik pada 100 Mbit/s, dan jauh di bawah satu menit di jaringan lokal yang cepat. Transfer nyata berjalan sedikit di bawah angka ini karena beban protokol, kecepatan disk, dan, jika memakai relay, lompatan tambahan. Satu tautan bisa dibuka oleh beberapa penerima; masing-masing mengunduh langsung dari pengirim. Beberapa unduhan sekaligus berbagi bandwidth unggah pengirim.
Ringkasan
Transfer file WebRTC adalah negosiasi singkat yang diikuti aliran panjang yang terenkripsi: signaling memperkenalkan browser, STUN dan ICE mencari jalur melewati NAT, TURN menjadi relay sebagai upaya terakhir, dan saluran data terenkripsi DTLS membawa file dari disk ke disk. Untuk sisi praktisnya — apa artinya bagi Anda sebagai pengirim — mulailah dari transfer file P2P di browser dan Cara kerja StrongFolder.