从socket.io移动到原始WebSocket？

现在我使用socket.io和强制WebSocket作为传输。我正在考虑迁移到原始WebSocket，但我不清楚离开socket.io会失去哪些功能。谢谢你的指导

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

如果浏览器不支持webSocket或如果网络路径具有阻止webSocket的代理/防火墙，则自动选择长轮询与webSocket

如果连接中断，则自动重新连接客户端（即使服务器重新启动）

自动检测失效连接（通过使用常规ping来检测失效连接）

具有与JSON自动转换的消息传递方案

服务器端的房间概念，在这里可以方便地与一组连接的用户进行通信

连接到服务器上的名称空间而不仅仅是连接到服务器的概念。这可以用于各种不同的功能，但我使用它来告诉服务器我想要订阅什么类型的信息。这就像连接到一个特定的频道

服务器端数据结构，自动跟踪所有连接的客户端，以便您可以随时枚举它们

内置于socket.io库中的中间件体系结构，可用于实现身份验证等功能，并从原始连接访问cookie

自动存储首次连接时连接上存在的Cookie和其他标头（对于识别连接的用户非常有用）

服务器端广播功能，用于向所有连接的客户端、房间中的所有客户端或命名空间中的所有客户端发送公共消息

使用消息名称标记每条消息，并将消息名称路由到eventEmitter，以便通过侦听eventEmitter上所需的消息名称来侦听传入消息

---

为什么你想转向普通的WebSocket？虽然这是一个离题的话题，并且引发了基于观点的讨论，但我还是投票支持它。。。我希望你能得到一个好的技术答案，并希望更多的人了解平台之间的（巨大）差异。中间件和cookie不仅仅是socket.io功能，它们是常见的框架功能，可能在其他框架上也可用。。。此外，它与websocket层几乎没有关系（如果有的话），而与http层关系更大。我建议把它们从名单上删除。话虽如此，回答得很好。。。尽管我想了解一些技术细节，第一。这是错误的

socket.io

不执行回退到长轮询。它实际上执行到WebSocket的慢速连接，因此它总是使用XHR启动。@如果浏览器不支持WebSocket，Myst-socket.io绝对支持长轮询。而且，您可能希望了解所有webSocket连接都是从一个常规HTTP请求开始的（其中设置了一些自定义头）。有关更多信息，请参阅。事实上，除了webSocket之外，socket.io还支持多种传输。长轮询就是其中之一。@Myst-中间件和cookie点是服务器端socket.io库的功能。如果您使用socket.io，则会自动包含它们。它们不是任何webSocket规范的一部分，因此要获得等效规范，您必须找到一个包含它们的webSocket库。对我来说，它们是使用socket.io而不是简单的标准webSocket的好处的一部分，这正是这个问题的目的。@jfriend00我知道。我用C编写了一个websocket服务器。socket.io总是以长轮询开始。它会在稍后阶段升级到WebSocket的连接，因此它不是一种退路。长轮询是默认值。此外，由于所有websocket连接都是从HTTP开始的，所以中间件和cookie不是socket.io特定的。