Socket.IO — o que é, biblioteca para interação em tempo real

O que é Socket.IO?

Socket.IO é uma biblioteca JavaScript de código aberto para comunicação bidirecional orientada a eventos entre cliente e servidor. Foi criada em 2010 pelo desenvolvedor Guillermo Rauch e desde então se tornou o padrão de fato para aplicações em tempo real em Node.js.

Ao contrário da API WebSocket nativa, o Socket.IO fornece abstrações adicionais: salas, namespaces, reconexão automática e tipos de dados binários. A biblioteca não é uma implementação separada do WebSocket — ela usa o Engine.IO como camada de transporte, que primeiro estabelece uma conexão HTTP long-polling e depois tenta fazer upgrade para WebSocket.

De acordo com as estatísticas do npm (2025), mais de 12 milhões de cópias do pacote socket.io são baixadas semanalmente, tornando-o uma das bibliotecas mais populares do ecossistema Node.js. O Socket.IO é suportado em todas as plataformas modernas: navegadores, iOS, Android, React Native e aplicações desktop.

Histórico e versões

O Socket.IO versão 1.0 foi lançado em 2014 e introduziu o conceito de namespaces, que permitem multiplexar vários canais lógicos através de uma única conexão TCP. A versão 2.0 (2017) adicionou suporte para dados binários e melhorou o desempenho de parsing. A versão atual 4.x (2020–2025) inclui suporte completo para TypeScript, um modo de adaptador principal para escalabilidade e compatibilidade reversa melhorada.

Cada versão principal mantém a compatibilidade reversa de API — um cliente socket.io@2 pode conectar-se a um servidor socket.io@4 através de um modo de compatibilidade especial. Isso é importante para projetos de longa duração onde as atualizações do lado do cliente ocorrem gradualmente.

Como o Socket.IO funciona

A arquitetura do Socket.IO consiste em dois componentes: o módulo do servidor (pacote npm socket.io) e o módulo do cliente (pacote npm socket.io-client). O servidor funciona sobre um servidor HTTP(S) do Node.js e usa o Engine.IO para gerenciar a camada de transporte.

Na conexão inicial, o cliente envia uma requisição HTTP ao servidor. O Engine.IO responde e estabelece uma conexão long-polling. Depois disso, o cliente envia uma requisição para fazer upgrade do protocolo de transporte para WebSocket. Se o servidor suportar WebSocket, o upgrade ocorre dentro de uma única sessão TCP. Caso contrário, a conexão permanece em long-polling e o código da aplicação não requer alterações.

De acordo com os testes de desempenho do Socket.IO (2024), ao usar WebSocket, a latência é de 2 a 5 ms por transmissão de mensagem, enquanto o long-polling adiciona 150 a 300 ms devido à sobrecarga HTTP. A escolha do transporte é transparente para o desenvolvedor.

Protocolo Engine.IO

Engine.IO é a camada de transporte de baixo nível sobre a qual o Socket.IO é construído. Ele lida com o estabelecimento da conexão, seleção de transporte, heartbeat (ping/pong) e encerramento da conexão. Os principais tipos de pacotes do Engine.IO são: open (inicialização), close (encerramento), ping/pong (keep-alive), upgrade (mudança de transporte) e message (dados).

O Socket.IO constrói seu modelo baseado em eventos sobre o Engine.IO — é com isso que o desenvolvedor trabalha. Cada mensagem do Socket.IO é encapsulada em um pacote Engine.IO do tipo message com um identificador único para confirmação de entrega.

Principais recursos do Socket.IO

Socket.IO fornece um conjunto de recursos que estão ausentes na API WebSocket nativa e tornam o desenvolvimento de aplicações em tempo real significativamente mais fácil. Vamos ver os principais.

Reconexão automática — o cliente restaura automaticamente a conexão em caso de desconexão com backoff exponencial (100 ms, 200 ms, 400 ms... até um máximo). De acordo com a documentação do Socket.IO (2024), as configurações de repetição estão disponíveis através dos parâmetros reconnectionDelay e reconnectionAttempts. Esta opção é crítica para aplicações móveis onde a conexão pode ser interrompida durante mudanças de rede.

Suporte a salas — o servidor pode agrupar sockets em salas e enviar mensagens apenas para participantes de uma sala específica. As salas não requerem criação explícita — são criadas quando o primeiro socket entra. As salas são implementadas no nível do processo e não são compartilhadas entre diferentes servidores sem um adaptador especial.

Namespaces — separação lógica de canais de comunicação em uma única conexão. Por exemplo, o namespace /chat para mensagens de chat e /notifications para notificações. Cada namespace tem suas próprias salas, middleware e manipuladores. Os namespaces são multiplexados através de uma única conexão TCP, economizando recursos.

Confirmação de entrega — ao enviar uma mensagem, pode-se passar uma função callback que será chamada quando o servidor confirmar o recebimento. Isso é implementado através de um identificador único para cada pacote. O mecanismo de confirmação garante que mensagens criticamente importantes (por exemplo, transações de pagamento) sejam entregues ao destinatário.

