Transferência Encriptada Peer-to-Peer: Guia Técnico

A transferência de ficheiros peer-to-peer envia bytes diretamente entre dois browsers ou dispositivos sem que o ficheiro alguma vez toque num servidor. O WebRTC, padronizado nas RFCs 8825 a 8837, fornece o transporte: canais de dados encriptados sobre UDP com DTLS 1.3, NAT traversal via ICE, STUN e TURN, e sinalização sobre WebSocket ou HTTP. Ferramentas como Snapdrop, Wormhole.app e Magic Wormhole provam que o modelo funciona. Eis como construí-lo: o handshake de sinalização, as armadilhas do NAT traversal, a camada de encriptação, e o que se ganha ou perde em comparação com serviços de transferência via relay na nuvem.

Por que P2P para Transferência de Ficheiros

O apelo é simples: nenhum servidor armazena o seu ficheiro, sem fatura de largura de banda para o serviço de transferência, e o upload do remetente É o download do destinatário sem cópia intermédia. Para uma transferência de 10 GB entre dois utilizadores na mesma LAN gigabit, o P2P pode terminar em 80 segundos enquanto um relay na nuvem faria upload para um servidor distante e download novamente, duplicando o uso de largura de banda e a latência. A privacidade também é um ponto de venda — os bytes do ficheiro existem apenas nos dispositivos do remetente e do destinatário. Os trade-offs: ambas as partes devem estar online em simultâneo, o NAT traversal falha ocasionalmente, e a ligação é tão rápida quanto o link de upload do participante mais lento.

Canais de Dados WebRTC como Transporte

O WebRTC começou como um protocolo de vídeo/áudio, mas o RTCDataChannel fornece transporte de mensagens binárias arbitrárias com entrega fiável ordenada (como TCP) ou não fiável não ordenada (como UDP). Por baixo, os canais de dados correm sobre SCTP sobre DTLS 1.3 sobre UDP. A camada DTLS fornece confidencialidade e integridade autenticada via AES-128-GCM ou ChaCha20-Poly1305, negociada durante o handshake. Para transferência de ficheiros, crie um canal fiável ordenado, divida o ficheiro em mensagens de 16 KB a 64 KB (o Chrome limitou historicamente o tamanho das mensagens a 256 KB), e envie-as sequencialmente com controlo de fluxo via o limiar bufferedAmount.

O Papel do Servidor de Sinalização

O WebRTC precisa de um servidor de sinalização para trocar informação de ligação (ofertas e respostas SDP, candidatos ICE) entre pares. O servidor de sinalização não faz relay dos bytes dos ficheiros, apenas ~5 KB de metadados de ligação. Um serviço de sinalização baseado em WebSocket em Node.js, Python ou Go trata disto em algumas centenas de linhas de código. O Firebase Realtime Database, o Supabase Realtime e o Pusher funcionam todos como backends de sinalização. O servidor de sinalização vê quem está a falar com quem e quando, mas nunca o conteúdo dos ficheiros. A maior parte dos serviços de transferência P2P corre a sua sinalização gratuitamente porque a largura de banda é trivial.

NAT Traversal: STUN, TURN e ICE

A maior parte dos dispositivos está por detrás de NAT, tornando impossíveis as ligações IP diretas. O ICE (Interactive Connectivity Establishment, RFC 8445) tenta múltiplos caminhos de ligação. O STUN (RFC 8489) permite que um par descubra o seu IP e porta públicos via um servidor STUN público; a Google corre stun.l.google.com gratuitamente. Se ambos os pares têm NATs razoáveis (full-cone ou restricted-cone), a ligação UDP direta funciona — talvez 70 por cento das tentativas. Para NATs simétricos, firewalls empresariais e CGNAT, o TURN (RFC 8656) faz relay do tráfego através de um servidor. Os servidores TURN são dispendiosos porque transportam os bytes reais dos ficheiros. O coturn auto-hospedado, twilio.com/stun ou Cloudflare Calls fornecem opções. Espere que 10 a 30 por cento das transferências P2P recorram ao TURN em ambiente real.

Camada de Encriptação sobre DTLS

O DTLS já encripta os dados WebRTC, pelo que a encriptação adicional na camada de aplicação é uma camada de segurança extra. O handshake DTLS autentica certificados de par, mas o WebRTC tipicamente usa certificados auto-assinados que não verificam identidade — verificam que a ligação é para o mesmo par que assinou o SDP. A encriptação na camada de aplicação com AES-256-GCM e um segredo partilhado derivado do rendezvous de sinalização adiciona garantia de identidade. O SPAKE2 PAKE do Magic Wormhole (Password-Authenticated Key Exchange) deriva uma chave forte a partir de uma frase curta legível por humanos, de modo que mesmo um servidor de sinalização comprometido não consegue desencriptar.

