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

Is there a limit on number of tcp/ip connections between machines on linux?

提问by erotsppa

I have a very simple program written in 5 min that opens a sever socket and loops through the request and prints to the screen the bytes sent to it.

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

I then tried to benchmark how many connections I can hammer it with to try to find out how many concurrent users I can support with this program.

然后我尝试基准测试我可以使用多少连接来尝试找出我可以使用该程序支持多少并发用户。

On another machine (where the network between them is not saturated) I created a simple program that goes into a loop and connects to the server machine and send the bytes "hello world".

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

When the loop is 1000-3000 the client finishes with all requests sent. When the loop goes beyond 5000 it starts to have time outs after finish the first X number of requests. Why is this? I have made sure to close my socket in the loop.

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

Can you only create so many connections within a certain period of time?

你能不能在一段时间内只建立这么多的连接？

Is this limit only applicable between the same machines and I need not worry about this in production where 5000+ requests are all coming from different machines?

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

回答by Jason Cohen

There is a limit, yes. See ulimit.

有限制，是的。见ulimit。

Also you need to consider the TIMED_WAITstate. Once a TCP socket is closed (by default) the port remains occupiedin TIMED_WAITstatus for 2 minutes. This value is tunable. This will also "run you out of sockets" even though they are closed.

您还需要考虑TIMED_WAIT状态。一旦TCP套接字被关闭（默认），则端口仍然占据在TIMED_WAIT状态2分钟。该值是可调的。即使它们已关闭，这也会“耗尽您的套接字”。

Run netstatto see the TIMED_WAITstuff in action.

运行netstat以查看正在运行的TIMED_WAIT东西。

P.S. The reason for TIMED_WAITis to handle the case of packets arriving after the socket is closed. This can happen because packets are delayed or the other side just doesn't know that the socket has been closed yet. This allows the OS to silently drop those packets without a chance of "infecting" a different, unrelated socket connection.

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

回答by Ian

You might wanna check out /etc/security/limits.conf

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

回答by Don Werve

Yep, the limit is set by the kernel; check out this thread on Stack Overflow for more details: Increasing the maximum number of tcp/ip connections in linux

是的，限制是由内核设置的；查看堆栈溢出上的此线程以获取更多详细信息：增加 linux 中的最大 tcp/ip 连接数

回答by DGM

When looking for the max performance you run into a lot of issue and potential bottlenecks. Running a simple hello world test is not necessarily going to find them all.

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

Possible limitations include:

可能的限制包括：

• Kernel socket limitations: look in /proc/sys/netfor lots of kernel tuning..
• process limits: check out ulimitas others have stated here
• as your application grows in complexity, it may not have enough CPU power to keep up with the number of connections coming in. Use topto see if your CPU is maxed
• number of threads? I'm not experienced with threading, but this may come into play in conjunction with the previous items.

• 内核套接字限制：寻找/proc/sys/net大量内核调优..
• 流程限制：查看ulimit其他人在此处所述的内容
• 随着您的应用程序变得越来越复杂，它可能没有足够的 CPU 能力来跟上进入的连接数。top用于查看您的 CPU 是否已达到最大值
• 线程数？我对线程没有经验，但这可能会与之前的项目一起发挥作用。

回答by MarkR

Is your server single-threaded? If so, what polling / multiplexing function are you using?

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

Using select() does not work beyond the hard-coded maximum file descriptor limit set at compile-time, which is hopeless (normally 256, or a few more).

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

poll() is better but you will end up with the scalability problem with a large number of FDs repopulating the set each time around the loop.

poll() 更好，但最终会出现可扩展性问题，每次循环都会有大量 FD 重新填充集合。

epoll() should work well up to some other limit which you hit.

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

10k connections should be easy enough to achieve. Use a recent(ish) 2.6 kernel.

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

How many client machines did you use? Are you sure you didn't hit a client-side limit?

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

回答by Trivet

The quick answer is 2^16 TCP ports, 64K.

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

The issues with system imposed limits is a configuration issue, already touched upon in previous comments.

系统强加限制的问题是一个配置问题，在之前的评论中已经提到。

The internal implications to TCP is not so clear (to me). Each port requires memory for it's instantiation, goes onto a list and needs network buffers for data in transit.

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

Given 64K TCP sessions the overhead for instances of the ports might be an issue on a 32-bit kernel, but not a 64-bit kernel (correction here gladly accepted). The lookup process with 64K sessions can slow things a bit and every packet hits the timer queues, which can also be problematic. Storage for in transit data can theoretically swell to the window size times ports (maybe 8 GByte).

给定 64K TCP 会话，端口实例的开销在 32 位内核上可能是一个问题，但在 64 位内核上不是问题（很高兴接受此处的更正）。使用 64K 会话的查找过程可能会稍微减慢速度，并且每个数据包都会命中计时器队列，这也可能会出现问题。传输中数据的存储理论上可以扩展到窗口大小乘以端口（可能是 8 GByte）。

The issue with connection speed (mentioned above) is probably what you are seeing. TCP generally takes time to do things. However, it is not required. A TCP connect, transact and disconnect can be done very efficiently (check to see how the TCP sessions are created and closed).

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

There are systems that pass tens of gigabits per second, so the packet level scaling should be OK.

有些系统每秒传输数十吉比特，因此数据包级别缩放应该没问题。

There are machines with plenty of physical memory, so that looks OK.

有些机器有足够的物理内存，所以看起来没问题。

The performance of the system, if carefully configured should be OK.

系统的性能，如果仔细配置应该是可以的。

The server side of things should scale in a similar fashion.

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

I would be concerned about things like memory bandwidth.

我会担心诸如内存带宽之类的事情。

Consider an experiment where you login to the local host 10,000 times. Then type a character. The entire stack through user space would be engaged on each character. The active footprint would likely exceed the data cache size. Running through lots of memory can stress the VM system. The cost of context switches could approach a second!

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

This is discussed in a variety of other threads: https://serverfault.com/questions/69524/im-designing-a-system-to-handle-10000-tcp-connections-per-second-what-problems

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