When you think about load balancers, most people picture them handling regular web traffic — simple HTTP requests that come in, get processed, and leave. Easy. But things change when we start talking about WebSocket Secure (WSS) connections.
Unlike normal HTTP requests, a WebSocket connection doesn’t just appear and disappear. It stays open. Once a client connects, it expects to keep talking to the same server for as long as the connection lasts. That’s where the challenge comes in: how do you make sure a client always talks to the right server when there’s a load balancer in the middle?
Let’s break down the main ways this problem is solved.
1. Sticky Sessions (a.k.a Session Affinity)
This is the go-to method most people use. The idea is simple: once a client connects to a server, the load balancer makes sure that client always goes back to the same server.
How it works:
- IP Hash: The load balancer looks at the client’s IP address and uses it to decide which server they should connect to.
- Cookies: The load balancer adds a special cookie to the client’s connection. That cookie tells the load balancer which server to route them to in the future.
Pros & Cons:
- It works well for keeping sessions alive.
- But if one server ends up with more clients than others, things can get unbalanced. That server might be overloaded while others sit idle. And if the “sticky” server goes down, those clients lose their connection.
2. External Session Storage
Instead of tying a client to a single server, another approach is to make the servers stateless.
Here, all session information is stored in a shared system like Redis or a database. That way, it doesn’t matter which server the load balancer sends the client to — every server has access to the same session data.
Why this is good:
- It’s more flexible.
- Servers can come and go, and clients can reconnect without caring which server they hit.
- It makes scaling and failover a lot smoother.
The tradeoff:
- You need a reliable external store, which adds complexity.
- The servers now depend on that shared system being fast and always available.
3. Load Balancing Algorithms
Even with WebSockets, load balancers can use different algorithms to decide which server should take a new connection:
- Round Robin: Sends each new connection to the next server in line.
- Least Connections: Sends the client to the server with the fewest active connections. This helps balance things when some clients are heavier than others.
- Weighted Least Connections: Like “least connections,” but you can give stronger servers more weight so they handle more clients.
These algorithms don’t solve the session persistence problem on their own, but they work alongside sticky sessions or external storage.
Since we’re talking about WSS, remember it’s secure WebSockets. That means SSL/TLS is involved. Usually, the load balancer handles this by terminating SSL — it decrypts the traffic from the client, decides which server to send it to, and (optionally) re-encrypts it before forwarding.
This is important because the load balancer needs to see the traffic to do its job.
Handling WebSocket Secure (WSS) connections with a load balancer isn’t just about spreading traffic around. The key challenge is keeping sessions consistent, because WebSockets aren’t like regular web requests that come and go.
- Sticky sessions are simple but can create uneven loads.
- External session storage makes things more flexible and scalable.
- Load balancing algorithms help distribute new connections fairly.
The “best” approach depends on your setup. For smaller systems, sticky sessions might be enough. For larger, more complex environments, externalizing session state usually pays off in the long run.
What limits how many WSS connections a load balancer can handle?
Main factors
- RAM per connection — each open WebSocket consumes memory (connection objects, buffers).
- File-descriptors / sockets limit — OS/process limits; must be upped for large scale.
- CPU — SSL/TLS handshake + per-message handling, application logic.
- Network throughput — bandwidth available and packet overhead.
- TLS offload — hardware TLS or dedicated offload reduces CPU cost.
- Load balancer software — some implementations (HAProxy, Nginx, Envoy, L4 TCP proxies, cloud LB) scale better for many idle connections.
- Connection churn & message rate — many idle connections cost less than many active, chatty connections.
- Kernel & TCP tuning — ephemeral ports, tcp_tw_reuse, keepalive, net.core settings.
- Session persistence strategy — sticky sessions vs stateless backends impacts resource needs and failover behavior.
Typical ranges (very approximate & highly workload-dependent)
- Small VM / default config: 10k–50k simultaneous WSS connections.
- Tuned x86 server with 64 GB RAM and kernel tuning: 100k–500k+ connections.
- Large beefy machines or specialized LB appliances (or horizontally scaled cluster): hundreds of thousands to millions of concurrent connections.
Hope you find it helpful!
For cloud consultation visit here.