Estratégia de Chunking para Transferência P2P de Ficheiros

Os canais de dados WebRTC têm um limite de tamanho de mensagem (256 KB na maioria dos browsers, com fragmentação de mensagens maiores a funcionar mas de forma não fiável). Divida os ficheiros em 16 KB a 64 KB por mensagem para compatibilidade. Acompanhe o bufferedAmount via bufferedAmount e bufferedAmountLowThreshold para implementar backpressure — pause o envio quando o buffer excede 1 MB, retome quando cai abaixo de 256 KB. Para integridade, faça hash de cada chunk com SHA-256 e inclua o hash num manifesto enviado primeiro. O recetor reassembla, verifica os hashes e escreve para disco via a File System Access API ou um download Blob.

Considerações para Dispositivos Móveis e Multi-Dispositivo

O P2P desktop-para-desktop funciona bem. O móvel-para-desktop introduz complicações: os browsers móveis aplicam suspensão agressiva de separadores, pelo que o remetente deve manter o separador do browser em primeiro plano. A implementação de canais de dados do iOS Safari tem sido historicamente menos fiável do que o Chromium. Os uploads em background no móvel requerem implementações suportadas por app (Snapdrop Relay, ShareDrop). O impacto na bateria também importa — as sessões WebRTC sustentadas drenam as baterias mais rapidamente do que os downloads HTTPS. Para transferências móvel-para-móvel na mesma Wi-Fi, o AirDrop (iOS/macOS) e o Nearby Share (Android) superam o P2P do browser ao usar protocolos diretos de dispositivo.

Descoberta de Pares Sem Contas Centrais

Como se conectam dois desconhecidos sem um sistema baseado em contas? Vários padrões funcionam. Um código curto como o "4-truck-roger" do Magic Wormhole serve tanto como endereço de rendezvous como senha; o servidor de sinalização mapeia códigos para sessões. Os códigos QR que codificam um URL de sessão funcionam para transferências presenciais. O toque NFC para ligação no Android conecta via proximidade. Para redes maiores, uma DHT como a Mainline DHT do BitTorrent pode bootstrapar a descoberta de pares sem um servidor central, mas as pesquisas DHT demoram segundos e não são adequadas para partilha casual de ficheiros.

Ameaças de Segurança Específicas do P2P

O P2P introduz ameaças que os relays na nuvem não têm. Divulgação de endereço IP: as ligações diretas revelam o IP público de cada par ao outro, potencialmente expondo utilizadores em contextos sensíveis à privacidade (denunciantes, ativistas). Alguns serviços P2P forçam o relay TURN para esconder IPs ao custo do desempenho. A distribuição de malware é mais difícil de moderar porque o operador do serviço nunca vê o conteúdo dos ficheiros. A negação de serviço via esgotamento de ligações no servidor de sinalização precisa de limitação de taxa. Para transferências extra-sensíveis, um serviço onion Tor pode cobrir a sinalização para esconder ambos os IPs com um custo pesado de latência.

Verificação de Desempenho Real

A velocidade P2P é limitada pela largura de banda de upload do par mais lento e pela latência round-trip. Em ligações residenciais, os limites de upload são frequentemente 20 a 50 Mbps mesmo quando o download é gigabit. Uma transferência P2P de 10 GB a partir de um upload doméstico de 20 Mbps para um destinatário em gigabit demora no mínimo 68 minutos. Um relay na nuvem com um uplink rápido e download suportado por CDN pode superar isso fazendo upload uma vez para um servidor bem ligado. O P2P vence em transferências na mesma LAN (gigabit ou mais rápido), dados sensíveis onde nenhuma cópia no servidor é aceitável, e otimização de custos quando as faturas de largura de banda seriam dolorosas.

Quando o Relay na Nuvem Ainda Vence

Para transferências assíncronas onde remetente e destinatário não estão online em simultâneo, o P2P falha por completo — não há par para receber. Para grandes transferências que excedem a janela de sessão (separadores de browser móvel fecham, portáteis adormecem), o modelo de relay na nuvem de "fazer upload e partilhar um link" é simplesmente mais prático. Para distribuição de um-para-muitos, um único upload mais fanout CDN supera a execução de N sessões P2P simultâneas. O HexaTransfer usa o modelo de relay na nuvem com encriptação AES-256-GCM do lado do cliente, obtendo a maior parte do benefício de privacidade do P2P com muito melhor suporte assíncrono e multi-destinatário.

Experimente em https://hexatransfer.com — gratuito, sem conta, máximo de 10 GB.