当前位置：文江博客话题详情

多个 websocket 连接

发布于 2025-01-04 18:17:10 字数 85 浏览 1 评论 0原文

从同一个客户端到同一服务器有两个不同的 websocket 连接有什么优点吗？对我来说，这似乎是一个糟糕的设计选择，但是有什么理由/地方它应该表现得更好吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

在你怀里撒娇 2025-01-11 18:17:10

您可能想要这样做的原因有多种，但它们可能不太常见（至少目前还不是）：

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

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

回复收藏 0 原文

再浓的妆也掩不了殇 2025-01-11 18:17:10

我发现当您仅订阅服务器管理的某些对象的更新时，它可以使客户端逻辑变得更加简单。您无需为单个通道设计自定义订阅协议，只需为每个元素打开一个套接字即可。

假设您通过 REST API 获得了元素集合，

http://myserver/api/some-elements

您可以使用如下所示的套接字 url 来订阅单个元素的更新：

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

当然，有人可能会认为这不适用于复杂页面。然而，对于小型和简单的应用程序来说，它可能会让您的生活变得更加轻松。

I found that it can make client logic much simpler when you are only subscribing to updates of certain objects being managed by the server. Instead of devising a custom subscription protocol for a single channel, you can just open a socket for each element.

Let's say you obtained a collection of elements via a REST API at

http://myserver/api/some-elements

You could subscribe to updates of a single element using a socket url like this:

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

Of course one can argue that this doesn't scale for complex pages. However, for small and simple appications it might make your life a lot easier.

回复收藏 0 原文

雨后咖啡店 2025-01-11 18:17:10

除了kanaka说的之外，可能还有另一个问题。比如你的APP是这样配置的：每30秒WebSocket网络进行一次乒乓，服务器根据乒乓来判断是否有客户端的响应。您开始通过 WebSocket 上传大量数据，例如 1Gb，这可能需要几分钟，具体取决于互联网连接速度。服务器发送 ping，客户端接收并发送 pong，但 WebSocket 通道已经忙于传输数据。服务器未收到 pong 并重置连接。数据传输中断。

因此，根据功能分离 WebSocket 通道是有意义的。一种应该用于客户端信令和系统数据，例如 - 已经上传了多少数据到服务器，另一种专门用于传输大数据。

回复收藏 0 原文