服务器发送的事件与轮询 [英] Server-Sent Events vs Polling
问题描述
在在性能，浏览器实现可用性，服务器负载等方面存在很大差异HTML5 SSE 和直接的Ajax轮询？从服务器端看，似乎 EventSource 只是每隔约3秒左右点击指定的页面（虽然我知道时间是灵活的）。
当然，在客户端设置比设置计时器要简单很多，并且它的 $。get 每隔一段时间，但还有其他事情吗？它会发送更少的头文件，还是执行其他一些我不知道的魔法？解决方案
Ajax轮询会增加很多HTTP开销，它不断建立和拆除HTTP连接。正如 HTML5 Rocks 将其放在Server-Sent Events on other从一开始就设计得很高效。
服务器发送的事件打开一个长期存在的HTTP连接。然后，服务器在发送数据时单向发送数据，不需要客户端请求它或做任何事情，只是等待消息。
服务器发送的一个缺点事件是因为他们创建了一个到服务器的持久连接，所以你可能有很多开放的连接到你的服务器。某些服务器比其他服务器更好地处理大量并发连接。也就是说，你会有类似的轮询问题加上不断重建这些连接的开销。
服务器发送的事件非常好，当然是IE的明显例外。但是 polyfills （以及一个 jQuery插件）将解决这个问题。
如果您正在做一些只需要单向通信的事情，我肯定会选择服务器发送的事件。正如你所提到的，服务器发送的事件往往更简单，更清晰，可以在客户端实现。您只需要为消息和事件设置侦听器，并且浏览器会处理低级别的事情，如断开连接时重新连接等。在服务器端，由于它只使用简单的文本，因此实现起来也相当容易。如果您发送JSON编码对象，您可以通过 JSON.parse（） 。
如果您在服务器上使用PHP， json_encode（） 将字符串，数字，数组和对象转换为正确编码的JSON。其他后端语言也可能提供类似的功能。
Is there a big difference (in terms of performance, browser implementation availability, server load etc) between HTML5 SSEs and straight up Ajax polling? From the server side, it seems like an EventSource is just hitting the specified page every ~3 seconds or so (though I understand the timing is flexible).
Granted, it's simpler to set up on the client side than setting up a timer and having it $.get every so often, but is there anything else? Does it send fewer headers, or do some other magic I'm missing?
Ajax polling adds a lot of HTTP overhead since it is constantly establishing and tearing down HTTP connections. As HTML5 Rocks puts it "Server-Sent Events on the other hand, have been designed from the ground up to be efficient."
Server-sent events open a single long-lived HTTP connection. The server then unidirectionally sends data when it has it, there is no need for the client to request it or do anything but wait for messages.
One downside to Server-sent events is that since they create a persistent connection to the server you could potentially have many open connections to your server. Some servers handle massive numbers of concurrent connections better than others. That said, you would have similar problems with polling plus the overhead of constantly reestablishing those connections.
Server-sent events are quite well supported in most browsers, the notable exception of course being IE. But there are a couple of polyfills (and a jQuery plugin) that will fix that.
If you are doing something that only needs one-way communication, I would definitely go with Server-sent events. As you mentioned Server-sent events tend to be simpler and cleaner to implement on the client-side. You just need to set up listeners for messages and events and the browser takes care of low-level stuff like reconnecting if disconnected, etc. On the server-side it is also fairly easy to implement since it just uses simple text. If you send JSON encoded objects you can easily turn them into JavaScript objects on the client via JSON.parse().
If you are using PHP on the server you can use json_encode() to turn strings, numbers, arrays and objects into properly encoded JSON. Other back-end languages may also provide similar functions.
这篇关于服务器发送的事件与轮询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
