使用TCP负载均衡器代理W​​ebSockets而不需要粘性会话

我想使用Amazon Elastic Load Balancer将WebSocket连接代理到多个node.js服务器。 由于Amazon ELB不提供实际的WebSocket支持,我需要使用它的香草TCP消息传递。 不过,我试图了解这将如何工作没有某种粘滞会话function。

据我所知,WebSockets的工作原理是首先从客户端发送HTTP升级请求,由服务器通过发送正确处理密钥authentication的响应来处理。 服务器发送该响应并被客户端批准后,该客户端与服务器之间就存在双向连接。

然而,假设客户端在批准服务器响应之后将数据发送到服务器。 如果将数据发送到负载平衡器,然后负载平衡器将该数据中继到不处理原始WebSocket升级请求的其他服务器,那么这个新的服务器将如何知道WebSocket连接? 或者,客户端是否会自动绕过负载平衡器,并直接将数据发送到处理初始升级的服务器?

我认为为了回答这个问题我们需要了解的是,在整个WebSocket创build过程中,底层的TCP连接究竟是如何发展的。 你会意识到WebSocket连接的粘性部分本身就是底层的TCP连接。 我不确定在WebSockets的上下文中,“session”是什么意思。

在较高层次上,启动“WebSocket连接”需要客户端向HTTP服务器发送HTTP GET请求,而请求包含Upgrade标头字段。 现在,为了这个请求发生,客户端需要build立到HTTP服务器的TCP连接(这可能是显而易见的,但我认为在这里明确指出这一点很重要)。 随后的HTTP服务器响应通过相同的 TCP连接发送。

请注意,现在,在发送服务器响应之后,如果未由客户端或服务器主动closures,则TCP连接仍处于打开/活动状态。

现在,根据RFC 6455,WebSocket标准,在4.1节的末尾:

如果服务器的响应按照上面的规定进行了validation,那就是
WebSocket连接是build立的
WebSocket连接处于OPEN状态

我从这里读到,在发送初始HTTP GET(升级)请求之前,客户端启动的相同TCP连接将保持打开状态,并且从现在开始将作为全双工WebSocket连接的传输层。 这是有道理的!

就您的问题而言,这意味着负载平衡器将仅在进行初始HTTP GET(升级)请求之前 ,即两个通信端点之间build立所述WebSocket连接创build中涉及的唯一的TCP连接之前起作用。 此后,TCP连接保持build立,并且不能由其间的networking设备“redirect”。

我们可以得出结论 – 在你的会话术语中,TCP连接定义了会话 。 只要WebSocket连接处于活动状态(即未被终止),它就按其定义提供并存在于自己的会话中。 没有什么能改变这个会议。 在这张照片中,两个独立的WebSocket连接不能共享同一个会话。

如果你用“会话”来引用别的东西,那么它可能是由应用层引入的一个会话,我们不能对此进行评论。

编辑您的意见:

所以你是说负载平衡器不参与TCP连接

不,这是不正确的,至less在一般情况下。 它确实可以影响TCP连接的build立,也就是说可以决定如何处理客户端连接尝试。 具体取决于负载均衡器的确切types(*,见下文)。 重要事项:在两个端点之间build立连接之后 – 我认为负载平衡器不是端点,我指的是WebSocket客户端和WebSocket服务器 – 两个端点在WebSocket连接的生命周期内不再改变。 负载平衡器可能仍然在networkingpath中,但可以被假定为不再受影响。

因此,全双工连接在客户端和terminal服务器之间?

是!

***有不同types的负载平衡。 取决于types,在两个端点之间build立连接之后,负载平衡器的angular色是不同的。 例子:

  • 如果负载平衡发生在DNS基础上,则负载平衡器根本不参与最终的TCP连接。 它只是告诉客户端哪个主机必须直接连接。
  • 如果负载平衡器的工作方式类似于AWS的Layer 4 ELB(文档在这里 ),那么它就是代理TCP连接。 所以客户端实际上将ELB本身看作是服务器。 然而,发生的事情是,ELB只是双向转发包裹,没有任何改变。 因此,透明地依然严重参与TCP连接。 在这种情况下,实际上有两个永久的TCP连接:一个从你到ELB,一个从ELB到服务器。 这些在WebSocket连接的生命周期中也是永久的。

WebSocket使用一个持久的TCP连接,因此要求该TCP连接的所有IP数据包被转发到相同的后端服务器(在TCP连接的生存期内)。

它需要粘性。 这不同于能够根据HTTP请求分派的L7 HTTP LB。

LB可以通过不同的方法工作,即

  • 将源IP /端口散列到一组活着的后端服务器
  • 在build立TCP连接时,select一个后端服务器并记住