Передача файлов по локальной сети
Передавайте файлы и текст напрямую между устройствами в одной локальной сети через WebRTC — без сервера
Что такое передача файлов по локальной сети?
Передача файлов по LAN использует WebRTC-связь peer-to-peer для отправки файлов и текста между двумя устройствами в одной локальной сети. После установления соединения данные могут идти напрямую между браузерами, без предварительной загрузки во внешнее облачное хранилище. Это удобно для офисных компьютеров, тестовых устройств, домашней сети, учебных классов, лабораторий и быстрых передач, когда флешка, облачная папка или вложение в чат слишком неудобны. Скорость зависит от локальной сети, поддержки браузера и производительности устройств. Для конфиденциальных файлов нужно проверять получателя и закрывать временную сессию после обмена. Для реальной диагностики результат нужно сопоставлять с permissions, средой браузера, сетевым путем и состоянием устройства или сервера.
Как использовать
Как использовать
- На одном устройстве нажмите «Создать подключение» — система сгенерирует QR-код с информацией для подключения
- Отсканируйте QR-код на другом устройстве — страница откроется автоматически и сгенерирует код ответа
- Отсканируйте код ответа на первом устройстве — будет установлено WebRTC-соединение
- После подключения обе стороны могут обмениваться текстовыми сообщениями и файлами любого типа
Советы по передаче
- Во время передачи держите оба устройства активными с доступной сетью — закрытие вкладки или переход в спящий режим прервёт WebRTC-сессию.
- Для очень больших или критически важных файлов проверяйте скачанный файл после передачи: ограничения памяти браузера, качество сети и устройства могут снижать надёжность.
Применение
Технический принцип
Передача файлов по локальной сети построена на WebRTC (Web Real-Time Communication) — стандарте W3C/IETF, определённом в RFC 8825–8835, изначально созданном для браузерной аудио- и видеосвязи в реальном времени. Тот же механизм peer-to-peer поддерживает API RTCDataChannel, который передаёт произвольные двоичные данные между двумя браузерами без какого-либо ретрансляционного сервера на пути данных. Сигналинг, открывающий канал, реализуется через QR-код: инициатор создаёт SDP (Session Description Protocol, RFC 8866), описывающий медиа- и данные, кодирует его в URL или QR-код, а отвечающая сторона возвращает встречный SDP. После того как обе стороны применили удалённое описание, ICE (Interactive Connectivity Establishment, RFC 8445) собирает кандидатные транспортные адреса. Каждый кандидат — это кортеж (IP, порт, протокол) с приоритетом: host-кандидаты (собственный LAN IP устройства) обычно побеждают в одной сети, но srflx (server-reflexive, полученный через STUN binding request) и relay (TURN-ретрансляция, RFC 8656) кандидаты проверяются в порядке приоритета. Проверка связности отправляет STUN binding requests между кандидатами; первая прошедшая пара становится выбранным кандидатным соединением. Когда ICE достигает состояния connected, DTLS (Datagram Transport Layer Security, RFC 6347, UDP-дружественный аналог TLS 1.2/1.3 из RFC 5246/8446) выполняет верификацию отпечатков обоих пиров через хеши сертификатов в SDP, проводя рукопожатие за один RTT. Ключи сессии DTLS затем защищают каждый пакет SCTP (Stream Control Transmission Protocol, RFC 4960/RFC 9260) поверх, а каждый DataChannel — это пара SCTP-потоков через единую DTLS-ассоциацию. Большие файлы передаются чанками через DataChannel. SCTP-уровень браузера фрагментирует каждое сообщение на записи по ~16 КБ (MTU по умолчанию за вычетом накладных расходов DTLS + SCTP + заголовка чанка, настраивается в зависимости от реализации, часто 16 КБ или 64 КБ), а получатель собирает их в правильном порядке. Управление потоком и перегрузкой (RFC 4960 §6) не позволяет отправителю перегрузить получателя: cwnd растёт аддитивно при ACK и сжимается мультипликативно при потерях — та же модель AIMD, что и в TCP, но применяемая к SCTP-ассоциации. В гигабитной LAN пропускная способность обычно ограничена 200–400 МБ/с из-за накладных расходов кодирования на главном потоке браузера (преобразование каждого чанка в представление ArrayBuffer и передача в стек SCTP), а не скоростью линии. Страница собирает входящие чанки в единый Blob и предлагает его для загрузки, чтобы получатель не удерживал гигабайты в памяти на пике. Поскольку данные текут peer-to-peer с шифрованием в стиле DTLS-SRTP, промежуточные маршрутизаторы и ретрансляционные серверы видят только шифротекст; оператор страницы никогда не видит открытый текст, и этапа загрузки на сервер нет. Компромисс — необходимость сигналинг-сервера для обмена SDP: эта страница использует QR-коды и ссылки для копирования как ручной, бессерверный канал сигналинга, поэтому требуется два сканирования.
- WebRTC — стандарт W3C/IETF (RFC 8825–8835), объединяющий три движка: SDP для согласования, ICE для сбора кандидатов и DTLS-SRTP / DTLS-SCTP для транспортной безопасности.
- QR-кодное рукопожатие — бессерверный сигналинг: инициатор публикует SDP offer, отвечающая сторона возвращает SDP answer, и ни один центральный сервер не видит путь данных.
- ICE (RFC 8445) собирает host, srflx (STUN-reflexive), prflx (peer-reflexive) и relay (TURN, RFC 8656) кандидаты; пара с наивысшим приоритетом, прошедшая проверку связности, становится выбранным транспортом.
- DTLS (RFC 6347) выполняет рукопожатие за один RTT с верификацией отпечатков через хеши сертификатов, закреплённые в SDP, и шифрует каждый байт на линии — без откатов на обычный HTTP или WebSocket.
- DataChannel работает на SCTP поверх DTLS, а не на raw UDP: SCTP предоставляет упорядоченные, надёжные, сообщение-ориентированные потоки с контролем перегрузки (RFC 4960 §6) поверх UDP-сокета.
- Размер чанка по умолчанию составляет примерно 16 КБ (зависит от браузера, иногда 64 КБ): получатель собирает чанки в единый Blob и запускает загрузку, чтобы не удерживать весь файл в памяти.
- Память браузера — реальный предел: файл размером 1 ГБ означает ~1 ГБ работы с ArrayBuffer, поэтому на телефонах практический лимит обычно составляет 200–500 МБ на одну передачу, а не скорость сети.
- NAT-трансверсия WebRTC требует STUN/TURN-сервера для пиров в разных сетях; эта страница предполагает топологию одной LAN, поэтому host-кандидаты (LAN IP) обычно побеждают и STUN-сервер не запрашивается.
Примеры
Отправка фото с телефона на компьютер
1. На компьютере нажмите «Создать соединение», чтобы сгенерировать QR-код
2. Отсканируйте его телефоном; страница откроется и сформирует ответный код
3. Отсканируйте ответный код на компьютере, чтобы завершить рукопожатие
4. Выберите фотографии для отправки и нажмите «Отправить»Отправка файлов с компьютера на телефон
После установления соединения нажмите «Отправить файл» на компьютере и выберите документ, архив или видео.
На телефоне появится уведомление, и файл сохранится одним касанием.Обмен текстовыми сообщениями
После подключения обе стороны могут вводить текст в поле ввода и отправлять его.
Дополнительные приложения не нужны — это простой двусторонний чат в браузере.Часто задаваемые вопросы
Как работает передача файлов?
Два устройства в одной локальной сети соединяются через WebRTC peer-to-peer. После того как сигнализация устанавливает соединение, файлы передаются напрямую между браузерами — они не проходят через какой-либо промежуточный сервер. Скорость зависит от вашей локальной сети (Wi-Fi или Ethernet); типичный Wi-Fi выдаёт 30–150 Мбит/с.
Покидают ли мои файлы локальную сеть?
После установки WebRTC-соединения — нет, байты файла идут только между двумя устройствами. Перед поднятием соединения происходит небольшой этап сигнализации (обмен описаниями сессии) через координационный сервер; этот обмен — метаданные, а не содержимое файла.
Почему два устройства не соединяются?
Оба устройства должны быть в одной Wi-Fi-сети или сегменте LAN. Корпоративные сети часто блокируют peer-to-peer-соединения; гостевой Wi-Fi часто изолирует клиентов друг от друга («client isolation»). Попробуйте личный Wi-Fi или точку доступа. VPN на любом из устройств также может блокировать прямое соединение.
Есть ли ограничение на размер файла?
У WebRTC нет протокольного лимита, но практические границы — это память браузера и время жизни вкладки. Многогигабайтные передачи обычно работают на десктопах; мобильные браузеры могут приостановить вкладку и оборвать передачу. Держите обе вкладки на переднем плане во время больших передач.
Шифруются ли передаваемые файлы?
Да. Каналы данных WebRTC используют сквозное шифрование DTLS-SRTP; даже атакующий в той же Wi-Fi-сети не сможет прочитать содержимое файла. Этап сигнализации идёт по HTTPS к координационному серверу. Считайте передачу приватной, пока обе стороны доверенные.
Подойдёт ли это нетехническим пользователям?
Да — поделитесь кодом комнаты или URL с другим человеком; он открывает ссылку в браузере, и соединение устанавливается автоматически. Установка приложений не нужна. Интерфейс похож на AirDrop без привязки к платформе. Работает между iOS Safari, Android Chrome, Windows Edge, macOS Firefox и т. д.
Можно ли отправлять на несколько устройств одновременно?
Большинство сборок поддерживают комнату «один к одному». Чтобы отправить нескольким получателям, повторите передачу или используйте multicast-инструмент. Групповая передача через WebRTC реализуема, но требует в N раз больше восходящей пропускной способности.