SSL Balancer + Websockets

[Justin Reiners]

We've got a pretty busy site hosted on a single giant machine, which works well. This service uses WebSockets extensively.

When trying to clone a few instances, and placing them in the instance group the page loads fine, but WebSockets seem to be not passing at all...

I looked into the documentation a few times.

on the following page

https://cloud.google.com/compute/docs/load-balancing/http/#websocket_proxy_support

I see the following info:

WebSocket proxy support

The HTTP(S) load balancer has native support for the WebSocket protocol. Backends that use WebSocket to communicate with clients can use the HTTP(S) load balancer as a front end, for scale and availability. The load balancer does not need any additional configuration to proxy WebSocket connections.

The WebSocket protocol, which is defined in RFC 6455, provides a full-duplex communication channel between clients and servers. The channel is initiated from an HTTP(S) request.

When the HTTP(S) load balancer recognizes a WebSocket Upgrade request from an HTTP(S) client and the request is followed by a successful Upgrade response from the backend instance, the load balancer proxies bidirectional traffic for the duration of the current connection. If the backend does not return a successful Upgrade response, the load balancer closes the connection.

The timeout for a WebSocket connection depends on the configurable response timeout of the load balancer, which is 30 seconds by default. This timeout is applied to WebSocket connections regardless of whether they are in use or not. For more information about the response timeout and how to configure it, refer to Timeouts and retries.

If you have configured either client IP or generated cookie session affinity for your HTTP(S) load balancer, all WebSocket connections from a client are sent to the same backend instance, provided the instance continues to pass health checks and has capacity.

I'm seeing the following in developer tools:

WebSocket connection to 'wss://www.mydomain.com:9000/' failed: WebSocket opening handshake timed out

Is there some piece of config I might be missing? All of my instances show as healthy, and port 9000 is open on the instances.

[Dinesh (Google Platform Support)]

Any specific reason why you cloning the instance and placing them on instance group manually and not using the Autoscaling  feature[1]. Autoscaling helps your applications gracefully handle increases in traffic and reduces cost when the need for resources is lower. Define the autoscaling policy and the autoscaler performs automatic scaling based on the measured load.

Having said that, did you checked the new instances are receiving some traffic as you suggesting all instances being marked as healthy? You may want to try to test by sending your service request directly to the new instances (without LB in front) to verify the behavior. There might be a chance that the application service is not running correctly on new instances. 

Let us know if this helps?

[1]: https://cloud.google.com/compute/docs/autoscaler/

[Justin Reiners]

Dinesh,

Thanks for getting back to me here.

I would love to use autoscale, but we are in constant development, and I want to pull out as many variables as I can.

I know the traffic works to both large nodes, because when we scale, we end up scaling the other host, and changing host the external points to.

I have confirmed all 3 endpoints are available with https://ip:9000

but when I put them behind the balancer I get no connection. My site loads just fine but the websockets show 404 not found.

I see no way to add :9000 to the balancer rules. I'd autoscale for sure if I could confirm it would work at all... :)

[Dinesh (Google Platform Support)]

As per the cloud documentations[1] HTTP requests can be load balanced based on port 80 or port 8080. HTTPS requests can be load balanced on port 443. Whereas TCP Proxy Load Balancing[2] supports the following ports: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 5222. Can you please confirm how you redirecting your Web-socket request from one of these ports to port 9000 OR you are not re-directing at all?

Alternatively, you may want to test the behavior by configuring your service on port 80 or 443 in place of port 9000. There are numerous advantages to running Web-Sockets on port 80 (or 443) as suggested in this Stack Overflow thread[3]. Let us know if this helps?

[1]: https://cloud.google.com/compute/docs/load-balancing/http/

[2]: https://cloud.google.com/compute/docs/load-balancing/tcp-ssl/tcp-proxy

[3]: https://stackoverflow.com/questions/28522857/shall-i-use-websocket-on-ports-other-than-80

[Justin Reiners]

Hey Dinesh, thanks again for helping.

I was not proxying at all because of this phrasing:

The HTTP(S) load balancer has native support for the WebSocket protocol. Backends that use WebSocket to communicate with clients can use the HTTP(S) load balancer as a front end, for scale and availability. The load balancer does not need any additional configuration to proxy WebSocket connections.

I do have an apache reverse proxy running behind the balancer on each host. I just couldn't figure out how to get 9000 to my instance but I think I figured it out now... I'll need to change my ws port to 8080, or run it from a proxied subfolder on https.

--
© 2018 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043
 
Email preferences: You received this email because you signed up for the Google Compute Engine Discussion Google Group (gce-discussion@googlegroups.com) to participate in discussions with other members of the Google Compute Engine community and the Google Compute Engine Team.
---
You received this message because you are subscribed to the Google Groups "gce-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gce-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to gce-discussion@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gce-discussion/5dbd6ba2-55a0-4fe4-969e-4a0cbc8d91dd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.