设计/架构：web-socket 单连接 vs 多连接

Posted 2023-02-16

【中文标题】设计/架构：web-socket 单连接 vs 多连接

【英文标题】：Design/Architecture: web-socket one connection vs multiple connections

【发布时间】：2015-09-17 00:32:30

【问题描述】：

在设计客户端/服务器架构期间，将多个 WEBSOCKET 连接从同一进程多路复用到服务器（即共享一个连接）与在客户端中为每个线程/会话打开一个 WEBSOCKET 连接（如通常在连接到 memcached 或数据库服务器时完成。）

我知道与每个连接相关的开销（例如 RAM ...）。但预计每个客户端最多少于 1K-10K。

---

具体用例： 假设，我有一个远程服务器，一侧有多个会话，另一侧有多个客户端，每个客户端将通过 websocket 服务器连接到不同的会话。 在远程服务器中，有两种实现方式：（1）每个会话创建自己的 websocket 连接（2）所有会话将使用相同的 websocket 连接。

从连接的角度来看，我喜欢共享解决方案（一个 websocket 连接到所有会话），因为 websocket 服务器受到可用连接数的限制（节省服务器/缩放）。

但是从流量/数据速度/性能的角度来看，如果一个会话会通过连接发送很多小包，那么，如果我们使用一个共享连接，我们将无法利用带宽（有效负载.. ../collect几个小包为一个或将大包拆分为小包），因为我们可能需要从不同的会话向不同的客户端发送不同的包，在这种情况下，我们将无法收集几个包（小包）因为它们有不同的目的地和不同的来源！！，除非我们将创建“虚拟连接”来管理每个会话数据以最大限度地提高速度，但这会产生很多实现复杂性！！！

还有其他意见吗？

谢谢， JB.

【参考方案1】：

我认为您应该考虑使用有限的连接池，就像他们使用数据库连接架构一样。

我会考虑的另一个解决方案是 Pub/Sub 数据库中间人，例如 Redis。这使您可以使用现有的解决方案以及更轻松的可扩展性。

据我所知，使用单个连接和使用多个连接都有各自的问题。

例如，一个连接一次只能发送一条消息。足够大的消息可能会阻止连接...您在移动大数据吗？

许多连接可能会导致非常昂贵的开销，并会带来更多的错误机会。考虑以下几点：

创建新连接非常昂贵、占用带宽、遭受更长的网络延迟并且需要本地资源，而这正是 websockets 让我们能够避免的。

您将遇到可伸缩性问题。例如，Heroku 将每台服务器的 websocket 连接限制为 600 个，或者至少他们在不久前就这样做了（我认为这是合理的）......您将如何将所有服务器连接到一个数据存储区？

请记住，每个操作系统都有打开文件限制，并且 websocket 使用 IO 架构（每个都是“打开文件”，因此 websocket 是有限资源）。

关于流量/数据速度/性能，这是服务器架构的问题……但我相信您实际上会看到使用一个连接（或一小部分连接）会略微提高速度。重要的是要记住，当您需要发送 TCP/IP 数据包时，没有任何有效的多任务处理。

此外，在连接数量有限的情况下（即使只有一个连接），您将能够受益于操作系统的数据包连接功能，该功能允许您通过一个 TCP/IP 数据包发送多个 websocket 帧（除非您不断刷新 TCP/IP 套接字）。更多的连接实际上会浪费更多的带宽——甚至不考虑打开每个新连接所使用的带宽。

只要我的 5 美分，我敢肯定，我们都会有不同的想法。

祝你好运！

【讨论】：

感谢Myst，确实有很多问题需要考虑，解决方案是根据需求（更重要的是……）。

@Myst 你知道关于应该使用多少个 websocket 连接来仍然享受数据包连接和其他有限的连接优势，同时具有比 1 个连接更好的吞吐量的任何特定经验法则吗？例如 (# session)/3 之类的？

@JonathanLee - 计算应该类似于 TCP/IP 吞吐量，因为解析数据包的 CPU 开销相对于网络开销通常可以忽略不计。例如看到这个TCP/IP throughput calculator（有很多）。根据您的客户端和服务器 TCP/IP 缓冲区限制，在达到 13 Mbits/Sec（每秒仅 2MB）之前，您可能不需要另一个连接......它可能足以流式传输（压缩）全高清电影，但 4K 电影需要额外的服务器套接字缓冲区。