WSS on ALB with WS backend.

0

I am developing an app which uses Websockets. The ALB is terminating HTTPS with an AWS certificate. This passes through to HTTP at the backend.

I am experiencing issues that socket.io will not elevate its connection to websocket.

I think this may be because the websocket is not terminated in the same way as HTTPS is but is instead passed through to the backend still as WSS - i.e. it is expecting a secure connection.

Does this sound correct? Has anybody else found this issue and has anybody found a workaround?

Thanks!

asked 9 months ago1708 views
1 Answer
0

The Application Load Balancer (ALB) in AWS supports WebSockets. When a client sends a WebSocket upgrade request, the load balancer establishes a TCP connection to the target, sends the request to the target, and communicates the target's response to the client. After that, all data sent between the client and the target is forwarded without any modification. Thus, if you're terminating the HTTPS at the ALB and forwarding HTTP to the backend, the same logic should apply to the WebSocket connection.

However, with socket.io, things can be a bit more complex. Socket.io is a library that abstracts WebSockets and falls back to long polling if the WebSocket connection cannot be established. This is beneficial because it ensures real-time updates even when WebSockets are not supported, but it can also cause issues when trying to get the WebSocket connection working.

Now let's dig into your problem. If you are expecting an issue with WebSocket connection over a secure connection (WSS), you can check the following things:

  • Network configuration: Make sure there is no firewall or security group rule that blocks the WebSocket protocol. Ensure that the appropriate ports are open and the connection is not being blocked.

  • ALB configuration: You need to set up stickiness at the target group level of your ALB. WebSocket is a stateful protocol, so it is crucial to ensure that the connection between the client and the server is maintained. Also, ensure that the ALB Idle timeout value is greater than the WebSocket inactivity timeouts.

  • Socket.io Configuration: Make sure your socket.io client and server are correctly configured to use WebSockets. Sometimes, socket.io falls back to long polling because it cannot establish a WebSocket connection.

  • Check headers: Make sure your ALB is passing the correct headers to your backend. Some necessary headers for WebSocket connections are "Upgrade" and "Connection" headers.

  • Backend server: Check the backend server logs to see if it's getting the upgrade request and how it's responding.

  • Client-side logging: On the client side, use browser developer tools to check the network traffic and console messages related to the WebSocket connection. This could provide useful insights into why the connection isn't being upgraded.

  • SSL Termination: If you're terminating SSL at the ALB and then forwarding unencrypted traffic to the backend, make sure that your backend is configured to accept this unencrypted traffic.

Remember that the exact solution could vary based on your specific setup and configuration. If none of these suggestions help, it would be beneficial to provide more information about your setup, including the socket.io client and server versions and configurations, any proxy servers involved, and any specific error messages you are encountering.

profile picture
answered 9 months ago
  • Hi, I'm having this issue and from what I can see, ALB replaces the Connection: Upgrade header with the Connection: Keep-Alive header which makes the connection no longer recognizable as websocket on my backend service, I wonder what controls this or if it's possible for the ALB to append headers and not replace them?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions