单机单IP最大tcp连接数（转）
单机单IP最大tcp连接数
分类： TCP/IP 2012-04-17 22:22
在tcp应用中，server事先在某个固定端口监听，client主动发起连接，经过三次握手后建立tcp连接。那么对单机，其最大并发tcp连接数是多少？
如何标识一个TCP连接 在确定最大连接数之前，先来看看系统如何标识一个tcp连接。系统用一个四维数组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。
client最大tcp连接数 client每次发起tcp连接请求时，除非绑定端口，通常会让系统选取一个空闲的本地端口（local port），该端口是独占的，不能和其他tcp连接共享。tcp端口的数据类型是unsigned short，因此本地端口个数最大只有65536，端口0是代表全部端口，不能使用，这样可用端口最多只有65535，所以在作为client端的情况下，最大tcp连接数为65535，这些连接可以连到不同的server ip。 简单的说就是单机单IP在作为客户端时只允许同时连接65535个服务(每个服务一个连接的情况下)
server最大tcp连接数 server通常固定在某个本地端口上监听，等待client的连接请求。不考虑地址重用（unix的SO_REUSEADDR选项）的情况下，即使server端有多个ip，本地监听端口也是独占的，因此server端tcp连接4维数组中只有remote ip（也就是client ip）和remote port（客户端port）是可变的，因此最大tcp连接为客户端ip数×客户端port数，对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。 简单的说就是单机单IP在作为服务端对外提供服务时可以允许同时有2的48次方个连接(每个客户端都用上所有端口来连接)
实际的tcp连接数 上面给出的是理论上的单机最大连接数，在实际环境中，受到机器资源、操作系统等的限制，特别是sever端，其最大并发tcp连接数远不能达到理论上限。在unix/linux下限制连接数的主要因素是内存和允许的文件描述符个数（每个tcp连接都要占用一定内存，每个socket就是一个文件描述符），另外1024以下的端口通常为保留端口。 对server端，通过增加内存、修改最大文件描述符个数等参数，单机最大并发TCP连接数超过10万 是没问题的，国外 Urban Airship 公司在产品环境中已做到 50 万并发 。在实际应用中，对大规模网络应用，还需要考虑C10K 问题。
CONNTRACK_MAX的默认值 ------------------------------
在i386架构上，CONNTRACK_MAX = RAMSIZE (以bytes记) / 16384 = RAMSIZE (以MegaBytes记) * 64， 因此，一个32位的带512M内存的PC在默认情况下能够处理512*1024^2/16384 = 512*64 = 32768个并发的netfilter连接。
但是真正的公式是： CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32) 这里x是指针的bit数，（例如，32或者64bit）
请注意： －默认的CONNTRACK_MAX值不会低于128 －对于带有超过1G内存的系统，CONNTRACK_MAX的默认值会被限制在65536（但是可以手工设置成更大的值）
HASHSIZE的默认值 -------------------------
通常，CONNTRACK_MAX = HASHSIZE * 8。这意味着每个链接的列表平均包含8个conntrack的条目（在优化的情况并且CONNTRACK_MAX达到的情况下），每个链接的列表就是一个哈西表条目（一个桶）。
在i386架构上，HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes记) / 131072 = RAMSIZE (以MegaBytes记) * 8。 举例来说，一个32位、带512M内存的PC可以存储512*1024^2/128/1024 = 512*8 = 4096 个桶（链接表）
但是真正的公式是： HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes记) / 131072 / (x / 32) 这里x是指针的bit数，（例如，32或者64bit）
请注意： －默认HASHSIZE的值不会小于16 －对于带有超过1G内存的系统，HASHSIZE的默认值会被限制在8192（但是可以手工设置成更大的值）
了解了以上情况,就很容易理解负载均衡器和并发连接的问题了,这里最关键的问题是要分清楚客户端和服务端,因为客户端受端口数限制连接数只有6万多,而当它作为服务端时是受系统硬件配置限制(当然软件配置也非常重要)
我们假设一种经典的模型：
Client Side Server Side Client -----> Load Balancer------> RealServer Pool.
并且我们假设这里使用NAT模式的负载均衡，在这种模式下: * 1.负载均衡器只留给客户端一个公网IP地址(VIP); * 2.客户端发来的请求都被负载均衡器端截，然后通过调度算法转发到RealServer Pool里面的某台服务器; * 3.这些RealServer都在一个私有网络里面，对外不可见; * 4.负载均衡器转发请求到真实服务器(RealServer)的时候同时做了NAT，真实服务器看到的连接都是来自负载均衡器的(和真实服务器在一个私有网络的IP)。 Client Side(Client->Load Balancer) 这端的连接都由SourceIP:SoucePort->DesIP:DesPort唯一标识，所以对我们来说，能支持的连接数仅仅受限于负载均衡器的内存数(连接数可以是65000+)，这时负载均衡器作为服务端,见"Server最大tcp连接数"段落.因为DesIP和DesPort都是已知的唯一的(比如IP:80) Server Side(Load Balancer->RealServer) 这端的连接数刚好相反，每个连接都由负载均衡器的IP(这里称MIP:Mapped IP)和随机的端口进行标识。即：
MIP:RandomPort -> RealServerIP:80
这时负载均衡器作为客户端，它的端口也受限于TCP/IP的最大端口数64k(65536)限制，因此最多只能建立64k的服务器连接(server connnections).
因为瓶颈很可能出现在负载均衡器的服务器端连接上，针对这种情况，各负载均衡器厂家是怎么解决的呢？ 1、 NetScaler 我们首先来看NetScaler的解决办法，NetScaler的解决办法很简单，增加MIP的个数，这样最大的服务器连接数将变成： MaxServerConnections = 65536 * MIP数 2、 F5 F5其实也使用了一样的办法，但是F5首先建立一个Source-NAT pool,然后在SNAT Pool里面加入多个IP地址。这样得到的最大连接数和NetScaler完全一样： SA:SP -> DA:DP 10.1.1.1:1024 -> 10.1.1.100:80 10.1.1.2:1024 -> 10.1.1.100:80 这里10.1.1.1和10.1.1.2都在一个SNAT pool里面。
上述情况都是理论计算值，真实环境下的最大连接数还受限于各种因素： * 1、 每个连接都要耗费一定的资源，比如CPU、MEM，所以，真实值往往很难达到理论值； * 2、 根据协议的不同，能达到的最大连接数也不一样，比如HTTP/1.0连接的创建和关闭都非常快，而且浏览器对并发连接数有限制，所以，很难达到最大的理论值。HTTP/1.1支持流线技术，多个请求可以复用一个连接，这样就大大减少了并发连接数。FTP或者telnet连接都是长连接，很容易达到最大值。 * 3、 很多设备(比如NetScaler)在服务器端都支持连接池(连接复用)，里面的连接都是长连接，一样实现了HTTP/1.1里面的流线技术，一个连接就可以处理多个客户端连接。这样除了减少连接资源，同时还减少了负载均衡器的其他资源开销，同时减低了内网的带宽。 * 4、 一些设备(比如NetScaler的TCP-OFFLOAD)支持TCP卸载，仅仅把已经建立的连接发到服务器端，而TCP的三次握手完全有负载均衡器接管，这样，服务器端的连接就成倍的减少。
单机最大tcp连接数 http://wanshi.iteye.com/blog/1256282
一个IP能建立的最大连接数是多少 http://hi.baidu.com/hawk418/blog/item/8377b86e8fe7b3c081cb4a84.html
如何标识一个TCP连接 在确定最大连接数之前，先来看看系统如何标识一个tcp连接。系统用一个四维数组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。
client最大tcp连接数 client每次发起tcp连接请求时，除非绑定端口，通常会让系统选取一个空闲的本地端口（local port），该端口是独占的，不能和其他tcp连接共享。tcp端口的数据类型是unsigned short，因此本地端口个数最大只有65536，端口0是代表全部端口，不能使用，这样可用端口最多只有65535，所以在作为client端的情况下，最大tcp连接数为65535，这些连接可以连到不同的server ip。 简单的说就是单机单IP在作为客户端时只允许同时连接65535个服务(每个服务一个连接的情况下)
server最大tcp连接数 server通常固定在某个本地端口上监听，等待client的连接请求。不考虑地址重用（unix的SO_REUSEADDR选项）的情况下，即使server端有多个ip，本地监听端口也是独占的，因此server端tcp连接4维数组中只有remote ip（也就是client ip）和remote port（客户端port）是可变的，因此最大tcp连接为客户端ip数×客户端port数，对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。 简单的说就是单机单IP在作为服务端对外提供服务时可以允许同时有2的48次方个连接(每个客户端都用上所有端口来连接)
实际的tcp连接数 上面给出的是理论上的单机最大连接数，在实际环境中，受到机器资源、操作系统等的限制，特别是sever端，其最大并发tcp连接数远不能达到理论上限。在unix/linux下限制连接数的主要因素是内存和允许的文件描述符个数（每个tcp连接都要占用一定内存，每个socket就是一个文件描述符），另外1024以下的端口通常为保留端口。 对server端，通过增加内存、修改最大文件描述符个数等参数，单机最大并发TCP连接数超过10万 是没问题的，国外 Urban Airship 公司在产品环境中已做到 50 万并发 。在实际应用中，对大规模网络应用，还需要考虑C10K 问题。
CONNTRACK_MAX的默认值 ------------------------------
在i386架构上，CONNTRACK_MAX = RAMSIZE (以bytes记) / 16384 = RAMSIZE (以MegaBytes记) * 64， 因此，一个32位的带512M内存的PC在默认情况下能够处理512*1024^2/16384 = 512*64 = 32768个并发的netfilter连接。
但是真正的公式是： CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32) 这里x是指针的bit数，（例如，32或者64bit）
请注意： －默认的CONNTRACK_MAX值不会低于128 －对于带有超过1G内存的系统，CONNTRACK_MAX的默认值会被限制在65536（但是可以手工设置成更大的值）
HASHSIZE的默认值 -------------------------
通常，CONNTRACK_MAX = HASHSIZE * 8。这意味着每个链接的列表平均包含8个conntrack的条目（在优化的情况并且CONNTRACK_MAX达到的情况下），每个链接的列表就是一个哈西表条目（一个桶）。
在i386架构上，HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes记) / 131072 = RAMSIZE (以MegaBytes记) * 8。 举例来说，一个32位、带512M内存的PC可以存储512*1024^2/128/1024 = 512*8 = 4096 个桶（链接表）
但是真正的公式是： HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (以bytes记) / 131072 / (x / 32) 这里x是指针的bit数，（例如，32或者64bit）
请注意： －默认HASHSIZE的值不会小于16 －对于带有超过1G内存的系统，HASHSIZE的默认值会被限制在8192（但是可以手工设置成更大的值）
了解了以上情况,就很容易理解负载均衡器和并发连接的问题了,这里最关键的问题是要分清楚客户端和服务端,因为客户端受端口数限制连接数只有6万多,而当它作为服务端时是受系统硬件配置限制(当然软件配置也非常重要)
我们假设一种经典的模型：
Client Side Server Side Client -----> Load Balancer------> RealServer Pool.
并且我们假设这里使用NAT模式的负载均衡，在这种模式下: * 1.负载均衡器只留给客户端一个公网IP地址(VIP); * 2.客户端发来的请求都被负载均衡器端截，然后通过调度算法转发到RealServer Pool里面的某台服务器; * 3.这些RealServer都在一个私有网络里面，对外不可见; * 4.负载均衡器转发请求到真实服务器(RealServer)的时候同时做了NAT，真实服务器看到的连接都是来自负载均衡器的(和真实服务器在一个私有网络的IP)。 Client Side(Client->Load Balancer) 这端的连接都由SourceIP:SoucePort->DesIP:DesPort唯一标识，所以对我们来说，能支持的连接数仅仅受限于负载均衡器的内存数(连接数可以是65000+)，这时负载均衡器作为服务端,见"Server最大tcp连接数"段落.因为DesIP和DesPort都是已知的唯一的(比如IP:80) Server Side(Load Balancer->RealServer) 这端的连接数刚好相反，每个连接都由负载均衡器的IP(这里称MIP:Mapped IP)和随机的端口进行标识。即：
MIP:RandomPort -> RealServerIP:80
这时负载均衡器作为客户端，它的端口也受限于TCP/IP的最大端口数64k(65536)限制，因此最多只能建立64k的服务器连接(server connnections).
因为瓶颈很可能出现在负载均衡器的服务器端连接上，针对这种情况，各负载均衡器厂家是怎么解决的呢？ 1、 NetScaler 我们首先来看NetScaler的解决办法，NetScaler的解决办法很简单，增加MIP的个数，这样最大的服务器连接数将变成： MaxServerConnections = 65536 * MIP数 2、 F5 F5其实也使用了一样的办法，但是F5首先建立一个Source-NAT pool,然后在SNAT Pool里面加入多个IP地址。这样得到的最大连接数和NetScaler完全一样： SA:SP -> DA:DP 10.1.1.1:1024 -> 10.1.1.100:80 10.1.1.2:1024 -> 10.1.1.100:80 这里10.1.1.1和10.1.1.2都在一个SNAT pool里面。
上述情况都是理论计算值，真实环境下的最大连接数还受限于各种因素： * 1、 每个连接都要耗费一定的资源，比如CPU、MEM，所以，真实值往往很难达到理论值； * 2、 根据协议的不同，能达到的最大连接数也不一样，比如HTTP/1.0连接的创建和关闭都非常快，而且浏览器对并发连接数有限制，所以，很难达到最大的理论值。HTTP/1.1支持流线技术，多个请求可以复用一个连接，这样就大大减少了并发连接数。FTP或者telnet连接都是长连接，很容易达到最大值。 * 3、 很多设备(比如NetScaler)在服务器端都支持连接池(连接复用)，里面的连接都是长连接，一样实现了HTTP/1.1里面的流线技术，一个连接就可以处理多个客户端连接。这样除了减少连接资源，同时还减少了负载均衡器的其他资源开销，同时减低了内网的带宽。 * 4、 一些设备(比如NetScaler的TCP-OFFLOAD)支持TCP卸载，仅仅把已经建立的连接发到服务器端，而TCP的三次握手完全有负载均衡器接管，这样，服务器端的连接就成倍的减少。
单机最大tcp连接数 http://wanshi.iteye.com/blog/1256282
一个IP能建立的最大连接数是多少 http://hi.baidu.com/hawk418/blog/item/8377b86e8fe7b3c081cb4a84.html
