服务器端事件+客户端事件vs Websocket。

I am updating an old system that used to use an ajax polling mechanism. The script would periodically call the back-end looking for updates, and rarely the user would make an ajax request to send data. I first wanted to use Web Sockets because I could instantly get the data from push events, and because the connection stays open. I then read about Server Side Events, and how it is one directional. This fits exactly what I need because the browser is just waiting for events. However, there are rare cases when the user can send data. Is there an alternative to Server Side Events, where I can keep a connection open to send data back to the server? Is it better to use SSE + AJAX, SSE + (Alternative Way), or just a web socket (Even though data is rarely sent back to server)?

我正在更新一个以前使用ajax轮询机制的旧系统。脚本会定期调用后端来查找更新，用户很少会发出ajax请求来发送数据。我最初想要使用Web Sockets，因为我可以立即从push事件中获得数据，而且因为连接仍然是打开的。然后我阅读了服务器端事件，以及它是如何单向的。这正是我需要的，因为浏览器只是在等待事件。但是，用户可以发送数据的情况很少。是否有服务器端事件的替代方案，在那里我可以打开一个连接将数据发送回服务器?使用SSE + AJAX、SSE +(替代方式)还是只使用web套接字(即使数据很少被发送回服务器)更好?

Thank you

谢谢你！

2 个解决方案

#1

This is the best explanation for SSE and its flexibilty

这是对SSE及其灵活性的最好解释

Server-Sent Events vs. WebSockets

Why would you choose Server-Sent Events over WebSockets? Good question.

为什么要选择服务器发送的事件而不是WebSockets?好问题。

One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn't need to be sent from the client. You simply need updates from some server action. A few examples would be friends' status updates, stock tickers, news feeds, or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store). If you'll need to send data to a server, XMLHttpRequest is always a friend.

之所以一直隐藏SSEs，原因之一是后来的api如WebSockets提供了更丰富的协议来执行双向、全双工通信。有一个双向通道对于游戏、消息应用程序和需要在两个方向上进行实时更新的情况更有吸引力。但是，在某些情况下，不需要从客户端发送数据。您只需要从某些服务器操作中进行更新。一些例子可能是好友的状态更新、股票报价、新闻提要或其他自动数据推送机制(例如更新客户端Web SQL数据库或IndexedDB对象存储)。如果您需要向服务器发送数据，XMLHttpRequest始终是您的朋友。

SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.

SSEs是通过传统HTTP发送的。这意味着它们不需要特殊的协议或服务器实现来工作。另一方面，WebSockets需要全双工连接和新的WebSocket服务器来处理协议。此外，服务器发送的事件有许多WebSockets缺乏的特性，例如自动重连接、事件id和发送任意事件的能力。

I had built a chat application using sse and ajax for my site.I would suggest sse + ajax would be way to go if there is only stream updates and very few updates from client to server for that you can use the ajax part

我已经为我的站点构建了一个使用sse和ajax的聊天应用程序。如果只有流更新和很少的从客户端到服务器的更新，您可以使用ajax部分，我建议使用sse + ajax

Only problem that I found is its lack of support across browsers .And if you want to know more in depth about sse ask specifically what you want

我发现的唯一问题是它缺乏跨浏览器的支持

Browser Support List

浏览器支持列表

#2

As you usage is mostly server pushing to client, I would recommend a combination of Server-Sent events for the push from server to client and AJAX for the other way around.

由于您的使用主要是服务器向客户端推送，所以我建议将服务器发送的事件组合在一起，以便从服务器向客户端推送，而AJAX则相反。

You should definitely read this article to get to a decision:

你一定要读这篇文章才能做出决定:

http://streamdata.io/blog/push-sse-vs-websockets/

http://streamdata.io/blog/push-sse-vs-websockets/

This will give you pros and cons of using Server-Sent events versus WebSocket.

这将为您提供使用服务器发送事件与WebSocket的优缺点。