问题描述
我想使用Amazon Elastic Load Balancer将WebSocket连接代理到多个node.js服务器.由于Amazon ELB不提供实际的WebSocket支持，因此我需要使用其原始的TCP消息传递.但是，我试图了解如何在没有某种粘性会话功能的情况下工作.
I want to proxy WebSocket connections to multiple node.js servers using Amazon Elastic Load Balancer. Since Amazon ELB does not provide actual WebSocket support, I would need to use its vanilla TCP messaging. However, I'm trying to understand how this would work without some sort of sticky session functionality.
我了解WebSocket的工作方式是首先从客户端发送HTTP升级请求，服务器通过发送正确处理密钥身份验证的响应来处理该请求.服务器发送该响应并获得客户端批准后，该客户端与服务器之间便建立了双向连接.
I understand that WebSockets work by first sending an HTTP Upgrade request from the client, which is handled by the server by sending a response which correctly handles key authentication. After the server sends that response and it is approved by the client, there is a bidirectional connection between that client and server.
但是，假设客户端在批准服务器响应后将数据发送到服务器.如果它将数据发送到负载平衡器，然后负载平衡器将该数据中继到未处理原始WebSocket升级请求的其他服务器，那么此新服务器将如何知道WebSocket连接?还是客户端会自动绕过负载平衡器并将数据直接发送到处理初始升级的服务器?
However let's say the client, after approving the server response, sends data to the server. If it sends the data to the load balancer, and the load balancer then relays that data to a different server that did not handle the original WebSocket Upgrade request, then how will this new server be aware of the WebSocket connection? Or will the client automatically bypass the load balancer and send data directly to the server that handled the initial upgrade?
推荐答案
我认为，为了回答这个问题，我们需要理解的是底层TCP连接在整个WebSocket创建过程中究竟如何演变.您将认识到WebSocket连接的 sticky 部分是基础TCP连接本身.我不确定您在WebSockets上下文中对会话"的含义.
I think what we need to understand in order to answer this question is how exactly the underlying TCP connection evolves during the whole WebSocket creation process. You will realize that the sticky part of a WebSocket connection is the underlying TCP connection itself. I am not sure what you mean with "session" in the context of WebSockets.
在较高级别上，启动"WebSocket连接"要求客户端向HTTP服务器发送HTTP GET请求，而该请求包括Upgrade标头字段.现在，为了实现此请求，客户端需要建立与HTTP服务器的TCP连接(这可能很明显，但是我认为在此处明确指出这一点很重要).随后，随后的HTTP服务器响应将通过相同 TCP连接发送.
At a high level, initiating a "WebSocket connection" requires the client to send an HTTP GET request to an HTTP server whereas the request includes the Upgrade header field. Now, for this request to happen the client needs to have established a TCP connection to the HTTP server (that might be obvious, but I think here it is important to point this out explicitly). The subsequent HTTP server response is then sent through the same TCP connection.
请注意，现在，在发送服务器响应之后，如果客户端或服务器未主动关闭TCP连接，则该TCP连接仍然处于打开/活动状态.
Note that now, after the server response has been sent, the TCP connection is still open/alive if not actively closed by either the client or the server.
现在，根据RFC 6455(WebSocket标准)，在第4.1节的末尾:
Now, according to RFC 6455, the WebSocket standard, at the end of section 4.1:
我从这里读到，客户端在发送初始HTTP GET(升级)请求之前发起的同一TCP连接将保持打开状态，从现在开始将用作全双工WebSocket连接的传输层.这是有道理的！
I read from here that the same TCP connection that was initiated by the client before sending the initial HTTP GET (Upgrade) request will just be left open and will from now on serve as the transport layer for the full-duplex WebSocket connection. And this makes sense!
关于您的问题，这意味着负载均衡器将仅在发出初始HTTP GET(升级)请求的之前，即 before 和在两个通信端点之间仅建立了涉及所述WebSocket连接创建的TCP连接.此后，TCP连接将保持建立状态，并且不能被两者之间的网络设备重定向".
With respect to your question this means that a load balancer will only play a role before the initial HTTP GET (Upgrade) request is made, i.e. before the one and only TCP connection involved in said WebSocket connection creation is established between the two communication end points. Thereafter, the TCP connection stays established and cannot become "redirected" by a network device in between.
我们可以得出结论-在您的会话术语中- TCP连接定义了会话.只要WebSocket连接处于活动状态(即未终止)，它就按定义提供并生活在其自己的会话中.没有什么可以改变这个会议.在这张照片中，两个独立的WebSocket连接无法共享同一会话.
We can conclude that -- in your session terminology -- the TCP connection defines the session. As long as a WebSocket connection is alive (i.e. is not terminated), it by definition provides and lives in its own session. Nothing can change this session. Speaking in this picture, two independent WebSocket connections, however, cannot share the same session.
如果您用会话"引用其他内容，则可能是应用程序层引入的会话，我们无法对此进行评论.
If you referred to something else with "session", then it probably is a session that is introduced by the application layer and we cannot comment on that one.
根据您的评论进行
不，那是不正确的，至少在一般情况下是这样.从某种意义上说，它可以决定如何处理客户端连接尝试，它绝对会影响TCP连接的建立.具体细节取决于负载均衡器的确切类型(*，请参见下文).重要提示:在两个端点之间建立连接后-尽管我不认为负载均衡器是一个端点，但我指的是WebSocket客户端和WebSocket服务器-两个端点在WebSocket连接的生命周期中将不再改变.负载均衡器可能*仍在网络路径中，但可以假定不再具有影响力.
No, that is not true, at least in general. It definitely can take influence upon TCP connection establishment, in the sense that it can decide what to do with the client connection attempt. The specifics depend on the exact type of load balancer (* , see below). Important: After the connection is established between two endpoints -- whereas I don't consider the load balancer to be an endpoint, I refer to WebSocket client and WebSocket server -- the two endpoints will not change anymore for the lifetime of the WebSocket connection. The load balancer might* still be in the network path, but can be assumed to not take influence anymore.
是的！
***有不同类型的负载平衡.根据类型，在两个端点之间建立连接后，负载均衡器的作用会有所不同.例子:
***There are different types of load balancing. Depending on the type, the role of the load balancer is different after connection establishment between the two end points. Examples:
- 如果负载平衡是基于DNS发生的，则负载平衡器根本不参与最终的TCP连接.它只是告诉客户端必须直接连接到哪个主机.
- 如果负载平衡器的工作方式类似于AWS的第4层ELB(文档此处)，那么可以说它是TCP连接的代理.因此，客户端实际上会将ELB本身视为服务器.但是，发生的情况是，ELB只是沿两个方向转发包裹，而没有进行任何更改.因此，它仍然透明地大量参与TCP连接.在这种情况下，实际上涉及两个永久TCP连接:一个从您到ELB，一个从ELB到服务器.这些在您的WebSocket连接的生命周期中仍然是永久的.
- If the load balancing happens on DNS basis, then the load balancer is not involved in the final TCP connection at all. It just tells the client to which host is has to connect directly.
- If the load balancer works like the Layer 4 ELB from AWS (docs here), then it so to say proxies the TCP connection. So the client would actually see the ELB itself as the server. What happens, however, is that the ELB just forwards the packages in both directions, without change. Hence, it is still heavily involved in the TCP connection, just transparently. In this case there are actually two permanent TCP connections involved: one from you to the ELB, and one from the ELB to the server. These are again permanent for the lifetime of your WebSocket connection.
这篇关于在没有粘性会话的情况下使用TCP负载平衡器代理WebSocket的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！