我面临以下问题：由于当前的负载均衡策略基于客户端IP，所以服务器变得饱和。 一些公司客户端从大型代理服务器访问我们的服务器，所有客户端都显示与我们的负载均衡器相同的IP。 我想我们正在使用一些硬件负载平衡设备（如有必要可以进一步调查）。 我们需要保持会话关联（站点是在ASP中构build的），所以具有相同IP的所有请求都被路由到同一个节点。
由于所有的通信都通过HTTPS，所以没有任何请求数据（如会话Id）可用于作为客户端鉴别器的平衡器。 有没有办法使用除IP以外的其他数据来区分客户端，并且即使从相同的IP到不同的节点，也要路由客户端？
注意：我需要保持平衡器和节点之间的stream量安全（encryption）。
如果您现在有一个负载平衡器，最简单的方法是解密负载平衡器上的数据并查看cookie。 此时，您可以将请求发送到未经处理的后端服务器，也可以对其进行重新encryption并发送。
我所知道的大多数设置考虑负载平衡器和后端服务器之间的networking连接安全，并且不要因为多种原因而重新encryptionstream量。 原因之一是基于硬件的负载平衡器也可以充当SSL加速器 ，这也是HTTPSstream量在他们家门口结束的另一个原因。 另一个是它允许检查stream量是否受到攻击 。
有三种常见的方法来做到这一点：
首先，您可以更改您的负载均衡器转发逻辑（或者跟踪每个主机的连接数，并尝试平均分配负载，执行简单的循环等）。 我提到的任何一个选项都会消除当前设置的确定性（来自IP X的客户端不再去服务器Y），这也消除（或减less）了您的问题。
请注意，您希望实施“粘性会话”或其等同function，以便一旦客户端被随机分配给后端服务器，只要其连接处于活动状态，它们就会保持一致。
其次，您可以解密信息，从中读取一些服务器标识符，然后将其传递（重新encryption或通过后端networking传递）。 请注意，除非您的负载平衡硬件是SSL加速的（例如带有SSL模块的思科内容交换机），否则这并不是真正实用的，因为您通过所有stream量传输的设备必须完成所有的SSL工作。
在原始问题中，每个注释＃2可能不是一个选项，因为stream量需要保持端对端的encryption（听起来像在负载平衡器上解密将是违反策略？）
我不推荐使用第三种方法：为目标服务器设置水平分割或循环DNS（直接指向后端服务器或指向负载均衡器上的静态绑定到后端服务器的单独IP）最后，拥有不同的平衡池等等） – 在“贫民窟负载均衡”中，在较小的操作中这是相当普遍的，但是在你的情况下（已经有一个负载平衡设备），与其他解决scheme相比，它增加了不必要的复杂性。
唯一的方法就是在负载均衡器之前或之后终止SSL，然后根据会话ID进行负载平衡。 用于在一个软件中执行这两个步骤的开源解决scheme将是nginx，haproxy，varnish，以及其他任何软件。
某些硬件负载平衡器基于SSL会话ID进行平衡，但浏览器现在重新协商SSL会话，因此这不再可靠。
取决于盒子的确切types，但是如果你可以改变负载平衡鉴别器来考虑(src ip + src port)而不是(src ip)你就完成了。 我知道Citrix Netscaler支持这个，也可能是其他设备。
我不知道你的问题是否解决。 任何方式，一个很好的解决scheme是使用基于SSL ID的会话亲和力。
在这种情况下，您的设备会记住内存表中的SSL ID，以将具有相同SSL ID的用户请求路由到同一个服务器节点。
所以你必须进一步调查，如果你的负载平衡设备符合。