[TOC]

前言

曾几何时我们还在寻求网络编程中C10K问题的解决方案，但是现在从硬件和操作系统支持来看单台服务器支持上万并发连接已经没有多少挑战性了。

我们先假设单台服务器最多只能支持万级并发连接，其实对绝大多数应用来说已经远远足够了，但是对于一些拥有很大用户基数的互联网公司，往往面临的并发连接数是百万，千万，甚至腾讯的上亿（注：QQ默认用的UDP协议）。

虽然现在的集群，分布式技术可以为我们将并发负载分担在多台服务器上，那我们只需要扩展出数十台电脑就可以解决问题，但是我们更希望能更大的挖掘单台服务器的资源，先努力垂直扩展，再进行水平扩展，这样可以有效的节省服务器相关的开支（硬件资源，机房，运维，电力其实也是一笔不小的开支）。

那么到底一台服务器能够支持多少TCP并发连接呢？

文件句柄限制

在linux下编写网络服务器程序的朋友肯定都知道每一个tcp连接都要占一个文件描述符，一旦这个文件描述符使用完了，新的连接到来返回给我们的错误是：

“Socket/File:Can't open so many files”

这时你需要明白操作系统对可以打开的最大文件数的限制。

执行 ulimit -n输出 1024，说明对于一个进程而言最多只能打开1024个文件，所以你要采用此默认配置最多也就可以并发上千个TCP连接。
临时修改：ulimit -n 1000000，但是这种临时修改只对当前登录用户目前的使用环境有效，系统重启或用户退出后就会失效。
重启后失效的修改（不过我在CentOS 6.5下测试，重启后未发现失效）：编辑 /etc/security/limits.conf 文件，修改后内容为
- soft nofile 1000000
- hard nofile 1000000
永久修改：编辑/etc/rc.local，在其后添加如下内容
ulimit -SHn 1000000

执行 cat /proc/sys/fs/file-nr 输出 9344 0 592026，分别为：

1.已经分配的文件句柄数
2.已经分配但没有使用的文件句柄数
3.最大文件句柄数。

但在kernel 2.6版本中第二项的值总为0，这并不是一个错误，它实际上意味着已经分配的文件描述符无一浪费的都已经被使用了。

我们可以把这个数值改大些，用 root 权限修改 /etc/sysctl.conf 文件:

fs.file-max = 1000000

net.ipv4.ip_conntrack_max = 1000000

net.ipv4.netfilter.ip_conntrack_max = 1000000

操作系统上端口号1024以下是系统保留的，从1024-65535是用户使用的。

由于每个TCP连接都要占一个端口号，所以我们最多可以有60000多个并发连接。我想有这种错误思路朋友不在少数吧？（其中我过去就一直这么认为）

我们来分析一下吧

其实65535这个数字，只是决定了服务器端最多可以拥有65535个Bind的Socket。

也就是说，最多可以开65535个服务器进程，但是你要知道这个能够连接客户端的数量没有任何关系，Accept过来的Socket是不需要Bind任何IP地址的，也没有端口占用这一说。作为Server端的Socket本身只负责监听和接受连接操作

如何标识一个TCP连接：系统用一个4四元组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。
我们作为服务端实际只使用了bind时这一个端口，说明端口号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次方。

TCP连出受端口限制,连入仅受内存限制

上面给出的结论都是理论上的单机TCP并发连接数，实际上单机并发连接数肯定要受硬件资源（内存）、网络资源（带宽）的限制。

对server端，通过增加内存、修改最大文件描述符个数等参数，单机最大并发TCP连接数超过10万,甚至上百万是没问题的，国外 Urban Airship 公司在产品环境中已做到 50 万并发