Передача файлів через WebRTC дає змогу двом браузерам надіслати один одному файл, не завантажуючи його в хмарне сховище. Звучить просто, але інтернет не створювали для того, щоб два домашні комп'ютери «дзвонили» один одному напряму. У цьому посібнику простою мовою розбираємо, що насправді відбувається, — сигналізація, NAT, STUN, ICE, TURN, DTLS і канали даних — на прикладі StrongFolder.
Що таке WebRTC?
WebRTC (Web Real-Time Communication) — це набір браузерних API та мережевих протоколів, стандартизованих W3C та IETF, для з'єднань між браузерами в реальному часі. Його підтримують Chrome, Edge, Firefox, Safari й Opera. Його створювали для відео- й голосових дзвінків, але він має й канали даних, що переносять будь-які двійкові дані, — а файл саме такими даними і є.
Ключова властивість: щойно з'єднання WebRTC встановлено, дані йдуть між двома кінцевими точками, а не в сховище сервера. Саме це й робить можливою P2P-передачу файлів у браузері.
Чому два браузери не можуть просто з'єднатися один з одним?
Бо майже жоден пристрій не має власної публічної адреси. Ваш ноутбук стоїть за домашнім роутером, офісним файрволом або мережею мобільного оператора. Роутер виконує NAT (трансляцію мережевих адрес): багато приватних пристроїв ділять одну публічну IP-адресу, а роутер пропускає всередину лише трафік, який відповідає на щось, надіслане зсередини.
Тож перш ніж дані файлу почнуть передаватися, два браузери мають розв'язати три проблеми:
- Вони не знають, як дістатися один до одного, — жоден не знає про існування іншого.
- Вони не знають власної публічної адреси — лише приватну, наприклад 192.168.1.20.
- Їхні роутери можуть блокувати непрохані вхідні з'єднання.
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 — сигналізація. Відправник вибирає файли; сервіс записує метадані, потрібні для посилання. Коли одержувач відкриває посилання, обидва браузери під'єднуються до сервера сигналізації. WebRTC не визначає, як має працювати сигналізація; StrongFolder використовує PeerJS із власним сервером сигналізації.
Крок 3 — пропозиція й відповідь. Один браузер створює пропозицію (offer) у форматі SDP (Session Description Protocol): «Я хочу канал даних, ось мій відбиток шифрування й мої можливості». Інший відповідає відповіддю (answer). Обидва повідомлення йдуть через сервер сигналізації.
Крок 4 — STUN. Кожен браузер питає сервер STUN: «З якої адреси й порту ти мене бачиш?» Відповідь — його публічна адреса, як її зіставив роутер. Сервери STUN обробляють крихітний запит і жодних даних файлів; StrongFolder використовує публічні сервери STUN, зокрема Google, і власні.
Крок 5 — кандидати ICE. Кожен браузер збирає кандидатів — можливі способи до нього дістатися: адресу в локальній мережі (host), публічну адресу від STUN (server-reflexive) і адресу на ретрансляторі TURN (relayed). Кандидатами вони обмінюються через сигналізацію.
Крок 6 — перевірки зв'язності. ICE (Interactive Connectivity Establishment) перевіряє пари кандидатів і вибирає найкращу робочу. Якщо обидва пристрої в одній мережі Wi-Fi, перемагає локальний шлях. Якщо роутери дозволяють, перемагає прямий шлях через інтернет («пробивання діри», hole punching). Якщо нічого прямого не працює, використовується шлях через ретранслятор.
Крок 7 — DTLS. Перш ніж підуть будь-які дані, браузери виконують рукостискання 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 |
Усі ці терміни коротко пояснено в глосарії.
Коли використовується ретранслятор TURN і що він бачить?
Ретранслятор — це запасний варіант, а не варіант за замовчуванням. ICE використовує його, лише коли жодна пряма пара кандидатів не з'єднується, — зазвичай у мережах із симетричним NAT (деякі мобільні оператори), за корпоративними файрволами, що блокують вихідний UDP, або через певні VPN.
Якщо пряме з'єднання неможливе (суворий корпоративний файрвол, деякі мобільні мережі), зашифрований потік проходить через ретрансляційний (TURN) сервер StrongFolder. Ретранслятор пересилає дані й не зберігає їх.
Ретранслятор отримує зашифровані DTLS пакети й передає їх далі. Він бачить, що трафік іде, скільки й коли, — але не те, що всередині. Передача через ретранслятор може бути повільнішою за пряму, бо кожен байт робить додатковий шлях через ретранслятор. Якщо передача незвично повільна, спробуйте іншу мережу: точка доступу з телефона чи домашній Wi-Fi часто дають пряме з'єднання там, де офісна мережа — ні.
Безкоштовно · у браузері · без реєстрації
Наскільки надійне шифрування WebRTC?
WebRTC робить шифрування обов'язковим: відкрити незашифрований канал даних неможливо. DTLS використовує сучасні шифри, які узгоджують два браузери, а для кожного з'єднання створюються нові ключі.
Є одне чесне застереження, яке стосується будь-якого сервісу на WebRTC. Два браузери перевіряють один одного за відбитками сертифікатів, якими обмінюються через сервер сигналізації. Отже, ви довіряєте сигналізації сервісу в тому, що вона їх не підмінить. Саме тому StrongFolder описує свій захист як шифрування під час передачі, а не як наскрізне шифрування з ключами, які зберігаєте ви, і не як «zero-knowledge». Ширший погляд на те, що означає «безпечно», — у статтях Безпечний обмін файлами і Безпека й конфіденційність.
Чому браузер відправника має залишатися відкритим?
Бо браузер відправника і є джерелом. Немає копії на сервері, до якої можна повернутися: канал даних зчитує частини з диска відправника, лише поки вкладка відкрита, а пристрій не спить. Вкладка браузера відправника має залишатися відкритою й онлайн, доки одержувач не завершить завантаження: файли йдуть із пристрою відправника, а не із сервера. Як це спланувати, розповідаємо в статті Чому відправник залишається онлайн.
Наскільки швидка передача файлів через WebRTC?
Фіксованої швидкості немає. Стелю задає найповільніша ланка шляху: зазвичай швидкість вивантаження відправника. Орієнтовно 1 ГБ передається приблизно за 2,7 хвилини за 50 Мбіт/с, приблизно за 80 секунд за 100 Мбіт/с і значно менш ніж за хвилину в швидкій локальній мережі. Реальні передачі трохи повільніші за ці цифри через накладні витрати протоколу, швидкість диска й, у разі ретранслятора, додатковий перехід. Одне посилання можуть відкрити кілька одержувачів; кожен завантажує напряму у відправника. Кілька одночасних завантажень ділять вивантаження відправника.
Підсумок
Передача файлів через WebRTC — це коротке узгодження, після якого йде довгий зашифрований потік: сигналізація «знайомить» браузери, STUN та ICE шукають шлях крізь NAT, TURN ретранслює в крайньому разі, а зашифровані DTLS канали даних переносять файл із диска на диск. Про практичний бік — що це означає для вас як відправника — почніть зі статей P2P-передача файлів у браузері і Як працює StrongFolder.