A transferência de arquivos por WebRTC permite que dois navegadores enviem um arquivo um ao outro sem fazer upload para um armazenamento na nuvem. Parece simples, mas a internet não foi feita para dois computadores domésticos se chamarem diretamente. Este guia mostra o que realmente acontece — sinalização, NAT, STUN, ICE, TURN, DTLS e canais de dados — em linguagem simples, usando o StrongFolder como exemplo.
O que é WebRTC?
WebRTC (Web Real-Time Communication) é um conjunto de APIs de navegador e protocolos de rede, padronizado pelo W3C e pela IETF, para conexões em tempo real entre navegadores. Chrome, Edge, Firefox, Safari e Opera são todos compatíveis. Ele foi criado para chamadas de vídeo e voz, mas também tem canais de dados que transportam quaisquer dados binários — que é exatamente o que um arquivo é.
A propriedade principal: depois que uma conexão WebRTC é estabelecida, os dados vão entre as duas pontas, e não para o armazenamento de um servidor. É isso que torna possível a transferência de arquivos P2P no navegador.
Por que dois navegadores não podem simplesmente se conectar?
Porque quase nenhum dispositivo tem endereço público próprio. Seu notebook fica atrás de um roteador doméstico, de um firewall de escritório ou da rede de uma operadora de celular. O roteador faz NAT (Network Address Translation): muitos dispositivos privados compartilham um único endereço IP público, e o roteador só deixa entrar tráfego que responde a algo enviado de dentro.
Assim, dois navegadores enfrentam três problemas antes que qualquer dado de arquivo possa fluir:
- Eles não sabem como alcançar um ao outro — nenhum sabe que o outro existe.
- Eles não sabem o próprio endereço público — só o privado, como 192.168.1.20.
- Os roteadores deles podem bloquear tráfego de entrada não solicitado.
O WebRTC resolve cada problema com um mecanismo separado.
Como funciona uma transferência de arquivos por WebRTC, passo a passo?
Este é o fluxo completo, do clique em "compartilhar" até o ú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
Passos 1–2 — Sinalização. O remetente escolhe os arquivos; o serviço registra os metadados necessários para o link. Quando o destinatário abre o link, os dois navegadores estão conectados a um servidor de sinalização. O WebRTC não define como a sinalização funciona; o StrongFolder usa o PeerJS com um servidor de sinalização próprio.
Passo 3 — Oferta e resposta. Um navegador cria uma oferta em SDP (Session Description Protocol): "quero um canal de dados; aqui estão minha impressão digital de criptografia e meus recursos". O outro responde com uma resposta. As duas passam pelo servidor de sinalização.
Passo 4 — STUN. Cada navegador pergunta a um servidor STUN: "de qual endereço e porta você me vê chegando?" A resposta é o seu endereço público conforme mapeado pelo roteador. Os servidores STUN tratam uma requisição minúscula e nenhum dado de arquivo; o StrongFolder usa servidores STUN públicos, incluindo os do Google, e os próprios.
Passo 5 — Candidatos ICE. Cada navegador reúne candidatos — formas possíveis de alcançá-lo: o endereço da rede local (host), o endereço público obtido pelo STUN (server-reflexive) e um endereço em um relay TURN (relayed). Eles trocam os candidatos pela sinalização.
Passo 6 — Verificações de conectividade. O ICE (Interactive Connectivity Establishment) testa pares de candidatos e escolhe o melhor que funciona. Se os dois dispositivos estiverem na mesma rede Wi-Fi, vence um caminho local. Se os roteadores permitirem, vence um caminho direto pela internet ("hole punching"). Se nada direto funcionar, usa-se o caminho via relay.
Passo 7 — DTLS. Antes de qualquer dado fluir, os navegadores fazem um handshake DTLS (TLS adaptado para UDP) e verificam se as impressões digitais dos certificados batem com as da oferta e da resposta. A partir daí, tudo é criptografado.
Passo 8 — Canal de dados. Sobre o DTLS roda o SCTP, que dá ao canal de dados entrega confiável e ordenada. No StrongFolder, o navegador do destinatário pede um arquivo, o navegador do remetente o lê do disco em pedaços e os envia, e o destinatário grava cada pedaço no disco assim que ele chega — então nem arquivos muito grandes precisam caber na memória.
O que significam STUN, TURN, ICE e os outros termos?
| Termo | O que faz | Vê os dados do arquivo? | Padrão |
|---|---|---|---|
| Sinalização | Passa ofertas, respostas e candidatos entre os navegadores | Não | Não padronizado (específico de cada app) |
| NAT | Recurso do roteador que compartilha um IP público entre vários dispositivos | — | — |
| STUN | Informa ao navegador seu endereço e porta públicos | Não | IETF RFC 8489 |
| ICE | Reúne candidatos e escolhe um caminho que funcione | Não | IETF RFC 8445 |
| TURN | Retransmite o tráfego quando nenhum caminho direto funciona | Só pacotes criptografados | IETF RFC 8656 |
| DTLS | Criptografa a conexão (TLS para UDP) | Criptografa os dados | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Canal de dados SCTP | Entrega confiável e ordenada dos pedaços | Transporta os dados (criptografados) | IETF RFC 8831 |
Todos eles são explicados brevemente no glossário.
Quando um relay TURN é usado e o que ele vê?
O relay é a alternativa, não o padrão. O ICE só o usa quando nenhum par de candidatos diretos se conecta — normalmente em redes com NAT simétrico (algumas operadoras de celular), firewalls corporativos que bloqueiam UDP de saída ou certas VPNs.
Se uma conexão direta for impossível (firewall corporativo rígido, algumas redes móveis), o fluxo criptografado passa por um servidor relay (TURN) do StrongFolder. O relay encaminha os dados e não os armazena.
O relay recebe pacotes criptografados com DTLS e os repassa. Ele consegue ver que há tráfego, quanto e quando — não o que há dentro. Uma transferência via relay pode ser mais lenta que uma direta, porque cada byte faz uma viagem extra pelo relay. Se uma transferência estiver anormalmente lenta, tente outra rede: o roteador do celular ou o Wi-Fi de casa muitas vezes se conectam diretamente onde a rede do escritório não consegue.
Grátis · no navegador · sem cadastro
Quão segura é a criptografia do WebRTC?
O WebRTC torna a criptografia obrigatória: não há como abrir um canal de dados sem criptografia. O DTLS usa cifras modernas negociadas pelos dois navegadores, e chaves novas são criadas a cada conexão.
Há uma ressalva honesta que vale para todo serviço WebRTC. Os dois navegadores se verificam por meio de impressões digitais de certificados trocadas pelo servidor de sinalização. Portanto, você confia que a sinalização do serviço não as adultera. É por isso que o StrongFolder descreve sua proteção como criptografia em trânsito — não como criptografia de ponta a ponta com chaves que você guarda, nem como "zero-knowledge". Para uma visão mais ampla do que "seguro" significa, leia Compartilhamento seguro de arquivos e Segurança e privacidade.
Por que o navegador do remetente precisa ficar aberto?
Porque o navegador do remetente é a origem. Não há cópia em servidor para recorrer: o canal de dados só lê pedaços do disco do remetente enquanto a aba está aberta e o dispositivo está ativo. A aba do navegador do remetente precisa ficar aberta e online até o destinatário terminar o download — os arquivos vêm do dispositivo do remetente, não de um servidor. Como se planejar para isso está em Por que o remetente precisa ficar online.
Qual é a velocidade da transferência de arquivos por WebRTC?
Não há velocidade fixa. O teto é o trecho mais lento do caminho: geralmente a velocidade de upload do remetente. Como regra prática, 1 GB leva cerca de 2,7 minutos a 50 Mbit/s, cerca de 80 segundos a 100 Mbit/s e bem menos de um minuto em uma rede local rápida. As transferências reais ficam um pouco abaixo desses números por causa da sobrecarga dos protocolos, da velocidade do disco e, com relay, do salto extra. Um link pode ser aberto por vários destinatários; cada um baixa diretamente do remetente. Vários downloads ao mesmo tempo dividem o upload do remetente.
Resumo
Uma transferência de arquivos por WebRTC é uma negociação curta seguida de um fluxo longo e criptografado: a sinalização apresenta os navegadores, STUN e ICE encontram um caminho através do NAT, o TURN retransmite como último recurso e canais de dados criptografados com DTLS levam o arquivo de disco para disco. Para o lado prático — o que isso significa para você como remetente —, comece por transferência de arquivos P2P no navegador e Como o StrongFolder funciona.