可用内存、带宽、CPU，当然还有网络连接都存在限制。但这些通常可以垂直缩放。linux上还有其他限制因素吗？可以在不修改内核的情况下克服它们吗？我怀疑，如果不出意外，限制因素将成为千兆以太网。但是对于高效的协议，它可能需要 50K 并发连接才能淹没它。在我达到那么高之前会不会有其他东西破裂？
我在想我想要一个软件 udp 和/或 tcp/ip 负载平衡器。不幸的是，除了 http 协议之外，开源社区中似乎不存在类似的东西。但是使用 epoll 编写一个并不超出我的能力范围。我希望它会经过大量调整以使其规模化，但这是可以逐步完成的工作，我会成为一个更好的程序员。
您可能会遇到一些困难的一个参数是jitter。你是否扩展了每个盒子的连接数，你无疑会给所述系统的所有资源带来压力。结果，转发功能的抖动特性可能会受到影响。
根据您的目标要求，这可能不是问题：如果您计划主要支持弹性流量（不受抖动和延迟影响的流量），那么没关系。如果非弹性流量的比例很高（例如交互式语音/视频），那么这可能是一个更大的问题。
当然，在这种情况下，您总是可以过度设计 ;-)
如果您打算让服务器为每个客户端打开一个套接字，则需要仔细设计它，以便它可以有效地检查来自 10k+ 客户端的传入数据。这被称为 10k 问题。
现代 Linux 内核可以处理超过 10k 的连接，通常至少 100k。您可能需要进行一些调整，特别是许多 TCP 超时（如果使用 TCP）以避免在大量客户端频繁连接和断开连接时使用大量资源的关闭/陈旧套接字。
如果您使用的是 netfilter 的 conntrack 模块，则可能还需要调整以跟踪那么多连接（这与 tcp/udp 套接字无关）。
负载均衡有很多技术，最著名的是 LVS（Linux 虚拟服务器），它可以充当真实服务器集群的前端。我不知道它可以处理多少个连接，但我认为我们在生产中使用它至少有 50k。
对于您的问题，您只受到硬件限制的限制。这就是 linux 系统的设计理念。您正在准确描述您的限制因素。
试试 HAProxy 软件负载均衡器：