有几个原因可以解释为什么你想这么做，但它们可能不太常见（至少现在还不常见）：

• 您发送/接收的数据既有加密的，也有未加密的（例如一些数据是庞大的但不敏感）。
• 您同时拥有流数据和延迟敏感型数据：设想一个交互式游戏，偶尔在游戏内具有流视频。您不希望大型媒体流延迟对延迟敏感的正常游戏消息的接收。
• 您既有文本（例如JSON控制消息）和二进制数据（类型化数组或二进制大对象），并且不想添加自己的协议层来区分，因为WebSockets已经为您做了这些。
• 您有多个支持的WebSocket子协议（URI后面的可选设置），并且页面希望访问多个协议（每个WebSocket连接仅限于一个子协议）。
• 您有几个不同的WebSocket服务位于同一个Web服务器和端口后面。客户端为每个连接选择的方式可能取决于URI路径、URI方案（ws或wss）、子协议，甚至可能取决于从客户端到服务器的第一条消息。

我肯定还有其他的原因，但这就是我能想到的全部。

我发现，当您只订阅由服务器管理的某些对象的更新时，它可以使客户端逻辑简单得多。您可以只为每个元素打开一个套接字，而不是为单个通道设计一个自定义订阅协议。
假设您通过REST API在

http://myserver/api/some-elements

字符串
你可以使用一个socket url订阅单个元素的更新，如下所示：

ws://myserver/api/some-elements/42/updates

型
当然，人们可以争辩说，这不适合复杂的页面。然而，对于小型和简单的应用程序，它可能会使您的生活变得更加轻松。

除了什么kanaka said，可能还有另一个问题。例如，您的APP是这样配置的：每隔30秒，WebSocket网络就有一次乒乓，服务器根据它来确定是否有来自客户端的响应。您开始通过WebSocket上传大量数据，例如1Gb，这可能需要几分钟，具体取决于互联网连接速度。服务器发送一个ping，客户端接收到它并发送一个pong，但是WebSocket通道已经忙碌传输数据。服务器未收到pong并重置连接。数据传输中断。
因此，根据其功能分离WebSocket通道是有意义的。一个应该用于客户端信令和系统数据，例如，已经上传到服务器的量，另一个专门用于传输大数据。