我正在建立一个网站，该网站有大量聊天消息和社交通信在用户之间实时传输，也可通过存档（文本材料，而非图像）访问。我想为用户提供尽可能安全的体验，并希望通过 https 运行所有内容。我想说大约 30% 的网站实际上不需要 https，但由于网站中使用了所有跨框架 javascript 通信，因此编写代码以绕过跨站点脚本安全措施会很麻烦。我还使用 xhr 长轮询（ape ajax-push 引擎）来传输数据，因此我也将通过 stunnel 运行许多并发打开的连接。
我的问题是：我见过物理防火墙的主机可以处理数十万个常规并发连接，但只能处理数百个并发 SSL 连接。一般来说，物理防火墙的可扩展性在使用 https 时是否会比使用 http 时严重下降？特别是考虑到大约 90% 的登录到站点的用户将使用 ape-engine 与服务器建立开放连接以获取实时数据。如果是这样，防火墙有哪些选项可以正确处理 SSL 的这种情况，同时仍允许可扩展性？
我理解这个问题的开放性。我真正想做的只是了解其他开发人员遇到这种情况的经验、他们如何处理这种情况以及他们发现哪种硬件在这种情况下有用。我可以重新编码网站以使用 https 和 http，但这是最后的选择。
顺便说一句：该网站运行在 LAMP 堆栈上。它必须扩展到大约 100 万并发用户，因此可扩展性确实很重要。（我们不要把这变成一场关于“你的网站永远不会变得那么大”的争论）
答案1
我们在工作中使用 F5 硬件负载均衡器，它们可以将 SSL 终止作为其工作的一部分。通过这样做，它们减轻了我们服务器的大量负载，并且我们可以比以前更远地横向扩展。F5 模型按并发 SSL 事务收费每秒，定义为在给定的秒内主动传输数据，因此很难从“100 万并发用户”转化为可能是会话数指标。
需要注意的关键一点是，这些设备本身并不是防火墙。它们位于我们的防火墙后面，我们只是将 tcp/443 流量传递给它们，就像我们原本传递 tcp/80 流量一样，并让设备根据需要铲取数据包。对于 SSL 卸载，它们非常高效，当 SSL 证书更换时，您只需在少数设备上进行更换，而不是在一堆服务器上进行更换。
答案2
看一下 xmpp 和一些可集群的免费服务器，可以扩展，更适合需要并发持久连接的 Web 应用程序。