# Як працює передача файлів через WebRTC

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

> Передача файлів через WebRTC відбувається у три фази. Сервер сигналізації «знайомить» два браузери; STUN та ICE шукають мережевий шлях крізь домашні роутери (NAT), а якщо прямого шляху немає, використовують ретранслятор TURN; потім браузери відкривають зашифрований DTLS канал даних і передають файл частинами — напряму або через ретранслятор, не зберігаючи його.

Передача файлів через WebRTC дає змогу двом браузерам надіслати один одному файл, не
завантажуючи його в хмарне сховище. Звучить просто, але інтернет не створювали для того, щоб
два домашні комп'ютери «дзвонили» один одному напряму. У цьому посібнику простою мовою
розбираємо, що насправді відбувається, — сигналізація, NAT, STUN, ICE, TURN, DTLS і канали
даних — на прикладі StrongFolder.

**Key facts**

- **WebRTC** — браузерний стандарт для прямих зашифрованих з'єднань між двома пристроями; інструменти для файлів використовують його **канали даних**.
- **Сигналізація** «знайомить» браузери; **STUN** та **ICE** шукають шлях крізь роутери (**NAT**); **ретранслятор TURN** пересилає трафік, коли прямого шляху немає.
- **Шифрування:** кожен канал даних використовує **DTLS** — у WebRTC немає незашифрованого режиму.
- StrongFolder використовує PeerJS поверх WebRTC, власний сервер сигналізації, публічні сервери STUN (зокрема Google) і власні ретранслятори TURN. Файли ніколи не завантажуються на сервер StrongFolder і не зберігаються на ньому.
- Файл передається частинами з диска відправника на диск одержувача; відправник залишається онлайн.

## Що таке WebRTC?

