一台Linux服务器最多能支撑多少个TCP连接

困惑很多人的并发问题

在网络开发中，我发现有很多同学对一个基础问题始终是没有彻底搞明白。那就是一台服务器最大究竟能支持多少个网络连接？我想我有必要单独发一篇文章来好好说一下这个问题。

很多同学看到这个问题的第一反应是65535。原因是：“听说端口号最多有65535个，那长连接就最多保持65535个了”。是这样的吗？还有的人说：“应该受TCP连接里四元组的空间大小限制，算起来是200多万亿个！”

如果你对这个问题也是理解的不够彻底，那么今天讲个故事讲给你听！

一次关于服务器端并发的聊天

"TCP连接四元组是源IP地址、源端口、目的IP地址和目的端口。任意一个元素发生了改变，那么就代表的是一条完全不同的连接了。拿我的Nginx举例，它的端口是固定使用80。另外我的IP也是固定的，这样目的IP地址、目的端口都是固定的。剩下源IP地址、源端口是可变的。所以理论上我的Nginx上最多可以建立2的32次方（ip数）×2的16次方（port数）个连接。这是两百多万亿的一个大数字！！"

但是有时候会遇到报错，如目标 IP 都是110.242.68.3，目标端口都是 80。当同一个客户端建立大量连接时，会报错：

表示端口号不够用啦！一个劲地对着同一个 IP 和端口创建 TCP 连接，端口号不够用了，源端口那里没法给了。

可是知道端口号是 16 位的，范围是 1~65535，一共可以创建 65535 个 TCP 连接，Linux 对可使用的端口范围是有具体限制的，具体可以用如下命令查看。

[root]# cat /proc/sys/net/ipv4/ip_local_port_range 
1024 65000

文件描述符

建立大量的TCP连接,直到又报错。

"进程每打开一个文件（linux下一切皆文件，包括socket），都会消耗一定的内存资源。如果有不怀好心的人启动一个进程来无限的创建和打开新的文件，会让服务器崩溃。所以linux系统出于安全角度的考虑，在多个位置都限制了可打开的文件描述符的数量，包括系统级、用户级、进程级。这三个限制的含义和修改方式如下："

• 系统级：当前系统可打开的最大数量，通过fs.file-max参数可修改
• 用户级：指定用户可打开的最大数量，修改/etc/security/limits.conf
• 进程级：单个进程可打开的最大数量，通过fs.nr_open参数可修改

 服务端百万连接达成记

“准备啥呢，还记得前面说过Linux对最大文件对象数量有限制，所以要想完成这个实验，得在用户级、系统级、进程级等位置把这个上限加大。我们实验目的是100W，这里都设置成110W，这个很重要！因为得保证做实验的时候其它基础命令例如ps，vi等是可用的。“

线程

突破了文件描述符限制，又开始肆无忌惮地创建起了TCP连接。

但我发现，系统的办事效率越来越慢，建立一个TCP连接花的时间越来越久。

因为每建一个TCP连接都需要消耗一个线程来为你服务？现在CPU老大那里都忙得不可开交了，一直在为你这好几十万个线程不停地进行上下文切换，我们精力有限啊，自然就没法像以前那么快为你服务了。

想起了之前似乎有人跟我说过 C10K 问题，就是当服务器连接数达到 1 万且每个连接都需要消耗一个线程资源时，操作系统就会不停地忙于线程的上下文切换，最终导致系统崩溃，这可不是闹着玩的。那我们现在应该怎么办呢？

现在这种每建一个TCP连接就创建一个线程的方式，是最传统的多线程并发模型，早期的操作系统也只支持这种方式。但现在我进化了，我还支持 IO 多路复用的方式，简单说就是一个线程可以管理多个 TCP 连接的资源，这样你就可以用少量的线程来管理大量的 TCP 连接了。

这次真是大开眼界了，赶紧把代码改成了这种 IO 多路复用的模型，将原来的 TCP 连接销毁掉，改成同一个线程管理多个 TCP 连接，很快，操作系统老大就恢复了以往的办事效率，同时 TCP 连接数又多了起来。 

内存

突破了端口号、文件描述符、线程数等重重限制的我，再次肆无忌惮地创建起了TCP连接。

直到有一次，我又收到了一张红牌。

嗨，又是啥东西限制了呀，改了不就完了。这个错误叫内存溢出，每个TCP连接本身，以及这个连接所用到的缓冲区，都是需要占用一定内存的，现在内存已经被你占满了，不够用了，所以报了这个错。此时只能加大服务器内存或者kill无用进程了。

CPU

由于你的 TCP 连接，CPU 占用率已经很长时间维持在 100%，此时还是只能加大服务器CPU核心数或者kill无用进程了。

结语

互联网后端的业务特点之一就是高并发. 但是一台服务器最大究竟能支持多少个TCP连接，这个问题似乎却又在困惑着很多同学。希望今天过后，你能够将这个问题踩在脚下摩擦！