文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录博客园版 为您奉上珍贵的学习资源：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你实现技术自由，完成职业升级，薪酬猛涨！加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领
免费赠送经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备加尼恩免费领

免费赠送资源宝库： Java 必备百度网盘资源大合集价值>10000元加尼恩领取

极兔面试：一台服务器，支持的TCP连接数最大是多少？

尼恩说在前面

在40岁老架构师尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、shein 希音、百度、网易的面试资格，遇到系列服务器相关的面试题：

一台服务器最大能支持多少条 TCP 连接？

一台服务器，最大能打开的文件数 ?

一台服务器，最大能支持多少连接?

一台客户端机器，最多能发起多少条连接?

小伙伴没有回答好，导致面试挂了。小伙伴面试完了之后，来求助尼恩：如何才能回答得很漂亮，才能让面试官刮目相看、口水直流。

所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

当然，这道面试题，以及参考答案，也会收入咱们的《尼恩Java面试宝典》V152版本PDF集群，供后面的小伙伴参考，提升大家的 3高架构、设计、开发水平。

特别提示：尼恩的3高架构宇宙，持续升级。

《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到公众号【技术自由圈】获取

本文目录

极兔面试：一台服务器，支持的TCP连接数最大是多少？

一台服务器最大能打开的文件数

操作系统维度的限制参数

在Linux中，一切皆文件。

那么一台服务器最大能打开多少个文件呢？

Linux上能打开的最大文件数量受三个参数影响，分别是：

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的方式修改内核参数！！！

调整服务器能打开的最大文件数示例

假设想让进程可以打开100万个文件描述符，这里用修改conf文件的方式给出一个建议。

如果日后工作里有类似的需求可以作为参考。

vim /etc/sysctl.conf

fs.file-max=1100000 // 系统级别设置成110万，多留点buffer  
fs.nr_open=1100000 // 进程级别也设置成110万，因为要保证比hard nofile大

使上面的配置生效sysctl -p

vim /etc/security/limits.conf
    
// 用户进程级别都设置成100完  
soft nofile 1000000  
hard nofile 1000000

一台服务器最大能支持多少连接

我们知道TCP连接，从根本上看其实就是client和server端在内存中维护的一组【socket内核对象】

一组【socket内核对象】也对应着TCP四元组：源IP、源端口、目标IP、目标端口，他们只要能够找到对方，那么就算是一条连接。

网络数据的四元组：源ip地址，源端口，目标ip地址，目标端口。可以类比为收发快递上的快递单：

关于TCP协议，具体参见尼恩两篇文章：

TCP协议详解 (史上最全)

网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！

如果网络原理的基础知识不好，基本上看了尼恩的上面两篇文章，基本也就差不了。

如果还不行，就去看看尼恩在清华大学出版社出版的《Java高并发核心编程卷1加强版》。最新的PDF电子书可以找尼恩获取。

了解了TCP链接之后，咱们来看看, 一台服务器最大能建立多少条连接呢？

由于TCP连接本质上可以理解为是client-server端的一对socket内核对象，那么从理论上将应该是【2^32 (ip数) * 2^16 (端口数)】条连接（约等于两百多万亿）。
但是实际上由于受其他软硬件的影响，我们一台服务器不可能能建立这么多连接（主要是受CPU和内存限制）。

如果只以ESTABLISH状态的连接来算（这些连接只是建立，但是不收发数据也不处理相关的业务逻辑）,一台服务器最大能建立多少连接呢？以一台4GB内存的服务器为例！

