WebRTC Deep Dive: A Arquitetura por trás do Zoom e Google Meet

Antigamente, para fazer uma videochamada no navegador, você precisava do Adobe Flash ou de plugins Java duvidosos. Hoje, você abre um link e simplesmente funciona. Essa mágica é o WebRTC (Web Real-Time Communication).

Lançado pelo Google em 2011 como open-source, o WebRTC padronizou a comunicação Peer-to-Peer (P2P) entre navegadores. Ele permite que o Chrome do Usuário A envie vídeo direto para o Firefox do Usuário B, sem que esses dados passem por um servidor central (na maioria das vezes).

Mas a internet não foi feita para P2P. Firewalls, roteadores NAT e IPs dinâmicos conspiram para impedir que dois computadores conversem diretamente. Como o WebRTC fura essas barreiras? Vamos mergulhar na arquitetura.

1. O Conceito de Signaling (Sinalização)

A primeira coisa que você precisa saber sobre WebRTC é que o WebRTC não sabe como conectar dois computadores.

Ele precisa de um intermediário inicial para trocar os "dados de contato". Esse processo chama-se Signaling. Curiosamente, o padrão WebRTC não define como fazer o signaling. Você pode usar WebSockets, HTTP, MQTT ou até pombos-correio, desde que os dados cheguem.

O que é trocado no Signaling?

1. Session Control Messages: "Quero iniciar uma chamada", "Desliguei".
2. Network Data (ICE Candidates): "Meu IP público é X, minha porta é Y".
3. Media Metadata (SDP): "Eu suporto codec de vídeo VP8 e áudio Opus".

O formato padrão para esses dados é o SDP (Session Description Protocol). É um bloco de texto meio críptico que descreve as capacidades multimídia do dispositivo.

2. NAT Traversal: O Grande Vilão

A maioria dos dispositivos não tem um IP público. Eles estão atrás de um roteador NAT (Network Address Translation). O IP do seu computador é algo como 192.168.1.5, que é inútil para alguém na internet.

Para dois peers se conectarem, eles precisam descobrir seus IPs Públicos e mapear uma porta no roteador. É aqui que entra o framework ICE (Interactive Connectivity Establishment).

O ICE tenta conectar os peers nesta ordem de preferência:

1. Conexão Direta (Host): Se estiverem na mesma rede Wi-Fi.
2. STUN (Server Reflexive): Usa um servidor leve para descobrir o IP público.
3. TURN (Relay): Usa um servidor pesado para repassar todo o tráfego (último recurso).

STUN (Session Traversal Utilities for NAT)

O servidor STUN é muito simples e barato. O cliente pergunta: "Quem sou eu?". O servidor STUN responde: "Você é o IP 203.0.113.5 na porta 45000". O cliente pega essa informação e manda para o outro peer via Signaling. Cerca de 80% das conexões WebRTC funcionam apenas com STUN.

TURN (Traversal Using Relays around NAT)

Se você estiver atrás de um firewall corporativo restrito (Symmetric NAT), o STUN falha. O firewall bloqueia conexões diretas de IPs desconhecidos. A solução é o TURN. Ele é um servidor "repetidor".

• Peer A envia vídeo para o servidor TURN.
• Servidor TURN envia vídeo para o Peer B.

Isso não é mais P2P puro. É caro (banda de servidor custa dinheiro) e adiciona latência, mas é a única forma de garantir 100% de conectividade.

3. Data Channels: Além do Vídeo

O WebRTC não é só para Zoom. Ele possui uma API chamada Data Channel, que permite enviar dados arbitrários (JSON, arquivos, binários) entre navegadores com baixíssima latência.

Diferente do WebSocket (que é TCP), o Data Channel roda sobre SCTP (Stream Control Transmission Protocol) encapsulado em DTLS (UDP). Isso permite configurar a confiabilidade:

• Modo Confiável (TCP-like): Garante entrega e ordem. Bom para chat e transferência de arquivos.
• Modo Não-Confiável (UDP-like): Se perder pacote, paciência. Ótimo para posição de jogadores em games multiplayer (onde a posição de 1 segundo atrás não importa mais).

4. Segurança: DTLS e SRTP

WebRTC é seguro por padrão. Não existe "WebRTC sem criptografia".

• Signaling: Deve ser protegido por HTTPS/WSS (responsabilidade do desenvolvedor).
• Media (Áudio/Vídeo): Usa SRTP (Secure Real-time Transport Protocol). Ninguém na rede pode ver seu vídeo.
• Data Channels: Usa DTLS (Datagram Transport Layer Security).

Mesmo se a conexão passar por um servidor TURN, o servidor apenas repassa os pacotes encriptados. Ele não consegue decifrar o conteúdo (E2E Encryption).

5. Exemplo de Código: A Conexão Manual

Embora na prática usemos bibliotecas como simple-peer ou PeerJS, entender o fluxo bruto é vital.

// 1. Configuração com servidores ICE (Google oferece um STUN público)
const config = { 
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] 
};
const pc = new RTCPeerConnection(config);

// 2. Quando o ICE achar um candidato (IP/Porta), mande pro outro lado
pc.onicecandidate = event => {
if (event.candidate) {
  sendToSignalingServer('candidate', event.candidate);
}
};

// 3. Criar a oferta (SDP)
pc.createOffer()
.then(offer => pc.setLocalDescription(offer))
.then(() => {
  sendToSignalingServer('offer', pc.localDescription);
});

Conclusão

O WebRTC democratizou a comunicação em tempo real. Ele transformou o navegador em uma plataforma de telefonia e videoconferência completa. Para o desenvolvedor, entender a dança entre Signaling, STUN e TURN é a diferença entre um app que "funciona na minha máquina" e um app que funciona em qualquer rede corporativa do mundo.

Glossário Técnico

• P2P (Peer-to-Peer): Arquitetura onde os clientes falam diretamente entre si sem passar por um servidor central.
• SDP (Session Description Protocol): Formato de texto para descrever codecs, endereços e capacidades da sessão.
• ICE Candidate: Um possível endereço de rede (IP:Porta) onde o peer pode ser encontrado.
• Symmetric NAT: Tipo de NAT restritivo que muda a porta de saída dependendo do destino. O pesadelo do P2P, exige TURN.
• SCTP: Protocolo usado pelos Data Channels. Oferece o melhor do TCP e UDP.

Referências

1. WebRTC.org. WebRTC Architecture. Documentação oficial.
2. High Performance Browser Networking (Ilya Grigorik). Capítulo sobre WebRTC. O melhor livro técnico sobre redes web.
3. MDN Web Docs. WebRTC API. Referência da API JavaScript.
4. WebRTC for the Curious. Livro Open Source. Guia profundo e moderno.