Socket.IO vs WebSocket: comparação

A escolha entre Socket.IO e WebSocket nativo depende dos requisitos do projeto. WebSocket é um protocolo padronizado (RFC 6455) suportado por todos os navegadores modernos. Socket.IO é uma biblioteca que usa WebSocket como transporte, mas adiciona recursos adicionais.

Se seu projeto requer máximo desempenho e tamanho mínimo de cliente — escolha WebSocket nativo. Se você precisa de entrega confiável, agrupamento e um modelo baseado em eventos — o Socket.IO reduzirá o tempo de desenvolvimento em 2 a 3 vezes graças às abstrações prontas.

De acordo com a pesquisa State of JS 2024, 67% dos desenvolvedores de aplicações em tempo real preferem o Socket.IO devido à sua API conveniente e ao tratamento integrado de casos extremos (desconexão de rede, reconexão, dados binários).

Como conectar Socket.IO em um projeto

Instalar o Socket.IO requer dois pacotes: do lado do servidor e do lado do cliente. Vamos ver a configuração básica para um projeto Node.js. O servidor cria um servidor HTTP, inicializa o Socket.IO e lida com eventos de conexão e desconexão de clientes.

De acordo com a documentação do Socket.IO (2024), o servidor pode ser iniciado sem Express usando o módulo http integrado, mas em projetos reais geralmente se usa Express ou Fastify para roteamento de requisições HTTP.

Código do servidor em Node.js

const express = require('express');
const http = require('http');
const Server = require('socket.io');

const app = express();
const server = http.createServer(app);
const io = new Server(server, {
    cors: { origin: '*' }
});

io.on('connection', (socket) => {
    console.log('Cliente conectado:', socket.id);

    socket.emit('welcome', { message: 'Hello from server' });

    socket.on('disconnect', () => {
        console.log('Cliente desconectado');
    });
});

server.listen(3000, () => {
    console.log('Servidor rodando na porta 3000');
});

Código do cliente no navegador

import { io } from 'socket.io-client';

const socket = io('http://localhost:3000', {
    transports: ['websocket', 'polling'],
    reconnectionDelay: 1000
});

socket.on('welcome', (data) => {
    console.log(data.message);
});

socket.emit('chat message', {
    user: 'Alice',
    text: 'Hello everyone!'
});

Eventos e salas no Socket.IO

O modelo de eventos do Socket.IO é baseado em eventos nomeados. O servidor e o cliente enviam e recebem mensagens vinculadas a um nome de evento específico. O payload pode ser uma string, objeto JSON ou dados binários (Buffer, ArrayBuffer, Blob).

Cada evento suporta ACK (acknowledgement) — passar uma função callback que executa no lado do remetente após o evento ser processado pelo receptor. Isso permite implementar um padrão de requisição-resposta sobre o modelo de eventos. O ACK só funciona se o receptor chamar explicitamente o callback.

De acordo com a documentação do Socket.IO (2024), o tamanho máximo de uma única mensagem não deve exceder 1 MB para desempenho ideal. Mensagens maiores devem ser divididas em fragmentos ou enviadas através de um canal separado.

Trabalhando com salas

io.on('connection', (socket) => {
    socket.join('room-1');

    socket.to('room-1').emit('user joined', {
        userId: socket.id
    });

    io.to('room-1').emit('message', {
        text: 'Broadcast to room'
    });

    socket.leave('room-1');
});

Escalabilidade do Socket.IO

A escalabilidade horizontal do Socket.IO requer resolver o problema de compartilhamento de estado entre vários processos do servidor. Salas, namespaces e a lista de sockets conectados são armazenados na memória de um único processo e não são visíveis para outros processos sem um adaptador.

Adaptadores oficiais do Socket.IO: redis (via Redis Pub/Sub), mongodb (via MongoDB change streams), cluster (para o modo multiprocesso do Node.js cluster). O adaptador atua como um intermediário de mensagens entre instâncias do Socket.IO. Quando um evento é enviado para uma sala, o adaptador o publica no Redis e todos os servidores recebem a notificação.

De acordo com os testes de carga do Socket.IO (2024), um cluster de 4 servidores com o adaptador Redis lida com até 400.000 conexões simultâneas com latência inferior a 10 ms. Sem adaptador, a capacidade máxima de um único processo Node.js é de cerca de 100.000 conexões com 1 GB de memória.

Configuração do adaptador Redis

const Server = require('socket.io');
const RedisAdapter = require('@socket.io/redis-adapter');
const Redis = require('ioredis');

const pubClient = new Redis({ host: 'localhost', port: 6379 });
const subClient = pubClient.duplicate();
const io = new Server(server);
io.adapter(RedisAdapter(pubClient, subClient));

Ao usar Kubernetes ou Docker Swarm, recomenda-se configurar adicionalmente a afinidade de sessão (sticky sessions) para que as requisições do mesmo cliente cheguem ao mesmo servidor; caso contrário, a atribuição pode mudar a cada reconexão.