这种情况下，那么能建立的连接数量主要取决于【内存的大小】（因为如果是）ESTABLISH状态的空闲连接，不会消耗CPU（虽然有TCP保活包传输，但这个影响非常小，可以忽略不计）。
我们知道一条ESTABLISH状态的连接大约消耗【8KB内存】，那么通过计算得知一台8GB内存的服务器，【可以建立100w+的TCP连接`】（当然这里只是计算所有的连接都只建立连接但不发送和处理数据的情况，如果真实场景中有数据往来和处理（数据接收和发送都需要申请内存，数据处理便需要CPU），那便会消耗更高的内存以及占用更多的CPU，并发不可能达到100w+）。

上面讨论的都是进建立连接的理想情况，在现实中如果有频繁的数据收发和处理（比如：压缩、加密等），那么一台服务器能支撑1000连接都算好的了，所以一台服务器能支撑多少连接还要结合具体的场景去分析，不能光靠理论值去算。抛开业务逻辑单纯的谈并发没有太大的实际意义。

服务器的开销大头往往并不是连接本身，而是每条连接上的数据收发，以及请求业务逻辑处理！！！

一台客户端机器最多能发起多少条连接

我们知道客户端每和服务端建立一个连接便会消耗掉client端一个端口。

一台机器的端口范围是【0 ~ 65535】，那么是不是说一台client机器最多和一台服务端机器建立65535个连接呢？

由TCP连接的四元组特性可知，只要四元组里某一个元素不同，那么就认为这是不同的TCP连接。所以需要分情况讨论：

【情况一 】如果一台client仅有一个IP，server端也仅有一个IP并且仅启动一个程序，监听一个端口的情况下，client端和这台server端最大可建立的连接条数就是 65535 个。

因为源IP固定，目标IP和端口固定，四元组中唯一可变化的就是【源端口】，【源端口】的可用范围又是【0 ~ 65535】，所以一台client机器最大能建立65535个连接。

【情况二 】如果一台client有多个IP（假设客户端有 n 个IP），server端仅有一个IP并且仅启动一个程序，监听一个端口的情况下，一台client机器最大能建立的连接条数是：n * 65535 个。

因为目标IP和端口固定，有 n 个源IP，四元组中可变化的就是【源端口】+ 【源IP】，【源端口】的可用范围又是【0 ~ 65535】，所以一个IP最大能建立65535个连接，那么n个IP最大就能建立 n * 65535个连接了。

以现在的技术，给一个client分配多个IP是非常容易的事情，只需要去联系你们网管就可以做到。

【情况三 】如果一台client仅有一个IP，server端也仅有一个IP但是server端启动多个程序，每个程序监听一个端口的情况下（比如server端启动了m个程序，监听了m个不同端口），一台client机器最大能建立的连接数量为：65535 * m。

源IP固定，目标IP固定，目标端口数量为m个，可变化的是源端口，而源端口变化范围是【0 ~ 65535】，所以一台client机器最大能建立的TCP连接数量是 65535 * m个。

其余情况类推，但是客户端的可用端口范围一般达不到65535个，受内核参数net.ipv4.ip_local_port_range限制，如果要修改client所能使用的端口范围，可以修改这个内核参数的值。

这65535个端口里还有很多保留端口，可用端口可能只有64000个左右

总之，得到的结论是：

一台server端可以接收100w+个TCP连接，
一台client照样能发出100w+个连接。

操作系统的其他配置

三次握手里socket的全连接队列长度由参数net.core.somaxconn来控制，默认大小是128，当两台机器离的非常近，但是建立连接的并发又非常高时，可能会导致半连接队列或全连接队列溢出，进而导致server端丢弃握手包。然后造成client超时重传握手包（至少1s以后才会重传），导致三次握手连接建立耗时过长。我们可以调整参数net.core.somaxconn来增加去按连接队列的长度，进而减小丢包的影响
有时候我们通过 ctrl + c方式来终止了某个进程，但是当重启该进程的时候发现报错端口被占用，这种问题是因为【操作系统还没有来得及回收该端口，等一会儿重启应用就好了】
client程序在和server端建立连接时，如果client没有调用bind方法传入指定的端口，那么client在和server端建立连接的时候便会自己随机选择一个端口来建立连接。一旦我们client程序调用了bind方法传入了指定的端口，那么client将会使用我们bind里指定的端口来和server建立连接。所以不建议client调用bind方法，bind函数会改变内核选择端口的策略

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..........");  
}

在Linux一切皆文件，当然也包括之前TCP连接中说的socket。进程打开一个socket的时候需要创建好几个内核对象，换一句直白的话说就是打开文件对象吃内存，所以Linux系统基于安全角度考虑（比如：有用户进程恶意的打开无数的文件描述符，那不得把系统搞奔溃了），在多个位置都限制了可打开的文件描述符的数量。
内核是通过【hash表】的方式来管理所有已经建立好连接的socket，以便于有请求到达时快速的通过【TCP四元组】查找到内核中对应的socket对象。

在epoll模型中，通过红黑树来管理epoll对象所管理的所有socket，用红黑树结构来平衡快速删除、插入、查找socket的效率。

有关epoll模型的知识，请参考尼恩的《NIO学习圣经》