# Cómo funciona la transferencia de archivos con WebRTC Source: https://help.strongfolder.com/es/guides/how-webrtc-file-transfer-works/ Updated: 2026-11-05 > La transferencia de archivos con WebRTC funciona en tres fases. Un servidor de señalización presenta a dos navegadores; STUN e ICE encuentran una ruta de red a través de los routers domésticos (NAT), con un relé TURN como alternativa si no existe ruta directa; después, los navegadores abren un canal de datos cifrado con DTLS y transmiten el archivo por fragmentos, directamente o a través del relé, sin guardarlo. 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. **Key facts** - **WebRTC** es un estándar de los navegadores para conexiones directas y cifradas entre dos dispositivos; las herramientas de archivos usan sus **canales de datos**. - **La señalización** presenta a los navegadores; **STUN** e **ICE** encuentran una ruta a través de los routers (**NAT**); un **relé TURN** reenvía el tráfico cuando no hay ruta directa. - **Cifrado:** todos los canales de datos usan **DTLS**; WebRTC no tiene modo sin cifrar. - StrongFolder usa PeerJS sobre WebRTC, un servidor de señalización de StrongFolder, servidores STUN públicos (entre ellos los de Google) y sus propios relés TURN. Los archivos nunca se suben ni se guardan en un servidor de StrongFolder. - El archivo se transmite por fragmentos del disco del remitente al del destinatario; el remitente sigue conectado. ## ¿Qué es WebRTC? [WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/). ## ¿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](https://help.strongfolder.com/en/glossary/#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: 1. No saben **cómo localizarse**: ninguno sabe que el otro existe. 2. No conocen **su propia dirección pública**: solo la privada, del tipo 192.168.1.20. 3. 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](https://help.strongfolder.com/en/glossary/#signaling). 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/). ## ¿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. [Enviar archivos ahora](https://strongfolder.com) ## ¿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](https://help.strongfolder.com/en/guides/secure-file-sharing/) y [Seguridad y privacidad](https://help.strongfolder.com/en/security/). ## ¿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](https://help.strongfolder.com/en/guides/why-sender-stays-online/). ## ¿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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) y [Cómo funciona StrongFolder](https://help.strongfolder.com/en/how-it-works/). ## FAQ ### ¿Qué es un canal de datos WebRTC? Un canal de datos es la parte de WebRTC que transporta bytes arbitrarios entre dos navegadores en lugar de audio o vídeo. Funciona con SCTP sobre DTLS sobre UDP, así que va cifrado y se puede configurar como fiable y ordenado, que es lo que necesita una transferencia de archivos. ### ¿Qué diferencia hay entre STUN y TURN? Un servidor STUN solo le dice a un navegador cómo se ve su dirección pública, para que los dos navegadores intenten conectarse directamente; por él no pasa ningún dato de los archivos. Un servidor TURN es un relé: cuando ninguna ruta directa funciona, el flujo cifrado pasa por él. StrongFolder tiene sus propios relés TURN, que reenvían los datos y no los guardan. ### ¿El servidor de señalización ve mis archivos? No. El servidor de señalización solo transmite mensajes de conexión (descripciones de sesión y candidatos de red) entre los navegadores. Los datos de los archivos fluyen por el canal de datos, directamente o a través de un relé TURN. ### ¿La transferencia de archivos con WebRTC va cifrada? WebRTC cifra cada canal de datos con DTLS, así que el flujo de archivos va cifrado en tránsito en todas las conexiones. WebRTC no permite canales de datos sin cifrar. Las claves las negocian los dos navegadores; sus huellas viajan por la señalización, y por eso esto es cifrado en tránsito y no cifrado de extremo a extremo con claves que gestionas tú. ### ¿Por qué una transferencia WebRTC a veces falla o va lenta? Normalmente por la ruta de red: un cortafuegos estricto o una VPN bloquean el UDP directo, así que la conexión recurre a un relé TURN por TCP o no llega a conectarse. Prueba otra red (por ejemplo, la zona wifi del móvil), desactiva la VPN o pide a TI que permita WebRTC. ### ¿Puede un relé TURN leer mis archivos? El relé reenvía paquetes cifrados con DTLS entre los dos navegadores. Ve tráfico cifrado, tamaños y tiempos, no el contenido de los archivos, y el relé de StrongFolder no guarda lo que reenvía.