服务器发送事件与 websockets？答案

【问题标题】：Server sent event vs web sockets?服务器发送事件与 websockets？
【发布时间】：2014-07-17 20:08:35
【问题描述】：

我正在开发一个网络应用程序，用户可以通过从智能手机到台式机的多个平台访问该应用程序，有时需要在两个客户端之间进行通信，例如，如果我希望我的朋友加入我的网络，我会向他发送一个朋友请求，但我希望我的朋友无需刷新页面即可看到该请求。

在这种情况下，哪个是更好的选择？而且因为我希望它可以在尽可能多的平台和浏览器上工作，而这些平台和浏览器支持更多的浏览器？有更好的选择吗？

【问题讨论】：

【解决方案1】：

做出此选择时要记住的一些事项。

尝试通过 WebSocket 连接获取内容是很糟糕的设计决策，因为 WebSockets 是嵌套的不同协议在 HTTP 连接中，它不能利用缓存（无论是浏览器或 CDN）。
一些较旧的代理不会通过 Websocket 连接，除非它隐藏在安全连接中，而服务器发送的事件仍然是一个 HTTP 连接，不会受到影响这。
原生 Android 不支持 WebSockets 和 SSE 浏览器直到 4.4（当他们切换到使用 Chrome 时） - 因此如果你正在考虑一个混合移动应用程序，你需要一个后备作为 SocketIO，在撰写本文时，4.4 仅占市场的 20% 和混合应用程序使用原生 Android 浏览器。
WebSockets 是最省电的移动设备协议，因为所有其他选项需要许多 HTTP 连接，并且是重复的协商将加重 cpu 负担并耗尽电池。

另一个选项可能是通知。现在，所有移动设备都支持可以针对应用程序的通知，许多浏览器也支持。在所有情况下，从客户端到消息中心（Apple、Google、Microsoft 等）的连接都已经存在，并且所有通知都通过此通道发送。

【讨论】：

我已经阅读了所有答案，您的答案似乎是最有帮助和最合乎逻辑的。谢谢:)
“所有其他选项都需要许多 HTTP 连接”。 SSE 不需要一个吗？
SSE 确实只需要一个连接来让客户端从服务器接收事件，但每次客户端需要更新服务器时都需要一个新连接。
HTTP KeepAlive 自 1.1 以来一直存在，这意味着大多数时候，不需要新的 TCP 连接。 Websocket/SSE 确实保存了标头（这可能非常重要）和往返（延迟的主要原因）。
“尝试通过 WebSocket 连接获取内容是一个糟糕的设计决策，因为 WebSockets 是嵌套在 HTTP 连接中的不同协议，它不能利用缓存（浏览器和 CDN 都没有）。”您可以自己实现缓存。我不会说这是一个糟糕的设计。在某些实时应用程序中不需要缓存，因为您总是希望看到最新的数据。

【解决方案2】：

服务器发送事件：仅用于发送文本消息的持久连接服务器 2 客户端，在除 Internet Explorer 之外的所有主要浏览器中实现。如果连接丢失，它可以自行重新连接。 http://caniuse.com/eventsource
WebSokets：能够传输 UTF8 文本和二进制数据的全双工持久连接。 http://caniuse.com/websockets

WebSocket 更好，还有未来。

【讨论】：

你的事实是正确的，但你的总结是不正确的。 “未来”应该是关于工作的正确工具。例如，由于 WebSockets 是嵌套在 HTTP 连接中的不同协议，它不能利用缓存代理 (C!DN)，某些代理不能正确处理它并且它不能利用
服务器可以发送事件吗？问题是关于 SSE 与 WS。您可能误读了 OP 的问题。
此评论是在我完成之前发布的，请在此处查看我的回答，了解做出此选择时要考虑的其他事项。

【解决方案3】：

据我了解，SSE 更简单、更易于实现，而 WebSocket 提供双向数据传输，但您需要了解它们自己的协议/API 才能利用。老实说，我从来没有真正为 SSE 烦恼过，Socket.IO 可以轻松完成我所需要的所有实时 Web 应用程序通信，并且可以跨浏览器构建。

如果您只是希望他能够看到通知，那么 SSE 应该没问题。如果您希望他能够从同一页面回复您的好友请求，然后让服务器向您发送他已被接受的通知，您可能希望使用 WebSockets 实现。

【讨论】：