Socket.IO — co to jest, biblioteka do interakcji w czasie rzeczywistym

Co to jest Socket.IO?

Socket.IO to biblioteka JavaScript z otwartym kodem źródłowym do dwukierunkowej komunikacji zdarzeniowej między klientem a serwerem. Została stworzona w 2010 roku przez dewelopera Guillermo Raucha i od tego czasu stała się standardem de facto dla aplikacji czasu rzeczywistego na Node.js.

W przeciwieństwie do natywnego WebSocket API, Socket.IO zapewnia dodatkowe abstrakcje: pokoje, przestrzenie nazw, automatyczne ponowne łączenie i binarne typy danych. Biblioteka nie jest osobną implementacją WebSocket — używa Engine.IO jako warstwy transportowej, która najpierw ustanawia połączenie HTTP long-polling, a następnie próbuje upgrade do WebSocket.

Według danych statystyk npm (2025), co tydzień pobieranych jest ponad 12 milionów kopii pakietu socket.io, co czyni go jedną z najpopularniejszych bibliotek w ekosystemie Node.js. Socket.IO jest obsługiwany na wszystkich nowoczesnych platformach: przeglądarki, iOS, Android, React Native i aplikacje desktopowe.

Historia powstania i wersje

Socket.IO w wersji 1.0 został wydany w 2014 roku i wprowadził koncepcję przestrzeni nazw (namespaces), które pozwalają multipleksować kilka logicznych kanałów przez jedno połączenie TCP. Wersja 2.0 (2017) dodała obsługę danych binarnych i poprawiła wydajność parsowania. Obecna wersja 4.x (2020–2025) obejmuje pełną obsługę TypeScript, flagowy tryb adaptacji do skalowania i ulepszoną kompatybilność wsteczną.

Każde wydanie główne zachowuje kompatybilność wsteczną API — klient socket.io@2 może łączyć się z serwerem socket.io@4 poprzez specjalny tryb zgodności. Jest to ważne dla długoterminowych projektów, w których aktualizacja części klienckiej odbywa się etapami.

Jak działa Socket.IO

Architektura Socket.IO składa się z dwóch komponentów: moduł serwerowy (npm-pakiet socket.io) i moduł kliencki (npm-pakiet socket.io-client). Serwer działa na bazie serwera HTTP(S) Node.js i używa Engine.IO do zarządzania warstwą transportową.

Przy pierwszym połączeniu klient wysyła żądanie HTTP do serwera. Engine.IO odpowiada i ustanawia połączenie long-polling. Następnie klient wysyła żądanie upgrade protokołu transportowego do WebSocket. Jeśli serwer obsługuje WebSocket, upgrade następuje w ramach jednej sesji TCP. Jeśli nie — połączenie pozostaje na long-polling, a kod aplikacji nie wymaga zmian.

Według danych testów wydajności Socket.IO (2024), przy użyciu WebSocket opóźnienie wynosi 2–5 ms na przesłanie wiadomości, podczas gdy long-polling dodaje 150–300 ms ze względu na narzuty HTTP. Wybór transportu jest przezroczysty dla programisty.

Protokół Engine.IO

Engine.IO to niskopoziomowa warstwa transportowa, na której zbudowany jest Socket.IO. Odpowiada za nawiganie połączenia, wybór transportu, heartbeat (ping/pong) i zrywanie połączenia. Główne typy pakietów Engine.IO: open (inicjalizacja), close (zamknięcie), ping/pong (sprawdzenie żywotności), upgrade (zmiana transportu), message (dane).

SocketIO nakłada na Engine.IO swój model zdarzeniowy — to z nim pracuje programista. Każda wiadomość Socket.IO jest pakowana w pakiet Engine.IO z typem message i unikalnym identyfikatorem do potwierdzenia dostarczenia.

Kluczowe możliwości Socket.IO

Socket.IO zapewnia zestaw funkcji, których brakuje w natywnym WebSocket API i które znacznie upraszczają tworzenie aplikacji czasu rzeczywistego. Omówmy najważniejsze z nich.

Automatyczne ponowne łączenie — klient automatycznie przywraca połączenie po przerwaniu z wykładniczym opóźnieniem (100 ms, 200 ms, 400 ms... aż do maksimum). Według danych dokumentacji Socket.IO (2024), ustawienia retry są dostępne przez parametry reconnectionDelay i reconnectionAttempts. Ta opcja jest kluczowa dla aplikacji mobilnych, gdzie połączenie może się przerywać przy zmianie sieci.

Obsługa pokoi — serwer może grupować sockety w pokoje i wysyłać wiadomości tylko do uczestników konkretnego pokoju. Pokoje nie wymagają jawnego tworzenia — są tworzone przy pierwszym dołączeniu socketu. Pokoje są zaimplementowane na poziomie procesu i nie są współdzielone między różnymi serwerami bez specjalnego adaptera.

Przestrzenie nazw — logiczne rozdzielenie kanałów komunikacji na jednym połączeniu. Na przykład przestrzeń /chat dla wiadomości czatu i /notifications dla powiadomień. Każda przestrzeń ma własne pokoje, middleware i procedury obsługi. Przestrzenie nazw są multipleksowane przez jedno połączenie TCP, co oszczędza zasoby.

Potwierdzenie dostarczenia — przy wysyłaniu wiadomości można przekazać funkcję zwrotną, która zostanie wywołana, gdy serwer potwierdzi otrzymanie. Jest to zaimplementowane przez unikalny identyfikator każdego pakietu. Mechanizm potwierdzeń gwarantuje, że krytycznie ważne wiadomości (np. transakcje płatnicze) zostały dostarczone do odbiorcy.

Socket.IO vs WebSocket: porównanie

Wybór między Socket.IO a natywnym WebSocket zależy od wymagań projektu. WebSocket to standaryzowany protokół (RFC 6455) obsługiwany przez wszystkie nowoczesne przeglądarki. Socket.IO to biblioteka używająca WebSocket jako transportu, ale dodająca dodatkowe funkcje.

Jeśli projekt wymaga maksymalnej wydajności i minimalnego rozmiaru klienta — wybierz natywny WebSocket. Jeśli potrzebujesz niezawodnego dostarczania, grupowania i modelu zdarzeniowego — Socket.IO skróci czas tworzenia 2–3 razy dzięki gotowym abstrakcjom.

Według danych ankiety State of JS 2024, 67% programistów aplikacji czasu rzeczywistego preferuje Socket.IO ze względu na wygodę API i wbudowaną obsługę przypadków brzegowych (przerwanie sieci, ponowne łączenie, dane binarne).

Jak podłączyć Socket.IO w projekcie

Instalacja Socket.IO wymaga dwóch pakietów: serwerowego i klienckiego. Omówimy podstawową konfigurację dla projektu Node.js. Serwer tworzy serwer HTTP, inicjalizuje Socket.IO i obsługuje zdarzenia połączenia i rozłączenia klientów.

Według danych dokumentacji Socket.IO (2024), serwer można uruchomić bez Express, używając wbudowanego modułu http, ale w rzeczywistych projektach zwykle używa się Express lub Fastify do routingu żądań HTTP.

Kod serwera w 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('Klient połączony:', socket.id);

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

    socket.on('disconnect', () => {
        console.log('Klient rozłączony');
    });
});

server.listen(3000, () => {
    console.log('Serwer uruchomiony na porcie 3000');
});

Kod klienta w przeglądarce

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!'
});

Zdarzenia i pokoje w Socket.IO

Model zdarzeniowy Socket.IO opiera się na nazwanych zdarzeniach. Serwer i klient wysyłają i odbierają wiadomości powiązane z określoną nazwą zdarzenia. Payload może być ciągiem znaków, obiektem JSON lub danymi binarnymi (Buffer, ArrayBuffer, Blob).

Każde zdarzenie obsługuje ACK (acknowledgement) — przekazanie funkcji zwrotnej, która wykonuje się po stronie nadawcy po przetworzeniu zdarzenia przez odbiorcę. Pozwala to zaimplementować wzorzec request-response na modelu zdarzeniowym. ACK działa tylko wtedy, gdy odbiorca jawnie wywoła funkcję zwrotną.

Według danych dokumentacji Socket.IO (2024), maksymalny rozmiar pojedynczej wiadomości nie powinien przekraczać 1 MB dla optymalnej wydajności. Większe wiadomości należy dzielić na fragmenty lub przesyłać przez osobny kanał.

Praca z pokojami

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');
});

Skalowanie Socket.IO

Skalowanie horyzontalne Socket.IO wymaga rozwiązania problemu współdzielenia stanu między wieloma procesami serwerowymi. Pokoje, przestrzenie nazw i lista podłączonych socketów są przechowywane w pamięci jednego procesu i nie są widoczne dla innych procesów bez adaptera.

Oficjalne adaptery Socket.IO: redis (przez Redis Pub/Sub), mongodb (przez MongoDB change streams), cluster (dla trybu wieloprocesowego Node.js cluster). Adapter działa jako broker wiadomości między instancjami SocketIO. Przy wysyłaniu zdarzenia do pokoju adapter publikuje je w Redis, a wszystkie serwery otrzymują powiadomienie.

Według danych testów obciążeniowych Socket.IO (2024), klaster z 4 serwerów z adapterem Redis obsługuje do 400 000 jednoczesnych połączeń z opóźnieniem poniżej 10 ms. Bez adaptera maksymalna wydajność jednego procesu Node.js wynosi około 100 000 połączeń przy 1 GB pamięci.

Konfiguracja adaptera 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));

Przy użyciu Kubernetes lub Docker Swarm zaleca się dodatkowo skonfigurować session affinity (sticky sessions), aby żądania od jednego klienta trafiały na ten sam serwer, w przeciwnym razie przy każdym ponownym łączeniu może zmieniać się przypisanie.