使用TCP负载均衡器代理WebSockets而无需粘性会话
我想使用Amazon Elastic Load Balancer将WebSocket连接代理到多个node.js服务器。 由于Amazon ELB不提供实际的WebSocket支持，我需要使用它的vanilla TCP消息。 但是，我试图了解如何在没有某种粘滞会话功能的情况下工作。
我明白，WebSockets的工作原理是首先从客户端发送一个HTTP升级请求，该请求由服务器通过发送正确处理密钥认证的响应来处理。 在服务器发送该响应并被客户端批准后，该客户端和服务器之间就存在双向连接。
但是，让我们说客户端在批准服务器响应之后，将数据发送到服务器。 如果它将数据发送到负载平衡器，然后负载平衡器将该数据中继到不处理原始WebSocket升级请求的其他服务器，那么这个新服务器如何知道WebSocket连接？ 或者，客户端是否会自动绕过负载平衡器并将数据直接发送到处理初始升级的服务器？
我认为，为了回答这个问题我们需要了解的是，在整个WebSocket创建过程中，底层TCP连接究竟是如何发展的。 你会意识到WebSocket连接的粘性部分本身就是底层的TCP连接。 我不确定在WebSockets的上下文中，“session”是什么意思。
在高层次上，启动“WebSocket连接”需要客户端向HTTP服务器发送HTTP GET请求，而请求包含Upgrade标头字段。 现在，为了发生这个请求，客户端需要建立到HTTP服务器的TCP连接（这可能很明显，但我认为在这里明确指出这一点非常重要）。 随后的HTTP服务器响应通过相同的 TCP连接发送。
请注意，现在，在发送服务器响应之后，如果未由客户端或服务器主动关闭，TCP连接仍处于打开/活动状态。
现在，根据RFC 6455，WebSocket标准，在4.1节的末尾：
如果服务器的响应按照上述规定进行了验证，则是
说WebSocket连接建立并且
WebSocket连接处于OPEN状态
我从这里读到，在发送初始HTTP GET（升级）请求之前，客户端启动的同一个TCP连接将保持打开状态，并且从现在开始将作为全双工WebSocket连接的传输层。 这是有道理的！
就您的问题而言，这意味着负载均衡器仅在进行初始HTTP GET（升级）请求之前发挥作用，即在两个通信端点之间建立所述WebSocket连接创建中涉及的唯一TCP连接之前。 此后，TCP连接保持建立，并且不能由其间的网络设备“重定向”。
我们可以得出结论 - 在你的会话术语中，TCP连接定义了会话。 只要WebSocket连接处于活动状态（即未终止），它就会按照定义提供并存在于其自己的会话中。 没有什么能改变这个会议。 在这张图片中，两个独立的WebSocket连接不能共享同一个会话。
如果您使用“会话”引用其他内容，那么它可能是由应用程序层引入的会话，我们无法对该会话发表评论。
针对您的评论进行编辑：
所以你说的是负载平衡器不参与TCP连接
不，这是不正确的，至少在一般情况下。 它肯定会影响TCP连接建立，因为它可以决定如何处理客户端连接尝试。 具体取决于负载均衡器的确切类型（*，见下文）。 重要：在两个端点之间建立连接之后 - 我认为负载平衡器不是端点，我指的是WebSocket客户端和WebSocket服务器 - 两个端点在WebSocket连接的生命周期内不再发生变化。 负载平衡器可能仍然在网络路径中，但可以假定不再受影响。
因此全双工连接在客户端和终端服务器之间？
是!
***有不同类型的负载平衡。 根据类型的不同，在两个端点之间建立连接后，负载平衡器的角色会有所不同。 例子：
WebSocket使用持久性TCP连接，因此要求将该TCP连接的所有IP数据包转发到相同的后端服务器（在TCP连接的生存期内）。
它需要粘性。 这不同于能够根据HTTP请求分派的L7 HTTP LB。
LB可以通过不同的方法工作，即
上一篇: Proxying WebSockets with TCP load balancer without sticky sessions
下一篇: How to install Google Play app in Android Studio emulator?