当有一堆系统充当WebSocket无人机，并且在这些无人机前面有一个负载均衡器时。当WebSocket请求进入LB时，它选择一个WebSocket drone，并且WebSocket被建立。（我使用在ELB终止的AWS ELB tcp SSL）
问题：现在，创建的WebSocket是否通过LB，或者LB是否将WebSocket请求转发到WebSocket无人机，从而在客户端和WebSocket人机之间存在直接链接？
如果WebSocket连接通过LB，这将使LB成为一个巨大的瓶颈。
删除LB并向客户端提供WebSocket无人机的直接IP可以绕过这个瓶颈，但需要自己创建这个逻辑，我正计划这样做（取决于这些问题的答案）。
那么，我对这种工作方式的看法正确吗？
AWS ELB作为LB
在查看了Pavel K建议的可能的重复之后，我得出结论，WebSocket连接将通过AWS ELB，如：
Browser <--WebSocket--> LB <--WebSocket--> WebSocketServer
这使得ELB成为瓶颈，我想要的是：
Browser <--WebSocket--> WebSocketServer
其中ELB仅用于为客户端提供可用WebSocketServer的主机名/IP。
DNS为LB
上述问题可以通过在DNS级别上进行平衡来避免，如可能的重复中所解释的。由于这样，当请求ws.myapp.com时，DNS将提供可用WebSocketServer的IP。
不利的一面是，这将需要通过向上/向下更改WebSocketServer来不断更新DNS（如果你的应用程序是弹性的，这将成为一个更大的问题）。
自定义LB
另一种选择可能是创建一个自定义LB，该LB不断监视WebSocketServer，并在客户端请求时返回可用WebSocketServer的IP。
不利的一面是，客户端需要执行一个单独的（AJAX）请求来获取可用WebSocketServer的IP，而使用AWS ELB，负载平衡是隐式发生的。
结论
选择更好的邪恶。。