Backend / Networking

Real-time komunikacja

WebSocket, SSE, Long Polling, MQTT i WebTransport — kiedy który protokół wybrać, jak skalować w Kubernetes i jak działają za kulisami.

WebSocket

Bidirectional

SSE

Server push

Socket.io

Fallback + rooms

MQTT

IoT protocol

6 protokołów real-time

Każdy protokół optymalizuje inny aspekt — latencję, overhead, odporność na proxy czy zużycie baterii.

Protokół	Kierunek	Transport	Overhead	Reconnect	Zastosowanie
WebSocket	Bidirectional	TCP (WS/WSS)	Niski (po handshake)	Manualny	Chat, games, collaboration
SSE (EventSource)	Server -> Client	HTTP/1.1, HTTP/2	Średni (HTTP headers)	Automatyczny	Live feeds, notifications, dashboards
Long Polling	Bidirectional (sekwencyjnie)	HTTP	Wysoki (per request)	Automatyczny	Legacy, restrykcyjne proxy
MQTT	Pub/Sub	TCP lub WS	Bardzo niski (2B header)	Wbudowany (QoS)	IoT, embedded, mobile
WebTransport	Bidirectional	QUIC (UDP)	Niski	Manualny	Gry, media streaming (Chrome 97+)
gRPC streaming	Bidirectional	HTTP/2	Niski (Protobuf)	Manualny	Mikroserwisy, wewnętrzne API

Często zadawane pytania

WebSocket vs SSE vs Long Polling — czym się różnią?

Long Polling: klient wysyła request, serwer trzyma połączenie otwarte do czasu nowych danych (lub timeout ~30s), potem zwraca odpowiedź, klient natychmiast wysyła nowy request. Zalety: działa wszędzie, przez wszystkie proxy i firewalle. Wady: overhead HTTP per request, latencja (min. 1 RTT per message), skalowanie (utrzymanie otwartych połączeń). Server-Sent Events (SSE): jednostronne połączenie Server -> Client. HTTP/1.1 streaming (Content-Type: text/event-stream). Serwer wysyła eventy: 'data: {json} '. Klient: EventSource API. Automatyczny reconnect. Zalety: prostota, działa przez proxy/firewalle (HTTP), HTTP/2 multiplexing (wiele streams), natywne wsparcie w przeglądarkach. Wady: tylko serwer -> klient (unidirectional), max 6 połączeń per domain w HTTP/1.1. WebSocket: pełne dwukierunkowe połączenie. Handshake HTTP Upgrade, potem protokół WS. Zalety: bidirectional, niski overhead (brak HTTP headers per message), sub-10ms latencja, binary support (ArrayBuffer). Wady: nie działa przez wszystkie proxy, wymaga specjalnego wsparcia w load balancerach, brak automatycznego reconnect. WebTransport (QUIC): nowy standard, QUIC zamiast TCP, datagram i stream transport, Google Chrome 97+.

Kiedy używać WebSocket, a kiedy SSE?

Używaj WebSocket gdy: aplikacja wymaga bidirectional komunikacji (chat, multiplayer games, collaborative editing). Real-time low-latency (trading, live coding, whiteboarding). Binary data streaming (video, audio). Sub-100ms latencja krytyczna. Używaj SSE gdy: serwer pushuje dane do klienta (feed, powiadomienia, live updates). Unidirectional wystarczy (dashboard, stock ticker, live blog). Prosta implementacja bez bibliotek. HTTP/2 environment (SSE skaluje lepiej). Chcesz automatyczny reconnect bez kodu. Używaj Long Polling gdy: środowisko gdzie WebSocket i SSE mogą być blokowane przez proxy. Starsze przeglądarki (IE11). Bardzo rzadkie aktualizacje (co kilka minut) — SSE/WS marnuje zasoby. Frameworki i librarie: WebSocket — Socket.io (z fallback na polling), ws (Node.js), Gorilla WebSocket (Go). SSE — EventSource (native), ssestream (Node), fanout/SSE. MQTT nad WebSocket — IoT use cases. Phoenix Channels (Elixir) — abstrakcja nad WS. ActionCable (Rails) — WS dla Rails. Ktor WebSocket (Kotlin). Skalowanie WebSocket: sticky sessions (klient zawsze do tego samego serwera) lub Redis Pub/Sub do przekazywania wiadomości między serwerami. Kafka jako message broker.

