Transferencia cifrada P2P: guía técnica
Construye sistemas de transferencia cifrada peer-to-peer: NAT traversal, servidores de señalización e implementación de cifrado de extremo a extremo.
La transferencia de archivos peer-to-peer envía los bytes directamente entre dos navegadores o dispositivos sin que el archivo llegue jamás a un servidor. WebRTC, estandarizado en los RFC 8825 a 8837, proporciona el transporte: canales de datos cifrados sobre UDP con DTLS 1.3, NAT traversal mediante ICE, STUN y TURN, y señalización sobre WebSocket o HTTP. Herramientas como Snapdrop, Wormhole.app y Magic Wormhole demuestran que el modelo funciona. Aquí está cómo construirlo: el handshake de señalización, los problemas del NAT traversal, las capas de cifrado y qué ganas o pierdes frente a los servicios de transferencia mediante relay en la nube.
Por qué la transferencia P2P para archivos
El atractivo es sencillo: ningún servidor almacena tu archivo, ninguna factura de ancho de banda para el servicio de transferencia, y la subida del emisor ES la descarga del receptor sin copia intermedia. Para una transferencia de 10 GB entre dos usuarios en la misma red gigabit LAN, P2P puede terminar en 80 segundos mientras que un relay en la nube subiría a un servidor distante y descargaría de nuevo, duplicando el uso de ancho de banda y la latencia. La privacidad también es un argumento de venta: los bytes del archivo solo existen en los dispositivos del emisor y el receptor. Los compromisos: ambas partes deben estar conectadas simultáneamente, el NAT traversal falla ocasionalmente, y la conexión es tan rápida como el enlace de subida del participante más lento.
WebRTC Data Channels como transporte
WebRTC comenzó como un protocolo de vídeo/audio pero RTCDataChannel ofrece transporte binario de mensajes arbitrario con entrega fiable ordenada (como TCP) o no fiable desordenada (como UDP). Por debajo, los canales de datos se ejecutan sobre SCTP sobre DTLS 1.3 sobre UDP. La capa DTLS proporciona confidencialidad e integridad autenticada mediante AES-128-GCM o ChaCha20-Poly1305, negociados durante el handshake. Para la transferencia de archivos, crea un canal fiable ordenado, fragmenta el archivo en mensajes de 16 KB o 64 KB (Chrome ha limitado históricamente el tamaño del mensaje a 256 KB) y envíalos secuencialmente con control de flujo mediante el umbral bufferedAmount.
El papel del servidor de señalización
WebRTC necesita un servidor de señalización para intercambiar información de conexión (ofertas SDP y respuestas, candidatos ICE) entre los pares. El servidor de señalización no retransmite bytes de archivo, solo ~5 KB de metadatos de conexión. Un servicio de señalización basado en WebSocket en Node.js, Python o Go gestiona esto en pocas cientos de líneas de código. Firebase Realtime Database, Supabase Realtime y Pusher funcionan como backends de señalización. El servidor de señalización ve quién habla con quién y cuándo, pero nunca el contenido del archivo. La mayoría de los servicios de transferencia de archivos P2P gestionan su señalización de forma gratuita porque el ancho de banda es trivial.
NAT traversal: STUN, TURN e ICE
La mayoría de los dispositivos están detrás de NAT, lo que hace imposibles las conexiones IP directas. ICE (Interactive Connectivity Establishment, RFC 8445) prueba múltiples caminos de conexión. STUN (RFC 8489) permite a un par descubrir su IP y puerto públicos mediante un servidor STUN público; Google ejecuta stun.l.google.com de forma gratuita. Si ambos pares tienen NATs razonables (full-cone o restricted-cone), la conexión UDP directa funciona, quizás el 70 por ciento de los intentos. Para NATs simétricas, cortafuegos corporativos y CGNAT, TURN (RFC 8656) retransmite el tráfico a través de un servidor. Los servidores TURN son caros porque llevan los bytes reales del archivo. coturn autogestionado, twilio.com/stun o Cloudflare Calls proporcionan opciones. Espera que el 10–30 por ciento de las transferencias P2P recurran a TURN en condiciones reales.
Capas de cifrado sobre DTLS
DTLS ya cifra los datos WebRTC, por lo que el cifrado adicional en la capa de aplicación es una precaución extra. El handshake DTLS autentica los certificados del par, pero WebRTC típicamente usa certificados autofirmados que no verifican la identidad —verifican que la conexión es al mismo par que firmó el SDP. El cifrado en la capa de aplicación con AES-256-GCM y un secreto compartido derivado del encuentro de señalización añade garantía de identidad. El SPAKE2 PAKE (Password-Authenticated Key Exchange) de Magic Wormhole deriva una clave fuerte a partir de una frase legible por humanos corta, de modo que incluso un servidor de señalización comprometido no puede descifrar el contenido.
Estrategia de fragmentación para la transferencia P2P
Los canales de datos WebRTC tienen un límite de tamaño de mensaje (256 KB en la mayoría de los navegadores, con la fragmentación de mensajes más grandes funcionando pero siendo poco fiable). Fragmenta los archivos en mensajes de 16 KB a 64 KB por compatibilidad. Rastrea el bufferedAmount mediante bufferedAmount y bufferedAmountLowThreshold para implementar la contrapresión —pausa el envío cuando el buffer supere 1 MB, reanuda cuando caiga por debajo de 256 KB. Para la integridad, hashea cada fragmento con SHA-256 e incluye el hash en un manifiesto enviado primero. El receptor rearma, verifica los hashes y escribe en disco mediante la File System Access API o una descarga Blob.
Consideraciones móviles y entre dispositivos
La transferencia P2P de escritorio a escritorio funciona bien. La transferencia de móvil a escritorio introduce complicaciones: los navegadores móviles imponen una suspensión agresiva de pestañas, por lo que el emisor debe mantener la pestaña del navegador en primer plano. La implementación de los canales de datos de iOS Safari ha sido históricamente menos fiable que la de Chromium. Las subidas en segundo plano en móvil requieren implementaciones respaldadas por apps. El impacto en la batería también importa: las sesiones WebRTC sostenidas agotan las baterías más rápido que las descargas HTTPS. Para las transferencias móvil a móvil en la misma Wi-Fi, AirDrop (iOS/macOS) y Nearby Share (Android) superan al P2P en el navegador usando protocolos de dispositivo directos.
Descubrimiento de pares sin cuentas centrales
¿Cómo se conectan dos desconocidos sin un sistema basado en cuentas? Varios patrones funcionan. Un código corto como "4-truck-roger" de Magic Wormhole sirve tanto de dirección de encuentro como de contraseña; el servidor de señalización mapea los códigos a sesiones. Los códigos QR que codifican una URL de sesión funcionan para las transferencias en persona. La conexión NFC por proximidad en Android conecta mediante proximidad. Para redes más grandes, una DHT como la DHT Mainline de BitTorrent puede arrancar el descubrimiento de pares sin un servidor central, pero las búsquedas DHT tardan segundos y no son aptas para el compartir casual de archivos.
Amenazas de seguridad específicas del P2P
El P2P introduce amenazas que los relays en la nube no tienen. Divulgación de la dirección IP: las conexiones directas revelan la IP pública de cada par al otro, lo que podría identificar a los usuarios en contextos sensibles a la privacidad (denuncia de irregularidades, activismo). Algunos servicios P2P fuerzan el relay TURN para ocultar las IPs a costa del rendimiento. La distribución de malware es más difícil de moderar porque el operador del servicio nunca ve el contenido del archivo. La denegación de servicio mediante el agotamiento de conexiones en el servidor de señalización necesita limitación de tasa. Para las transferencias extra sensibles, un servicio onion de Tor puede preceder la señalización para ocultar ambas IPs a un coste de latencia elevado.
Comprobación de rendimiento realista
La velocidad P2P está limitada por el ancho de banda de subida del par más lento y la latencia de ida y vuelta. En las conexiones residenciales, los límites de subida suelen ser 20–50 Mbps incluso cuando la descarga es gigabit. Una transferencia P2P de 10 GB desde una subida doméstica de 20 Mbps a un receptor con gigabit tarda mínimo 68 minutos. El relay en la nube con un enlace ascendente rápido y una descarga respaldada por CDN puede superar eso subiendo una vez a un servidor bien conectado. El P2P gana para las transferencias en la misma LAN (gigabit o más rápidas), datos sensibles donde no es aceptable ninguna copia en el servidor, y optimización de costes cuando las facturas de ancho de banda serían dolorosas.
Cuándo el relay en la nube sigue ganando
Para las transferencias asíncronas donde el emisor y el receptor no están conectados simultáneamente, P2P falla por completo: no hay par para recibir. Para las transferencias grandes que exceden la ventana de sesión (las pestañas del navegador móvil se cierran, los portátiles se suspenden), el modelo "sube y comparte un enlace" del relay en la nube es simplemente más práctico. Para la distribución de uno a muchos, una única subida más el despliegue CDN supera a ejecutar N sesiones P2P simultáneas. HexaTransfer usa el modelo de relay en la nube con cifrado de extremo a extremo con AES-256-GCM del lado del cliente, obteniendo la mayor parte del beneficio de privacidad del P2P con un soporte asíncrono y multi-receptor mucho mejor.
Pruébalo en https://hexatransfer.com — gratuito, sin cuenta, hasta 10 GB.
Envía archivos grandes de forma segura con cifrado de extremo a extremo
Transfiere archivos de hasta 10 GB gratis con cifrado de extremo a extremo. Sin necesidad de cuenta. Tus archivos se cifran en tu navegador antes de subirlos: nadie más puede leerlos.
Enviar un archivo