Você tem um IP público e uma dúzia de dispositivos atrás do roteador. O seu iPad está no celular, a três redes de distância. De algum jeito, um app de área de trabalho remota abre uma conexão direta de um para o outro em menos de um segundo — geralmente sem nenhum relay no meio. É assim que essa mágica realmente funciona: ICE, STUN, TURN, hole punching e a verdade incômoda sobre o NAT simétrico.
Por que isso importa
Imagine uma manhã de terça-feira. O seu Mac mini está em casa, atrás de um roteador com um único endereço IPv4 público. O seu iPad está no trem, na rede móvel de uma operadora, com as próprias camadas de tradução de endereços. Há pelo menos dois NATs entre os dois dispositivos, provavelmente três. Nenhuma das máquinas é acessível a partir da internet externa por padrão.
E mesmo assim você abre o Remio no iPad, toca no Mac e, um segundo depois, está olhando para a sua área de trabalho. O vídeo e a entrada fluem diretamente entre os dois dispositivos — sem relay na nuvem, sem proxy no meio recodificando a sua tela.
A técnica que torna isso possível tem nome — NAT traversal — e uma família de protocolos bem definidos por trás: STUN, TURN e ICE. São os mesmos protocolos que o WebRTC usa nas videochamadas do navegador, e é por causa deles que qualquer área de trabalho remota P2P moderna consegue evitar que os quadros da sua tela passem pelo data center de um terceiro. Este artigo explica o que cada um faz, por que existe e como eles se combinam para encontrar o caminho de menor latência entre dois dispositivos escondidos atrás de roteadores.
O problema do NAT em 60 segundos
A internet foi projetada para que cada dispositivo tivesse o próprio endereço roteável publicamente. Existem cerca de 4,3 bilhões de endereços IPv4 em todo o espaço — de sobra em 1981, e muito claramente insuficientes no fim dos anos 1990.
A solução de contorno foi a Network Address Translation. O seu roteador recebe um endereço IPv4 público do provedor. Dentro da sua casa, cada dispositivo recebe um endereço privado de uma faixa reservada (normalmente 192.168.x.x ou 10.x.x.x). Quando o seu notebook envia um pacote para fora, o roteador reescreve o endereço de origem com o seu próprio IP público, memoriza o mapeamento e encaminha. Quando a resposta volta, o roteador consulta o mapeamento e reescreve o destino de volta para o seu notebook.
É exatamente por isso que conexões de entrada não funcionam por padrão. Vista de fora, a sua máquina não tem endereço; só o roteador tem. O pacote de um desconhecido para your-router-public-ip:5060 chega a um roteador sem nenhum mapeamento para ele e é descartado.
Para um app P2P, esse é o jogo inteiro. Os dois pares estão atrás de roteadores que só encaminham pacotes se lembrarem de ter enviado algo para fora primeiro. Nenhum dos lados pode simplesmente “ligar” para o outro — eles precisam cooperar com os seus roteadores para abrir um caminho temporário.
Hole punching: fazendo o firewall deixar você entrar de volta
Eis o truque. A tabela NAT do roteador é indexada por uma tupla de cinco elementos: IP de origem, porta de origem, IP de destino, porta de destino e protocolo. Quando o seu dispositivo envia um pacote UDP para fora, para 1.2.3.4:5678, o roteador cria uma entrada temporária dizendo: “se qualquer pacote UDP voltar de 1.2.3.4:5678 para o meu IP público na porta X, encaminhe-o a este dispositivo na porta Y”.
Essa entrada existe por uma janela de tempo — normalmente de 30 a 60 segundos — e depois expira, a menos que algo a renove. Durante essa janela, qualquer pacote vindo do endereço de destino será aceito.
Esse é o buraco de fechadura que os apps P2P usam. Se os dois pares conhecem o endereço público um do outro, cada um pode enviar um único pacote UDP de saída para o outro ao mesmo tempo. O roteador de cada lado abre um mapeamento de saída. O primeiro pacote de cada lado pode muito bem ser descartado — o outro roteador ainda não abriu o seu mapeamento —, mas o segundo pacote já tem para onde ir. A partir daí, os dois roteadores acham que estão encaminhando uma conversa de saída normal, e os dois dispositivos estão conversando diretamente.
Isso se chama UDP hole punching. É levemente milagroso, bem documentado (RFC 5128) e funciona na grande maioria dos NATs domésticos existentes. Os casos restantes — NAT simétrico, CGNAT, firewalls corporativos — são o motivo de o TURN existir.
O hole punching não é uma gambiarra. É o contrato explícito em torno do qual o NAT foi projetado: um pacote de saída cria permissão de entrada. Os apps P2P apenas enviam o pacote de saída de propósito.
STUN: “qual é o meu endereço público?”
O hole punching tem um pré-requisito: cada par precisa conhecer o próprio endereço público para poder dizer ao outro lado para onde enviar os pacotes. Esse endereço não é visível de dentro do dispositivo. O seu iPad enxerga o seu endereço Wi-Fi local (192.168.1.42). O que o resto da internet enxerga depois que o roteador reescreve o pacote é algo completamente diferente.
O STUN — Session Traversal Utilities for NAT, RFC 5389 — é o protocolinho que resolve isso. O fluxo é quase constrangedoramente simples:
- O par envia um pacote UDP a um servidor STUN público. (O Remio usa os servidores STUN públicos da Cloudflare e do Google, para ter redundância.)
- O servidor STUN lê o IP e a porta de origem direto do tráfego — que é, por definição, o endereço público do par, já traduzido pelo NAT.
- O servidor STUN responde com esse endereço como conteúdo: “Até onde consigo ver, você é
203.0.113.42:48291.” - O par agora sabe qual endereço anunciar ao outro lado.
Esse endereço público é chamado de candidato server-reflexive na terminologia do ICE. Ele não custa praticamente nada — uma ida e volta durante o estabelecimento da conexão e zero de banda ou latência extra depois que a conexão está estabelecida. O único trabalho do STUN é apresentar dois pares um ao outro; depois que eles estão conversando, o servidor STUN não tem mais papel nenhum.
TURN: quando o hole punching falha
O hole punching funciona para a maioria dos NATs, mas não para todos. Os casos de falha são reais, e um app P2P que finge que eles não existem simplesmente não conseguirá conectar para uma fatia significativa de usuários.
Os principais vilões:
- NAT simétrico. Um NAT que atribui uma porta pública diferente para cada destino distinto. O STUN diz ao seu par que você está na porta 48291 (porque foi a porta que o servidor STUN viu), mas, quando você envia um pacote para o endereço do seu par, o seu roteador escolhe outra porta — digamos, 48317. O roteador do par rejeita o pacote porque ele vem de uma porta inesperada. O hole punching quebra.
- NAT de nível de operadora (CGNAT). Redes celulares e de muitos provedores colocam um segundo NAT na camada da operadora. Você pode estar atrás de dois NATs sem saber, e os dois precisam cooperar. O CGNAT costuma ser simétrico, e você não tem acesso administrativo a ele.
- Firewalls corporativos restritivos. Algumas redes empresariais bloqueiam todo UDP de saída, ou só o permitem para destinos específicos. O hole punching precisa de um caminho UDP; se não há nenhum, ele não tem chance.
Para esses casos, a alternativa é o TURN — Traversal Using Relays around NAT, RFC 5766. Um servidor TURN é um relay que os dois pares conseguem alcançar porque tem um endereço público que sempre aceita tráfego de entrada. Cada par faz uma conexão TLS de saída normal até o servidor TURN (que qualquer NAT permite), e o servidor encaminha os bytes entre os dois lados.
O TURN tem um custo real. Cada pacote de vídeo precisa atravessar um salto de rede extra. Num relay TURN regional, isso acrescenta cerca de 30 a 80 milissegundos de latência de ida e volta. Entre regiões — digamos, um relay em Frankfurt para um par em Tóquio e outro em São Paulo — pode chegar a 80 a 200 milissegundos. O operador do TURN também paga pela banda: cada bit da sua transmissão passa pelos canais dele.
É por isso que um app bem projetado usa o TURN somente quando o hole punching comprovadamente falhou. O ICE toma essa decisão automaticamente.
ICE: testando todos os candidatos em paralelo
O Interactive Connectivity Establishment, RFC 8445, é a coreografia que amarra tudo isso. O ICE não escolhe uma estratégia de antemão. Ele reúne todos os endereços candidatos possíveis de cada par, troca a lista completa com o outro lado e então faz as duas pilhas sondarem todos os pares de candidatos em paralelo — numa corrida para achar o primeiro que funcione.
Para cada par, o ICE normalmente reúne:
- Candidatos host — todo endereço IP local em cada interface de rede (Ethernet, Wi-Fi, interfaces virtuais, IPv4 e IPv6).
- Candidatos server-reflexive — endereços públicos descobertos por servidores STUN.
- Candidatos relay — endereços alocados num servidor TURN.
Os dois pares trocam essas listas por um canal de sinalização — no caso do Remio, uma pequena conexão WebSocket com relay.remio.net que transporta os candidatos ICE e a descrição de sessão do WebRTC (o SDP) e que, depois que a mídia começa a fluir, não tem mais nada a fazer.
Com as duas listas em mãos, o ICE começa as verificações de conectividade. Cada par envia um pacote STUN binding request por cada par de candidatos, em ordem de prioridade. As prioridades são projetadas para preferir o caminho de menor latência:
- Host para host — os dois pares na mesma rede local. É o caso dos sonhos: algumas centenas de microssegundos de latência, sem roteador envolvido.
- Host para server-reflexive, ou server-reflexive para server-reflexive — pares em redes diferentes, com hole punching através dos respectivos NATs. É o que “P2P pela internet” costuma significar na prática.
- Qualquer coisa que envolva um relay — último recurso, usado só quando todos os caminhos de maior prioridade falham nas verificações de conectividade.
O primeiro par de candidatos em que as duas direções funcionam é nomeado vencedor, e a mídia começa a fluir por esse caminho. O processo inteiro costuma terminar bem abaixo de um segundo.
O ICE também reúne candidatos continuamente. Se um caminho melhor surgir no meio da sessão — digamos, o seu celular sai da rede móvel e entra no Wi-Fi —, o ICE pode renomear o novo caminho sem derrubar a chamada.
Por que o Remio prefere P2P a qualquer custo
O Remio é um app de área de trabalho remota, não uma videochamada. O orçamento de latência é brutal. Para uma sessão parecer que você está sentado diante da máquina host, o pipeline inteiro — captura, codificação, rede, decodificação, renderização — precisa ser minúsculo: numa rede local ele custa cerca de 8 ms, e o resto é a própria cadência de atualização de 60 Hz da sua tela (cerca de 16,7 ms por quadro). Todo salto extra é um pecado.
Numa conexão P2P direta na rede local, a parte de rede desse orçamento é de cerca de 1 a 5 milissegundos de ida e volta. Não há relay; os bytes vão direto de um dispositivo para o outro. Com o pipeline do Remio, isso soma cerca de 8 ms de processamento na rede local (medidos internamente; o resto é a própria cadência de atualização de 60 Hz da sua tela) — sua entrada chega antes de o próximo quadro ser desenhado. A máquina remota fica indistinguível de uma local.
Numa conexão com relay TURN — mesmo regional —, a parte de rede salta para 30 a 80 milissegundos. A latência total percebida pelo usuário passa a ser de 40 a 100 ms. Ainda utilizável para a maioria dos trabalhos, mas dá para sentir num arrasto rápido ou numa sequência rápida de cliques. O trackpad já não parece bem o seu.
Essa diferença é o motivo de nos esforçarmos tanto para manter as sessões em P2P. A pilha WebRTC do Remio reúne candidatos IPv4 e IPv6, conversa com vários servidores STUN em paralelo e prefere agressivamente os caminhos diretos na seleção de pares de candidatos do ICE. Internamente, usamos até o RTT medido da conexão para classificar a rede — abaixo de 15 ms sabemos que é rede local, então o codificador começa alto e pode usar muito mais banda. Qualquer coisa mais lenta é tratada como WAN e ajustada de forma mais conservadora.
E — esta é a parte que os concorrentes costumam omitir discretamente — a conexão tem criptografia de ponta a ponta independentemente do caminho. A sua tela nunca passa pelos nossos servidores, e até um relay TURN só enxerga texto cifrado: as chaves são negociadas diretamente entre os dois pares durante o handshake, antes de qualquer pixel se mover. Seja o fluxo de bytes P2P ou por TURN, nem o servidor de sinalização do Remio nem o operador do TURN conseguem lê-los. P2P só significa que não há nenhum terceiro no caminho dos dados.
Quando o relay é inevitável (e tudo bem)
Às vezes os deuses da rede dizem não. NAT simétrico nas duas pontas, CGNAT duplo numa operadora celular com um provedor rígido, um firewall corporativo que só permite TLS de saída para provedores de nuvem conhecidos — são configurações reais e comuns. Nesses casos, a sessão simplesmente precisa passar por um relay ou não acontece.
O backend TURN do Remio é o Cloudflare Calls, que nos dá uma rede global de relays próximos da maioria dos usuários. Quando o ICE seleciona um caminho por relay, a experiência passa de “parece local” para “parece Splashtop” — ainda muito utilizável, mas dá para perceber. A latência adicional fica em 30 a 80 ms para um relay regional; entre regiões, pode chegar a 200 ms.
O ponto importante: os dados continuam com criptografia de ponta a ponta. A Cloudflare vê pacotes UDP criptografados indo num sentido e pacotes UDP criptografados indo no outro. Ela pode contar bytes para cobrança. Não pode ver a sua tela, as suas teclas digitadas nem nada do conteúdo da sessão. Também não há ponto de decifragem do lado do Remio, porque não há nuvem do Remio no pipeline — operamos o serviço TURN pela Cloudflare e nunca tocamos nos dados.
Essa é a arquitetura que o nosso whitepaper de segurança descreve com mais detalhes. Resumindo: P2P ou relay, o modelo de ameaças é o mesmo.
A saída de emergência do IPv6
O IPv6 tem 340 undecilhões de endereços (3,4 × 1038) — o bastante para dar a cada grão de areia da Terra o seu próprio IP público, com alguns trilhões de sobra. Num mundo só de IPv6, o NAT é em grande parte desnecessário. Dois dispositivos compatíveis com IPv6 podem simplesmente enviar pacotes para o endereço um do outro, e o único obstáculo é o firewall do host em cada ponta.
Se você tem IPv6 em casa e na operadora celular, talvez tenha notado que alguns apps conectam mais rápido quando as duas pontas são IPv6 — isso acontece porque toda a dança de “reunir candidatos, sondar pares” tem menos obstáculos. Não há tradução de NAT a descobrir, nenhuma ida ao STUN necessária, só endereços diretos.
Mas há um porém: em 2026, a implantação global ainda está incompleta. Muitos roteadores domésticos tratam o IPv6 mal ou nem o tratam. Muitas redes corporativas bloqueiam IPv6 de entrada por padrão. Algumas operadoras oferecem IPv6 no lado do rádio, mas fazem a ponte para IPv4 em outro ponto. Caminhos puramente IPv6 para IPv6 existem, mas não podem ser o único mecanismo.
Por isso o Remio — como toda pilha P2P séria — reúne candidatos IPv4 e IPv6 e deixa o ICE fazê-los correr. Se um caminho IPv6 direto existe e funciona, ele geralmente vence em latência. Se não, o IPv4 com hole punching assume. Se os dois falham, relay. O usuário nunca vê nada disso; a conexão simplesmente se estabelece.
Como saber qual caminho a sua sessão está usando
Curioso para saber em qual caminho a sua sessão foi parar? O indicador de conexão do Remio mostra o tipo em linguagem simples — “Direta” para P2P, “Relay” para TURN. O painel de estatísticas para desenvolvedores expõe o estado completo do WebRTC, incluindo os tipos de candidato do par nomeado (host, srflx, relay) e o RTT medido.
Algumas interpretações rápidas:
- RTT abaixo de 5 ms, Direta — você está na mesma rede local que o host. O melhor caso. Dá para chegar a cerca de 8 ms de processamento (o resto é a própria cadência de atualização de 60 Hz da sua tela).
- RTT de 5 a 15 ms, Direta — mesma rede Wi-Fi, mas com um salto extra de ponto de acesso ou mesh. Ainda excelente.
- RTT de 15 a 80 ms, Direta — você está numa rede diferente da do host, e o hole punching funcionou. O P2P pela internet está funcionando.
- RTT de 30 a 80 ms, Relay (regional) — um NAT simétrico ou um NAT de operadora derrotou o hole punch. O TURN da Cloudflare mais próximo assumiu.
- RTT de 80 a 200 ms, Relay — TURN por uma distância geográfica maior, ou você e o host estão em regiões muito diferentes.
Se você cai de forma consistente para relay mesmo em casa, os suspeitos de sempre são um modem do provedor fazendo NAT simétrico, CGNAT IPv4 na sua conexão doméstica (mais comum do que se imagina em revendedores de fibra) ou um firewall zeloso demais bloqueando UDP de entrada. O nosso guia para reduzir o lag da área de trabalho remota percorre os culpados mais comuns, e a página de conexão direta na rede local é o caminho rápido se os dois dispositivos estão na sua rede.
Números de desempenho do mundo real
Juntando tudo, estes são os valores de latência que medimos em produção nos diferentes caminhos que uma sessão do Remio pode seguir:
- P2P direto na rede local: 1–5 ms de RTT de rede. De ponta a ponta (evento de entrada até a atualização do pixel): cerca de 8 ms de processamento (o resto é a própria cadência de atualização de 60 Hz da sua tela), com o resto do pipeline colaborando.
- Wi-Fi na mesma rede com saltos extras: 5–10 ms de RTT de rede.
- Relay TURN, regional: 30–80 ms de RTT de rede.
- Relay TURN, entre regiões: 80–200 ms de RTT de rede.
- Celular 4G/5G, P2P com hole punching: 40–100 ms de RTT de rede.
Esses valores correspondem aos dos benchmarks do Remio e explicam por que definimos o limite entre rede local e WAN em 15 ms de RTT — ele separa com nitidez os caminhos diretos de qualquer relay (mínimo de 30 ms) ou caminho celular (mínimo de 40 ms), com pouquíssimos falsos positivos.
O NAT traversal é um desses assuntos em que os protocolos são simples individualmente, mas a combinatória é espinhosa. A maioria dos usuários nunca precisará saber que ICE, STUN e TURN existem — apenas vai usar um app que conecta rápido de qualquer lugar para qualquer lugar. Os protocolos estão fazendo o trabalho quando você não os percebe. Quando você os percebe — uma sessão demora um instante a mais, ou “Direta” vira “Relay” —, agora você tem o modelo mental.
Para saber mais sobre o pipeline nativo do Remio e as escolhas que transformam 1–5 ms de latência de rede em cerca de 8 ms de processamento (o resto é a própria cadência de atualização de 60 Hz da sua tela), veja por que o nativo importa. Para o modelo de ameaças dos caminhos por relay, veja o whitepaper de segurança. Ou simplesmente explore os recursos e baixe o Remio para sentir funcionando.
