从同一客户端到同一服务器有两个不同的websocket连接有什么好处吗？对我来说，这似乎是一个糟糕的设计选择，但有什么理由让它变得更好吗？
您可能想要这样做有几个原因，但它们可能并不太常见（至少目前还不常见）：
- 您发送/接收的数据既有加密数据，也有未加密数据（例如，有些数据庞大但不敏感）
- 你既有流媒体数据，也有对延迟敏感的数据：想象一个互动游戏，偶尔会在游戏中播放流媒体视频。您不希望大型媒体流延迟接收对延迟敏感的正常游戏消息
- 您既有文本数据（例如JSON控制消息），也有二进制数据（类型化的数组或Blob），不想麻烦添加自己的协议层来区分，因为WebSockets已经为您做到了这一点
- 您有多个支持的WebSocket子协议（URI后面的可选设置），并且页面希望访问多个（每个WebSocket连接仅限于一个子协议）
- 在同一个web服务器和端口后面有几个不同的WebSocket服务。客户端选择每个连接的方式可能取决于URI路径、URI方案（ws或wss）、子协议，甚至可能是从客户端到服务器的第一条消息
我相信还有其他原因，但这就是我脑海中所能想到的。
我发现，当您只订阅服务器管理的某些对象的更新时，它可以使客户端逻辑变得更简单。您可以为每个元素打开一个套接字，而不是为单个通道设计自定义订阅协议。
假设您通过的REST API获得了一组元素
http://myserver/api/some-elements
您可以使用如下的套接字url订阅单个元素的更新：
ws://myserver/api/some-elements/42/updates
当然，有人会争辩说，这不适合复杂的页面。然而，对于小而简单的应用程序，它可能会让你的生活轻松很多。
除了卡纳卡所说的，可能还有另一个问题。例如，您的应用程序是这样配置的：每30秒就会有一次WebSocket网络的乒乓球，服务器根据乒乓球确定是否有来自客户端的响应。您开始通过WebSocket上传大量数据，例如1Gb，这可能需要几分钟的时间，具体取决于互联网连接速度。服务器发送ping，客户端接收并发送pong，但是WebSocket通道已经忙于传输数据。服务器没有接收到乒乓球并重置连接。数据传输中断。
因此，根据WebSocket通道的功能来分离它们是有意义的。一个应该用于客户端信令和系统数据，例如，有多少已经上传到服务器，另一个专门用于传输大数据。