Transferencia de archivos por LAN
Transfiere archivos y texto directamente entre dispositivos en la misma red local mediante WebRTC, sin necesidad de servidor
¿Qué es la transferencia de archivos por LAN?
La transferencia de archivos por LAN usa comunicación WebRTC punto a punto para enviar archivos y texto entre dos dispositivos de la misma red local. Después de establecer la conexión, los datos pueden moverse directamente entre navegadores sin subirse primero a un servicio externo. Es útil entre equipos de oficina, dispositivos de prueba, redes domésticas, aulas, laboratorios y entregas rápidas donde memorias USB, carpetas en la nube o adjuntos de chat resultan más lentos o incómodos. La velocidad depende de la red local, el navegador y el rendimiento de los dispositivos. Para archivos sensibles conviene verificar el receptor y cerrar la sesión temporal al terminar.
Cómo usar
Cómo usar
- En un dispositivo, haz clic en Create Connection; el sistema generará un código QR con la información de conexión
- Escanea el código QR con otro dispositivo; la página se abrirá automáticamente y generará un código de respuesta
- Escanea el código de respuesta con el primer dispositivo; se establecerá la conexión WebRTC
- Una vez conectados, ambas partes pueden intercambiar mensajes de texto y archivos de cualquier tipo
Consejos de transferencia
- Mantén ambos dispositivos activos y en una red accesible mientras transfieres archivos; cerrar la pestaña o suspender el dispositivo interrumpirá la sesión WebRTC.
- Para archivos muy grandes o críticos, verifica el archivo descargado después de la transferencia, ya que la memoria del navegador, la calidad de la red y las limitaciones del dispositivo pueden afectar la fiabilidad.
Casos de uso
Principio técnico
La transferencia de archivos por LAN se basa en WebRTC (Web Real-Time Communication), el estándar W3C/IETF definido en RFC 8825-8835, diseñado originalmente para audio y vídeo en tiempo real en el navegador. La misma maquinaria punto a punto soporta la API RTCDataChannel, que transporta cargas binarias arbitrarias entre dos navegadores sin ningún servidor de retransmisión en la ruta de datos. La señalización que abre el canal es lo que realiza el handshake mediante código QR: el emisor crea un blob SDP (Session Description Protocol, RFC 8866) que describe sus capacidades de medios y datos, lo codifica en una URL o código QR, y el receptor devuelve un SDP de respuesta. Una vez que ambos lados han aplicado la descripción remota, ICE (Interactive Connectivity Establishment, RFC 8445) reúne las direcciones de transporte candidatas. Cada candidato es una tupla (IP, puerto, protocolo) con una prioridad: los candidatos host (la propia IP de la LAN del dispositivo) suelen ganar en la misma red, pero los candidatos srflx (server-reflexive, obtenidos de una solicitud de binding STUN) y relay (TURN-relayed, RFC 8656) se prueban en orden de prioridad. Las verificaciones de conectividad envían solicitudes de binding STUN entre candidatos; el primer par que tiene éxito se convierte en el par de candidatos seleccionado. Una vez que ICE alcanza el estado conectado, DTLS (Datagram Transport Layer Security, RFC 6347, el primo UDP-friendly de TLS 1.2/1.3 en RFC 5246/8446) verifica las huellas digitales de ambos pares usando los hashes de certificado en el SDP, realizando un handshake de un RTT. Las claves de sesión DTLS protegen entonces cada paquete SCTP (Stream Control Transmission Protocol, RFC 4960/RFC 9260) por encima, y cada DataChannel es un par de flujos SCTP que funcionan sobre esa única asociación DTLS. Los archivos grandes se envían en fragmentos a través del DataChannel. La capa SCTP del navegador fragmenta cada mensaje en registros de ~16 KB (el MTU SCTP por defecto menos la sobrecarga de DTLS + SCTP + Chunk Header, y ajustable según la implementación, a menudo 16 KB o 64 KB dependiendo del motor), y el receptor los reensambla en orden. El control de flujo y congestión (RFC 4960 §6) evita que el sature al receptor: cwnd crece aditivamente en ACK y se reduce multiplicativamente en pérdida, la misma forma que el AIMD de TCP pero aplicado por asociación SCTP. En una LAN gigabit, el rendimiento extremo a extremo suele limitarse a 200-400 MB/s por el coste de codificación en el hilo principal del navegador (convertir cada fragmento en una vista de ArrayBuffer e introducirlo en la pila SCTP), no por la velocidad del cable. La página reensambla los fragmentos entrantes en un único Blob y lo ofrece como descarga para que el usuario decida dónde se almacenan los bytes, evitando que el receptor mantenga gigabytes en memoria en el pico. Dado que los datos fluyen de par a par con cifrado de estilo DTLS-SRTP, los routers intermedios y los servidores de retransmisión solo ven texto cifrado; el operador de la página nunca ve el texto plano y no hay paso de subida. La contrapartida es el servidor de señalización necesario para intercambiar SDP: esta página usa códigos QR y enlaces de copiar-pegar como canal de señalización manual y sin servidor, por eso se requieren dos escaneos.
- WebRTC es un estándar W3C/IETF (RFC 8825-8835) que agrupa tres motores: SDP para negociación, ICE para recopilación de candidatos y DTLS-SRTP / DTLS-SCTP para seguridad del transporte.
- El handshake mediante código QR es señalización sin servidor: el emisor publica una oferta SDP, el receptor devuelve una respuesta SDP, y ningún servidor central ve la ruta de datos.
- ICE (RFC 8445) recopila candidatos host, srflx (STUN-reflexive), prflx (peer-reflexive) y relay (TURN, RFC 8656); el par de mayor prioridad que pasa las verificaciones de conectividad se convierte en el transporte seleccionado.
- DTLS (RFC 6347) realiza un handshake de un RTT con verificación de huella digital usando los hashes de certificado fijados en el SDP, y luego cifra cada byte en el cable: no hay fallback a HTTP plano ni WebSocket.
- DataChannel funciona sobre SCTP sobre DTLS, no sobre UDP en bruto: SCTP proporciona flujos orientados a mensajes, ordenados y fiables con control de congestión (RFC 4960 §6) sobre un socket UDP.
- El tamaño del fragmento es de aproximadamente 16 KB por defecto (según el navegador, a veces 64 KB): el receptor reensambla los fragmentos en un único Blob y activa una descarga para evitar mantener todo el archivo en memoria.
- La memoria del navegador es el límite real: un archivo de 1 GB implica ~1 GB de uso de ArrayBuffer, por lo que en teléfonos el límite práctico suele ser 200-500 MB por transferencia, no la velocidad de la red.
- El atravesamiento NAT de WebRTC necesita un servidor STUN/TURN para pares en redes diferentes; esta página asume una topología de LAN única, por lo que los candidatos host (IPs de LAN) suelen ganar y no se consulta ningún servidor STUN.
Ejemplos
Enviar fotos del teléfono al ordenador
1. En el ordenador, haz clic en "Crear conexión" para generar un código QR
2. Escanéalo con el teléfono; la página se abre y produce un código de respuesta
3. Escanea el código de respuesta en el ordenador para completar el handshake
4. Selecciona las fotos que quieras enviar y haz clic en EnviarEnviar archivos del ordenador al teléfono
Una vez establecida la conexión, haz clic en "Enviar archivo" en el ordenador y elige un documento, archivo comprimido o vídeo.
El teléfono recibe una notificación y guarda el archivo con un solo toque.Intercambiar mensajes de texto
Una vez conectados, ambos lados pueden escribir en el cuadro de entrada y enviar.
No se requiere una app adicional: es un chat bidireccional sencillo en el navegador.Preguntas frecuentes
¿Cómo funciona la transferencia de archivos?
Dos dispositivos en la misma red local se conectan por WebRTC peer-to-peer. Después de que la señalización establezca la conexión, los archivos viajan directamente entre los navegadores: no pasan por ningún servidor intermedio. La velocidad depende de tu red local (Wi-Fi o Ethernet); un Wi-Fi típico ofrece de 30 a 150 Mbps.
¿Mis archivos salen de la red local?
Una vez establecida la conexión WebRTC, no: los bytes del archivo fluyen solo entre los dos dispositivos. Antes de que la conexión esté en pie hay un pequeño paso de señalización (intercambio de descripciones de sesión) a través de un servidor de coordinación; ese intercambio son metadatos, no contenido del archivo.
¿Por qué no se conectan los dos dispositivos?
Ambos dispositivos deben estar en la misma red Wi-Fi o segmento de LAN. Las redes corporativas suelen bloquear las conexiones peer-to-peer; el Wi-Fi para invitados a menudo aísla a los clientes entre sí ('client isolation'). Prueba con un Wi-Fi personal o un punto de acceso. Las VPN en cualquiera de los dispositivos también pueden bloquear la conexión directa entre pares.
¿Hay un límite de tamaño de archivo?
WebRTC no tiene límite de protocolo, pero los límites prácticos son la memoria del navegador y el tiempo de actividad de la pestaña. Las transferencias de varios GB suelen funcionar en escritorio; los navegadores móviles pueden suspender la pestaña y romper la transferencia. Mantén ambas pestañas en primer plano durante transferencias grandes.
¿Los archivos transferidos están cifrados?
Sí. Los canales de datos de WebRTC usan cifrado DTLS-SRTP de extremo a extremo; ni siquiera un atacante en el mismo Wi-Fi puede leer el contenido del archivo. El paso de señalización usa HTTPS hacia el servidor de coordinación. Considera la transferencia privada siempre que ambos extremos sean de confianza.
¿Funciona para usuarios sin conocimientos técnicos?
Sí: comparte el código/URL de la sala con la otra persona; lo abre en su navegador y la conexión se forma automáticamente. Sin instalar app. La interfaz se parece a AirDrop sin la restricción de plataforma. Funciona entre iOS Safari, Android Chrome, Windows Edge, macOS Firefox, etc.
¿Puedo enviar a varios dispositivos a la vez?
La mayoría de las versiones admiten una sala uno a uno. Para enviar a varios receptores, repite la transferencia o usa una herramienta de multidifusión. La transferencia en grupo por WebRTC es implementable, pero usa N veces el ancho de banda de subida.