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!

Published Jul 31, 2015
Version 1.0
  • Hi all ,

    i'm new on  F5, my question is, what's the best to configure Websocket on F5 LTM ? 

    Thanks, 

     

  • 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

     

  • 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

     

  • Re: redirecting http to https

    There should be no issues.

    redirect: http -> https (only HTTP)
    https: https -> wss (transition from https to websockets)
    
  • 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.

     

  • For version 10.2.4 you'll need to use an iRule to disable a HTTP profile or remove the HTTP profile. This is detailed in SOL14814.

     

  • Hii, Thanks for such a nice article, does BIGIP 10.2.4 also support websocket protocol?

     

  • Patrik, 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