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

    Powiązane artykuły

    Kontakt

    Skontaktuj się z nami

    Porozmawiajmy o Twoim projekcie. Bezpłatna wycena w ciągu 24 godzin.

    Wyślij zapytanie

    Bezpłatna wycena w 24h
    Bez zobowiązań
    Indywidualne podejście
    Ekspresowa realizacja

    Telefon

    +48 790 814 814

    Pon-Pt: 9:00 - 18:00

    Email

    adam@fotz.pl

    Odpowiadamy w ciągu 24h

    Adres

    Plac Wolności 16

    61-739 Poznań

    Godziny pracy

    Pon - Pt9:00 - 18:00
    Sob - NdzZamknięte

    Wolisz porozmawiać?

    Zadzwoń teraz i porozmawiaj z naszym specjalistą o Twoim projekcie.

    Zadzwoń teraz