一台服务器最大能打开的文件数
调整服务器能打开的最大文件数示例
一台服务器最大能支持多少连接
一台客户端机器最多能发起多少条连接
其他
相关实际问题
之前有一位粉丝诉苦，有次面试，好不容易（今年行情大家都懂的）熬到到技术终面，谁知道面试官突然放个大招问他：一台服务器最大能支持多少条 TCP 连接，把他直接给问懵了……（请自行脑补那尴尬的场面与气氛）。
所以，今天就来讨论一下这个问题。
一台服务器最大能打开的文件数
fs.file-max （系统级别参数） ：该参数描述了整个系统可以打开的最大文件数量。但是root用户不会受该参数限制（比如：现在整个系统打开的文件描述符数量已达到fs.file-max ，此时root用户仍然可以使用ps、kill等命令或打开其他文件描述符）。
soft nofile（进程级别参数） ：限制单个进程上可以打开的最大文件数。只能在Linux上配置一次，不能针对不同用户配置不同的值。
fs.nr_open（进程级别参数） ：限制单个进程上可以打开的最大文件数。可以针对不同用户配置不同的值。
如果想加大soft nofile，那么hard nofile参数值也需要一起调整。如果因为hard nofile参数值设置的低，那么soft nofile参数的值设置的再高也没有用，实际生效的值会按照二者最低的来。
如果增大了hard nofile，那么fs.nr_open也都需要跟着一起调整（fs.nr_open参数值一定要大于hard nofile参数值）。如果不小心把hard nofile的值设置的比fs.nr_open还大，那么后果比较严重。会导致该用户无法登录，如果设置的是*，那么所有用户都无法登录。
如果加大了fs.nr_open，但是是用的echo "xxx" > ../fs/nr_open命令来修改的fs.nr_open的值，那么刚改完可能不会有问题，但是只要机器一重启，那么之前通过echo命令设置的fs.nr_open值便会失效，用户还是无法登录。所以非常不建议使用echo的方式修改内核参数！！！
调整服务器能打开的最大文件数示例
vim /etc/sysctl.conffs.file-max=1100000 // 系统级别设置成110万，多留点bufferfs.nr_open=1100000 // 进程级别也设置成110万，因为要保证比 hard nofile大
vim /etc/security/limits.conf用户进程级别都设置成100完soft nofile 1000000hard nofile 1000000
一台服务器最大能支持多少连接
由于TCP连接本质上可以理解为是client-server端的一对socket内核对象，那么从理论上将应该是【2^32 (ip数) * 2^16 (端口数)】条连接（约等于两百多万亿）。 但是实际上由于受其他软硬件的影响，我们一台服务器不可能能建立这么多连接（主要是受CPU和内存限制）。
这种情况下，那么能建立的连接数量主要取决于【内存的大小】（因为如果是）ESTABLISH状态的空闲连接，不会消耗CPU（虽然有TCP保活包传输，但这个影响非常小，可以忽略不计）。
我们知道一条ESTABLISH状态的连接大约消耗【3.3KB内存】，那么通过计算得知一台4GB内存的服务器，【可以建立100w+的TCP连接】（当然这里只是计算所有的连接都只建立连接但不发送和处理数据的情况，如果真实场景中有数据往来和处理（数据接收和发送都需要申请内存，数据处理便需要CPU），那便会消耗更高的内存以及占用更多的CPU，并发不可能达到100w+）。
一台客户端机器最多能发起多少条连接
其余情况类推，但是客户端的可用端口范围一般达不到65535个，受内核参数net.ipv4.ip_local_port_range限制，如果要修改client所能使用的端口范围，可以修改这个内核参数的值。
所以，不光是一台server端可以接收100w+个TCP连接，一台client照样能发出100w+个连接。
其他
public static void main(String[] args) throws IOException {SocketChannel sc = SocketChannel.open();// 客户端还可以调用bind方法sc.bind(new InetSocketAddress("localhost", 9999));sc.connect(new InetSocketAddress("localhost", 8080));System.out.println("waiting..........");}
相关实际问题
因为每打开一个文件（包括socket），都需要消耗一定的内存资源。为了避免个别进程不受控制的打开了过多文件而让整个服务器奔溃，Linux对打开的文件描述符数量有限制。如果你的进程触发到内核的限制，那么"too many open files" 报错就产生了。
可以通过修改fs.file-max 、soft nofile、fs.nr_open这三个参数的值来修改进程能打开的最大文件描述符数量。
在不考虑连接上数据的收发和处理的情况下，仅考虑ESTABLISH状态下的空连接情况下，一台服务器上最大可支持的TCP连接数量基本上可以说是由内存大小来决定的。
四元组唯一确定一条连接，但服务端可以接收来自任意客户端的请求，所以根据这个理论计算出来的数字太大，没有实际意义。另外文件描述符限制其实也是内核为了防止某些应用程序不受限制的打开【文件句柄】而添加的限制。这个限制只要修改几个内核参数就可以加大。
一个socket大约消耗3kb左右的内存，这样真正制约服务端机器最大并发数的就是内存，拿一台4GB内存的服务器来说，可以支持的TCP连接数量大约是100w+。
客户度每次建立一条连接都需要消耗一个端口。从数字上来看，似乎最多只能建立65535条连接。但实际上我们有两种办法破除65535这个限制。
所以一台client发起百万条连接是没有任何问题的。
对于长连接推送模块这种服务来说，给客户端发送数据只是偶尔的，一般一天也就顶多一两次。绝大部分情况下TCP连接都是空闲的，CPU开销可以忽略。
再基于内存来考虑，假设服务器内存是128G的，那么一台服务器可以考虑支持500w条并发。这样会消耗掉大约不到20GB内存用来保存这500w条连接对应的socket。还剩下100GB以上的内存来应对接收、发送缓冲区等其他的开销足够了。所以，一亿用户，仅仅需要20台服务器就差不多够用了！
- End-
DailyMart是一个基于 DDD 和Spring Cloud Alibaba的微服务商城系统，采用SpringBoot3.x以及JDK17。旨在为开发者提供集成式的学习体验，并将其无缝地应用于实际项目中。该专栏包含领域驱动设计（DDD）、Spring Cloud Alibaba企业级开发实践、设计模式实际应用场景解析、分库分表战术及实用技巧等内容。如果你对这个系列感兴趣，可在本公众号回复关键词 DDD 获取完整文档以及相关源码。
