服务器发送的事件与轮询

Question

在HTML5 SSEs和直接Ajax轮询之间是否存在很大差异（在性能，浏览器实现可用性，服务器负载等方面）？从服务器端看，似乎EventSource每隔约3秒左右才会到达指定的页面（虽然我知道时间很灵活）。

当然，在客户端设置比设置计时器并且经常使用$.get更简单，但还有其他什么吗？它会发送更少的标题，还是做其他一些我不知道的魔法？

Answer 1

Ajax轮询增加了大量的HTTP开销，因为它不断建立和拆除HTTP连接。由于HTML5 Rocks将“服务器发送事件放在另一方面，因此从头开始设计为高效。”

服务器发送的事件打开一个长期存在的HTTP连接。然后，服务器在有数据的情况下单向发送数据，客户端无需请求数据或执行任何操作，只需等待消息。

服务器发送事件的一个缺点是，由于它们与服务器建立了持久连接，因此您可能与服务器建立了许多打开的连接。有些服务器handle massive numbers of concurrent connections better比其他服务器多。也就是说，你会遇到类似的轮询问题以及不断重新建立连接的开销。

服务器发送的事件非常好supported in most browsers，当然是IE的明显例外。但有一个couple polyfills（以及jQuery plugin）可以解决这个问题。

如果您正在做一些只需要单向通信的事情，我肯定会选择服务器发送的事件。正如您所提到的，在客户端执行服务器发送的事件往往更简单，更清晰。你只需要设置消息和事件的监听器，浏览器就会处理低级别的东西，比如重新连接，如果断开连接等等。在服务器端，它也很容易实现，因为它只使用简单的文本。如果您发送JSON编码对象，则可以通过JSON.parse()轻松将它们转换为客户端上的JavaScript对象。

如果您在服务器上使用PHP，则可以使用json_encode()将字符串，数字，数组和对象转换为正确编码的JSON。其他后端语言也可能提供类似的功能。

Answer 2

我只会对所说的内容添加更高的视角，那就是SSE是发布 - 订阅模型，而不是AJAX的常规轮询。

通常，两种方式（轮询和发布 - 订阅）都试图解决如何在客户端上维护最新状态的问题。

1）轮询模型

很简单。客户端（浏览器）首先获得初始状态（页面）并且要进行更新，它需要定期请求状态（页面或其部分）并将结果处理为当前状态（刷新整个页面或将其呈现在其中部分适用于AJAX）。

当然，一个缺点是如果服务器状态没有发生，则不必要地使用资源（CPU，网络......）。另一个是，即使状态发生变化，客户端也只能在下一个轮询期间获得它，而不是尽快。人们经常需要评估这两件事之间的良好时期妥协。

轮询的另一个例子是线程中的spinwait。

2）发布 - 订阅模型

它的工作原理如下：

• （客户首先请求并显示一些初始状态）
• 客户端订阅服务器（发送一个请求，可能带有一些上下文，如事件源）
• server将对客户端的引用标记为某个客户端引用存储库
• 在更新状态的情况下，服务器根据对其拥有的客户端的引用向客户端发送通知;即，它不是对请求的响应，而是由服务器发起的消息
• 好客户在对通知不感兴趣时​​取消订阅

这是SSE，或者在线程中进行等待事件，作为另一个例子。 如上所述，一个自然的缺点是服务器必须知道所有订阅的客户端，这取决于实现，可能是一个问题。