# Como funciona a transferência de arquivos por WebRTC

Source: https://help.strongfolder.com/pt/guides/how-webrtc-file-transfer-works/
Updated: 2026-11-05

> A transferência de arquivos por WebRTC acontece em três fases. Um servidor de sinalização apresenta dois navegadores; STUN e ICE encontram um caminho de rede através dos roteadores domésticos (NAT), recorrendo a um relay TURN se não houver caminho direto; depois, os navegadores abrem um canal de dados criptografado com DTLS e transmitem o arquivo em pedaços, diretamente ou pelo relay, sem armazená-lo.

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.

**Key facts**

- **WebRTC** é um padrão dos navegadores para conexões diretas e criptografadas entre dois dispositivos; as ferramentas de arquivos usam os **canais de dados** dele.
- A **sinalização** apresenta os navegadores; **STUN** e **ICE** encontram um caminho através dos roteadores (**NAT**); um **relay TURN** encaminha o tráfego quando não há caminho direto.
- **Criptografia:** todo canal de dados usa **DTLS** — o WebRTC não tem modo sem criptografia.
- O StrongFolder usa o PeerJS sobre o WebRTC, um servidor de sinalização próprio, servidores STUN públicos (incluindo os do Google) e relays TURN próprios. Os arquivos nunca são enviados nem armazenados em um servidor do StrongFolder.
- O arquivo é transmitido em pedaços do disco do remetente para o disco do destinatário; o remetente fica online.

## O que é WebRTC?

[WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/).

## 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](https://help.strongfolder.com/en/glossary/#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:

1. Eles não sabem **como alcançar um ao outro** — nenhum sabe que o outro existe.
2. Eles não sabem **o próprio endereço público** — só o privado, como 192.168.1.20.
3. 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](https://help.strongfolder.com/en/glossary/#signaling). 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/).

## 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.

[Enviar arquivos agora](https://strongfolder.com)
## 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](https://help.strongfolder.com/en/guides/secure-file-sharing/) e
[Segurança e privacidade](https://help.strongfolder.com/en/security/).

## 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](https://help.strongfolder.com/en/guides/why-sender-stays-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](https://help.strongfolder.com/en/guides/p2p-file-transfer/)
e [Como o StrongFolder funciona](https://help.strongfolder.com/en/how-it-works/).

## FAQ

### O que é um canal de dados WebRTC?

Um canal de dados é a parte do WebRTC que transporta bytes arbitrários entre dois navegadores em vez de áudio ou vídeo. Ele roda SCTP sobre DTLS sobre UDP, então é criptografado e pode ser configurado como confiável e ordenado — exatamente o que a transferência de arquivos precisa.

### Qual é a diferença entre STUN e TURN?

Um servidor STUN só informa ao navegador como é o seu endereço público, para que os dois navegadores tentem se conectar diretamente; nenhum dado de arquivo passa por ele. Um servidor TURN é um relay: quando nenhum caminho direto funciona, o fluxo criptografado passa por ele. O StrongFolder mantém seus próprios relays TURN, que encaminham e não armazenam dados.

### O servidor de sinalização vê meus arquivos?

Não. O servidor de sinalização passa entre os navegadores apenas mensagens de conexão — descrições de sessão e candidatos de rede. Os dados do arquivo fluem pelo canal de dados, diretamente ou por um relay TURN.

### A transferência de arquivos por WebRTC é criptografada?

O WebRTC criptografa cada canal de dados com DTLS, então o fluxo do arquivo é criptografado em trânsito em toda conexão. O WebRTC não permite canais de dados sem criptografia. As chaves são negociadas pelos dois navegadores; as impressões digitais delas passam pela sinalização, e é por isso que se trata de criptografia em trânsito, e não de criptografia de ponta a ponta com chaves que você gerencia.

### Por que uma transferência WebRTC às vezes falha ou fica lenta?

Geralmente por causa do caminho de rede: um firewall rígido ou uma VPN bloqueia o UDP direto, então a conexão recorre a um relay TURN via TCP ou nem consegue se conectar. Tente outra rede (por exemplo, o roteador do celular), desligue a VPN ou peça à TI para liberar o WebRTC.

### Um relay TURN consegue ler meus arquivos?

O relay encaminha pacotes criptografados com DTLS entre os dois navegadores. Ele vê tráfego criptografado, tamanhos e horários, não o conteúdo do arquivo, e o relay do StrongFolder não armazena o que encaminha.