Transferência de arquivos pela rede local
Transfira arquivos e texto diretamente entre dispositivos na mesma rede local via WebRTC — sem necessidade de servidor
O que é a transferência de arquivos pela rede local?
A transferência de arquivos por LAN usa comunicação WebRTC ponto a ponto para enviar arquivos e texto entre dois dispositivos na mesma rede local. Depois que a conexão é estabelecida, os dados podem circular diretamente entre os navegadores, sem primeiro subir para um serviço externo de armazenamento. Isso é útil em computadores de escritório, dispositivos de teste, redes domésticas, salas de aula, laboratórios e entregas rápidas em que pendrives, pastas na nuvem ou anexos de chat seriam mais lentos ou incômodos. A velocidade depende da rede local, do navegador e do desempenho dos dispositivos. Para arquivos sensíveis, verifique o destinatário e feche a sessão ao terminar.
Como Usar
Como usar
- Em um dispositivo, clique em 'Criar Conexão' - o sistema gerará um código QR contendo informações de conexão
- Escaneie o código QR com outro dispositivo - a página abrirá automaticamente e gerará um código de resposta
- Escaneie o código de resposta com o primeiro dispositivo - a conexão WebRTC será estabelecida
- Uma vez conectados, ambas as partes podem trocar mensagens de texto e qualquer tipo de arquivo
Dicas de Transferência
- Mantenha ambos os dispositivos ativos e em uma rede acessível durante a transferência de arquivos; fechar a aba ou colocar o dispositivo em modo de suspensão interromperá a sessão WebRTC.
- Para ficheiros muito grandes ou críticos, verifique o ficheiro descarregado após a transferência, pois a memória do navegador, a qualidade da rede e os limites do dispositivo podem comprometer a fiabilidade.
Casos de uso
Princípio técnico
A transferência de arquivos pela rede local é construída sobre WebRTC (Web Real-Time Communication), o padrão W3C/IETF definido nas RFC 8825-8835, originalmente projetado para áudio e vídeo em tempo real no navegador. A mesma infraestrutura ponto a ponto suporta a API RTCDataChannel, que transporta cargas binárias arbitrárias entre dois navegadores sem nenhum servidor de retransmissão no caminho dos dados. A sinalização que abre o canal é o que o handshake por QR code faz: o emissor cria um blob SDP (Session Description Protocol, RFC 8866) descrevendo suas capacidades de mídia e dados, codifica-o em uma URL ou QR code, e o receptor devolve um SDP de resposta. Uma vez que ambos os lados aplicaram a descrição remota, o ICE (Interactive Connectivity Establishment, RFC 8445) coleta endereços de transporte candidatos. Cada candidato é uma tupla (IP, porta, protocolo) com uma prioridade: candidatos host (IP da própria rede local do dispositivo) geralmente vencem na mesma rede, mas candidatos srflx (server-reflexive, obtidos via solicitação STUN binding) e relay (TURN-relayed, RFC 8656) são tentados em ordem de prioridade. Verificações de conectividade enviam solicitações STUN binding entre candidatos; o primeiro par que obtém sucesso torna-se o par de candidato selecionado. Quando o ICE alcança o estado conectado, o DTLS (Datagram Transport Layer Security, RFC 6347, o primo do TLS 1.2/1.3 em RFC 5246/8446 amigável ao UDP) verifica as impressões digitais de ambos os peers usando os hashes de certificado no SDP, realizando um handshake de uma RTT. As chaves de sessão DTLS então protegem cada pacote SCTP (Stream Control Transmission Protocol, RFC 4960/RFC 9260) por cima, e cada DataChannel é um par de fluxos SCTP sobre essa única associação DTLS. Arquivos grandes são enviados em pedaços pelo DataChannel. A camada SCTP do navegador fragmenta cada mensagem em registros de ~16 KB (o MTU SCTP padrão menos o overhead de DTLS + SCTP + Chunk Header, ajustável por implementação, frequentemente 16 KB ou 64 KB dependendo do motor), e o receptor os reassem em ordem. Controle de fluxo e congestão (RFC 4960 §6) impedem que o sender sobrecarregue o receptor: cwnd cresce aditivamente em ACK e contrai multiplicativamente em perda, o mesmo formato do AIMD do TCP mas aplicado por associação SCTP. Em uma rede local gigabit, a taxa de transferência de ponta a ponta geralmente fica limitada a 200-400 MB/s pelo custo de codificação na thread principal do navegador (converter cada chunk em uma view ArrayBuffer e empurrá-lo para a pilha SCTP), não pela velocidade do cabo. A página reassem os chunks recebidos em um único Blob e o oferece para download para que o usuário decida onde os bytes serão salvos, o que evita que o receptor mantenha gigabytes em memória no pico. Como os dados fluem ponto a ponto com criptografia no estilo DTLS-SRTP, roteadores intermediários e servidores de retransmissão só veem texto cifrado; o operador da página nunca vê o texto plano, e não há etapa de upload. A troca é o servidor de sinalização necessário para trocar SDP — esta página usa QR codes e links de copiar-e-colar como canal de sinalização manual e sem servidor, razão pela qual duas leituras são necessárias.
- WebRTC é um padrão W3C/IETF (RFC 8825-8835) que reúne três motores: SDP para negociação, ICE para coleta de candidatos e DTLS-SRTP / DTLS-SCTP para segurança de transporte.
- O handshake por QR code é sinalização sem servidor: o emissor publica uma oferta SDP, o receptor devolve uma resposta SDP, e nenhum servidor central jamais vê o caminho dos dados.
- ICE (RFC 8445) coleta candidatos host, srflx (STUN-reflexive), prflx (peer-reflexive) e relay (TURN, RFC 8656); o par de maior prioridade que passa nas verificações de conectividade torna-se o transporte selecionado.
- DTLS (RFC 6347) realiza um handshake verificado por impressão digital em uma RTT usando os hashes de certificado fixados no SDP, e então criptografa cada byte no cabo — sem fallback para HTTP ou WebSocket em texto plano.
- DataChannel funciona sobre SCTP-over-DTLS, não UDP bruto: SCTP fornece fluxos ordenados, confiáveis e orientados a mensagem com controle de congestão (RFC 4960 §6) sobre um socket UDP.
- O tamanho do chunk é aproximadamente 16 KB por padrão (dependente do navegador, às vezes 64 KB): o receptor reassem os chunks em um único Blob e aciona um download para evitar manter o arquivo inteiro em memória.
- A memória do navegador é o teto real: um arquivo de 1 GB significa ~1 GB de movimentação de ArrayBuffer, então em celulares o limite prático geralmente é de 200-500 MB por transferência, não a velocidade da rede.
- A travessia NAT do WebRTC precisa de um servidor STUN/TURN para peers em redes diferentes; esta página assume uma topologia na mesma rede local, então candidatos host (IPs da LAN) geralmente vencem e nenhum servidor STUN é consultado.
Exemplos
Enviar fotos do celular para o computador
1. No computador, clique em "Criar conexão" para gerar um QR code
2. Escaneie com o celular; a página abre e gera um código de resposta
3. Escaneie o código de resposta no computador para concluir o handshake
4. Selecione as fotos que deseja enviar e clique em EnviarEnviar arquivos do computador para o celular
Após a conexão estar ativa, clique em "Enviar arquivo" no computador e escolha um documento, arquivo compactado ou vídeo.
O celular recebe um aviso e salva o arquivo com um único toque.Trocar mensagens de texto
Uma vez conectado, ambos os lados podem digitar na caixa de entrada e enviar.
Não é necessário nenhum app extra - é um simples chat bidirecional no navegador.Perguntas frequentes
Como funciona a transferência de arquivos?
Dois dispositivos na mesma rede local se conectam via WebRTC peer-to-peer. Depois que a sinalização configura a conexão, os arquivos viajam diretamente entre os navegadores — não passam por nenhum servidor intermediário. A velocidade depende da sua rede local (Wi-Fi ou Ethernet); um Wi-Fi típico entrega de 30 a 150 Mbps.
Meus arquivos saem da rede local?
Depois que a conexão WebRTC é estabelecida, não — os bytes do arquivo trafegam apenas entre os dois dispositivos. Um pequeno passo de sinalização (troca de descrições de sessão) acontece através de um servidor de coordenação antes de a conexão ser estabelecida; essa troca é metadado, não conteúdo do arquivo.
Por que os dois dispositivos não se conectam?
Ambos os dispositivos precisam estar na mesma rede Wi-Fi ou no mesmo segmento de LAN. Redes corporativas frequentemente bloqueiam conexões peer-to-peer; redes Wi-Fi para visitantes muitas vezes isolam clientes uns dos outros ('client isolation'). Tente um Wi-Fi pessoal ou um hotspot. VPNs em qualquer um dos dispositivos também podem bloquear a conexão peer direta.
Existe limite de tamanho de arquivo?
O WebRTC não tem limite no protocolo, mas os limites práticos são a memória do navegador e o tempo de atividade da aba. Transferências de vários GB normalmente funcionam em desktops; navegadores móveis podem suspender a aba e quebrar a transferência. Mantenha as duas abas em primeiro plano durante transferências grandes.
Os arquivos transferidos são criptografados?
Sim. Os data channels do WebRTC usam criptografia DTLS-SRTP de ponta a ponta; mesmo um atacante na mesma rede Wi-Fi não consegue ler o conteúdo do arquivo. O passo de sinalização usa HTTPS para o servidor de coordenação. Trate a transferência como privada, desde que ambos os endpoints sejam confiáveis.
Funciona para usuários não técnicos?
Sim — compartilhe o código/URL da sala com a outra pessoa; ela abre no navegador e a conexão se forma automaticamente. Sem instalar app. A interface parece o AirDrop sem a restrição de plataforma. Funciona entre Safari no iOS, Chrome no Android, Edge no Windows, Firefox no macOS, etc.
Posso enviar para vários dispositivos de uma vez?
A maioria das versões suporta uma sala um-para-um. Para enviar para vários receptores, repita a transferência ou use uma ferramenta de multicast. Transferência em grupo via WebRTC é implementável, mas usa N vezes a banda de upload.