Engine.io 或 SockJS，选择哪一个？答案

【问题标题】：Engine.io or SockJS, which one to choose?Engine.io 或 SockJS，选择哪一个？
【发布时间】：2014-04-03 18:01:59
【问题描述】：

我最近在 Socket.io 上遇到了内存泄漏和扩展问题。一年多前我决定使用 Socket.io，当时它无疑是最好的库。

既然 Socket.io 引起了很多麻烦，我花时间寻找同时可用的替代方案，并认为 Engine.io 和 SockJS 通常都非常适合我。但是，在我看来，两者都有一些缺点，我不确定该选择哪一个。

Engine.io 基本上是 Socket.io 的完美轻量级版本，它不包含我不需要的所有功能。我已经为 Socket.io 编写了自己的重新连接和心跳逻辑，因为我对默认逻辑不满意，并且我从未打算使用 Socket.io 提供的房间或其他功能。

但是 - 在我看来 - Engine.io 的主要缺点是建立连接的方式。客户端从较慢的 jsonp-polling 开始，如果它们支持更好的传输，则会升级。与使用过时浏览器的客户端相比，原生支持 websockets 的客户端（数量稳步增加）的缺点是连接过程更长且不稳定，这与我对如何处理它的感觉相矛盾。

另一方面，SockJS 完全按照我的意愿处理连接。从我读到的内容来看，它似乎相当稳定，而 Engine.io 目前有一些问题。

我的应用程序在单个域上的 Nginx 路由器后面运行，因此我不需要 SockJS 提供的跨域功能。然而，由于提供了这个功能，SockJS 根本不会暴露客户端的 cookie 数据。到目前为止，我通过 cookie 和查询字符串令牌对 Socket.io 进行了 2 因素授权，而这对于 SockJS 是不可能的（对于 Engine.io 来说）。

我已经阅读了几乎所有可用的内容以及两者的优缺点，但到目前为止似乎没有太多讨论或发表，尤其是关于 Engine.io（只有 8 个问题标记为 engine.io在这里）。

您更喜欢这两个库中的哪一个？出于什么原因？你在生产中使用它们吗？
未来哪一个可能会得到更积极的维护，并且可能比另一个更有优势？

【问题讨论】：

engine.io 是对socket.io（均由LearnBoost 开发）和socket.io 1.0 的较低级别的“改造”，应该提供构建在顶部的更高级别的接口engine.io.
另见author's thoughts，了解他们的关系性质。
嗨 1nsane，只是想知道在 Socket.io 新版本发布后您的应用发生了什么以及您最后选择了什么。谢谢
顺便说一句，SockJS 有双重 JSON.stringify() 限制。我想知道它怎么能与 Engine.IO 相提并论。
这篇文章在将近 2 年后还有意义吗？

标签： websocket socket.io comparison sockjs engine.io

【解决方案1】：

你看过Primus吗？它提供了您提到的 cookie 要求，它支持所有可用的 major 'real-time'/websocket 库，并且是一个非常活跃的项目。在我看来，供应商锁定也可能是您担心的问题，Primus 会解决这个问题。

它使用 plugin system 的事实也应该 a) 让您在需要时更容易扩展，并且 b) 实际上可能有一个 community plugin 已经可以满足您的需求。

您更喜欢这两个库中的哪一个？出于什么原因？您在生产中使用它们吗？

我只通过 Vert.x API 使用过 SockJS，它是用于我认为是“生产”的内部项目，而不是面向生产的消费者应用程序。也就是说，它表现得非常好。

未来哪一个可能会得到更积极的维护，并且可能比另一个更有优势？

仅查看Engine.io 和SockJS 的提交历史，以及Autotomatic 支持Engine.io 的事实让我倾向于认为它会更稳定，更长的时间，但当然这是有争议的。查看Engine.io 和SockJS 的问题是另一个评估的好地方，但由于它们都被拆分为多个存储库，因此应该持保留态度。我不确定 Automattic 在哪里/如何使用 Engine/Socket.io，但如果它在 WordPress.com 或其插件之一中，它具有大量的大规模生产战斗测试。

编辑：更改答案以反映 Primus 作者在下面的 cmets 中确认的 cookie 支持

【讨论】：

作为 Primus 的作者，我可以确认 Primus 支持 cookie。我们已经绕过 SockJS 的标头限制，为我们的用户提供完整的标头访问权限。
@3rdEden 太棒了！感谢您的参与。我认为，仅此一点，Primus 就成为最佳选择，尤其是在这个问题的背景下。

【解决方案2】：

我想将您重定向到这个（非常详细的）关于 SockJS 和 Engine.io 的讨论帖

https://groups.google.com/forum/#!topic/sockjs/WSIdcY14ciI

基本上，

SockJS 在标记连接之前检测工作传输作为开放。 Engine.io 将立即打开连接并升级

flash，Engine.io 的后备之一（并且 在 SockJS 中不存在）在环境中加载缓慢代理后面需要 3 秒超时。

SockJS 不使用 flash，因此不需要解决这个问题。

SockJS 在启动时进行升级。之后你有一致的体验。你发送你发送的，你收到你收到什么。

另外，据我所知，engine.io 的 engine.io-client（客户端）库不支持 requirejs 构建，所以这是另一个负面因素。（SockJS 确实可以完美构建）。

【讨论】：

仅供参考：Engine.IO 不再使用闪存作为后备。
是的，我认为它已被删除...我在文档中没有遇到它。

【解决方案3】：

您也可以考虑node-walve。完成 WebSocket 基础。完全基于流的性能非常好。

使用示例：

walve.createServer(function(wsocket) {
  wsocket.on('incoming', function(incoming) {
    incoming.pipe(process.stdout, { end: false });
  });
}).listen(server);

如果您在 nodejs 环境中感到不安全（例如扩展 API 糖的原型），它可能不是最佳选择，为项目做出贡献（尽管代码作为 socket.io 更具可读性）。

【讨论】：

感谢您的回复。但我认为这并不是我想要的，因为如果客户端不支持 websocket，它似乎没有后备。