1

We have the following setup for Google HTTPS load balancer.

Two Frontends: 1. HTTP traffic to static IP 2. HTTPS traffic to the same static IP(DNS configured to a domain name)

Host and Path rules All going to backend

One Backend: With HTTP protocol with session affinity set to client IP

The backend instance has a MEAN app running on port 3000.

From our client side application we are able to get through to backend app using loadbalancer domain name. But we also have a chat feature with socket.io

For socket connection we were not able to use loadbalancer domain name. It throws 400 error.

If we try to use the backend IP directly for socket connection, it works but the if the client is on HTTPS, it creates another problem because backend is http.

Google documentation says loadbalancer supports websockets by default. So not sure what is going on. All other examples I see are relatively old and not relevant I think. Any help is appreciated. Thanks.

  • Because socket.io starts out the connection with a couple http polling requests, the connection will regularly fail if you don't have sticky load balancing. So, you can either enable sticky load balancing in the load balancer (if that's a supported option) or configure the socket.io client to connect directly with webSocket and not use http polling at the start of the connection. – jfriend00 Apr 20 '18 at 4:31
  • 1
    Like I tried to explain, Google documentation clearly says HTTP(S) load balancing supports websockets without additional support. And I don't think there is a sticky option available on GCE. However there is session affinity and I tried that. – NunnaS Apr 20 '18 at 4:58
  • 1
    You apparently didn't understand my comment. A socket.io connection starts with several http requests before it switches to a webSocket connection. If those http requests aren't sticky and go to the same host every time, then the socket.io connection will fail. You can force the client to connect directly with a webSocket as the transport to avoid that or you can configure the load balancer to be sticky. You NEED one of those for a socket.io connection to work through a load balancer, even one that supports webSockets. socket.io is NOT plain webSocket, it's got stuff on top of that. – jfriend00 Apr 20 '18 at 5:00
  • See Socket.io to use webSocket only for how to force webSocket transport from the beginning. – jfriend00 Apr 20 '18 at 5:02
  • Further to above comment, please note that as per GCP documentation, If you have configured either client IP or generated cookie session affinity for your HTTP(S) LB, all WebSocket connections from a client are sent to the same backend instance, provided the instance continues to pass health checks. – D Saini Apr 20 '18 at 23:28

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.