Linux 机器可以有多少个打开的 udp 或 tcp/ip 连接?

发布于 2024-08-10 14:21:15 字数 302 浏览 11 评论 0原文

可用内存、带宽、CPU,当然还有网络连接都受到限制。但这些通常可以垂直缩放。 Linux 上还有其他限制因素吗?可以在不修改内核的情况下克服它们吗?我怀疑,如果不出意外的话,限制因素将成为千兆以太网。但对于高效的协议来说,可能需要 50K 并发连接才能解决这个问题。在我达到那么高之前,还会有什么东西坏掉吗?

我想我需要一个软件 udp 和/或 tcp/ip 负载平衡器。不幸的是,除了 http 协议之外,开源社区中似乎不存在类似的东西。不过用epoll写一个也不超出我的能力。我预计它会经过大量的调整才能达到规模,但这是可以逐步完成的工作,而且我会成为一名更好的程序员。

There are limits imposed by available memory, bandwidth, CPU, and of course, the network connectivity. But those can often be scaled vertically. Are there any other limiting factors on linux? Can they be overcome without kernel modifications? I suspect that, if nothing else, the limiting factor would become the gigabit ethernet. But for efficient protocols it could take 50K concurrent connections to swamp that. Would something else break before I could get that high?

I'm thinking that I want a software udp and/or tcp/ip load balancer. Unfortunately nothing like that in the open-source community seems to exist, except for the http protocol. But it is not beyond my abilities to write one using epoll. I expect it would go through a lot of tweaking to get it to scale, but that's work that can be done incrementally, and I would be a better programmer for it.

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

亚希 2024-08-17 14:21:15

您可能会遇到一些困难的一个参数是抖动。如果您扩展每个盒子的连接数量,无疑会给该系统的所有资源带来压力。因此,转发功能的抖动特性可能会受到影响。

根据您的目标要求,这可能是也可能不是问题:如果您计划主要支持弹性流量(不会受到抖动延迟影响的流量)然后就可以了。如果非弹性流量的比例很高(例如交互式语音/视频),那么这可能会成为一个更大的问题。

当然,在这种情况下你总是可以过度设计;-)

The one parameter you will probably have some difficulty with is jitter. Has you scale the number of connections per box, you will undoubtedly put strain on all the resources of the said system. As a result, the jitter characteristics of the forwarding function will likely suffer.

Depending on your target requirements, that might or not be an issue: if you plan to support mainly elastic traffic (traffic which does not suffer much from jitter and latency) then it's ok. If the proportion of inelastic traffic is high (e.g. interactive voice/video), then this might be more of an issue.

Of course you can always over engineer in this case ;-)

-小熊_ 2024-08-17 14:21:15

如果您打算拥有一台为每个客户端打开一个套接字的服务器,那么需要仔细设计它,以便它可以有效地检查来自 10k 以上客户端的传入数据。这就是所谓的 10k 问题。

现代 Linux 内核可以处理超过 10k 个连接,通常至少 100k。您可能需要一些调整,特别是许多 TCP 超时(如果使用 TCP),以避免在大量客户端频繁连接和断开连接时关闭/过时的套接字占用大量资源。

如果您使用 netfilter 的 conntrack 模块,可能还需要调整以跟踪许多连接(这与 tcp/udp 套接字无关)。

用于负载均衡的技术有很多,最著名的是LVS(Linux虚拟服务器),它可以充当真实服务器集群的前端。我不知道它可以处理多少个连接,但我认为我们在生产中至少使用它 50k。

If you intend to have a server which holds one socket open per client, then it needs to be designed carefully so that it can efficiently check for incoming data from 10k+ clients. This is known as the 10k problem.

Modern Linux kernels can handle a lot more than 10k connections, generally at least 100k. You may need some tuning, particularly the many TCP timeouts (if using TCP) to avoid closing / stale sockets using up lots of resource if a lot of clients connect and disconnect frequently.

If you are using netfilter's conntrack module, that may also need tuning to track that many connections (this is independent of tcp/udp sockets).

There are lots of technologies for load balancing, the most well-known is LVS (Linux Virtual Server) which can act as the front end to a cluster of a real servers. I don't know how many connections it can handle, but I think we use it with at least 50k in production.

一抹淡然 2024-08-17 14:21:15

对于你的问题,你只受到硬件限制的限制。这就是linux系统的设计理念。您准确地描述了您的限制因素是什么。

To your question, you are only restrained by hardware limitations. This was the design philosophy for linux systems. You are describe exactly what would be your limiting factors.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文