Load Balancing WebSockets
An introduction to WebSockets and how to load balance them. WebSockets creates a responsive experience for end-users by creating a bi-directional communication stream versus the one-way HTTP stream. For example, when you’re waiting at the deli counter you need to take a number. An HTTP method of checking your status in line would be to periodically take your number up to the deli counter to see if you’re next in line. The WebSocket method for notification would be to have someone shout out the number to you when you’re next. One of these methods is more convenient!
HTTP is a stateless protocol. It looks like a series of request/responses that originate from the client to the server. WebSockets is a bi-directional protocol that allows the client to send requests to the server AND allows the server to push responses to the client.
On the BIG-IP with LTM the default HTTP profile has supported the WebSocket upgrade header since 11.4.0. It is possible to use a FastL4 profile to treat all the traffic as TCP, but you lose some resources like the ability to set X-Forwarded-For headers to provide visibility to the client IP when using SNAT, cookie persistence (avoid issues when client IP changes), and the ability to route traffic based on the HTTP request. Given the long duration of a WebSocket connection; you can also utilize pool member connection limits and least connection load balancing to ensure an even distribution of traffic across multiple nodes.
General tips for the backend servers is to ensure that the servers are stateless (any server can generate a response for any client) or share state. SignalR (ASP.NET) has a nice introduction to scaling out (don’t forget to use the same MachineKey across IIS servers). Socket.IO (Node.JS) has helpful documentation that covers utilizing multiple nodes (Redis works well as a provided adapter). Not all clients will support WebSocket natively, and/or web proxy/firewalls may not allow these connections. Fallback mechanisms exist for both SignalR/Socket.IO to allow communication without support for WebSockets (via HTTP).
Using these tips to load balance WebSockets you can create a highly available service of WebSocket servers or create a demo that combines an Apache web, Node.JS Socket.IO, and SignalR ASP.NET server under a single URL!
- Poseidon1974Cirrostratus
Hi all ,
i'm new on F5, my question is, what's the best to configure Websocket on F5 LTM ?
Thanks,
- Habibah_386189Nimbostratus
hi,
I write a program for the client-server using socket in python and I want to make the client connect to the f5 load balancer and then the load balancer will distribute the requests between servers.
my question is does F5 load balancer support a code that is written in TCP socket in python and how the connection will work.
Best Regards, Habibah
- Phuc_Le_384684Nimbostratus
hi,
My company is using F5 Load Balancer. We are implementing a NodeJs application which will have more than 2 billion users connect to the server using WebSocket
Could you please let me know F5 will be able to handle that high traffic or we need another solution likes Orchestration server?
Thanks, Phuc
- Eric_ChenEmployee
Re: redirecting http to https
There should be no issues.
redirect: http -> https (only HTTP) https: https -> wss (transition from https to websockets)
- ar09_362646Nimbostratus
if we are redirecting http to https, will it impact the behavior?
- MaaS_170765Nimbostratus
Thanks Eric for the great article. I found this very helpful with some troubleshooting of WebSockets and SignalR issues. Developers expected that F5 was the issue because when they hit their web servers directly, connections using websockets worked, but they did not work when they hit the load-balanced URL.
It turned out their issue was related to missing SPN's and that WebSockets connections failed due to authentication when they used the URL that was load-balanced by f5. Your article allowed me to get up to speed quickly with web devs.
- Divya_Vardha_20Nimbostratus
Hii, Thanks for such a nice article, does BIGIP 10.2.4 also support websocket protocol?
- Eric_ChenEmployeePatrik, Yes, the XFF would only be visible for the initial HTTP connection. Typically this would be associated with a thread/process that you could preserve the last XFF that was seen. Once the connection is upgraded to websocket it will appear to be a normal TCP connection. It is possible to parse the individual TCP messages as websocket frames (I started to play around with this as an iRule). In my limited tested I observed that if you took a websocket server down it would be possible for a client to re-connect and associate with another server. If the client was sending data at the time of the disconnect it would be possible to lose a message. Once a connection becomes a websocket connection it is more like a telnet/ssh/database connection (long lived). Hope that helps. Eric
- Hi! Thank you for your article. It was interesting. You would be able to use XFF for the first packet for the rest would be depending on the web sockets application right? You lose certain aspects as URI manipulation, cookie insertion in the load balancers too right? One more question about the scaling. If you'd patch servers wouldn't the connections be quite unbalanced after service interruption since they're so long lived? One of the benefit with short lived HTTP connections is that they're easily distributed. Can you achieve this with web sockets too somehow? It seems useful, but I'd like to read more about the limitations too. I know Lori wrote some last year, but it's been a while now. :) /Patrik