linux上机器之间的tcp/ip连接数有限制吗？

Posted 2023-04-14

【中文标题】linux上机器之间的tcp/ip连接数有限制吗？

【英文标题】：Is there a limit on number of tcp/ip connections between machines on linux?

【发布时间】：2010-10-20 03:16:25

【问题描述】：

我有一个在 5 分钟内编写的非常简单的程序，它打开一个服务器套接字并循环通过请求并将发送给它的字节打印到屏幕上。

然后我尝试对我可以锤击它的连接数进行基准测试，以尝试找出我可以通过该程序支持多少并发用户。

在另一台机器上（它们之间的网络未饱和），我创建了一个简单的程序，该程序进入一个循环并连接到服务器机器并发送字节“hello world”。

当循环为 1000-3000 时，客户端完成发送所有请求。当循环超过 5000 时，它在完成前 X 个请求后开始超时。为什么是这样？我确保在循环中关闭我的套接字。

你只能在某个时间段内创建这么多连接吗？

这个限制是否只适用于同一台机器，我不必担心生产环境中 5000 多个请求都来自不同的机器？

【问题讨论】：

您可以使用 ss -s 命令监控您的套接字。如果需要，请按照步骤增加套接字限制

您可以重用 TIMED_WAIT 套接字，例如：s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

【参考方案1】：

有一个限制，是的。见ulimit。

您还需要考虑TIMED_WAIT 状态。一旦 TCP 套接字关闭（默认情况下），端口会在TIMED_WAIT 状态下保持占用 2 分钟。该值是可调的。即使它们已关闭，这也会“使您无法使用套接字”。

运行 netstat 以查看 TIMED_WAIT 的运行情况。

附： TIMED_WAIT 的原因是为了处理套接字关闭后数据包到达的情况。这可能是因为数据包延迟或另一方不知道套接字已关闭。这允许操作系统静默丢弃这些数据包，而不会“感染”不同的、不相关的套接字连接。

【讨论】：

我刚刚检查了两台机器上的netstat，客户端确实有大量的TIMED_WAIT，但服务器端没有TIMED_WAIT。这是你描述的行为吗？假设是：1）这是否意味着这在生产中不会成为问题，因为限制似乎来自客户端（用完套接字）而不是服务器端（没有创建套接字）2）是否存在一种解决此问题的方法，以便我可以使用类似于生产的负载测试我的服务器？

TIMED_WAIT 的行为是特定于操作系统的。是的，您可以绕过它 - 可以更改 TIMED_WAIT 超时，例如从 120 秒到 30 秒甚至更少。

【参考方案2】：

在寻找最大性能时，您会遇到很多问题和潜在的瓶颈。运行一个简单的 hello world 测试不一定会找到所有这些。

可能的限制包括：

内核套接字限制：查看/proc/sys/net 以获取大量内核调整.. 进程限制：查看ulimit，正如其他人在此处所述 随着您的应用程序变得越来越复杂，它可能没有足够的 CPU 处理能力来跟上传入的连接数。请使用 top 查看您的 CPU 是否已达到最大值 线程数？我没有线程方面的经验，但这可能与前面的项目一起发挥作用。

【参考方案3】：

您的服务器是单线程的吗？如果是这样，您使用的是什么轮询/多路复用功能？

使用 select() 不能超出在编译时设置的硬编码最大文件描述符限制，这是没有希望的（通常是 256 或更多）。

poll() 更好，但您最终会遇到可伸缩性问题，每次循环都会有大量 FD 重新填充集合。

epoll() 应该可以很好地达到您达到的其他限制。

10k 连接应该很容易实现。使用最近的（ish）2.6 内核。

您使用了多少台客户端计算机？你确定你没有达到客户端限制吗？

【讨论】：

在我的系统上硬编码的选择限制是 1024，而且确实不可能超过这个限制（限制是由保存要查看的文件描述符映射的数据类型强加的）。

【参考方案4】：

快速回答是 2^16 个 TCP 端口，64K。

系统强加限制的问题是配置问题，在之前的 cmets 中已经提到过。

对 TCP 的内部影响不是很清楚（对我来说）。每个端口的实例化都需要内存，进入列表并需要网络缓冲区来传输数据。

鉴于 64K TCP 会话，端口实例的开销在 32 位内核上可能是一个问题，但在 64 位内核上不是问题（这里很高兴接受更正）。具有 64K 会话的查找过程可能会稍微减慢速度，并且每个数据包都会进入计时器队列，这也可能会出现问题。传输中数据的存储理论上可以膨胀到窗口大小乘以端口（可能是 8 GB）。

连接速度问题（如上所述）可能就是您所看到的。 TCP 通常需要时间来做事。但是，这不是必需的。可以非常高效地完成 TCP 连接、事务和断开连接（检查 TCP 会话是如何创建和关闭的）。

有些系统每秒通过几十个千兆比特，所以数据包级别的缩放应该没问题。

有些机器有大量的物理内存，所以看起来还可以。

系统的性能，如果仔细配置应该没问题的。

服务器端应该以类似的方式扩展。

我会担心内存带宽等问题。

考虑一个您登录本地主机 10,000 次的实验。然后键入一个字符。通过用户空间的整个堆栈将参与每个角色。活动占用空间可能会超过数据缓存大小。运行大量内存会给 VM 系统带来压力。上下文切换的成本可能接近一秒！

这在各种其他线程中进行了讨论： https://serverfault.com/questions/69524/im-designing-a-system-to-handle-10000-tcp-connections-per-second-what-problems

【参考方案5】：

您可能想查看 /etc/security/limits.conf

【参考方案6】：

是的，限制是由内核设置的；查看 Stack Overflow 上的这个帖子了解更多详情：Increasing the maximum number of tcp/ip connections in linux