我为一家规模较小的公司工作，现在我正在努力解决会话持续性问题。
有些人正在多路复用（最近由Fortinet诊断）用户与网站的连接，而FortiWeb显然只是在第一次请求时向用户处理会话持久性cookie。多路复用连接上的所有后续用户＆＃34;背驮式＆＃34;到第一个用户。一旦建立了新的TCP连接，第一个用户就会再次获得一个分配的cookie，并且所有后续用户都会“捎带”＃34;新用户。
问题在于，每次发生这种情况时，每个需要背负的人都很可能（有75％的可能性）切换服务器，并最终导致会话丢失，并被迫再次登录。结果，用户越多，越普遍，越频繁，并且变得越来越有害。
我们的绝大多数用户都没有这方面的问题，但我们有几个较大的客户遇到了问题。我们无法在内部成功地重现这个问题。
粗糙的网络信息：
我们所处的数据中心（经过SSAE16审核）为我们提供了一对冗余链路，连接到高度可用的FortiGate（主动/被动）对，连接到一对HA交换机（主动/主动），转向连接到HA对FortiWebs（主动/被动）进行负载平衡（以及攻击检测/预防）。我们有两个这样的网站，一个制作，一个DR。
FortiWebs以循环格式将四个Web服务器与基于cookie的持久性运行ColdFusion进行负载平衡。我们已经使用了他们的cookie注入方法和他们的持久cookie（读取我们设置的预先存在的cookie）方法。持久性cookie方法有所帮助，但似乎只是增加了在症状出现之前可以使用我们的人数。
我们一直在与Fortinet的支持工作很长一段时间。例如，他们告诉我们让客户关闭多路复用并结束对话。我们建议的客户表示他们实施了变更并没有看到差异。 Fortinet回应说，他们无法帮助配置其他公司的硬件，我们陷入困境。但是这种情况持续的时间越长，这就越成问题。我们试图对此施加更多压力，但几乎没有成功。
我一直在考虑的一些想法和选择：
短期：
切换到我们多年前使用的CentOS代理虚拟机（更不用说全功能了，我们没有完全确认这有用，但据信，这使我们的故障转移方案更加手动）
使用动态DNS配置仅将某些实体路由到CentOS代理（必须为每个实体手动配置）
让一位外部专家再次参与（我们做到了，但他们无法提供帮助，因为他们无法重现它并且多路复用的东西没有被曝光直到最近，部分为什么我在这里，我正在等待我们经常使用的咨询公司的回电）
还原到一个网络服务器（不会在高峰时段处理负载）以确保所有会话都转到一个网络服务器
长期：
对Web服务器进行集群以共享会话信息（我们关注这将如何影响内存和带宽，以及在我们添加更多Web服务器时它将如何扩展）
切换到F5负载均衡器（很多钱，直到我们尝试它，我们无法保证这将解决问题。如果它确实解决了问题，那么这笔钱是值得的。）
离开会话并回到cookie（显然非常低的吸引力）
等待Fortinet的功能请求（他们不认为这是一个错误）有一个选项来强制执行每个请求的持久性（他们根本没有继续这样做，没有满足关于它的一个多月）
切换到私有云或混合云提供商，而不是操作我们自己的硬件
我错过了什么或者您认为我们应该做什么？