Sessions persistantes et routage WebSocket
Configurez les répartiteurs de charge pour acheminer correctement les connexions WebSocket avec état grâce aux sessions persistantes, et apprenez dans quels cas un courtier partagé rend cette solution inutile.
Sessions persistantes et routage WebSocket est une leçon WebSockets & Real-Time Systems with Spring gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage WebSockets & Real-Time Systems with Spring, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours WebSockets & Real-Time Systems with Spring comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
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
Apprends WebSockets & Real-Time Systems with Spring avec un tuteur IA — gratuit
Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.
- Cours
- 12
- Leçons
- 48
Questions Fréquemment Posées
La leçon « Sessions persistantes et routage WebSocket » est-elle gratuite ?
Oui — le texte complet de « Sessions persistantes et routage WebSocket » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours WebSockets & Real-Time Systems with Spring, passe à CoddyKit PRO. Le cours WebSockets & Real-Time Systems with Spring comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Sessions persistantes et routage WebSocket » ?
Configurez les répartiteurs de charge pour acheminer correctement les connexions WebSocket avec état grâce aux sessions persistantes, et apprenez dans quels cas un courtier partagé rend cette solutio… Tu pratiques WebSockets & Real-Time Systems with Spring avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer WebSockets & Real-Time Systems with Spring ?
Aucune expérience préalable n'est requise. WebSockets & Real-Time Systems with Spring sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Sessions persistantes et routage WebSocket » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon WebSockets & Real-Time Systems with Spring ?
Oui. Chaque leçon WebSockets & Real-Time Systems with Spring inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- WebSockets dans les architectures de microservices
- Stratégies de déploiement cloud (AWS/GCP)
- Équilibrage de charge et haute disponibilité
- Sessions persistantes et routage WebSocket