Передача файлов по WebRTC позволяет двум браузерам отправить друг другу файл, не загружая его в облачное хранилище. Звучит просто, но интернет не создавался для того, чтобы два домашних компьютера звонили друг другу напрямую. В этом руководстве простым языком разберём, что происходит на самом деле, — сигнализация, NAT, STUN, ICE, TURN, DTLS и каналы данных — на примере StrongFolder.
Что такое WebRTC?
WebRTC (Web Real-Time Communication) — набор браузерных API и сетевых протоколов, стандартизованных W3C и IETF, для соединений между браузерами в реальном времени. Его поддерживают Chrome, Edge, Firefox, Safari и Opera. Он создавался для видео- и голосовых звонков, но в нём есть и каналы данных, которые передают любые двоичные данные, — а файл именно ими и является.
Главное свойство: после установки соединения WebRTC данные идут между двумя конечными точками, а не в хранилище сервера. Именно это делает возможной P2P-передачу файлов в браузере.
Почему два браузера не могут просто соединиться друг с другом?
Потому что почти ни у одного устройства нет собственного публичного адреса. Ваш ноутбук находится за домашним роутером, офисным файрволом или сетью мобильного оператора. Роутер выполняет NAT (Network Address Translation, трансляцию сетевых адресов): много частных устройств делят один публичный 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, побеждает локальный путь. Если роутеры позволяют, побеждает прямой путь через интернет («пробивание NAT», 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.