现代Linux机顶盒可以打开的TCP连接的理论最大数量是多少


236

假设硬件具有无限的性能,Linux盒能否支持> 65536的开放TCP连接?

我知道临时端口的数量(<65536)限制了从一个本地IP到一个远程IP上一个端口的连接数量。

元组(本地ip,本地端口,远程ip,远程端口)是唯一定义TCP连接的元组。这是否意味着如果这些参数中的一个以上空闲,则可以支持65K以上的连接。例如,从多个本地IP连接到多个远程主机上的单个端口号。

系统中还有16位限制吗?可能有多少个文件描述符?

Answers:


349

单个侦听端口可以同时接受多个连接。

通常会引用“ 64K”限制,但这是每个客户端每个服务器端口的限制,需要澄清。

每个TCP / IP数据包基本上都有四个用于寻址的字段。这些是:

source_ip source_port destination_ip destination_port
< client            > < server                      >

在TCP堆栈内部,这四个字段用作复合键,以将数据包与连接进行匹配(例如,文件描述符)。

如果客户端在同一目标上具有到同一端口的许多连接,则这些字段中的三个将相同-只是source_port为了区分不同的连接而有所不同。端口是16位数字,因此任何给定客户端可以与任何给定主机端口建立的最大连接数为64K。

但是,多个客户端可以分别与某个服务器的端口建立多达64K的连接,并且如果服务器具有多个端口,或者其中一个是多宿主的,则可以进一步增加该数量。

因此,真正的限制是文件描述符。每个单独的套接字连接都有一个文件描述符,因此限制实际上是系统已配置为允许的文件描述符的数量和要处理的资源。最大限制通常超过300K,但可以使用sysctl进行配置。

普通机顶盒所吹嘘的实际限制约为80K,例如单线程Jabber消息传递服务器。


3
如果您(a)使用SO_REUSEADDR和(b)定位不同的目标IP地址,则理论上可以有64K以上的传出连接。但是内核内存限制可能会首先阻止您。
Darron 2010年

4
sysctl限制适用于整个系统,对吗?还有一个可以用ulimit配置的限制,它限制了进程的文件描述符的最大数量。默认情况下,该值远小于300K,通常为
1024。– pacoverflow

1
略微的技术性:客户端计算机还可以从路由器分配多个IP地址。这些都可以分配给单个MAC,或者该机器可以具有多个物理网络接口以用于其他IP地址。OP指定了1个IP,但对其他人而言,不要排除更多IP地址也很重要。
托德

2
@将精美解释!很有帮助...想给+100赞...谢谢:-)
汤姆·泰勒

1
请注意,默认情况下,tcp_fin_timeout将阻塞同一套接字(源,目标,端口组合)另外60秒钟,如果频繁断开连接并重新连接,则这将大大减少两个系统之间实际可用的tcp连接数。可以通过允许重用(tcp_tw_reuse = 1)处于TIME_WAIT状态的套接字(不总是受支持)或通过打破TCP / IP标准以将此超时减小到一个较低的值(通常无论如何都能正常工作)来最小化此问题。
fgwaller

17

如果您正在考虑运行服务器并试图确定一台计算机可以服务多少个连接,则可能需要阅读C10k问题 以及同时服务多个客户端所涉及的潜在问题。


14
C10k已经10岁了,不再有趣。[阅读本文]以了解如何解决C1024K。
Chandranshu 2013年

@Chandranshu-您的意思是metabrew.com/article/…吗?
Mikko Rantalainen

1
@MikkoRantalainen-是的。我认为现在有更好的基准。凤凰城的家伙已经将它推到了200万个同时连接的位置。
Chandranshu

3
@Chandranshu -有戴尔演示用12M连接:mrotaru.wordpress.com/2013/06/20/...
米克Rantalainen

1
几年前:Intel Atom D2700、2GB RAM,120万个并发连接。我唯一遇到的问题是测试工作中的Windows框。这些通常会在尝试对Intel Atom盒进行DoS时变得腹部
不适

12

如果您使用原始套接字(SOCK_RAW)并在userland中重新实现了TCP,我认为在这种情况下,答案仅受(local address, source port, destination address, destination port)元组数量(每个本地地址〜2 ^ 64)的限制。

当然,保持所有这些连接的状态将需要大量内存,并且我认为您必须设置一些iptables规则以防止内核TCP堆栈烦恼和/或代表您响应。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.