维护和操作Socket.IO
如上所述，Socket.IO上手相对简单——你只需要用一个Node.js服务器来运行它。如果是一小部分用户想开始使用一种实时应用，Socket.IO是一个不错的选择。但是它会在大规模使用时出现问题。比如说，你想要构建一个类似CRM的应用程序来构建企业之间的通信。 Socket.IO会搭建在异步网络库上，导致服务器负载。因为维护与用户的连接以及发送、接收消息也会增加Socket.IO的压力，并且如果客户端开始通过Socket.IO发送大量数据，它会以块的形式进行传输。但是在传输数据块时可能会丢失资源。因此，当你的应用程序吸引了更多用户，使服务器达到其最大负载时，你需要在多个服务器上拆分连接，否则可能会丢失重要信息。
但是这并不像添加一个服务器那么简单。套接字是一种服务器和客户端之间的开放连接。服务器只识别与其直接连接的客户端，而不知道连接到其他服务器的客户端。对于上述的会话功能，假设你想要向此应用的所有用户广播一则消息，即有人加入群聊。如果用户们连接到了不同的服务器，他们不会收到这条消息的。
要解决这个问题，你需要有一个pub / sub 商店（比如Redis）。该商店将通过在有人加入群聊时通知所有服务器发送消息来解决前文问题。但是这意味着你要维护一个有自己服务器的数据库。
Socket.IO创建了一个适配器socket.io-adapter，它与pub / sub存储和服务器共享信息。你可以编写自己的适配器版本，也可以使用他们为Redis提供的版本。Socket.IO很容易与其搭配。
Socket.IO的其他适配器包括CoreOS，它可将结构分解为在可用硬件上分布的单元，并且在负载增加时引入新实例。
扩展Socket.IO的另一个问题是，当WebSockets保持其连接打开时，如果连接退回到轮询，那么在连接存活期间会出现多个请求。当其中一个请求转到另一个服务器时，你将收到 “Error during WebSocket handshake: Unexpected response code: 400”这样的错误信息。
主要有两种解决上述问题的方法：一是根据初始地址路由客户端；二是根据cookie路由客户端。 Socket.IO有文件具体说明了如何在不同的环境中解决这个问题。
虽然Socket.IO提供详实的说明来解决其局限性，但这些说明通常被视为“补救措施”而不是解决方案。如果您打算扩大规模，那么这些建议最终会使您的扩展变得复杂且更易出错。
Socket.IO何时达到极限？
与所有技术一样，选择正确的技术意味着你明确自己对产品的期待。与自己设置套接字相比，Socket.IO确实使许多操作变得更容易，但除了上面提到的扩展问题之外，Socket.IO还存在一些限制和缺点。
首先，与WebSocket相比，Socket.IO初始连接时间更长。这是因为它首次建立连接时使用了长轮询和xhr轮询，然后升级到WebSockets（如果可用的话）。
如果你不需要支持旧浏览器且不担心不支持WebSockets的客户端环境，那就不需要增加Socket.IO的开销。你可以通过指定仅连接WebSockets来减少开支。这将更改与WebSocket的初始连接，但同时删除了所有后退操作。
客户端
服务器
在这种情况下，客户端仍然需要下载61.2 KB 的socket.io JavaScript文件。点击此处查看更多信息。
对于根据定义流式传输的数据，比如视频流，套接字不能解决问题。如果你想支持此级别的数据交换，更好的解决方案是使用webRTC或数据流作为服务提供商。
原文地址：https://www.ably.io/concepts/socketio
原文作者：Glyn Lewington