Socket.io — jak działa i kiedy używać?

Socket.io: biblioteka do real-time komunikacji z fallback mechanizmem. Transport negotiation: próbuje WebSocket, jeśli nie działa — fallback do HTTP long polling. Automatyczny reconnect z exponential backoff. Heartbeat/ping-pong. Rooms i namespaces: logiczne grupowanie klientów. socket.join('room1') — dołącz do pokoju. io.to('room1').emit('event', data) — wyślij do wszystkich w pokoju. Namespaces: /chat, /admin — osobne przestrzenie. Events: socket.on('event', data => ...) — listener. socket.emit('event', data) — wyślij do jednego klienta. io.emit('event', data) — broadcast do wszystkich. Acknowledgements: callback potwierdzający odbiór. socket.emit('event', data, (response) => ...). Middleware: socket.use() — autentykacja, rate limiting. Adapter: domyślnie in-memory. Redis Adapter — multi-server deployment. MongoDB Adapter. Wady Socket.io: overhead w stosunku do natywnego WS. Wersja klienta musi pasować do serwera. Nie działa z natywnym WebSocket API (wymaga Socket.io client). Alternatywy: Ably, Pusher (SaaS), Centrifugo, PubNub. Centrifugo: open-source, Go, obsługuje WebSocket, SSE, HTTP streaming, SockJS.

WebSocket w Kubernetes i load balancerach — jak skonfigurować?

Wyzwania WebSocket w K8s: sticky sessions — klient musi trafić na ten sam pod przez całe połączenie. Load Balancer round-robin zrywa WS. Rozwiązania: Nginx Ingress — proxy_read_timeout 3600s (domyślnie 60s — za krótkie). proxy_send_timeout 3600s. Włącz upgrade negotiation. AWS ALB — obsługuje WebSocket natywnie (sticky sessions przez cookies). Traefik — natywne WebSocket support. Sticky Sessions: Cookie-based affinity w Nginx Ingress (nginx.ingress.kubernetes.io/affinity: cookie). Podproblem: rolling updates zrywają połączenia. Rozwiązanie: preStop hook z drenowaniem. Horizontal scaling: Redis Pub/Sub adapter — wiadomości propagowane między podami. NATS jako alternativa. Architecture: Gateway (WebSocket) -> Kafka -> Microservices -> Kafka -> Gateway. Monitoring WS: metryki — active connections, messages/sec, connection duration. Prometheus websocket_connections_total. Grafana dashboard. Load testing: k6 (WebSocket scenario), Artillery, Gatling. k6 WS API: ws.connect() z callbacks. Timeout i rate limiting: tokeny, żeby zapobiec abuse. Server: max connections per IP. Client: max reconnect attempts.

MQTT i CoAP — protokoły dla IoT real-time?

MQTT (Message Queuing Telemetry Transport): protokół pub/sub dla IoT. Niski overhead (2 bajty nagłówek vs HTTP setki bajtów). Działa nad TCP lub WebSocket. QoS levels: QoS 0 — At most once (fire and forget, może zgubić). QoS 1 — At least once (gwarantowana dostawa, możliwe duplikaty). QoS 2 — Exactly once (gwarantowana, brak duplikatów, największy overhead). Retain messages: ostatnia wiadomość zachowana na brokerze — nowy subscriber dostaje ją od razu. Last Will: wiadomość wysyłana gdy klient się rozłączy (device offline notification). Brokery MQTT: Mosquitto (open-source, lekki). EMQX (enterprise, klaster). HiveMQ (enterprise, Java). AWS IoT Core (SaaS). CloudMQTT (SaaS). MQTT 5.0 — user properties, request/response, shared subscriptions, topic alias. CoAP (Constrained Application Protocol): protokół dla urządzeń z ograniczonymi zasobami. RESTful nad UDP. Observe mode — subskrypcja na zasób. Małe payloady, idealne dla microcontrollerów. AMQP (Advanced Message Queuing Protocol): RabbitMQ. Enterprise messaging. Porównanie: WebSocket — przeglądarka, bidirectional, HTTP transport. SSE — przeglądarka, serwer->klient, HTTP. MQTT — IoT, pub/sub, TCP/WS, QoS levels. CoAP — IoT, REST, UDP. AMQP — enterprise messaging, zaawansowane routing.

Czytaj dalej