我想使用亚马逊弹性负载均衡器代理WebSocket连接到多个node.js服务器。因为Amazon ELB不提供实际的WebSocket支持,所以我需要使用它的普通TCP消息传递。然而,我正在尝试理解在没有某种粘性会话功能的情况下这是如何工作的。
据我所知,WebSockets的工作原理是先从客户端发送一个超文本传输协议升级请求,该请求由服务器通过发送正确处理密钥身份验证的响应来处理。在服务器发送该响应并得到客户端的批准后,客户端和服务器之间就会有一个双向连接。
但是,假设客户端在批准服务器响应后向服务器发送数据。如果它将数据发送到负载均衡器,然后负载均衡器将该数据中继到不处理原始WebSocket升级请求的另一台服务器,那么这台新服务器如何知道WebSocket连接?或者,客户端是否会自动绕过负载均衡器,直接将数据发送到处理初始升级的服务器?
发布于 2013-03-07 20:08:26
我认为,为了回答这个问题,我们需要了解的是,在整个WebSocket创建过程中,底层TCP连接到底是如何演变的。您将认识到,WebSocket连接的粘性部分是底层连接本身。我不确定您在WebSockets上下文中使用“会话”是什么意思。
在较高的级别上,发起"WebSocket连接“需要客户端向HTTP服务器发送HTTP GET请求,而该请求包括Upgrade标头字段。现在,要使此请求发生,客户端需要建立到HTTP服务器的TCP连接(这可能很明显,但我认为在这里明确指出这一点很重要)。然后,通过与相同的 TCP连接发送后续的HTTP服务器响应。
请注意,现在,在发送服务器响应之后,如果客户端或服务器没有主动关闭TCP连接,则TCP连接仍处于打开/活动状态。
现在,在section 4.1的末尾,根据RFC6455,WebSocket标准
如果服务器的响应按照上面提供的方式进行了验证,则为
表示WebSocket连接已建立,并且
WebSocket连接处于打开状态
我从这里了解到,在发送初始HTTP GET (升级)请求之前由客户端发起的同一个TCP连接将保持打开状态,并且从现在开始将用作全双工WebSocket连接的传输层。这是有道理的!
关于你的问题,这意味着负载均衡器将仅在初始HTTP GET (升级)请求被作出之前,即在所述WebSocket连接创建中涉及的一个且唯一的TCP连接在两个通信端点之间被建立之前发挥作用。此后,TCP连接保持已建立状态,并且不能被中间的网络设备“重定向”。
我们可以得出结论,在您的会话术语中,TCP连接定义了会话。只要WebSocket连接是活动的(即未终止),它就会根据定义提供并存在于其自己的会话中。没有什么可以改变这个会话。但是,在此图中,两个独立的WebSocket连接不能共享同一会话。
如果你用" session“指的是其他东西,那么它可能是一个由应用层引入的会话,我们无法对此发表评论。
针对您的评论进行编辑:
,所以您的意思是负载均衡器不参与TCP连接。
不,这不是真的,至少在一般情况下是这样。它肯定会对TCP连接的建立产生影响,因为它可以决定如何处理客户端连接尝试。具体情况取决于负载均衡器的确切类型(*,见下文)。重要提示:在两个端点之间建立连接之后--虽然我不认为负载均衡器是端点,我指的是WebSocket客户机和WebSocket服务器--这两个端点在WebSocket连接的生命周期内不会再发生变化。负载均衡器可能仍在网络路径中,但可以假定它不再受影响。
因此,全双工连接位于客户端和终端服务器之间?
是!
*负载均衡有多种类型。根据类型的不同,在两个端点之间建立连接后,负载均衡器的角色也会有所不同。示例:
TCP
发布于 2013-03-08 00:26:06
WebSocket使用持久的TCP连接,因此需要将该TCP连接的所有IP数据包转发到相同的后端服务器(在TCP连接的生命周期内)。
它需要有粘性。这与L7 HTTP LBs不同,后者能够基于每个HTTP请求进行分派。
LB可以通过不同的方法进行粘性工作,即
https://stackoverflow.com/questions/15266702
复制相似问题