具有负载平衡的会话 cookie(非粘性会话)

Car*_*los 4 sid load-balancing sessionid session-cookies

我扫描了 RFC 6265 但没有找到以下问题的答案。

我想在单个 Web 应用程序的多个服务器前面放置一个简单的循环负载均衡器。负载均衡器不提供粘性会话。因此,客户端通常会根据连续的请求从一个应用程序服务器跳到另一个应用程序服务器。

在第一个连接上,客户端没有 SID,并且被随机路由到服务器 A。
服务器 A 使用会话 cookie(即随机数)进行响应。

在下一次连接时,客户端将来自服务器 A 的 SID 包含在 HTTP 标头中。这次,客户端被随机路由到服务器 B。服务器 B 看到的 SID(希望如此!)与它发出的任何 SID 都不匹配。会发生什么?服务器 B 是否只是忽略“坏”SID,或者抱怨,或者忽略请求,或者什么?

我的想法是,我根本不想使用会话cookie。我想避免粘性的所有复杂性。但我也知道我的服务器可能会生成——更重要的是寻找——会话cookie。

我怎样才能确保服务器忽略(或者更好的是不设置)会话cookie?

law*_*tte 5

我认为这个问题的答案将根据服务器上运行的应用程序的不同而有很大差异。虽然任何有价值的负载均衡器都具有粘性会话,但只要池中的所有服务器都可以通过集中式数据库访问相同的会话状态,就可以在没有粘性会话的情况下进行操作。

\n\n

由于您正在谈论会话 ID,我猜测应用程序确实依赖于会话状态才能运行。在这种情况下,如果请求带有“错误”会话 ID,则该请求很可能会被丢弃,并提示用户再次登录 \xe2\x80\x94,具体行为取决于应用程序。如果您完全禁用会话 cookie,问题可能会变得更糟,因为即使缺少 ID 也可能会导致登录提示。

\n\n

如果您确实想避免负载均衡器的复杂性,则需要引入某种机制,使所有服务器都可以处理来自所有会话的请求。通常,这采用集中式数据库或其他共享存储的形式。这允许维护会话状态,而不管服务器处理该特定请求。

\n\n

维护会话状态是负载平衡的症结之一(双关语),但简单地忽略或避免会话 cookie 并不是解决方案。

\n