La transferencia de archivos con WebRTC permite a dos navegadores enviarse un archivo sin subirlo a un almacenamiento en la nube. Parece sencillo, pero internet no se construyó para que dos ordenadores domésticos se llamen directamente. Esta guía recorre lo que ocurre realmente (señalización, NAT, STUN, ICE, TURN, DTLS y canales de datos) en lenguaje sencillo, con StrongFolder como ejemplo.
¿Qué es WebRTC?
WebRTC (Web Real-Time Communication) es un conjunto de API de navegador y protocolos de red, estandarizados por el W3C y el IETF, para conexiones en tiempo real entre navegadores. Chrome, Edge, Firefox, Safari y Opera lo admiten. Se creó para llamadas de vídeo y voz, pero también tiene canales de datos que transportan cualquier dato binario, que es exactamente lo que es un archivo.
La propiedad clave: una vez establecida una conexión WebRTC, los datos van entre los dos extremos, no al almacenamiento de un servidor. Eso es lo que hace posible la transferencia de archivos P2P en el navegador.
¿Por qué dos navegadores no pueden conectarse sin más?
Porque casi ningún dispositivo tiene su propia dirección pública. Tu portátil está detrás de un router doméstico, de un cortafuegos de oficina o de la red de un operador móvil. El router hace NAT (traducción de direcciones de red): muchos dispositivos privados comparten una sola dirección IP pública, y el router solo deja entrar el tráfico que responde a algo enviado desde dentro.
Así que dos navegadores tienen tres problemas antes de que pueda fluir ningún dato:
- No saben cómo localizarse: ninguno sabe que el otro existe.
- No conocen su propia dirección pública: solo la privada, del tipo 192.168.1.20.
- Sus routers pueden bloquear el tráfico entrante no solicitado.
WebRTC resuelve cada problema con un mecanismo distinto.
¿Cómo funciona una transferencia de archivos WebRTC, paso a paso?
Este es el flujo completo, desde que haces clic en «compartir» hasta el último byte:
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
Pasos 1–2: señalización. El remitente elige los archivos; el servicio registra los metadatos necesarios para el enlace. Cuando el destinatario abre el enlace, ambos navegadores están conectados a un servidor de señalización. WebRTC no define cómo funciona la señalización; StrongFolder usa PeerJS con su propio servidor de señalización.
Paso 3: oferta y respuesta. Un navegador crea una oferta en SDP (Session Description Protocol): «Quiero un canal de datos; estas son mi huella de cifrado y mis capacidades». El otro contesta con una respuesta. Ambas viajan por el servidor de señalización.
Paso 4: STUN. Cada navegador pregunta a un servidor STUN: «¿desde qué dirección y puerto me ves llegar?». La respuesta es su dirección pública tal como la asigna el router. Los servidores STUN atienden una petición minúscula y ningún dato de los archivos; StrongFolder usa servidores STUN públicos, entre ellos los de Google, y los suyos propios.
Paso 5: candidatos ICE. Cada navegador reúne candidatos, es decir, posibles formas de llegar a él: su dirección en la red local (host), su dirección pública obtenida por STUN (server-reflexive) y una dirección en un relé TURN (relayed). Se intercambian los candidatos por la señalización.
Paso 6: comprobaciones de conectividad. ICE (Interactive Connectivity Establishment) prueba pares de candidatos y elige el mejor que funcione. Si ambos dispositivos están en la misma wifi, gana una ruta local. Si los routers lo permiten, gana una ruta directa por internet («hole punching»). Si nada directo funciona, se usa la ruta por el relé.
Paso 7: DTLS. Antes de que fluya ningún dato, los navegadores realizan un intercambio DTLS (TLS adaptado a UDP) y comprueban que las huellas de los certificados coinciden con las de la oferta y la respuesta. A partir de ahí, todo va cifrado.
Paso 8: canal de datos. Sobre DTLS funciona SCTP, que da al canal de datos una entrega fiable y ordenada. En StrongFolder, el navegador del destinatario solicita un archivo, el del remitente lo lee del disco por fragmentos y los envía, y el destinatario escribe cada fragmento en el disco a medida que llega, de modo que ni siquiera los archivos muy grandes tienen que caber en la memoria.
¿Qué significan STUN, TURN, ICE y los demás términos?
| Término | Qué hace | ¿Ve datos de los archivos? | Estándar |
|---|---|---|---|
| Señalización | Transmite ofertas, respuestas y candidatos entre navegadores | No | No estandarizada (propia de cada app) |
| NAT | Función del router que comparte una IP pública entre muchos dispositivos | — | — |
| STUN | Le dice a un navegador su dirección y puerto públicos | No | IETF RFC 8489 |
| ICE | Reúne candidatos y elige una ruta que funcione | No | IETF RFC 8445 |
| TURN | Reenvía el tráfico cuando ninguna ruta directa funciona | Solo paquetes cifrados | IETF RFC 8656 |
| DTLS | Cifra la conexión (TLS para UDP) | Los cifra | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Canal de datos SCTP | Entrega fiable y ordenada de los fragmentos | Los transporta (cifrados) | IETF RFC 8831 |
Todos se explican brevemente en el glosario.
¿Cuándo se usa un relé TURN y qué ve?
El relé es la alternativa, no lo habitual. ICE solo lo usa cuando ningún par de candidatos directo conecta, normalmente en redes con NAT simétrico (algunos operadores móviles), cortafuegos corporativos que bloquean el UDP saliente o ciertas VPN.
Si no es posible una conexión directa (cortafuegos corporativo estricto, algunas redes móviles), el flujo cifrado pasa por un servidor de relé (TURN) de StrongFolder. El relé reenvía los datos y no los guarda.
El relé recibe paquetes cifrados con DTLS y los pasa. Puede ver que hay tráfico, cuánto y cuándo, pero no qué contiene. Una transferencia por el relé puede ser más lenta que una directa, porque cada byte hace un viaje extra por el relé. Si una transferencia va inusualmente lenta, prueba otra red: la zona wifi del móvil o la wifi de casa suelen conectar directamente donde una red de oficina no lo hace.
Gratis · en tu navegador · sin registro
¿Qué seguridad ofrece el cifrado de WebRTC?
WebRTC hace obligatorio el cifrado: no hay forma de abrir un canal de datos sin cifrar. DTLS usa algoritmos modernos negociados por los dos navegadores, y se crean claves nuevas para cada conexión.
Hay una salvedad honesta que se aplica a todos los servicios WebRTC. Los dos navegadores se verifican mutuamente mediante huellas de certificado que se intercambian a través del servidor de señalización. Por tanto, confías en que la señalización del servicio no las manipule. Por eso StrongFolder describe su protección como cifrado en tránsito, no como cifrado de extremo a extremo con claves en tus manos ni como «conocimiento cero». Para una visión más amplia de lo que significa «seguro», lee Compartir archivos de forma segura y Seguridad y privacidad.
¿Por qué el navegador del remitente debe seguir abierto?
Porque el navegador del remitente es el origen. No hay ninguna copia en un servidor a la que recurrir: el canal de datos lee fragmentos del disco del remitente solo mientras la pestaña está abierta y el dispositivo despierto. La pestaña del navegador del remitente debe seguir abierta y conectada hasta que el destinatario termine de descargar: los archivos salen del dispositivo del remitente, no de un servidor. Cómo planificarlo se explica en Por qué el remitente sigue conectado.
¿Qué velocidad tiene la transferencia de archivos con WebRTC?
No hay una velocidad fija. El techo es el enlace más lento de la ruta: normalmente la velocidad de subida del remitente. Como regla general, 1 GB tarda unos 2,7 minutos a 50 Mbit/s, unos 80 segundos a 100 Mbit/s y bastante menos de un minuto en una red local rápida. Las transferencias reales van algo por debajo de estas cifras por la sobrecarga del protocolo, la velocidad del disco y, con un relé, el salto adicional. Varios destinatarios pueden abrir el mismo enlace; cada uno descarga directamente desde el remitente. Varias descargas a la vez se reparten la subida del remitente.
Resumen
Una transferencia de archivos WebRTC es una breve negociación seguida de un flujo largo y cifrado: la señalización presenta a los navegadores, STUN e ICE encuentran una ruta a través de NAT, TURN actúa como relé en último caso y los canales de datos cifrados con DTLS llevan el archivo de disco a disco. Para la parte práctica (lo que esto significa para ti como remitente), empieza por la transferencia de archivos P2P en el navegador y Cómo funciona StrongFolder.