最近，我发现服务器发送事件是 WebSocket 的一种更简单的替代方案，用于从服务器进行推送。大多数比较它们的地方（例如here https://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource, here http://www.html5rocks.com/en/tutorials/eventsource/basics/ and here http://www.html5rocks.com/en/tutorials/casestudies/sunlight_streamcongress/）说如果客户端和服务器之间不需要全双工通信，那么 WebSockets 就有点过头了，SSE 就足够了。
我的问题是，当您确实需要双向通信（例如聊天）时，使用常规 ajax 请求从客户端发送消息并使用服务器流接收消息时，使用 SSE 的缺点是什么？考虑到我在服务器端几乎不需要做任何配置就可以使用 SSE，这似乎是一个更有吸引力的选择。
SSE 优点通过 WebSocket：
- 无需进行特殊的 Web 服务器或 Web 代理更改。
- 定义自定义事件（否则客户端API基本相同）
- 更轻松地集成现有身份验证机制（OAuth、OpenID 等）
SSE 缺点与 WebSocket 相比：
- 单向通信通道（服务器到客户端）。客户端到服务器需要单独的通道。
- 浏览器支持更加有限（没有本机 IE 支持，而 IE 10 支持 WebSockets）：WebSockets http://caniuse.com/#search=websockets, SSE http://caniuse.com/#search=eventsource
- 依赖客户端来验证来源（可能比 WebSocket 更容易受到 XSS 攻击）
- 没有对二进制类型的本机支持（WebSockets 支持使用 ArrayBuffers 和 Blob 的原始帧）。
- 即使 SSE 端点不提供静态 Web 内容，也需要成熟的 Web 服务器（独立的 WebSocket 服务器可能相当简单）
- 与使用 WebSocket 连接相比，使用 AJAX 进行双向通信的 SSE 具有更高的往返延迟和更高的客户端->服务器带宽。这是由于每个客户端->服务器 AJAX 请求的连接设置开销造成的。此外，SSE 的服务器->客户端延迟可能会出现峰值，因为在许多配置中，长期保持的连接最终将被关闭（通常每 30 秒一次）并且需要重新打开，从而导致服务器->客户端延迟出现临时峰值。
参考：
- http://www.html5rocks.com/en/tutorials/eventsource/basics/ http://www.html5rocks.com/en/tutorials/eventsource/basics/
- https://developer.mozilla.org/en-US/docs/Server-sent_events https://developer.mozilla.org/en-US/docs/Server-sent_events
- https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events
- http://dev.w3.org/html5/eventsource/ http://dev.w3.org/html5/eventsource/
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
