从 socket.io 迁移到原始 websockets？答案

【问题标题】：Moving from socket.io to raw websockets?从 socket.io 迁移到原始 websockets？
【发布时间】：2016-11-27 12:58:57
【问题描述】：

现在我正在使用带有强制 websockets 作为传输的 socket.io。我正在考虑迁移到原始 websockets，但我不清楚从 socket.io 中我将失去哪些功能。感谢您的任何指导。

【问题讨论】：

为什么要迁移到普通的 webSockets？
虽然这是题外话，并引发了基于意见的讨论，但我还是投了赞成票……我希望你能得到一个好的技术答案，让更多的人了解 (巨大的）平台之间的差异。

标签： websocket socket.io

【解决方案1】：

socket.io 库在标准 webSockets 之外添加了以下功能：

如果浏览器不支持 webSockets 或网络路径具有阻止 webSockets 的代理/防火墙，则自动选择长轮询与 webSocket。
如果连接断开，客户端会自动重新连接（即使服务器重新启动）。
自动检测死连接（通过使用常规 ping 检测无效连接）
具有与 JSON 的自动转换的消息传递方案。
房间的服务器端概念，可以轻松与一组连接的用户进行交流。
连接到服务器上的命名空间而不是仅仅连接到服务器的概念。这可以用于各种不同的功能，但我用它来告诉服务器我想要订阅哪些类型的信息。这就像连接到特定频道。
自动跟踪所有已连接客户端的服务器端数据结构，以便您随时枚举它们。
socket.io 库中内置的中间件架构，可用于实现身份验证等功能，从原始连接访问 cookie。
在首次连接时自动存储连接上的 cookie 和其他标头（对于识别连接的用户非常有用）。
服务器端广播功能，可向所有连接的客户端、房间中的所有客户端或命名空间中的所有客户端发送公共消息。
使用消息名称标记每条消息并将消息名称路由到 eventEmitter，这样您就可以通过侦听所需消息名称的 eventEmitter 来侦听传入消息。

【讨论】：

中间件和 Cookie 不仅仅是 socket.io 的功能，它们是常见的框架功能，可能也可以在其他框架上使用......此外，它几乎没有（如果有的话） websocket 层和更多与 http 层有关。我建议将它们从列表中删除。话虽如此，很好的答案......虽然我喜欢一些东西的更多技术细节。
数字 1. 是错误的。 socket.io 不会回退到长轮询。它实际上执行到 Websockets 的慢速连接，所以它总是从使用 XHR 开始。
@Myst - 如果浏览器不支持 webSockets，socket.io 绝对支持长轮询。而且，您可能想了解所有 webSocket 连接都以常规 HTTP 请求开始（其中设置了一些自定义标头）。请参阅stackoverflow.com/questions/31282578/… 了解更多信息。事实上，socket.io 支持除了 webSocket 之外的多种传输方式。长轮询就是其中之一。
@Myst - 中间件和 cookie 点是服务器端 socket.io 库的功能。如果您使用 socket.io，它们会自动包含在内。它们不是任何 webSocket 规范的一部分，因此要获得等价物，您必须找到一个也包含它们的 webSocket 库。对我来说，它们是使用 socket.io 而不是普通标准 webSocket 的好处的一部分，这就是这个问题的意义所在。
@jfriend00 我知道。我用 C 编写了一个 websocket 服务器。socket.io 总是以长轮询开始。它会在稍后阶段升级到 websockets 的连接，所以它不是一个后备。长轮询是默认设置。此外，由于所有 websocket 连接都以 HTTP 开头，中间件和 cookie 不是 socket.io 特定的。