Comunicações em tempo real no desenvolvimento móvel: o que é, quais protocolos e como funciona

Comunicações em tempo real: protocolos WebSocket, SSE e Long Polling

Comunicações em tempo real são tecnologias que permitem a troca de dados entre cliente e servidor com latência mínima. Os principais protocolos: WebSocket, SSE (Server-Sent Events), Long Polling e Short Polling. Cada um tem o seu nicho: WebSocket para comunicação bidirecional, SSE para notificações, Long Polling como fallback para navegadores antigos. O tempo real no desenvolvimento móvel é especialmente importante: os utilizadores esperam entrega instantânea de mensagens e notificações. As comunicações no desenvolvimento móvel são construídas precisamente sobre estes protocolos.

WebSocket vs SSE

WebSocket é um protocolo full-duplex (cliente ↔ servidor). Após o handshake (HTTP Upgrade) a ligação permanece aberta. Os cabeçalhos são mínimos (2 bytes versus cabeçalhos HTTP). Usado em chats (WhatsApp, Telegram), jogos, trading em tempo real. SSE é um protocolo unidirecional (servidor → cliente). O cliente subscreve eventos e recebe-os através de uma única ligação HTTP. SSE é mais simples, mais fácil de escalar (HTTP simples), ideal para feeds do Twitter, taxas de câmbio, notificações push.

Long Polling é uma técnica onde o cliente faz um pedido HTTP e mantém-no aberto até o servidor enviar dados ou ocorrer um timeout (30–60 seg). Após receber dados, o cliente abre imediatamente um novo pedido. Long Polling é um fallback para WebSocket. Short Polling — o cliente consulta o servidor a cada N segundos. O mais simples mas ineficiente (a maioria dos pedidos retorna respostas vazias).

Servidor de Sinalização

Antes de estabelecer uma ligação P2P, os dispositivos precisam de um Servidor de Sinalização — um servidor intermediário para trocar ofertas SDP e candidatos ICE entre pares. A sinalização pode ser implementada via WebSocket, SSE ou qualquer outro protocolo. Após a ligação ser estabelecida, a sinalização já não participa na transmissão de tráfego multimédia.

WebRTC: comunicações em tempo real com chamadas de áudio e vídeo

WebRTC (Web Real-Time Communication) é uma tecnologia aberta para áudio/vídeo/dados P2P. Funciona em navegadores e aplicações nativas (iOS, Android). WebRTC inclui: getUserMedia (acesso à câmara/microfone), RTCPeerConnection (ligação P2P), RTCDataChannel (transferência de dados). WebRTC permite comunicações em tempo real em aplicações móveis — as comunicações em apps móveis funcionam sem plugins adicionais.

Fluxo WebRTC

O Par A cria uma RTCPeerConnection e uma Offer SDP. Passo 2: A Offer é enviada através do Servidor de Sinalização ao Par B. Passo 3: O Par B recebe a Offer, cria uma Answer SDP e envia de volta. Passo 4: Ambos os pares recolhem candidatos ICE (endereços para a ligação) e trocam-nos através da Sinalização. Passo 5: O framework ICE seleciona o melhor caminho (P2P ou através de TURN). Após a ligação — o tráfego multimédia flui diretamente.

SDP (Session Description Protocol) é um protocolo de texto que descreve os parâmetros da ligação: codecs, endereços IP, portas. ICE Candidate é uma proposta do STUN/TURN: "Pode encontrar-me neste endereço". Quanto mais candidatos, maior a probabilidade de P2P.

Socket.IO é o líder para startups: controla o servidor, sem limites. Pusher e Ably são para produtos onde não quer gerir infraestrutura. PubNub é para IoT e audiências globais. A IT Sectr recomenda Socket.IO para projetos com backend próprio, Pusher para protótipos rápidos, Ably para empresas com requisitos de fiabilidade.

Plataformas: Socket.IO, Pusher, Ably, PubNub

Plataformas em tempo real fornecem infraestrutura de servidor pronta para WebSocket e SSE. Eliminam a necessidade de escrever o seu próprio servidor em tempo real, equilibrar ligações WebSocket e escalá-las. A escolha da plataforma depende do orçamento, requisitos de fiabilidade e disposição para gerir um servidor. Para tempo real no desenvolvimento móvel, as plataformas oferecem SDKs de cliente e infraestrutura prontos.

Socket.IO

Socket.IO é uma biblioteca para Node.js e clientes (iOS, Android, web). Baseada em WebSocket, mas usa HTTP polling como fallback. Suporta salas, namespaces, confirmações ACK. Para desenvolvimento — socket.io-client-java (Android) e socket.io-client-swift (iOS). As comunicações em aplicações móveis com Socket.IO são tratadas de forma fiável graças à reconexão automática.

Pusher e Ably

Pusher é uma plataforma SaaS em tempo real. Integração simples: crie um canal e subscreva eventos. Pusher Channels para notificações, Pusher Beams para notificações push. Ably é de nível empresarial com replicação global em 7 centros de dados. Garante entrega exactly-once. Suporta SSE, WebSocket, MQTT para IoT. Ambas as plataformas resolvem tarefas de comunicação no desenvolvimento móvel sem escrever código de servidor.

Infraestrutura em tempo real: STUN, TURN, Signaling no WebRTC

STUN (Session Traversal Utilities for NAT) é um servidor que ajuda um dispositivo a descobrir o seu IP e porta externos atrás de NAT. O dispositivo envia um pedido STUN, o servidor responde: "É visível como 203.0.113.5:45678". O STUN é usado gratuitamente (Google STUN: stun.l.google.com:19302). No contexto da infraestrutura em tempo real, o STUN é o primeiro passo para estabelecer um canal P2P.

STUN vs TURN

TURN (Traversal Using Relays around NAT) é um servidor de retransmissão que retransmite tráfego multimédia se a ligação P2P for impossível (por exemplo, ambos os dispositivos atrás de NAT simétrico). O TURN consome largura de banda do servidor, por isso é caro. No WebRTC, o framework ICE tenta primeiro P2P, depois TURN como último recurso. O tempo real no desenvolvimento requer TURN para comunicações em aplicações móveis ao ligar através de redes corporativas.

ICE (Interactive Connectivity Establishment) é um framework que recolhe todos os caminhos de ligação possíveis (IP local, IP externo via STUN, relays TURN) e seleciona o melhor. ICE Candidate é cada caminho possível. Quanto mais candidatos, maior a probabilidade de P2P bem-sucedido.

Peer-to-Peer

P2P é uma ligação direta entre dois dispositivos sem um servidor intermediário para tráfego multimédia. O P2P reduz a latência (< 100 ms) e os custos de servidor. Desvantagens: fraca proteção contra NAT, necessidade de STUN/TURN. O WebRTC usa P2P por defeito.

P2P e ICE

Peer-to-Peer (P2P) é uma arquitetura onde os dados são transferidos diretamente entre dispositivos. No contexto das comunicações em tempo real, o P2P é usado no WebRTC para minimizar a latência. ICE (Interactive Connectivity Establishment) é o mecanismo que encontra o melhor caminho para uma ligação P2P. Para desenvolvimento, o P2P é a forma ideal de organizar comunicações em aplicações móveis em tempo real.

Como funciona o ICE

O ICE recolhe ICE Candidate de três tipos: 1) host (IP local), 2) srflx (via STUN), 3) relay (via TURN). Todos os candidatos são ordenados, e o ICE tenta ligar-se a cada um por ordem de prioridade. A primeira ligação bem-sucedida é usada. Se P2P não for possível, usa-se TURN (mas é caro).