P2P зашифрованная передача файлов: техническое руководство
Постройте системы зашифрованной P2P-передачи файлов. NAT-трансляция, сигнальные серверы и реализация сквозного шифрования.
Одноранговая передача файлов отправляет байты напрямую между двумя браузерами или устройствами, не позволяя файлу касаться сервера. WebRTC, стандартизированный в RFC 8825–8837, обеспечивает транспорт: зашифрованные каналы передачи данных по UDP с DTLS 1.3, обход NAT через ICE, STUN и TURN, сигнализация по WebSocket или HTTP. Инструменты Snapdrop, Wormhole.app и Magic Wormhole доказывают, что модель работает. Вот как это построить: сигнальное рукопожатие, подводные камни обхода NAT, наслоение шифрования и что вы получаете или теряете по сравнению с облачными ретрансляционными сервисами.
Почему P2P для передачи файлов
Привлекательность проста: никакой сервер не хранит ваш файл, нет счёта за трафик для сервиса передачи, и загрузка отправителя — это одновременно скачивание получателя без промежуточной копии. Для передачи 10 ГБ между двумя пользователями в одной гигабитной локальной сети P2P справится за 80 секунд, тогда как облачный ретранслятор потребовал бы загрузки на удалённый сервер и повторного скачивания, удвоив трафик и задержку. Конфиденциальность — тоже весомый аргумент: байты файла существуют только на устройствах отправителя и получателя. Компромиссы: обе стороны должны быть онлайн одновременно, обход NAT иногда не срабатывает, а скорость ограничена более медленным каналом загрузки.
Каналы данных WebRTC как транспорт
WebRTC начинался как протокол для аудио и видео, но RTCDataChannel обеспечивает произвольный бинарный транспорт сообщений — как с надёжной упорядоченной (аналог TCP), так и с ненадёжной неупорядоченной (аналог UDP) доставкой. Под капотом каналы данных работают через SCTP поверх DTLS 1.3 поверх UDP. Уровень DTLS обеспечивает конфиденциальность и аутентифицированную целостность через AES-128-GCM или ChaCha20-Poly1305, согласуемые в ходе рукопожатия. Для передачи файлов создайте надёжный упорядоченный канал, нарежьте файл на сообщения по 16 КБ или 64 КБ (Chrome исторически ограничивал размер сообщения 256 КБ) и отправляйте их последовательно с управлением потоком через порог buffered amount.
Роль сигнального сервера
WebRTC нужен сигнальный сервер для обмена информацией о соединении (SDP-предложения и ответы, кандидаты ICE) между узлами. Сигнальный сервер не ретранслирует байты файла — только около 5 КБ метаданных соединения. Сигнальный сервис на WebSocket на Node.js, Python или Go реализуется в несколько сотен строк кода. Firebase Realtime Database, Supabase Realtime и Pusher работают как сигнальные бэкенды. Сигнальный сервер видит, кто и когда с кем общается, но не содержимое файла. Большинство P2P-сервисов передачи файлов предоставляют сигнализацию бесплатно, поскольку трафик мизерный.
Обход NAT: STUN, TURN и ICE
Большинство устройств находятся за NAT, что делает прямые IP-соединения невозможными. ICE (Interactive Connectivity Establishment, RFC 8445) пробует несколько путей соединения. STUN (RFC 8489) позволяет узлу обнаружить свой публичный IP и порт через публичный STUN-сервер; Google бесплатно предоставляет stun.l.google.com. Если у обоих узлов разумные NAT (full-cone или restricted-cone), прямое UDP-соединение работает примерно в 70% попыток. При симметричных NAT, корпоративных межсетевых экранах и CGNAT TURN (RFC 8656) ретранслирует трафик через сервер. TURN-серверы дороги, поскольку несут реальные байты файла. Самостоятельно размещённый coturn, twilio.com/stun или Cloudflare Calls предоставляют варианты. Ожидайте, что 10–30% P2P-передач упадут на TURN в реальных условиях.
Наслоение шифрования поверх DTLS
DTLS уже шифрует данные WebRTC, поэтому дополнительное шифрование на прикладном уровне — это «ремень и подтяжки». DTLS-рукопожатие аутентифицирует сертификаты узлов, но WebRTC обычно использует самоподписанные сертификаты, которые не проверяют личность — только то, что соединение установлено с тем же узлом, что подписал SDP. Прикладное шифрование с AES-256-GCM и общим секретом, выведенным из встречи на сигнальном сервере, добавляет гарантию идентичности. PAKE-метод SPAKE2 из Magic Wormhole выводит надёжный ключ из короткой читаемой фразы, поэтому даже скомпрометированный сигнальный сервер не сможет расшифровать данные.
Стратегия нарезки для P2P-передачи файлов
Каналы данных WebRTC имеют ограничение на размер сообщения (256 КБ в большинстве браузеров, фрагментация больших сообщений работает, но ненадёжно). Нарезайте файлы на сообщения по 16–64 КБ для совместимости. Отслеживайте буферизованный объём через bufferedAmount и bufferedAmountLowThreshold для реализации обратного давления: приостанавливайте отправку, когда буфер превышает 1 МБ, возобновляйте при падении ниже 256 КБ. Для целостности хешируйте каждый блок с SHA-256 и включайте хеши в манифест, отправляемый первым. Получатель пересобирает данные, проверяет хеши и записывает на диск через File System Access API или загрузку Blob.
Мобильные устройства и кросс-платформенность
P2P между десктопами работает хорошо. Мобильный-к-десктопу вносит сложности: мобильные браузеры агрессивно приостанавливают вкладки, поэтому отправитель должен держать браузерную вкладку на переднем плане. Реализация канала данных в iOS Safari исторически менее надёжна, чем в Chromium. Фоновые загрузки на мобильных требуют поддержки приложением (Snapdrop Relay, ShareDrop). Нагрузка на аккумулятор тоже важна: длительные WebRTC-сессии разряжают батарею быстрее, чем HTTPS-загрузки. Для передачи между мобильными в одной Wi-Fi-сети AirDrop (iOS/macOS) и Nearby Share (Android) превосходят браузерный P2P, используя прямые протоколы устройств.
Обнаружение узлов без центральных аккаунтов
Как два незнакомца соединяются без системы на основе аккаунтов? Работают несколько паттернов. Короткий код, как «4-truck-roger» у Magic Wormhole, служит одновременно адресом встречи и паролем; сигнальный сервер сопоставляет коды с сессиями. QR-коды с закодированным URL сессии работают для личной передачи. NFC-касание на Android соединяет по близости. В Telegram-боте можно организовать обмен кодами без привязки к аккаунту сервиса. Для крупных сетей DHT (как Mainline DHT у BitTorrent) позволяет обнаруживать узлы без центрального сервера, но поиск в DHT занимает секунды и не подходит для случайного обмена файлами.
Угрозы безопасности, специфичные для P2P
P2P вводит угрозы, которых нет у облачных ретрансляторов. Раскрытие IP-адреса: прямые соединения открывают публичный IP каждого узла другому, потенциально деанонимизируя пользователей в чувствительных контекстах (разоблачение, активизм). Некоторые P2P-сервисы принудительно используют TURN-ретрансляцию для скрытия IP ценой производительности. Распространение вредоносного ПО сложнее модерировать, поскольку оператор сервиса никогда не видит содержимое файлов. Отказ в обслуживании через исчерпание соединений на сигнальном сервере требует ограничения частоты запросов. Для особо чувствительных передач onion-сервис Tor может маскировать сигнализацию, скрывая оба IP ценой значительной задержки.
Реальная оценка производительности
Скорость P2P ограничена более медленным каналом загрузки участника и задержкой туда-обратно. На домашних соединениях лимиты загрузки часто составляют 20–50 Мбит/с даже при гигабитном скачивании. Передача 10 ГБ по P2P с домашнего канала в 20 Мбит/с к гигабитному получателю займёт минимум 68 минут. Облачный ретранслятор с быстрым каналом загрузки и CDN-поддержкой скачивания может обойти это, загрузив один раз на хорошо подключённый сервер. P2P выигрывает для передач по одной локальной сети (гигабит и выше), конфиденциальных данных, где серверная копия недопустима, и оптимизации затрат при болезненных счетах за трафик.
Когда облачный ретранслятор всё же побеждает
При асинхронных передачах, когда отправитель и получатель не онлайн одновременно, P2P вообще не работает: некому принимать. При крупных передачах, превышающих окно сессии (вкладки мобильного браузера закрываются, ноутбуки уходят в спящий режим), модель облачного ретранслятора «загрузи и поделись ссылкой» просто практичнее. Для распределения одному-многим единственная загрузка с CDN-разветвлением превосходит N одновременных P2P-сессий. HexaTransfer использует модель облачного ретранслятора с клиентским шифрованием AES-256-GCM, получая большую часть преимуществ P2P в плане конфиденциальности при значительно лучшей поддержке асинхронного режима и нескольких получателей.
Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.
Безопасная отправка больших файлов со сквозным шифрованием
Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.
Отправить файл