# Cara kerja transfer file WebRTC

Source: https://help.strongfolder.com/id/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> Transfer file WebRTC berlangsung dalam tiga fase. Server signaling memperkenalkan dua browser; STUN dan ICE mencari jalur jaringan melewati router rumah (NAT), dengan relay TURN sebagai cadangan jika tidak ada jalur langsung; lalu browser membuka saluran data terenkripsi DTLS dan mengalirkan file dalam potongan, langsung atau melalui relay, tanpa menyimpannya.

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.

**Key facts**

- **WebRTC** adalah standar browser untuk koneksi langsung dan terenkripsi antara dua perangkat; alat transfer file memakai **saluran data**-nya.
- **Signaling** memperkenalkan browser; **STUN** dan **ICE** mencari jalur melewati router (**NAT**); **relay TURN** meneruskan lalu lintas jika tidak ada jalur langsung.
- **Enkripsi:** setiap saluran data memakai **DTLS** — WebRTC tidak punya mode tanpa enkripsi.
- StrongFolder memakai PeerJS di atas WebRTC, server signaling StrongFolder, server STUN publik (termasuk milik Google), dan relay TURN sendiri. File tidak pernah diunggah ke atau disimpan di server StrongFolder.
- File mengalir dalam potongan dari disk pengirim ke disk penerima; pengirim tetap online.

## Apa itu WebRTC?

[WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/).

## 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](https://help.strongfolder.com/en/glossary/#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:

1. Keduanya tidak tahu **cara saling menjangkau** — tidak ada yang tahu yang lain ada.
2. Keduanya tidak tahu **alamat publiknya sendiri** — hanya alamat privat, seperti 192.168.1.20.
3. 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/).

## 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.

[Kirim file sekarang](https://strongfolder.com)
## 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](https://help.strongfolder.com/en/guides/secure-file-sharing/)
dan [Keamanan & privasi](https://help.strongfolder.com/en/security/).

## 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](https://help.strongfolder.com/en/guides/why-sender-stays-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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) dan
[Cara kerja StrongFolder](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Apa itu saluran data WebRTC?

Saluran data adalah bagian WebRTC yang membawa byte apa pun antara dua browser, bukan audio atau video. Saluran ini menjalankan SCTP di atas DTLS di atas UDP, sehingga terenkripsi dan dapat diatur agar andal dan berurutan — persis yang dibutuhkan transfer file.

### Apa bedanya STUN dan TURN?

Server STUN hanya memberi tahu browser seperti apa alamat publiknya, sehingga kedua browser dapat mencoba terhubung langsung; tidak ada data file yang melewatinya. Server TURN adalah relay: jika tidak ada jalur langsung yang berfungsi, aliran terenkripsi melewatinya. StrongFolder menjalankan relay TURN sendiri, yang meneruskan dan tidak menyimpan data.

### Apakah server signaling melihat file saya?

Tidak. Server signaling hanya meneruskan pesan koneksi — deskripsi sesi dan kandidat jaringan — antarbrowser. Data file mengalir melalui saluran data, baik langsung maupun melalui relay TURN.

### Apakah transfer file WebRTC terenkripsi?

WebRTC mengenkripsi setiap saluran data dengan DTLS, sehingga aliran file selalu terenkripsi selama transit di setiap koneksi. WebRTC tidak mengizinkan saluran data tanpa enkripsi. Kuncinya dinegosiasikan oleh kedua browser; fingerprint-nya dikirim melalui signaling, karena itulah ini disebut enkripsi saat transit, bukan enkripsi end-to-end dengan kunci yang Anda kelola sendiri.

### Mengapa transfer WebRTC kadang gagal atau lambat?

Biasanya karena jalur jaringan: firewall yang ketat atau VPN memblokir UDP langsung, sehingga koneksi beralih ke relay TURN melalui TCP, atau sama sekali tidak bisa terhubung. Coba jaringan lain (misalnya hotspot ponsel), matikan VPN, atau minta tim TI mengizinkan WebRTC.

### Bisakah relay TURN membaca file saya?

Relay meneruskan paket terenkripsi DTLS antara kedua browser. Relay melihat lalu lintas terenkripsi, ukuran, dan waktunya, bukan isi file, dan relay StrongFolder tidak menyimpan apa yang diteruskannya.