服务器发送事件和浏览器限制

我有一个监听服务器发送事件的 Web 应用程序。当我在打开多个窗口的情况下进行工作和测试时，事情不起作用，我多次撞到头，朝错误的方向看：最终，我意识到问题出在并发连接上。

然而，我测试的数量非常有限，即使我在 Apache 上运行测试（我知道，我应该使用节点）。

然后，我切换浏览器并注意到一些非常有趣的事情：显然 Chrome 将服务器发送事件连接限制为 4-5，而 Opera 则没有。另一方面，Firefox 在 4-5 个同时连接后拒绝加载any其他页面。

这背后的原因是什么？该限制是否仅适用于来自同一源的 SSE 连接，或者如果我要测试从不同域打开它们，它是否会相同？我是否有可能滥用 SSE，这实际上会阻止浏览器，或者这是一种已知的行为？有什么办法解决吗？

这在所有浏览器中的工作方式是每个域获得有限数量的连接，并且限制对于整个应用程序是全局的。这意味着，如果您打开一个连接用于实时通信，那么您就少了一个用于加载图像、CSS 和其他页面的连接。最重要的是，您不会获得新选项卡或窗口的新连接，所有这些都需要共享相同数量的连接。这非常令人沮丧，但限制连接是有充分理由的。几年前，所有浏览器中的此限制均为 2（基于 (http://www.ietf.org/rfc/rfc2616.txt http://www.ietf.org/rfc/rfc2616.txt）HTTP1.1规范）但现在大多数浏览器一般使用4-10个连接。另一方面，移动浏览器仍然需要限制连接数量以节省电池电量。

这些技巧可用：

1. 使用更多主机名。通过分配前。www1.example.com, www2.example.com您将获得每个主机名的新连接。这个技巧适用于所有浏览器。不要忘记更改 cookie 域以包含整个域（example.com, not www.example.com)
2. 使用网络套接字。 Web 套接字不受这些限制的限制，更重要的是它们不会与网站的其他内容竞争。
3. 打开新选项卡/窗口时重复使用相同的连接。如果您已将所有实时通信逻辑收集到一个对象调用集线器，您可以在所有打开的窗口上调用该对象，如下所示：

window.hub = window.opener ? window.opener.hub || new Hub() 4. 或使用 flash - 如今这并不是最好的建议，但如果 websockets 不是一个选项，它可能仍然是一个选项。 5. 请记住在每个 SSE 请求之间添加几秒钟的时间，以便在开始新请求之前清除排队的请求。还要为用户不活动的每一秒增加一点等待时间，这样您就可以将服务器资源集中在那些活动的用户上。还添加随机数的延迟以避免雷群问题 http://en.wikipedia.org/wiki/Thundering_herd_problem

另一件需要记住的事情是，当使用多线程和阻塞语言（例如 Java 或 C#）时，您可能会在长轮询请求中使用应用程序其余部分所需的资源。例如，在 C# 中，每个请求都会锁定 Session 对象，这意味着在 SSE 请求处于活动状态期间整个应用程序没有响应。

NodeJs 非常适合这些事情，原因有很多，正如您已经了解的那样，如果您使用 NodeJS，您会使用 socket.io 或 engine.io，它们通过使用 websockets、flashsockets 和 XHR-polling 为您解决所有这些问题而且因为它是非阻塞和单线程的，这意味着当它等待发送内容时，它会消耗服务器上很少的资源。 C# 应用程序每个等待请求都会消耗一个线程，仅该线程就需要至少 2MB 的内存。