设计/架构:web-socket 单连接 vs 多连接 [英] Design/Architecture: web-socket one connection vs multiple connections

查看:17
本文介绍了设计/架构:web-socket 单连接 vs 多连接的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在设计客户端/服务器架构时,多路复用从同一进程到服务器的多个 WEBSOCKET 连接(即共享一个连接)与在客户端中的每个线程/会话打开一个 WEBSOCKET 连接(按原样)有什么优势?通常在连接到 memcached 或数据库服务器时完成.)

During a designing of a client/server architecture, is there any advantage to multiplexing multiple WEBSOCKET connections from the same process to the server (i.e. sharing one connection) vs opening one WEBSOCKET connection per thread/session in the client (as is typically done when connecting to memcached or database servers.)

我知道与每个连接相关的开销(例如 RAM ...).但预计每个客户端最多不到1K-10K.

I'm aware about the overhead associated with each connection (e.g. RAM ...). But expect to have less than 1K-10K at the most in each client side.

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

Specific use case: Lets assume, I have a remote server with multiple sessions on one side, and on the other side I have multiple clients, each client will connect to a different session through the websocket server. In the remote server, there are 2 ways to implement it: (1) each session create its own websocket connection (2) all sessions will use same websocket connection.

从连接的角度来看,我喜欢共享解决方案(一个 websocket 连接到所有会话),因为 websocket 服务器受到可用连接数的限制(保存服务器/缩放).

From connection point of view, I like the sharing solution (one websocket connection to all sessions), because websocket server is limited by #of connections available (saving servers/scaling).

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

But from traffic/data speed/performance point of view, if a sessions will send lots of small packages through the connection, then, if we use one sharing connection, we will not be able to utilize the bandwidth (payload..../collect few small packages into one or split big package into small packages), because we may have to send different packages to different clients from different sessions, in this case, we will not be able to collect few packages (small packages) since they have different destination and from different sources!!, unless we will create "virtual connection" that manage each session data to maximize the speed, but this would create much implementation complexity!!!

还有其他意见吗?

谢谢,JB.

推荐答案

我认为您应该考虑使用有限的连接池,就像他们对数据库连接架构所做的那样.

I think you should consider using a limited connection pool, like they do with Database connection architecture.

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

Another solution I would consider is a Pub/Sub database middleman such as Redis. This allows you to use existing solutions as well as easier scalability.

据我所知,使用单个连接和使用多个连接都有其问题.

To the best of my understanding, both having a single connection and using a multitude of connections have their issues.

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

For example, one connection can send only one message at a time. A big enough message could block the connection... are you moving big data?

许多连接可能会导致开销非常昂贵,并会增加出错的机会.考虑以下几点:

Many connections can cause an overhead that could be very expensive as well as introduce more chances for errors. Consider the following:

  1. 创建新连接非常昂贵,使用带宽,遭受更长的网络延迟并需要本地资源,而这正是 websockets 允许我们避免的.

  1. Creating new connections is very expensive, uses bandwidth, suffers from longer network delays and requires local resources and this is exactly what websockets allows us to avoid.

您会遇到可扩展性问题.例如,Heroku 将 websocket 连接限制为每台服务器 600 个,或者至少他们在不久之前这样做了(我认为这是合理的)......你将如何将所有服务器连接到一个数据存储?

You will run into scalability issues. For instance, Heroku limits websocket connections to 600 per server, or at least they did so a short while back (and I think it's reasonable)... How will you connect all the servers together to one data-store?

请记住,每个操作系统都有一个打开文件限制,并且 websocket 使用 IO 架构(每个操作系统都是一个打开文件",因此 websocket 是一种有限的资源).

Remember every OS has an open file limit and that websockets use the IO architecture (each one is an 'open-file', so that websockets are a limited resource).

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

Regarding traffic/data speed/performance, it is a question of server architecture... but I believe you will actually see a slight speed increase by using one connection (or a small pool of connections). It's important to remember that there isn't any effective multi-tasking when you need to send TCP/IP packets.

此外,通过有限数量的连接(即使只有一个连接),您将能够从操作系统的数据包加入功能中受益,该功能将允许您通过一个 TCP/IP 数据包发送多个 websocket 帧(除非您不断刷新 TCP/IP 套接字).您实际上会因更多连接而浪费更多带宽 - 甚至不考虑用于打开每个新连接的带宽.

Also, with a limited number of connections (even with one connection), you will be able to benefit from the OS's packet joining feature that will allow you to send a number of websocket frames over one TCP/IP packet (unless you constantly flush the TCP/IP socket). You will actually waste more bandwidth with more connections - even disregarding the bandwidth used to open each new connection.

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

Just my 5 cents, we will all think differently, I'm sure.

祝你好运!

这篇关于设计/架构:web-socket 单连接 vs 多连接的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