Sesje sticky i routing WebSocket
Skonfigurują Państwo load balancery tak, aby prawidłowo kierowały stanowe połączenia WebSocket za pomocą sesji sticky, oraz dowiedzą się, kiedy współdzielony broker eliminuje tę potrzebę.
Sesje sticky i routing WebSocket to bezpłatna lekcja WebSockets & Real-Time Systems with Spring na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej WebSockets & Real-Time Systems with Spring, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs WebSockets & Real-Time Systems with Spring zawiera 4 lekcji w sumie.
Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.
WebSockets Are Long-Lived
Unlike a stateless HTTP request, a WebSocket is a persistent connection pinned to one server instance for its entire life. This breaks the assumption load balancers make about HTTP.
The Routing Problem
If the in-memory simple broker holds a user's subscriptions on instance A, a message that lands on instance B has nowhere to deliver. The connection state lives only where the socket terminated.
Sticky Sessions (Session Affinity)
Sticky sessions make the load balancer always route a given client to the same backend instance. This keeps the socket and its server-side state co-located.
Affinity by Cookie
Cloud load balancers commonly implement affinity with a cookie they set on the first response and read on later requests.
# AWS ALB target group attribute
stickiness.enabled = true
stickiness.type = lb_cookie
stickiness.lb_cookie.duration_seconds = 86400Forwarding the Upgrade
The load balancer must support and forward the HTTP Upgrade handshake. Most modern L7 balancers (ALB, GCP HTTPS LB, Nginx) do, but it must be enabled.
# Nginx
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";Idle Timeouts Bite WebSockets
Load balancers close connections idle beyond a timeout (ALB default 60s). A mostly-quiet WebSocket gets dropped unless you send heartbeats or raise the idle timeout.
idle_timeout.timeout_seconds = 300Health Checks and Draining
During a deploy, instances are removed. Enable connection draining so in-flight WebSockets finish (or clients reconnect) instead of being cut abruptly.
The Better Answer: Shared Broker
Sticky sessions are a workaround. A cleaner design uses a shared external broker (the STOMP relay): any instance can deliver to any subscriber, so affinity is no longer required for routing.
Combining Both
Even with a shared broker, sticky sessions can still help by keeping a client on one instance to avoid mid-stream reconnects. Use them as an optimization, not a correctness crutch.
Kubernetes Ingress Notes
On Kubernetes, the ingress controller needs WebSocket support and affinity annotations. Nginx ingress, for example, uses cookie-based affinity.
nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/proxy-read-timeout: "300"Scaling Out Safely
To add capacity, scale instances behind the balancer and rely on the shared broker for fan-out. Keep sessions evenly spread and use draining on scale-down.
Quick Check
Test your routing knowledge.
Recap
You routed WebSockets correctly:
- WebSockets are long-lived and pinned to one instance
- Sticky sessions (cookie affinity) keep a client on its instance
- The balancer must forward the
Upgradeheader and tolerate idle WebSockets - Use connection draining on deploys
- A shared broker removes the routing need; affinity then becomes an optimization
Ucz się WebSockets & Real-Time Systems with Spring dzięki korepetycjom AI — za darmo
Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.
- Kursy
- 12
- Lekcje
- 48
Często zadawane pytania
Czy lekcja „Sesje sticky i routing WebSocket” jest bezpłatna?
Tak — pełny tekst „Sesje sticky i routing WebSocket” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu WebSockets & Real-Time Systems with Spring, przejdź na CoddyKit PRO. Kurs WebSockets & Real-Time Systems with Spring zawiera 4 lekcji w sumie.
Co nauczysz się w „Sesje sticky i routing WebSocket”?
Skonfigurują Państwo load balancery tak, aby prawidłowo kierowały stanowe połączenia WebSocket za pomocą sesji sticky, oraz dowiedzą się, kiedy współdzielony broker eliminuje tę potrzebę. Ćwiczysz WebSockets & Real-Time Systems with Spring z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć WebSockets & Real-Time Systems with Spring?
Nie wymagamy żadnego doświadczenia. WebSockets & Real-Time Systems with Spring w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.
Ile czasu zajmuje lekcja „Sesje sticky i routing WebSocket”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji WebSockets & Real-Time Systems with Spring?
Tak. Każda lekcja WebSockets & Real-Time Systems with Spring zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- WebSockets w architekturach mikrousług
- Strategie wdrażania w chmurze (AWS/GCP)
- Równoważenie obciążenia i wysoka dostępność
- Sesje sticky i routing WebSocket