[WebRTC](https://help.strongfolder.com/en/glossary/#webrtc) (Web Real-Time Communication) — це набір браузерних API та
мережевих протоколів, стандартизованих W3C та IETF, для з'єднань між браузерами в реальному
часі. Його підтримують Chrome, Edge, Firefox, Safari й Opera. Його створювали для відео- й
голосових дзвінків, але він має й **канали даних**, що переносять будь-які двійкові дані, — а
файл саме такими даними і є.

Ключова властивість: щойно з'єднання WebRTC встановлено, дані йдуть **між двома кінцевими
точками**, а не в сховище сервера. Саме це й робить можливою
[P2P-передачу файлів у браузері](https://help.strongfolder.com/en/guides/p2p-file-transfer/).

## Чому два браузери не можуть просто з'єднатися один з одним?

Бо майже жоден пристрій не має власної публічної адреси. Ваш ноутбук стоїть за домашнім
роутером, офісним файрволом або мережею мобільного оператора. Роутер виконує
[NAT](https://help.strongfolder.com/en/glossary/#nat) (трансляцію мережевих адрес): багато приватних пристроїв ділять одну
публічну IP-адресу, а роутер пропускає всередину лише трафік, який відповідає на щось,
надіслане зсередини.

Тож перш ніж дані файлу почнуть передаватися, два браузери мають розв'язати три проблеми:

1. Вони не знають, **як дістатися один до одного**, — жоден не знає про існування іншого.
2. Вони не знають **власної публічної адреси** — лише приватну, наприклад 192.168.1.20.
3. Їхні роутери можуть **блокувати непрохані вхідні з'єднання**.

WebRTC розв'язує кожну проблему окремим механізмом.

## Як працює передача файлів через WebRTC, крок за кроком?

Ось увесь процес — від натискання «поділитися» до останнього байта:

```
 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
```

**Кроки 1–2 — сигналізація.** Відправник вибирає файли; сервіс записує метадані, потрібні для
посилання. Коли одержувач відкриває посилання, обидва браузери під'єднуються до сервера
[сигналізації](https://help.strongfolder.com/en/glossary/#signaling). WebRTC не визначає, як має працювати сигналізація;
StrongFolder використовує PeerJS із власним сервером сигналізації.

**Крок 3 — пропозиція й відповідь.** Один браузер створює **пропозицію** (offer) у форматі SDP
(Session Description Protocol): «Я хочу канал даних, ось мій відбиток шифрування й мої
можливості». Інший відповідає **відповіддю** (answer). Обидва повідомлення йдуть через сервер
сигналізації.

**Крок 4 — STUN.** Кожен браузер питає сервер [STUN](https://help.strongfolder.com/en/glossary/#stun): «З якої адреси й
порту ти мене бачиш?» Відповідь — його публічна адреса, як її зіставив роутер. Сервери STUN
обробляють крихітний запит і жодних даних файлів; StrongFolder використовує публічні сервери
STUN, зокрема Google, і власні.

**Крок 5 — кандидати ICE.** Кожен браузер збирає **кандидатів** — можливі способи до нього
дістатися: адресу в локальній мережі (host), публічну адресу від STUN (server-reflexive) і
адресу на ретрансляторі TURN (relayed). Кандидатами вони обмінюються через сигналізацію.

**Крок 6 — перевірки зв'язності.** [ICE](https://help.strongfolder.com/en/glossary/#ice) (Interactive Connectivity
Establishment) перевіряє пари кандидатів і вибирає найкращу робочу. Якщо обидва пристрої в
одній мережі Wi-Fi, перемагає локальний шлях. Якщо роутери дозволяють, перемагає прямий шлях
через інтернет («пробивання діри», hole punching). Якщо нічого прямого не працює,
використовується шлях через ретранслятор.

**Крок 7 — DTLS.** Перш ніж підуть будь-які дані, браузери виконують рукостискання
[DTLS](https://help.strongfolder.com/en/glossary/#dtls) (TLS, адаптований для UDP) і перевіряють, що відбитки сертифікатів
збігаються з тими, що були в пропозиції й відповіді. Відтепер усе зашифровано.

**Крок 8 — канал даних.** Поверх DTLS працює SCTP, який забезпечує каналу даних надійну
впорядковану доставку. У StrongFolder браузер одержувача запитує файл, браузер відправника
зчитує його з диска частинами й надсилає їх, а одержувач записує кожну частину на диск, щойно
вона надходить, — тож навіть дуже великі файли ніколи не мусять поміститися в пам'ять.

## Що означають STUN, TURN, ICE та інші терміни?

| Термін | Що робить | Бачить дані файлів? | Стандарт |
|---|---|---|---|
| Сигналізація | Передає пропозиції, відповіді й кандидатів між браузерами | Ні | Не стандартизовано (залежить від застосунку) |
| NAT | Функція роутера, що ділить одну публічну IP-адресу між багатьма пристроями | — | — |
| STUN | Повідомляє браузеру його публічну адресу й порт | Ні | IETF RFC 8489 |
| ICE | Збирає кандидатів і вибирає робочий шлях | Ні | IETF RFC 8445 |
| TURN | Ретранслює трафік, коли жоден прямий шлях не працює | Лише зашифровані пакети | IETF RFC 8656 |
| DTLS | Шифрує з'єднання (TLS для UDP) | Шифрує їх | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Канал даних SCTP | Надійна впорядкована доставка частин | Переносить їх (зашифрованими) | IETF RFC 8831 |

Усі ці терміни коротко пояснено в [глосарії](https://help.strongfolder.com/en/glossary/).

## Коли використовується ретранслятор TURN і що він бачить?

Ретранслятор — це запасний варіант, а не варіант за замовчуванням. ICE використовує його, лише
коли жодна пряма пара кандидатів не з'єднується, — зазвичай у мережах із **симетричним NAT**
(деякі мобільні оператори), за **корпоративними файрволами**, що блокують вихідний UDP, або
через певні VPN.

Якщо пряме з'єднання неможливе (суворий корпоративний файрвол, деякі мобільні мережі), зашифрований потік проходить через ретрансляційний (TURN) сервер StrongFolder. Ретранслятор пересилає дані й не зберігає їх.

Ретранслятор отримує зашифровані DTLS пакети й передає їх далі. Він бачить, що трафік іде,
скільки й коли, — але не те, що всередині. Передача через ретранслятор може бути повільнішою
за пряму, бо кожен байт робить додатковий шлях через ретранслятор. Якщо передача незвично
повільна, спробуйте іншу мережу: точка доступу з телефона чи домашній Wi-Fi часто дають
пряме з'єднання там, де офісна мережа — ні.

[Надіслати файли](https://strongfolder.com)
## Наскільки надійне шифрування WebRTC?

WebRTC робить шифрування обов'язковим: відкрити незашифрований канал даних неможливо. DTLS
використовує сучасні шифри, які узгоджують два браузери, а для кожного з'єднання створюються
нові ключі.

Є одне чесне застереження, яке стосується будь-якого сервісу на WebRTC. Два браузери
перевіряють один одного за **відбитками** сертифікатів, якими обмінюються через сервер
сигналізації. Отже, ви довіряєте сигналізації сервісу в тому, що вона їх не підмінить. Саме
тому StrongFolder описує свій захист як **шифрування під час передачі**, а не як наскрізне
шифрування з ключами, які зберігаєте ви, і не як «zero-knowledge». Ширший погляд на те, що
означає «безпечно», — у статтях [Безпечний обмін файлами](https://help.strongfolder.com/en/guides/secure-file-sharing/) і
[Безпека й конфіденційність](https://help.strongfolder.com/en/security/).

## Чому браузер відправника має залишатися відкритим?

Бо браузер відправника *і є* джерелом. Немає копії на сервері, до якої можна повернутися:
канал даних зчитує частини з диска відправника, лише поки вкладка відкрита, а пристрій не
спить. Вкладка браузера відправника має залишатися відкритою й онлайн, доки одержувач не завершить завантаження: файли йдуть із пристрою відправника, а не із сервера. Як це спланувати, розповідаємо в статті
[Чому відправник залишається онлайн](https://help.strongfolder.com/en/guides/why-sender-stays-online/).

## Наскільки швидка передача файлів через WebRTC?

Фіксованої швидкості немає. Стелю задає найповільніша ланка шляху: зазвичай швидкість
**вивантаження** відправника. Орієнтовно 1 ГБ передається приблизно за 2,7 хвилини за
50 Мбіт/с, приблизно за 80 секунд за 100 Мбіт/с і значно менш ніж за хвилину в швидкій
локальній мережі. Реальні передачі трохи повільніші за ці цифри через накладні витрати
протоколу, швидкість диска й, у разі ретранслятора, додатковий перехід. Одне посилання можуть відкрити кілька одержувачів; кожен завантажує напряму у відправника.
Кілька одночасних завантажень ділять вивантаження відправника.

## Підсумок

Передача файлів через WebRTC — це коротке узгодження, після якого йде довгий зашифрований
потік: сигналізація «знайомить» браузери, STUN та ICE шукають шлях крізь NAT, TURN
ретранслює в крайньому разі, а зашифровані DTLS канали даних переносять файл із диска на
диск. Про практичний бік — що це означає для вас як відправника — почніть зі статей
[P2P-передача файлів у браузері](https://help.strongfolder.com/en/guides/p2p-file-transfer/) і
[Як працює StrongFolder](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### Що таке канал даних WebRTC?

Канал даних — це частина WebRTC, яка переносить між двома браузерами довільні байти замість аудіо чи відео. Він працює як SCTP поверх DTLS поверх UDP, тому зашифрований і може бути налаштований на надійну впорядковану доставку — саме те, що потрібно для передачі файлів.

### Чим STUN відрізняється від TURN?

Сервер STUN лише повідомляє браузеру, як виглядає його публічна адреса, щоб два браузери могли спробувати з'єднатися напряму; жодні дані файлів через нього не проходять. Сервер TURN — це ретранслятор: коли жоден прямий шлях не працює, зашифрований потік іде через нього. StrongFolder має власні ретранслятори TURN, які пересилають і не зберігають дані.

### Чи бачить сервер сигналізації мої файли?

Ні. Сервер сигналізації передає між браузерами лише службові повідомлення про з'єднання — описи сеансу й мережеві кандидати. Дані файлів ідуть каналом даних — напряму або через ретранслятор TURN.

### Чи шифрується передача файлів через WebRTC?

WebRTC шифрує кожен канал даних за протоколом DTLS, тому потік файлів зашифрований під час передачі на будь-якому з'єднанні. WebRTC не дозволяє незашифрованих каналів даних. Ключі узгоджують два браузери; їхні відбитки (fingerprints) передаються через сигналізацію, тому це шифрування під час передачі, а не наскрізне шифрування з ключами, якими керуєте ви.

### Чому передача через WebRTC іноді не вдається або йде повільно?

Зазвичай через мережевий шлях: суворий файрвол або VPN блокує прямий UDP, тож з'єднання переходить на ретранслятор TURN через TCP або не встановлюється взагалі. Спробуйте іншу мережу (наприклад, точку доступу з телефона), вимкніть VPN або попросіть ІТ-відділ дозволити WebRTC.

### Чи може ретранслятор TURN прочитати мої файли?

Ретранслятор пересилає зашифровані DTLS пакети між двома браузерами. Він бачить зашифрований трафік, обсяги й час, а не вміст файлів, і ретранслятор StrongFolder не зберігає те, що пересилає.